On 2013-01-22 18:27 (GMT-0500) Patrick Shanahan composed:

* Felix Miata composed:

...

On 2013-01-22 13:10 (GMT-0500) Patrick Shanahan composed:

...

...

yast bootloader (grub2) offers 1600x1200 tty size but this size does not work for logon screen or graphical interface. 1200x1080 does work.

...

Unless I'm misremembering, bootloader screens are video BIOS dependent. Does your video BIOS support 1600x1200? The highest standard VESA mode I recall is 1280x1024.

...

The same problem occurs when X/login manager is using VESA instead of chip dependent driver like Nouveau, Radeon or Intel.

Maybe 1280x1024 is maximum but grub2 is only achieving allocation of about 80% of screen realestate where my Tumbleweed boot screen fills the entire screen of a 1920x1200 screen with kernel params set to vga=0x307.

That probably means your Tumbleweed is starting up from Grub Legacy. With KMS kernels and Grub2, vga= has no purpose beyond the second or two between kernel load and KMS kickin. Maybe the proprietary NVidia drivers I never use still react to it as well.

And yast offers 1600x1200 in grub2 configuration. If not supported, what is the reason for offering it (and my gfxcard, nvidia GTS450, will support it).

Maybe it's one of more than a few unfixed YaST Grub2 support bugs, maybe as yet unfiled. Maybe something in http://forums.opensuse.org/english/get-technical-help-here/install-boot-logi... or http://www.gnu.org/software/grub/manual/ will help. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 23 Jan 2013 13:45, Robert Kaiser wrote:

Felix Miata schrieb:

...

With KMS kernels and Grub2, vga= has no purpose beyond the second or two between kernel load and KMS kickin. Maybe the proprietary NVidia drivers I never use still react to it as well.

Note that both the NVidia and ATI proprietary drivers AFAIK only work *without* KMS. Those companies seem to not be ready to support modern architectures and progress, they cling to last-millennium ways of doing things, at least software-wise. Or something like that. ;-)

Robert Kaiser

Please, see the full picture before blowing fecal matter in the rotating device. Look at it from the legal side: Are they (AMD/nVidia) allowed to use KMS in closed source drivers? The big stink this rised on the kernel mailing list can be found, if one seeks for it. Personally I dislike Grub-legacy and Grub2. Both are Bloat for what they should do. Something like Gummiboot for BIOS would be more to my taste. -- Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Jan 23, 2013 at 10:25 AM, Roger Oberholtzer wrote:

...

Look at it from the legal side:

Are they (AMD/nVidia) allowed to use KMS in closed source drivers?

I would imagine that the KMS code has the same license as the Linux kernel itself? And surely they use other parts of the Linux kernel. Why would KMS be any different?

Look it up. To make the long and confusing story short, linking to some functions is "allowed", and not others. There's a whole legal gray area surrouding closed source kernel modules, and nVidia is doing only very basic stuff in theirs, with most of their "closed source" stuff on user space GL libraries. Even that is considered gray. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

В Tue, 22 Jan 2013 18:27:13 -0500 Patrick Shanahan пишет:

* Felix Miata [01-22-13 15:16]:

...

On 2013-01-22 13:10 (GMT-0500) Patrick Shanahan composed:

...

yast bootloader (grub2) offers 1600x1200 tty size but this size does not work for logon screen or graphical interface. 1200x1080 does work.

Unless I'm misremembering, bootloader screens are video BIOS dependent. Does your video BIOS support 1600x1200? The highest standard VESA mode I recall is 1280x1024.

The same problem occurs when X/login manager is using VESA instead of chip dependent driver like Nouveau, Radeon or Intel.

Maybe 1280x1024 is maximum but grub2 is only achieving allocation of about 80% of screen realestate

I am a bit confused what you mean. Could you make a picture of it?

where my Tumbleweed boot screen fills the entire screen of a 1920x1200 screen with kernel params set to vga=0x307. And yast offers 1600x1200 in grub2 configuration. If not supported, what is the reason for offering it (and my gfxcard, nvidia GTS450, will support it).

and I prev mis-typed 1200x1080/sb/1280x1024.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-01-23 10:37 (GMT-0500) Patrick Shanahan composed:

http://wahoo.no-ip.org/~pat/80per_cent_screen.jpg http://wahoo.no-ip.org/~pat/100per_cent_screen.jpg

video= replaced vga= for using cmdline to set the mode on the ttys when running KMS kernels. With nomodeset on cmdline, vga= should still do what it used to do. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-01-23 11:20 (GMT-0500) Patrick Shanahan composed:

Felix Miata composed:

...

On 2013-01-23 10:37 (GMT-0500) Patrick Shanahan composed:

...

...

http://wahoo.no-ip.org/~pat/80per_cent_screen.jpg http://wahoo.no-ip.org/~pat/100per_cent_screen.jpg

What changed between those two screenshots?

...

video= replaced vga= for using cmdline to set the mode on the ttys when running KMS kernels. With nomodeset on cmdline, vga= should still do what it used to do.

Doesn't appear to make any diff 80%/100%,

Which video= string(s) did you try? Hardware installation, or VM, or both? Which video chip? Does it appear you get the desired mode at any time during init before X starts if you disable Plymouth (noplymouth on cmdline? and/or splash=verbose)?

still see same screen size/ratio. And adding "nomodeset" with or w/o different vga/video parameters also doesn't appear to change anything .... -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-01-23 23:31 (GMT-0500) Patrick Shanahan composed:

...

...

Doesn't appear to make any diff 80%/100%,

What does fbset -s report in the VM?

...

Which video= string(s) did you try?

video=1920x1200x16 is actual monitor size video=1600x1200x16

Did you find some authoritative doc that says either of those is valid? Try 'dmesg | grep video', and again after a restart with s/1200x16/1200@60/ or s/1200x16/1200/. Also if you haven't already tried it, skip video= and vga= both. If your EDID is good I would expect you (on hardware) to get 1920x1200 by default. On my NEC CRT with up to 2048x1536 supported via video=, including x16 or using no video= results here with M2 on Intel 945 chip in the CRT's PreferredMode=1600x1200. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-01-24 15:29 (GMT-0500) Patrick Shanahan composed:

* Felix Miata [01-24-13 00:39]:

...

On 2013-01-23 23:31 (GMT-0500) Patrick Shanahan composed:

...

...

...

Doesn't appear to make any diff 80%/100%,

What does fbset -s report in the VM?

from tty1 after booting w/o vga=/video= : mode "1280x1024-77" # D: 131.096 MHz, H: 80.328 kHz, V: 76.649 Hz geometry 1280 1024 1280 1024 32 timings 7628 160 32 16 4 160 4 rgba 8/16,8/8,8/0,8/24 endmode

...

...

...

Which video= string(s) did you try?

...

video=1920x1200x16 is actual monitor size video=1600x1200x16

Did you find some authoritative doc that says either of those is valid? Try 'dmesg | grep video', and again after a restart with s/1200x16/1200@60/ or s/1200x16/1200/.

did "dmesg |grep video" after each boot but only saw 1200 displayed in kernel boot line except when using 1600 and no video parameter was displayed.

none change the ~80% displayed text area, ttyX

From your response I don't believe you did what I was trying to get you to do, which is to recognize that video=1600x1200x16 is not consistent with the following syntax: video=<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd] to wit, only the first "x" is legal, resulting in the whole video= string being ignored. As potential proof, I offer the following output from two successive boots: ################################################### # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) # cat /etc/os-release | grep PRETTY PRETTY_NAME="openSUSE 12.3 Beta 1 (Dartmouth) (x86_64)" # cat /proc/cmdline root=LABEL=15susenext ipv4only=1 noresume splash=verbose vga=794 video=1152x864x16 3 # dmesg | grep video [ 0.000000] Command line: root=LABEL=15susenext ipv4only=1 noresume splash=verbose vga=794 video=1152x864x16 3 [ 0.000000] Kernel command line: root=LABEL=15susenext ipv4only=1 noresume splash=verbose vga=794 video=1152x864x16 3 [ 1.053082] pci 0000:00:02.0: Boot video device [ 6.696687] parse error at position 4 in video mode '1152x864x16' # fbset -s mode "1600x1200" geometry 1600 1200 1600 1200 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode ^^^^^^^^^ end boot 1 ################################################### begin boot 2 vvvvvvvvv # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) # cat /etc/os-release | grep PRETTY PRETTY_NAME="openSUSE 12.3 Beta 1 (Dartmouth) (x86_64)" # cat /proc/cmdline root=LABEL=15susenext ipv4only=1 noresume splash=verbose vga=794 video=1152x864-16 3 # dmesg | grep video [ 0.000000] Command line: root=LABEL=15susenext ipv4only=1 noresume splash=verbose vga=794 video=1152x864-16 3 [ 0.000000] Kernel command line: root=LABEL=15susenext ipv4only=1 noresume splash=verbose vga=794 video=1152x864-16 3 [ 1.053090] pci 0000:00:02.0: Boot video device # fbset -s mode "1152x864" geometry 1152 864 1152 864 16 timings 0 0 0 0 0 0 0 accel true rgba 5/11,6/5,5/0,0/0 endmode ###################################################

...

Also if you haven't already tried it, skip video= and vga= both. If your EDID is good I would expect you (on hardware) to get 1920x1200 by default. On my NEC CRT with up to 2048x1536 supported via video=, including x16 or using no video= results here with M2 on Intel 945 chip in the CRT's PreferredMode=1600x1200.

Samsung SyncMaster 2433bw

in vbox which provides it's own video (card/driver), see: http://wahoo.no-ip.org/~pat/vbox_video.jpg

note: /etc/fb.modes contains 1600x1200 (60,66,76).

I don't have a 1920x1200 LCD to try here, but if you can't get expected results using a legal video= string of your choice, I have to think you've hit a VM bug and/or a bug related to your gfxchip. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-01-24 16:49 (GMT-0500) Felix Miata composed:

...

from tty1 after booting w/o vga=/video= : mode "1280x1024-77" geometry 1280 1024 1280 1024 32

After some reflection on the above, I'm of the opinion that this is the behavior of better widescreen displays in their support of non-widescreen modes, which is to say aspect preserving, rather than stretching 4:3 and 5:4 modes to fill the output area.

Confirmed on http://www.samsung.com/my/consumer/pc-peripherals-printer/monitor/lcd-monito... -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-01-24 22:10 (GMT-0500) Patrick Shanahan composed:

answers, /etc/devault/grub set gfxpayload to 1600x1200 add to kernel boot param video=1600x1200x32

Doesn't that cause the following? # dmesg | grep parse [ #.######] parse error at position 4 in video mode '1600x1200x32' IOW, legal cmdline syntax would include video=1600x1200-32. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-01-24 23:18 (GMT-0500) Patrick Shanahan composed:

Felix Miata composed:

...

On 2013-01-24 22:10 (GMT-0500) Patrick Shanahan composed:

...

...

answers, /etc/devault/grub set gfxpayload to 1600x1200 add to kernel boot param video=1600x1200x32

...

Doesn't that cause the following? # dmesg | grep parse [ #.######] parse error at position 4 in video mode '1600x1200x32'

...

IOW, legal cmdline syntax would include video=1600x1200-32.

no, dmesg |grep parse has no output

Based on my testing logged at http://fm.no-ip.com/Tmp/Linux/cmdlinevideoequal.txt I have to think most people who actually need to use video= need to exclude that second "x" following "video=" on cmdline. Why with that x32 appendage instead of -32 you don't see "parse error at position 4 in video mode" grepping video in dmesg I can only speculate. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Patrick Shanahan [01-25-13 09:41]:

* Felix Miata [01-25-13 00:24]: [...]

...

Based on my testing logged at http://fm.no-ip.com/Tmp/Linux/cmdlinevideoequal.txt I have to think most people who actually need to use video= need to exclude that second "x" following "video=" on cmdline. Why with that x32 appendage instead of -32 you don't see "parse error at position 4 in video mode" grepping video in dmesg I can only speculate.

I am away from sub box atm, but will try booting with -32 and report.

It does indeed work with "-32" or "x32". -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Felix Miata [01-24-13 22:58]:

On 2013-01-24 22:10 (GMT-0500) Patrick Shanahan composed:

...

/etc/devault/grub set gfxpayload to 1600x1200 add to kernel boot param video=1600x1200x32 ... still both sides of screen are unused in both modes, at least in vbox.

Does fbset -s still report as follows in the VM?

from tty1 after booting w/o vga=/video= : mode "1280x1024-77" # D: 131.096 MHz, H: 80.328 kHz, V: 76.649 Hz geometry 1280 1024 1280 1024 32 timings 7628 160 32 16 4 160 4 rgba 8/16,8/8,8/0,8/24 endmode

fbset -s mode "1600x1200-77" # D: 192.012 MHz, H: 94.494 kHz, V: 77.201 Hz geometry 1600 1200 1600 1200 32 timings 5208 200 32 16 4 200 4 rgba 8/16,8/8,8/0,8/24 endmode dmesg|grep video [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.7.2-1-desktop root=/dev/mapper/system-root resume=/dev/system/swap splash=silent quiet showopts video=1600x1200x32 [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.7.2-1-desktop root=/dev/mapper/system-root resume=/dev/system/swap splash=silent quiet showopts video=1600x1200x32 [ 0.205145] pci 0000:00:02.0: Boot video device [ 9.028481] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0 and "yast bootloader" does not allow for setting "video=1600x1200x32" in /boot/grub2/grub.cfg, if fact left incomplete entries on the "linux" line but editing with nano appears to have stayed. At least I will know how to compensate if need be. tks for your help. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org