[Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[Jeremy Katz]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
for the Cirrus emulation so that you can tell that the system is running
under qemu.  This will make it so that, eg, we can detect that in X and
know that resolutions > 800x600 won't blow up a monitor.

Downside is that it's not an officially registered vendor ID as it looks
like that requires joining the PCI-SIG.  Also, if this is interesting,
it's probably also worth doing for other emulated PCI devices as well.

Jeremy

[-- Attachment #2: qemu-vendor-subsystem.patch --]
[-- Type: text/x-patch, Size: 764 bytes --]

Index: hw/cirrus_vga.c
===================================================================
RCS file: /sources/qemu/qemu/hw/cirrus_vga.c,v
retrieving revision 1.26
diff -u -u -r1.26 cirrus_vga.c
--- hw/cirrus_vga.c	31 Jul 2007 23:26:00 -0000	1.26
+++ hw/cirrus_vga.c	9 Aug 2007 19:27:03 -0000
@@ -3247,6 +3247,11 @@
     pci_conf[0x0a] = PCI_CLASS_SUB_VGA;
     pci_conf[0x0b] = PCI_CLASS_BASE_DISPLAY;
     pci_conf[0x0e] = PCI_CLASS_HEADERTYPE_00h;
+#define SUBSYSTEM_VENDOR_QEMU 0x514D
+    pci_conf[0x2c] = (uint8_t) (SUBSYSTEM_VENDOR_QEMU & 0xff);
+    pci_conf[0x2d] = (uint8_t) (SUBSYSTEM_VENDOR_QEMU >> 8);
+    pci_conf[0x2e] = (uint8_t) (device_id & 0xff);
+    pci_conf[0x2f] = (uint8_t) (device_id >> 8);
 
     /* setup VGA */
     s = &d->cirrus_vga;

Re: [Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[Paul Brook]

On Thursday 09 August 2007, Jeremy Katz wrote:
> The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
> for the Cirrus emulation so that you can tell that the system is running
> under qemu.  This will make it so that, eg, we can detect that in X and
> know that resolutions > 800x600 won't blow up a monitor.

I'd rather not. If you want autodetection to work then implement vesa DDC 
emulation.

Paul

Re: [Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[Jeremy Katz]

On Fri, 2007-08-10 at 17:28 +0100, Paul Brook wrote:
> On Thursday 09 August 2007, Jeremy Katz wrote:
> > The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
> > for the Cirrus emulation so that you can tell that the system is running
> > under qemu.  This will make it so that, eg, we can detect that in X and
> > know that resolutions > 800x600 won't blow up a monitor.
> 
> I'd rather not. If you want autodetection to work then implement vesa DDC 
> emulation.

The Cirrus hardware never supported it, so it's basically going to be
making up all new code for the emulation, the drivers, etc.  For
basically dead end emulation, this seems a bit overkill.  Especially as
subsystem vendor/device ids are strongly recommended anyway by the PCI
spec (though not required)

Longer term, getting emulation of more capable video chipsets is the
better answer (including DDC or some of the stuff that the VMware SVGA
adapter supports for passing information back and forth).  

Jeremy

Re: [Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[Paul Brook]

On Friday 10 August 2007, Jeremy Katz wrote:
> On Fri, 2007-08-10 at 17:28 +0100, Paul Brook wrote:
> > On Thursday 09 August 2007, Jeremy Katz wrote:
> > > The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
> > > for the Cirrus emulation so that you can tell that the system is
> > > running under qemu.  This will make it so that, eg, we can detect that
> > > in X and know that resolutions > 800x600 won't blow up a monitor.
> >
> > I'd rather not. If you want autodetection to work then implement vesa DDC
> > emulation.
>
> The Cirrus hardware never supported it, so it's basically going to be
> making up all new code for the emulation, the drivers, etc.

My sources say otherwise.
The current Xorg cirrus driver clearly has DDC (aka i2c) support, and there's 
a patch for linux framebuffer support here: http://lkml.org/lkml/2006/7/4/230

qemu already have a generic i2c framework, and i2c EEPROM devices (used to 
hold the EDID), so all you need to implement is the cirrus host bits.
It's not entirely trivial as the card sees to just expose the raw signal 
lines. However i2c is fairly straightforward, so it shouldn't be that hard to 
implement.

Paul

Re: [Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[Anthony Liguori]

Jeremy Katz wrote:
> On Fri, 2007-08-10 at 17:28 +0100, Paul Brook wrote:
>   
>> On Thursday 09 August 2007, Jeremy Katz wrote:
>>     
>>> The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
>>> for the Cirrus emulation so that you can tell that the system is running
>>> under qemu.  This will make it so that, eg, we can detect that in X and
>>> know that resolutions > 800x600 won't blow up a monitor.
>>>       
>> I'd rather not. If you want autodetection to work then implement vesa DDC 
>> emulation.
>>     
>
> The Cirrus hardware never supported it, so it's basically going to be
> making up all new code for the emulation, the drivers, etc.  For
> basically dead end emulation, this seems a bit overkill.  Especially as
> subsystem vendor/device ids are strongly recommended anyway by the PCI
> spec (though not required)
>
> Longer term, getting emulation of more capable video chipsets is the
> better answer (including DDC or some of the stuff that the VMware SVGA
> adapter supports for passing information back and forth).  
>   

QEMU already supports the VMware SVGA adapter nicely but the issue is 
that AFAIK the Windows driver is not licensed in such a way that it 
could be utilized for QEMU.

I suspect our best long term bet is a new paravirtual graphics driver 
that's also a standard VESA device and the hope that someone writes a 
proper Windows driver for it.

Regards,

Anthony Liguori

> Jeremy
>
>
>
>
>   

Re: [Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[WaxDragon]

On 8/10/07, Anthony Liguori <anthony@codemonkey.ws> wrote:

> I suspect our best long term bet is a new paravirtual graphics driver
> that's also a standard VESA device and the hope that someone writes a
> proper Windows driver for it.
>
> Regards,
>
> Anthony Liguori
>

Too bad we don't know of any open source OS projects that would be
interested in having a "proper windows driver" for this card-to-be.

*cough*ReactOS*cough*

WD
-- 
22:38 <@WaxDragon> false ^ true
22:39 < false> :(
22:39 < false> dont you think you can XOR me and get away with it! I
always return!

Re: [Qemu-devel] [PATCH/RFC] Set a (distinguishable) subsystem id for Cirrus VGA

[andrzej zaborowski]

On 10/08/07, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Jeremy Katz wrote:
> > On Fri, 2007-08-10 at 17:28 +0100, Paul Brook wrote:
> >
> >> On Thursday 09 August 2007, Jeremy Katz wrote:
> >>
> >>> The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
> >>> for the Cirrus emulation so that you can tell that the system is running
> >>> under qemu.  This will make it so that, eg, we can detect that in X and
> >>> know that resolutions > 800x600 won't blow up a monitor.
> >>>
> >> I'd rather not. If you want autodetection to work then implement vesa DDC
> >> emulation.
> >>
> >
> > The Cirrus hardware never supported it, so it's basically going to be
> > making up all new code for the emulation, the drivers, etc.  For
> > basically dead end emulation, this seems a bit overkill.  Especially as
> > subsystem vendor/device ids are strongly recommended anyway by the PCI
> > spec (though not required)
> >
> > Longer term, getting emulation of more capable video chipsets is the
> > better answer (including DDC or some of the stuff that the VMware SVGA
> > adapter supports for passing information back and forth).
> >
>
> QEMU already supports the VMware SVGA adapter nicely but the issue is
> that AFAIK the Windows driver is not licensed in such a way that it
> could be utilized for QEMU.

I believe Ms Windows now ships with the VMware SVGA driver of its own.
For reactOS the X driver should be partially reusable.

Regards,
Andrzej (away until mid-September(?))