[Qemu-devel] emulating a display, instead of just a dumb graphics card

[Qemu-devel] emulating a display, instead of just a dumb graphics card

[Olaf Hering]

Right now qemu does appearently just emulate a graphics card (Cirrus for
example), but not an attached monitor/display. The result is confusion
in the guest OS. 

The current DRM drivers in upstream Linux seem to default to VESA modes.
These are either provided by qemu, or Xorg uses a fixed internal list.
As a result the VM window is 1280x960. Much too large for my native
display.

It seems qemu does not provide a virtual display with valid EDID data.
If it would start doing that, the host admin could force a certain
display size. Ideally also with proper DPI data.

Any idea if thats possible to implement?


Olaf

Re: [Qemu-devel] emulating a display, instead of just a dumb graphics card

[Markus Armbruster]

Olaf Hering <olaf@aepfle.de> writes:

> Right now qemu does appearently just emulate a graphics card (Cirrus for
> example), but not an attached monitor/display. The result is confusion
> in the guest OS. 
>
> The current DRM drivers in upstream Linux seem to default to VESA modes.
> These are either provided by qemu, or Xorg uses a fixed internal list.
> As a result the VM window is 1280x960. Much too large for my native
> display.
>
> It seems qemu does not provide a virtual display with valid EDID data.
> If it would start doing that, the host admin could force a certain
> display size. Ideally also with proper DPI data.
>
> Any idea if thats possible to implement?

Not an expert in this area, but I can't see why it would be impossible.
Patches welcome.

Re: [Qemu-devel] emulating a display, instead of just a dumb graphics card

[Gerd Hoffmann]

On Do, 2014-03-27 at 10:57 +0100, Markus Armbruster wrote:
> Olaf Hering <olaf@aepfle.de> writes:
> 
> > Right now qemu does appearently just emulate a graphics card (Cirrus for
> > example), but not an attached monitor/display. The result is confusion
> > in the guest OS. 
> >
> > The current DRM drivers in upstream Linux seem to default to VESA modes.
> > These are either provided by qemu, or Xorg uses a fixed internal list.
> > As a result the VM window is 1280x960. Much too large for my native
> > display.

The kernel has a mode list.  cirrusdrm used to default to the largest
possible video mode, which is stupid and has been fixed meanwhile.  It's
1024x748 now.

> > It seems qemu does not provide a virtual display with valid EDID data.
> > If it would start doing that, the host admin could force a certain
> > display size. Ideally also with proper DPI data.
> >
> > Any idea if thats possible to implement?
> 
> Not an expert in this area, but I can't see why it would be impossible.
> Patches welcome.

qxl can already signal the size of the display(s) to the guest.  Where
"display size" == "spice client window size".  But it doesn't use edid
for that.

Simliar capabilities are planned for virtio-gpu.

Not sure it is possible with cirrus.  The hardware is pretty old, might
be it predates edid ...

stdvga is essentially paravirtual too (when it comes to capabilities
beyond standard vga stuff) and has no interface to communicate preferred
display size or edid blobs to the guest (yet?).

cheers,
  Gerd

Re: [Qemu-devel] emulating a display, instead of just a dumb graphics card

[Laszlo Ersek]

On 03/27/14 13:40, Gerd Hoffmann wrote:
> On Do, 2014-03-27 at 10:57 +0100, Markus Armbruster wrote:
>> Olaf Hering <olaf@aepfle.de> writes:
>>
>>> Right now qemu does appearently just emulate a graphics card (Cirrus for
>>> example), but not an attached monitor/display. The result is confusion
>>> in the guest OS. 
>>>
>>> The current DRM drivers in upstream Linux seem to default to VESA modes.
>>> These are either provided by qemu, or Xorg uses a fixed internal list.
>>> As a result the VM window is 1280x960. Much too large for my native
>>> display.
> 
> The kernel has a mode list.  cirrusdrm used to default to the largest
> possible video mode, which is stupid and has been fixed meanwhile.  It's
> 1024x748 now.
> 
>>> It seems qemu does not provide a virtual display with valid EDID data.
>>> If it would start doing that, the host admin could force a certain
>>> display size. Ideally also with proper DPI data.
>>>
>>> Any idea if thats possible to implement?
>>
>> Not an expert in this area, but I can't see why it would be impossible.
>> Patches welcome.
> 
> qxl can already signal the size of the display(s) to the guest.  Where
> "display size" == "spice client window size".  But it doesn't use edid
> for that.
> 
> Simliar capabilities are planned for virtio-gpu.
> 
> Not sure it is possible with cirrus.  The hardware is pretty old, might
> be it predates edid ...
> 
> stdvga is essentially paravirtual too (when it comes to capabilities
> beyond standard vga stuff) and has no interface to communicate preferred
> display size or edid blobs to the guest (yet?).

Most fb drivers (in the Linux guest) take a resolution hint from the
kernel command line; the parameter goes like video=1024x768. This
influences the character console, and also the Xorg display resolution,
if the Xorg driver is "fbdev" (and no other resolution is specified in
the X config file).

As far as I remember:
- cirrusdrmfb adheres to "video=...",
- so does "bochsdrmfb",
- so does "qxldrmfb",
- "efifb" does not, it simply inherits the resolution from the UEFI GOP,
but efifb is always kicked off by the drmfb driver that is specific to
the hardware (unless the latter is blacklisted); hence the resolution of
efifb has no practical significance. Usually.

If Xorg uses the "modesetting" driver, then the Xorg GUI resolution must
me specified spearately in the X config file (it's independent of the
*drmfb char console resolution).

The following is about the only fedoraproject wiki article I authored --
this problem used to drive me nuts:

https://fedoraproject.org/wiki/Display_resolution_of_Fedora_18_virtual_machines

Hope this helps somewhat.
Laszlo