[uae] Re: 8.28 and linux framebuffer
- From: Richard Drummond <evilrich@xxxxxxxxxxxxxx>
- To: uae@xxxxxxxxxxxxx
- Date: Mon, 22 Aug 2005 02:15:08 -0400
Hi Don
On Friday 19 August 2005 07:33 pm, Don Venhaus wrote:
> If the console buffer is at 640x480 ( for example ) and uae wants a 640x480
> buffer, it looks like it never really started, or sometimes it will be
> partially off the top of the screen. But switching consoles shows it
> properly. It's like the initial refresh just didn't happen. If uae wants a
> 800x600 size screen ( for example ), then it comes up fine.
I don't see this here, but SDL on the framebuffer device doesn't really work
very well either. I've tried Rage128, Radeon and Matrox fbdev, and they all
have issues.
AFAIK, the changes to the kernel framebuffer layer with kernel 2.6 broke SDL
on fbcon in many ways.
> > > Also, with 8-bit mode, colors are wacky.
> >
> > Define 'wacky'? ;-)
>
> Well, it's not in my dictionary! I guess I meant "not what you would
> expect", which is to say, wrong. The colors do change when I change the
> palette in prefs, but in wacky ways. Like the colors aren't being packed
> into the colortable properly.
This is due to 2.6 changes, I think. It seems to be than an application has to
restore the palette when you switch to the virtual terminal it's running on.
SDL should do this.
> Maybe this is the framebuffer code. ( behaviour is the same for 8.27 and
> 8.28 ). I'm using the matrox modules.
>
> One thing I've noticed is that if the chipset=aga, and the screen is
> 8-bits, you get a black screen. It can be confusing. Since you can't really
> do aga on an 8-bit screen, maybe you should just bail in that case.
Good point. Actually it could be supported by outputting in greyscale or via
some dithering method.
> > I just noticed how buggy that code really was.
>
> That makes me feel better. I thought I was losing it. :')
:-)
Cheers,
Rich
Other related posts:
