[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 <jsrain@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |mrmazda@earthlink.net --- Comment #1 from Jiri Srain <jsrain@novell.com> 2011-03-01 14:39:57 UTC --- Felix, to make sure, is there anything else except the label in YaST (VGA Mode) that you ask to be fixed? -- 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#c2 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|mrmazda@earthlink.net | --- Comment #2 from Felix Miata <mrmazda@earthlink.net> 2011-03-02 02:04:55 UTC --- Without a panoply of different LCDs to test, it's hard for me to be sure whether VGA and VIDEO always conflict when different modes are wanted on ttys and in X. With invalid EDID, VGA still works here as it used to. Possibly there should be separate lists for tty video and X video, even though one or the other may often fail to produce the desired results. I don't know what else to suggest, except for offering my collection of modes that exist various places in the wild on http://fm.no-ip.com/PC/displays.xhtml and http://fm.no-ip.com/PC/dpi.xhtml , nether of which I've populated as yet with 1600x900 as often found lately on smaller desktop panels and higher line laptops. -- 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#c3 --- Comment #3 from Jiri Srain <jsrain@novell.com> 2011-03-08 12:24:43 UTC --- Still, from your comment, I don't get what's wrong for bootloader. Yes, it sets only a single mode - which is primarily for the console. The list of modes is always according to a detection. 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. -- 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#c4 --- Comment #4 from Felix Miata <mrmazda@earthlink.net> 2011-03-08 14:43:04 UTC --- (In reply to comment #3)
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 <jsrain@novell.com> 2011-03-10 11:21:50 UTC --- 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. See http://svn.opensuse.org/svn/yast/trunk/yast2/library/system/src/Initrd.ycp Except for that (and possibly changing the label in YaST), I still don't see what can be improbed here :-/ -- 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#c6 --- Comment #6 from Felix Miata <mrmazda@earthlink.net> 2011-03-10 12:44:55 UTC --- (In reply to comment #5)
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 <jsrain@novell.com> 2011-03-11 08:05:40 UTC --- You are right that the list does not contain wide screen modes (they were not that popular when it was created - if they were used at all). On the other hand this is the first report of this issue in years, therefore I assume that failed detection of the modes is really rare. You can run 'hwinfo --framebuffer' as root to find whether the detection works for you. Sorry, but until I have a clear view what you find wrong, I cannot plan or do anything :-/ I can update the list of the fallback modes if you provide those missing and I can change the label. YaST can override the graphical mode which was passed to the kernel and save the one user selects (or even none), which will be effective on next boot. You can also type the code of the mode on your own - the combo box is editable. -- 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#c8 --- Comment #8 from Felix Miata <mrmazda@earthlink.net> 2011-03-19 22:02:04 UTC --- (In reply to comment #7)
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 <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Bootloader |Bootloader Product|openSUSE 11.4 |openSUSE 12.1 --- Comment #9 from Felix Miata <mrmazda@earthlink.net> 2011-06-09 03:34:56 UTC --- vga= on cmdline works at all with KMS kernels only for the virtual consoles, and only for two situations: 1-nomodeset or equivalent is necessarily also on cmdline (KMS disabled) 2-gfxchips unsupported by KMS (those other than AMD/Radeon, Intel, NVidia, e.g. RivaTNT, R128 or MGA) In contrast, for gfxchips supported by KMS, video= on cmdline may be appropriate: 1-if display EDID is unusable (consoles fall back to 1024x768 or less), or 2-if KMS mode choice produces console text size user deems inappropriate (too large, or worse but more common, too small) An example of #2 I run into repeatedly is use of a CRT that supports up to 2048x1536 but prefers mode 1600x1200. Even 1600x1200 produces unusably small text for my use. Absent an alteration of CONSOLE_FONT in /etc/sysconfig/console, the size I prefer requires video=1152x864 on cmdline if connected to a KMS-supported video chip. VGA= now represents a legacy option. If it is to be retained in YaST's boot loader section management, it should be accompanied by corresponding video= selections required for use with KMS-supported gfxchips to produce console video results comparable to legacy modes with non-KMS-supported chips. Going this route would mean the "VGA Mode" label would no longer be inappropriate. The best recommendation I can think of for a replacement would be "Virtual Console Video Mode". The select list could be populated with both types of modes. Alternatively, YaST could check if the gfxchip found is supported by KMS, and offer only video= modes if yes, and only vga= modes if not. An alternate route would be eliminating virtual console video mode management from YaST altogether, not what I would prefer. Yet another alternate might be a select list for a font to substitute for the default for CONSOLE_FONT, or a smallest, smaller, medium, larger, largest type list to choose from. Recent Fedora installations on my machines are including "SYSFONT=latarcyrheb-sun16" on Grub kernel lines, which looks to me like Fedora may be applying a CONSOLE_FONT-type route to managing virtual console text size. In any event, YaST should no longer preselect a vga= mode based upon the cmdline that started YaST's installation mode, nor necessarily strip one from "Optional Kernel Command Line Parameter" if one was used for installation, reason being that apparently the installation kernel is not KMS enabled, with the consequence that the desired cmdline video option for installation likely will be different from that desired for subsequent normal use. -- 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#c10 --- Comment #10 from Felix Miata <mrmazda@earthlink.net> 2011-08-01 16:29:04 UTC --- Proposed modified layout and behavior: Boot Loader Settings: Section Management Kernel Section Section Name [openSUSE 12.1 3.0.15-desktop ] Section Settings -------------------------------------------------------------- Kernel Image [/boot/vmlinuz ] |Browse| Initial RAM Disk [/boot/initrd ] |Browse| Root Device [LABEL=root121 ] |V| [ ] Do not verify filesystem before booting [ ] Enable SE Linux [ ] Disable Kernel Mode Setting [ ] Optional text console video [1920x1080] |V| Preferred Refresh [ ] |V| Optional kernel command line parameters [noresume splash=verbose acpi=off showopts ] ------------------------------------------------------------------------------- |Help| |Cancel| | Back | | OK | Behavior notes: 1-YaST checks in /proc to see if default gfxchip is supported by KMS a-not supported - disable kernel mode setting is preselected and immutable b-supported - optional console video is prefilled with EDID preferred mode 2-if section is predefined as failsafe, immutably preselect Disable KMS 3-console video select list is populated only by H#xV# types, not legacy framebuffer VGA= modes, YaST to specify video= or vga= on Grub lines to match select list choice according to whether or not KMS is enabled 4-optional text console video checkbox is never prefilled 5-possibly offer preferred colors in addition to preferred refresh. Barring that the mode select list could include both plain H#xV# as well as H#xV# with colors and/or refresh appendages. Comments: 1-scrap the following virtual anachronism (most now use Intel, ATI or NVidia): VGA Mode [ ] |V| 2-as long as installation kernel remains KMS disabled, installation cmdline vga= option(s) for video should not be prefilled here as they are currently. -- 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#c12 --- Comment #12 from Felix Miata <mrmazda@earthlink.net> 2012-03-05 17:22:49 UTC --- Upstream https://bugzilla.kernel.org/show_bug.cgi?id=27922#c3 resolved invalid: "This is not a bug, video= command line is only interpreted with kernel modesetting enabled. We don't support anymore non kernel modesetting case for radeon." -- 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#c13 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Bootloader |Bootloader Version|Factory |Milestone 2 Product|openSUSE 12.1 |openSUSE 12.2 --- Comment #13 from Felix Miata <mrmazda@earthlink.net> 2012-03-27 16:39:35 UTC --- As of 12.2M2, installation is still picking up any vga= used on installation cmdline, setting it as preselected in bootloader configuration, and setting that as DEFAULT_VGA in /etc/sysconfig/bootloader, even when KMS acceptably supports the installed gfxcard. -- 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#c Ihno Krumreich <ihno@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Other |openSUSE 12.2 -- 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.
participants (1)
-
bugzilla_noreply＠novell.com