Thread (1 message) 1 message, 1 author, 2006-12-30

Re: Bug#389433: Probable fix for fbdev shadow framebuffer issues

From: Michel Dänzer <hidden>
Date: 2006-12-30 12:34:22

On Fri, 2006-12-29 at 13:04 +0000, Robert de Bath wrote: 
quoted
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.
FWIW, xf86-video-fbdev 0.3.1 defaults to 32.
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 don't know any way to determine that's the specific reason for the
FBIOPUT_VSCREENINFO ioctl failing. If there are any framebuffer devices
that accept 24 bpp but not 32 bpp, I guess the fbdev driver could check
for that, but I don't particularly feel like spending more time on this
right now.

quoted
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!)
X considers modes to be different even if only a single parameter
differs, so I've changed fbdevhw to report failure in that case in

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=f6815cb68b0f6698497348fc6e4214dacef33b95

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!
I don't understand what you're saying here, please elaborate.

quoted
...
But back to the beginning; the bug this report was opened for looks fixed 
to me.
Yes, so please follow up to the linux-fbdev-devel list (or another
appropriate place) only.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help