Description of problem: The f7/8t1 livecd when booted under qemu uses a resolution of 800x600. The ubuntu 7.04 livecd boots to a resolution of 1024x768. This seems much nicer. note- I'm just filing this bug for the record, as I may well be the person annoyed enough to figure it out and offer a patch. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
It's caused by a combination of things between X and qemu. 1) When no monitor EDID information is available, we default to 800x600 rather than 1024x768 to avoid blowing up monitors. It's rare, but can still happen. 800x600 is pretty safe for anything that still works 2) qemu doesn't export any EDID information via the emulated video card. Although partially this is because the cirrus adapters never supported it, so it'd be making something up An approach that ajax and I discussed but never did anything for was to change the PCI subvendor for the cirrus card emulated by qemu so that it would be detectable as such. And then change the driver to notice that and default to 1024x768 in that case. So that's probably the route to go for fixing it, if any.
Given that qemu is such a (fairly) common environment, would you be entirely against some less graceful special case detection, at least for the short term f8 timeframe? I.e. something in /etc/rc.d/init.d/fedora-live, which detects qemu (I don't know off the top of my head, but I'm sure there is an easy way), and then invokes it as such. The problem with what you described, even though it may be the 'best' fix in some sense, is that it won't help the case of an existing ubuntu-7.04 user, running the f8 livecd under their stock qemu, deciding if f8 might be worth further investigation. I'll explore this and submit a patch regardless. I think, that even though it is less elegant than what you suggested, that it would be a practical and valuable addition to f8, perhaps with the understanding that it is meant to be ripped out in the long term, when the more elegant solution has had sufficient time to propagate to other distributions.
note- my prior comment was thinking that what you said meant changing qemu (changing what pci id stuff it exposes for it's vga). If what you meant didn't involve any changes to qemu, but only changes to the xdriver, then clearly that gets me everything I want. (though if that is less than trivial, some short term easier hack like I described still seems valuable enough to me as a placeholder until the better solution is implemented)
The thing is that we should be getting _rid_ of the system-config-display invocation, not making it more complicated. X should just start up in a reasonable resolution with everything figured out on its own. We're 99% there, the final 1% should hopefully be landing for Fedora 8. So then there's not anything we can do in the initscript, it _has_ to be done in X And the problem with hacks is that they last forever. They're always done with the best of intentions, but killing them off takes far far far too long.
Since you didn't specifically answer my question, I'll assume that what you were saying did involve changing qemu. Under that assumption- I think that you are being a bit too averse to temporary hacks here. Believe me, after having looked at most of the anaconda code in recent months, I completely agree with with what you are saying, _in general_. But in _this case_, adding a few lines to /etc/rc.d/init.d/fedora-live, which detect qemu host, and then trigger forcing of 1024x768, and have big surrounding comments saying that these lines of code will be removed when the necessary qemu+xdriver mods have had 1-year to percolate to other distros, seems completely reasonable to me. Since this seems like a better forum for this aspect of the general debate (versus fueling flames on livecd-list), I'll add that this does seem to me to be an area where fedora/rh sacrifices market share to ubuntu for no good reason (yes your reasons are good, but there are good times to make exceptions, and this is one of them, because...) In my mind, and maybe I'm wrong here, having the F8 livecd, *look spectacular* when booting under qemu is very important. In the same way that booting under qemu is how I decide whether I should be tempted to switch to ubuntu, the reverse is true. In _this case_, is it _really_ so disgusting, to put a few, very isolated lines in /etc/rc.d/init.d/fedora-live, which would make the f8-livecd not look second-rate to ubuntu when booted under qemu? (and rereading your comment once more, just to make sure I'm not off in left field- I'm sure there must be some way, even with the f8 you envision, to be able to force the 1024x768 in this case, with a few lines of bash script, no?)
(bah, firefox crashed while I was writing... so this response might be shorter. also, back to livecd component) (In reply to comment #5) > Since you didn't specifically answer my question, I'll assume that what you were > saying did involve changing qemu. Under that assumption- To get the full and correct fix, yes. > But in _this case_, adding a few lines to /etc/rc.d/init.d/fedora-live, which > detect qemu host, and then trigger forcing of 1024x768, and have big surrounding > comments saying that these lines of code will be removed when the necessary > qemu+xdriver mods have had 1-year to percolate to other distros, seems > completely reasonable to me. Yeah, but the problem is when you do the hack without also making the correct changes; the correct changes then linger on and don't happen for a loonnnggg time because no one sees the problem. Also, I thought ajax was shooting for no xorg.conf (and death of system-config-display) for f8, but our quick discussion just now on IRC says "not likely". So, a few avenues 1) We can make the qemu changes so that there's a different subvendor ID and then make the X driver recognize that and default to 1024x768 when it's there. This is the long-term right thing but as you say, hurts the short-term of people using "existing" qemu builds 2) We can do the hack to make the cirrus driver just default to 1024x768 in the driver on the assumption no one is using that crappy hardware anymore. Maybe the ugliest option 3) We do the hack to look at pci ids and pass a resolution accordingly to system-config-display. Of course, we probably want more than just the qemu ones here... at least VMware comes to mind, potentially Parallels. 4) We do 1 and 3. 3 gets us the short-term, but 1 makes sure that its only a short-term thing by getting the right fixes upstream for future releases. 4 would make me feel significantly better about the fact that the hack is there
4 sounds great to me. If nobody else gets around to it first, I'll get a patch together for the 3 side in a while (weeks?), submit, and revise as par suggestions/criticisms/etc...
Cool. I've thrown together the simple patch to make the cirrus vga show up with a specific pci subsystem vendor id and sent to qemu-devel. It's at http://article.gmane.org/gmane.comp.emulators.qemu/18988.
Jeremy, you won't mind to get this bug, right?
Just a note on where I'm at with respect to this- For my own livecd's, I'm just using a pre-cooked xorg.conf, which I copy in place if grep -q "^QEMU" /sys/block/sda/device/model returns true (or /sys/block/sr0). I'm still trying to figure out how ubuntu-7.04 and debian-gnome-livecd accomplishes this. I'm stuck looking at dexconf, and the absence of xdebconfigurator. I suspect it is in a reconfigure script of the xorg package, but it's been too long since I've played with dpkg's... And my above hack works well enough for me.
Given that there are soon to be more disk adapters with qemu, I figured the better thing was keying off of the display adapter and just not worrying about real Cirrus hardware. The problem I ran into is that system-config-display's --set-resolution, --set-hysnc and --set-vsync options are now noops. There's another bug where I'm harassing ajax about that
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Re-opening this bug because it is still very much relevant to KVM, if not more so. 800x600 is just too small for real world usage, so we need to try & get the sub-vendor ID patches merged in KVM again & hook of that in the cirrus driver
With kvm-83 RPM that is in F11 rawhide all PCI devices now have a subsystem device ID assigned by Qumranet. lspci -vv 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA controller]) Subsystem: Qumranet, Inc. Device 1100 Physical Slot: 2 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M] Region 1: Memory at f2000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at <unassigned> [disabled] Kernel modules: cirrusfb lspci -vv -n 00:02.0 0300: 1013:00b8 (prog-if 00 [VGA controller]) Subsystem: 1af4:1100 Physical Slot: 2 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M] Region 1: Memory at f2000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at <unassigned> [disabled] Kernel modules: cirrusfb Is this sufficient for the xorg cirrus driver to hook onto and thus default to 1024x768 for KVM guests ?
Indeed it is. cirrus 1.2.0-6.fc11 will default to 1024x768. There's minor issues in going much bigger than that, so let me know if that's something we want to do.