This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 251264 - xorg should use 1024x768 for kvm/qemu cirrus card
xorg should use 1024x768 for kvm/qemu cirrus card
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-cirrus (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 487118
  Show dependency treegraph
 
Reported: 2007-08-07 19:27 EDT by Jane Dogalt
Modified: 2013-01-09 23:23 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 487118 (view as bug list)
Environment:
Last Closed: 2009-02-27 12:01:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jane Dogalt 2007-08-07 19:27:40 EDT
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:
Comment 1 Jeremy Katz 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. 
Comment 2 Jane Dogalt 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.
Comment 3 Jane Dogalt 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)
Comment 4 Jeremy Katz 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. 
Comment 5 Jane Dogalt 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?)
Comment 6 Jeremy Katz 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
Comment 7 Jane Dogalt 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...

  
Comment 8 Jeremy Katz 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. 
Comment 9 Matěj Cepl 2007-08-15 12:59:37 EDT
Jeremy, you won't mind to get this bug, right?
Comment 10 Jane Dogalt 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.
Comment 11 Jeremy Katz 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
Comment 12 Bug Zapper 2008-11-26 02:39:36 EST
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
Comment 13 Bug Zapper 2009-01-09 02:12:05 EST
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.
Comment 14 Daniel Berrange 2009-02-24 06:08:15 EST
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
Comment 15 Daniel Berrange 2009-02-27 06:39:51 EST
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 ?
Comment 16 Adam Jackson 2009-02-27 12:01:10 EST
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.

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