Framebuffer mode setting
We're not clear how mode selection works for framebuffer. The file /etc/fb.modes lists many modes. We want 1280x1024-60. The choice matches a vendor 'preferred timing mode' for optimal monitor performance. We run this mode in X fine.
The problem is framebuffer. We do not get how to ask grml for 1280x1024-60. No fbset commands or lilo configs seem to do it. We get, instead, 1280x1024-77 or some other unexpected v-refresh, not even listed in fb.modes.
We tried a 'special name' for mode 1280x1024-60 to work with lilo commands and it also failed. (Actually we made a duplicate mode with a different name in fb.modes.)
The grml 0.9 live CD also does something weird. We boot 'grml fb1280x1024' but end up with lower resolution framebuffer, 1024x768. It seems that grml cheatcodes do not allow arbitrary selection from fb.modes, but only 3.
We cannot rely on automatic mode selection. We need to state the modes we want. We use KVMs quite a bit, which ruin DDC queries to monitor firmware, and also we run LCDs on analog video, not digital. This combination works fine in the right driving mode.
Thanks, Mark
* Mark 27e3kk302@sneakemail.com [20061214 02:15]:
The grml 0.9 live CD also does something weird. We boot 'grml fb1280x1024' but end up with lower resolution framebuffer, 1024x768. It seems that grml cheatcodes do not allow arbitrary selection from fb.modes, but only 3.
As stated in bootsplash "f3" you have to use fb1280x1024 as the main image name and not as additional bootoption (as you are triggering kernel and not userspace part).
So either boot using 'fb1280x1024' or boot with 'grml vga=794'.
regards, -mika-
As stated in bootsplash "f3" you have to use fb1280x1024 as the main image name
Sorry for a typo, my fault. That gives 1280x1024 but not 60 Hz v-refresh. Instead it gives a mode not even listed in /etc/fb.modes, 1280x1024-77 Hz, so fbset --show claims. We want the framebuffer to match the X11 mode - vendor recommended settings.
We have 60 Hz 1280x1024 full color in X, but not framebuffer. Somehow grml/framebuffer is doing its own thing out of our control.
This problem matters - switching between framebuffer and X11, monitor firmware settings can be optimized for one mode only, not two. We lose readability in framebuffer. Also we want slower for KVM signal degradation, besides what the vendor says is best.
We've tried fbset, lilo, all kinds of stuff, nothing seems to work...but I'm no expert in framebuffer...yes I know that vrefresh is meaningless for LCDs but not quite. The monitor will auto-self-adjust if it detects this particular timing, and that's very helpful to us. So we're trying to RTFM and follow vendor instructions here.
Mark
Here's the framebuffer mode from /etc/fb.modes. We did not create it; this mode came from the default file.
mode "1280x1024-60" # D: 108.00 MHz, H: 63.981 kHz, V: 60.02 Hz geometry 1280 1024 1280 1024 8 timings 9260 248 48 38 1 112 3 hsync high vsync high endmode
The mode currently reported by fbset is
mode "1280x1024-77" # D: 131.096 MHz, H: 80.328 kHz, V: 76.649 Hz geometry 1280 1024 1280 2048 8 timings 7628 160 32 16 4 160 4 rgba 8/0,8/0,8/0,8/0 endmode
...which does not exist in /etc/fb.modes or the vendor list. Is it compiled into grml? How can we get 1280x1024-60? Everything we try fails.
Here is a (German) link to the monitor & manual. Page 50 lists vendor preferred modes. http://www.samsung.com/at/products/monitors/tftmonitors/971p.asp
Mark
Well, we have now learned more about framebuffer. The puzzle arose from assuming that Linux offers modern video support. True in general, but wrong assumption here.
VBE 3.0 is 8 years old. Linux still has no VBE 3.0 support in vesafb. Vesafb is a VBE 2.0 driver. Two years ago they were talking about it: http://lkml.org/lkml/2004/10/18/143
VBE 2.0 uses fixed modes which are either compiled into the kernel, or assumed some other way. (I'm not clear.) Without VBE 3.0 calls, the video board cannot tell the kernel more than it assumes. We have VBE 3.0 boards like everyone else today. We do not have a VBE 3.0 framebuffer driver.
So, "just drop vesafb and use another framebuffer driver." Guess what, nVidia framebuffer conflicts with nVidia X11 driver. Do you have another suggestion that will not conflict with nVidia X11? The only one we know is vesa-tng.
All we can hope is that grml returns to vesa-tng (because the bugs are gone now?) or Linux brings vesafb up to date after 8 years.
If someone wishes to correct/inform/educate/tip us in some way, thank you, please do.
Mark
Teilnehmer (2)
-
Mark -
Michael Prokop