Bug 487118

+++ 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