+++ This bug was initially created as a clone of Bug #251264 +++ 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: --- Additional comment from katzj on 2007-08-07 20:04:14 EDT --- 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. --- Additional comment from jdogalt on 2007-08-08 01:37:26 EDT --- 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. --- Additional comment from jdogalt on 2007-08-08 01:50:21 EDT --- 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) --- Additional comment from katzj on 2007-08-08 11:35:12 EDT --- 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. --- Additional comment from jdogalt on 2007-08-08 16:43:39 EDT --- 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?) --- Additional comment from katzj on 2007-08-08 17:48:27 EDT --- (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 --- Additional comment from jdogalt on 2007-08-08 22:22:54 EDT --- 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... --- Additional comment from katzj on 2007-08-09 16:49:00 EDT --- 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. --- Additional comment from mcepl on 2007-08-15 12:59:37 EDT --- Jeremy, you won't mind to get this bug, right? --- Additional comment from jdogalt on 2007-09-19 01:21:34 EDT --- 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. --- Additional comment from katzj on 2007-09-19 07:23:30 EDT --- 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 --- Additional comment from fedora-triage-list on 2008-11-26 02:39:36 EDT --- 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 --- Additional comment from fedora-triage-list on 2009-01-09 02:12:05 EDT --- 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. --- Additional comment from berrange on 2009-02-24 06:08:15 EDT --- 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
So, this is the patch we want to re-submit: http://article.gmane.org/gmane.comp.emulators.qemu/18988
Yes, that's the patch, though it needs to be updated to use the official Red Hat / Qumranet PCI vendor ID, instead of the one Jeremy invented
All QEMU devices have sub device ID 0x1100, which is qemu-specific. Why isn't it necessary for X to test for it? Please enlighten me.
Hmm, this must be a new thing that came long fairly recently, because its not in the F10 kvm RPM I was looking at, but I see it in F11. So sounds like this would be sufficient for X to hook into.
Closing NOTABUG, since the subdevice ID is sufficient