Bug#389433: Probable fix for fbdev shadow framebuffer issues
That's bug #338241. I'm pondering changing the fbdev driver to default
to 32bpp though.
Well I suppose 32bpp is more likely with modern hardware.
Still even if you can't easily get fb_var_screeninfo.bits_per_pixel as
your default a big fat warning that they don't match and how to fix it
would be in order IMO.
I noticed that, but it's more likely a bug in vesafb. As the log
indicates, the fbdev driver actually queries the framebuffer device on
the usability of each mode.
I've had a look at the kernel code ...
Well it seems that the vesafb doesn't have an fb_check_var function to
call so the FBIOPUT_VSCREENINFO ioctl is defined by fbmem.c to be the
same as FBIOGET_VSCREENINFO.
This is actually reasonable, it's trying to tell you the closest mode
to the one you asked for. But X will have to check that the mode it gets
back is "the same" as the one it asked for and reject it if not.
(Especially if the returned mode is SMALLER than the request!)
Most of the kernel fb drivers seem to be reasonably lax in what they
accept as a mode request (those that can change the mode) and so I
think this will definitly be a "working as designed" for the kernel.
Also the TEST function doesn't look like it's implemented properly in
all the drivers; I'd make sure you 'GET' the original setup and 'TEST'
it after you've tested all your configured modes!
...
But back to the beginning; the bug this report was opened for looks fixed
to me.
--
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.debath.co.uk/>
Reply to: