On Wed, 2007-07-11 at 14:34 -0400, John David Anglin wrote: > > It could also indicate a broken framebuffer device. John, which one are > > you using? > > HP VisEG.
[...] > (II) FBDEV(0): hardware: stifb (video memory: 2048kB) > (II) FBDEV(0): checking modes against framebuffer device... > (II) FBDEV(0): mode "1280x1024" test failed > (II) FBDEV(0): checking modes against monitor... > (--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280) > (**) FBDEV(0): Built-in mode "current": 28000.0 MHz, 21875.0 kHz, 21362.3 Hz > (II) FBDEV(0): Modeline "current" 28000.00 1280 1280 1280 1280 1024 > 1024 1024 1024 -hsync -vsync -csync [...] > (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode > (EE) FBDEV(0): mode initialization failed Basically, the problem is that the framebuffer device doesn't accept the mode unchanged - the very same mode it reports as currently being programmed. This could be related to the patch pointed out, but I'd argue that even if the framebuffer device doesn't know or care about the pixel clock, it could just leave the requested one unchanged. So I'd consider this a bug in stifb. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
