Bug#389433: Probable fix for fbdev shadow framebuffer issues
On Fri, 2006-12-29 at 13:04 +, Robert de Bath wrote: 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. 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. ... 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
Bug#389433: Probable fix for fbdev shadow framebuffer issues
On Thu, 2006-12-28 at 21:15 +, Robert de Bath wrote: I still need to add the -fbbpp 32 option (or it's xorg.conf equiv). Without the option (and no rotation) the screen is now the full height but 'squished' into the left three quarters of the display (with nasty colours). I would say it's got a correct bytes per line but is encoding the pixels as 24bit not 32. That's bug #338241. I'm pondering changing the fbdev driver to default to 32bpp though. One other oddity is that it seems to be saying that the 640x480 mode is acceptable; but AFAIK the kernel vesa fbdev driver cannot change the video mode on the fly so only the 800x600x32 mode that the fb is currently set to on boot is actualy used ... 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. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
