[Bug 675793] New: KMS broke traditional framebuffer modes
https://bugzilla.novell.com/show_bug.cgi?id=675793 https://bugzilla.novell.com/show_bug.cgi?id=675793#c0 Summary: KMS broke traditional framebuffer modes Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: x86 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader AssignedTo: jsrain@novell.com ReportedBy: mrmazda@earthlink.net QAContact: jsrain@novell.com Found By: --- Blocker: --- I think this has been going on since KMS went into 11.3M3 or so a year ago, but since I've been using mostly displays with missing/invalid EDID, I hadn't noticed. Pre-KMS one would normally one set e.g. vga=791 or vga=0x31a in order to get appropriate sizes of font, rows and columns on the virtual consoles, and use xorg.conf to configure the most appropriate mode for X. Now that I've added a display with valid EDID to my repertoire, I cannot achieve desired console configuration with these legacy framebuffer modes. That is, I want 0x305/791/0x317 on my consoles, which happen to be 1024x768 modes, but I want X to run in the display's best native mode, which is unlikely to be 1024x768 on currently available desktop displays, and also unlikely on any but the tiniest of laptops (aka netbooks). In the instant case of a UXGA (1600x1200) display, vga=791 (with splash=verbose and no quiet) on cmdline only produces 1024x768 on tty1 briefly, then KMS switches to a 1600x1200 mode. IOW, the switch that happens constitutes brokenness, as opposed to making this bug a new feature request. What does produce expected results, that is, 1024x768 on the ttys and 1600x1200 in X (via autoconfig aka no xorg.conf file), is to put video=1024x768 on cmdline instead of any of the vga modes in YaST's "Vga Mode" select list. YaST Bootloader needs to augment or supplant the available legacy framebuffer modes with selections using the KMS syntax. Probably the title "Vga Mode" should be changed somehow, possibly to "Virtual Console Video Mode", since what vga or video parameter on cmdline appears doesn't affect X at all, at least not when EDID is valid. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c1
Jiri Srain
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c2
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c3
--- Comment #3 from Jiri Srain
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c4
--- Comment #4 from Felix Miata
Yes, it sets only a single mode - which is primarily for the console.
It should be exclusively for console, correct?
The list of modes is always according to a detection.
Unless the video BIOS doesn't support VESA correctly (original G400 BIOS) or at all (i810 only has old PC 80 column text modes plus proprietary 132 column text modes), and, apparently now with KMS, when EDID is bad or missing.
For X, you can have different mode - I just don't see why this should be defined by bootloader - often you change the mode via applets as needed.
AFAICT, cmdline parameters should normally (e.g.: default menu.lst stanza, as opposed to failsafe) not affect what mode X can or does use on initialization, which is not always the current case if a traditional framebuffer mode is specified using vga=. Really, my head is swimming in confusion over this right now, so I can understand if you're having trouble too. Do I need to build a table of video chips, valid vs invalid EDID, and various cmdline parameter combinations in order to get this sorted? cf. https://bugzilla.kernel.org/show_bug.cgi?id=27922 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c5
--- Comment #5 from Jiri Srain
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c6
--- Comment #6 from Felix Miata
Felix, I don't think that you need to build the table. I guess most chips can provide their modes correctly, in case they cannot, there is a hardcoded list of modes as a fallback solution. If you miss some mode there, it can be extended.
Extended how and where?
See http://svn.opensuse.org/svn/yast/trunk/yast2/library/system/src/Initrd.ycp
Other than its list of known modes, it's virtually all gibberish to me. Conspicuously absent in the list of known modes are SXGA+ (4:3, which 5:4 SXGA is not) and _any_ widescreen modes, which means fallback usage on any modern display resulting from what that file does will never be to the native/best mode for that display to use. Shouldn't 1920x1200, 1920x1080, 1280x800 (the most common laptop mode prior to the marketers' switch from 16:10 to 16:9), 1680x1050, 1600x900, 1440x900, 1366x768, 1280x720 & 1024x640 at least be included there?
Except for that (and possibly changing the label in YaST), I still don't see what can be improbed here :-/
Even assuming you meant s/improbed/improved/, I'm not sure what you meant. by this statement. Did you mean to include an "else" in that sentence? Is provision for using "video=" syntax in Initrd.ycp somewhere? Don't yast2-bootloader and/or perl-Bootloader need changes? What happens if cmdline for installation includes video= parameter but "unspecified" is selected from the list in YaST? Maybe I just need to see the results of whatever you've done or plan to do before commenting further. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c7
--- Comment #7 from Jiri Srain
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c8
--- Comment #8 from Felix Miata
Sorry, but until I have a clear view what you find wrong, I cannot plan or do anything :-/
Formulating a competent response to this is proving to be more complex and time consuming than I could have imagined. I am working on it as time permits, but have no real idea how much more effort will be required. e.g., I spent the better part of yesterday and today figuring out 1600x1200, available semi-automatically on 11.0 via SaX2 and nv driver, via KMS and (default) nouveau on RIVA TNT 2 Model 64 (rev15) is impossible, which means nomodeset on cmdline is required, and thus video= for this (ancient but still usable and likely still abundant) video model is invalid. IOW, validity of video= and/or vga= on cmdline may be hardware and driver dependent, and an interface modification to include selection or not of nomodeset may be indicated. Some of my raw data gathering can be found on http://fm.no-ip.com/Tmp/SUSE/Xorg/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c9
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c10
--- Comment #10 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c12
--- Comment #12 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c13
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=675793
https://bugzilla.novell.com/show_bug.cgi?id=675793#c
Ihno Krumreich
participants (1)
-
bugzilla_noreply@novell.com