Bug 858270 - 'Basic graphics mode' relies on specifying a fallback driver (vesa), should rather ask X to perform a system/firmware-appropriate fallback
Summary: 'Basic graphics mode' relies on specifying a fallback driver (vesa), should r...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker RejectedNTH
Depends On:
TreeView+ depends on / blocked
Reported: 2012-09-18 13:37 UTC by Kamil Páral
Modified: 2013-12-10 00:13 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-12-09 17:34:13 UTC
Type: Bug

Attachments (Terms of Use)
Xorg.0.log with xdriver=vesa (9.47 KB, text/plain)
2012-10-30 20:24 UTC, nucleo
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 855824 0 unspecified CLOSED vesa driver is not used in virtual machines 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 977816 0 unspecified CLOSED Safe graphics mode missing for Live UEFI 2021-02-22 00:41:40 UTC

Internal Links: 855824 977816

Description Kamil Páral 2012-09-18 13:37:34 UTC
Description of problem:
If I install system using 'basic graphics mode', vesa is forced through nomodeset (that is correct), but not through Xorg conf file (that is not correct). There is no xorg.conf file and no related conf file neither in xorg.conf.d/.

See this discussion:

Version-Release number of selected component (if applicable):
F18 Alpha

How reproducible:

Steps to Reproduce:
1. follow https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver

Comment 1 Kamil Páral 2012-09-18 13:39:03 UTC
Proposing as Beta blocker:
" The boot menu for all installation images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer and attempting to use the generic driver "

Comment 2 Adam Jackson 2012-09-18 14:20:26 UTC
I'm not entirely convinced.

vesa isn't the correct fallback driver in all cases.  On UEFI systems vesa simply won't work, and in that scenario an xorg.conf that explicitly requests vesa will result in X not launching at all.  Given that UEFI systems are expected to be the vast majority of new hardware over F18's lifespan, setting them up to fail seems like a bad idea.

Which actually suggests that "Basic graphics mode" may already be broken for UEFI.

xserver doesn't currently have a way to express "skip your native driver detection and just give me the platform-appropriate fallback", but it's not hard to add.  I'd rather see that than more X knowledge in anaconda.

Comment 3 Adam Williamson 2012-09-26 18:58:28 UTC
ajax: well, the behaviour described in the thread and the test case is what the current code is actually supposed to do, and what happened in the past. the fact that it isn't actually happening is clearly a bug.

but i'd be fine if we want to decide that instead of fixing the current intended behaviour, we should change the intended behaviour to 'tell X to force correct fallback', implement that on the X side, and fix anaconda/live boot to do that when using the 'basic graphics mode' boot option.

Comment 4 Adam Williamson 2012-09-26 19:12:41 UTC
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . This is rejected as a blocker because, though the absence of the xorg.conf.d snippet is clearly a bug, it has few practical consequences. The 'basic graphics driver' option also causes the 'nomodeset' kernel parameter to be passed at boot time. These days, virtually all X drivers (and all for common hardware) no longer have UMS code. So if you boot with KMS disabled (which is what nomodeset does), these drivers will not work, and X will wind up falling back to vesa anyway. Practically speaking, just passing 'nomodeset' is enough to cause the fallback driver to be used in almost all cases, so we don't think this bug needs to block the Beta release. The bug is also rejected as NTH: the changes to fix it are likely not trivial, and the fix would have little practical consequence, as described above, so it's not appropriate for NTH status. It should be fixed outside of freeze.

Comment 5 nucleo 2012-10-30 20:15:24 UTC
I tested F18 live image on system with gma3600 but X server fails to start because it tries to load intel driver instead of modesetting.
So I tried xdriver=modesetting and xdriver=vesa kernel parameters but X server still tries to use intel driver.

Comment 6 nucleo 2012-10-30 20:24:00 UTC
Created attachment 635778 [details]
Xorg.0.log with xdriver=vesa

Comment 7 Adam Williamson 2012-10-30 21:58:16 UTC
As discussed earlier in this bug, the 'basic graphics mode' option should at least get you booted. Did you try that?

Comment 8 nucleo 2012-10-30 22:28:08 UTC
I selected "Started Fedora 18 in basic graphics mode" but X fails to start with almost the same log as in Comment 6. Only nomodeset parameter added to xdriver=vesa.

Comment 9 Adam Williamson 2012-10-30 22:33:24 UTC
Ah. I think X's autodetection code needs an exception to *not* try and load the intel driver for this adapter. I'm assuming it already has exceptions for older Poulsbo-type adapters.

Comment 10 Adam Williamson 2013-06-25 16:43:03 UTC
ajax: so, uh, any chance we might get around to doing what you said would be pretty easy in comment #2, any time this year? :) Be nice to finally have this fixed for F20.

Comment 11 Adam Jackson 2013-12-09 17:34:13 UTC
At this point 'nomodeset' on kcmdline should be all you need to say, since we basically don't support non-KMS drivers anymore.

Comment 12 Adam Williamson 2013-12-09 19:38:50 UTC
that is how we've set up F20, unless I missed any paths; all 'basic graphics mode' options should now simply pass 'nomodeset' and nothing more.

Comment 13 nucleo 2013-12-09 20:34:13 UTC
When running live image in vmware xdriver=vesa really forces X server to use vesa, but with nomodeset X server uses vmware driver, so nomodeset in this case not equal xdriver=vesa.

Comment 14 Adam Williamson 2013-12-10 00:13:16 UTC
yeah, it may be the same in other virt environments, but then fallback graphics rarely makes any actual sense for use in virt, so it doesn't seem like a big issue.

Note You need to log in before you can comment on or make changes to this bug.