qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] emulating a display, instead of just a dumb graphics card
Date: Thu, 27 Mar 2014 14:09:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 03/27/14 13:40, Gerd Hoffmann wrote:
> On Do, 2014-03-27 at 10:57 +0100, Markus Armbruster wrote:
>> Olaf Hering <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]