[PATCH xserver 4/4] xfree86: promote one GPU screen if (NumScreens == 0 && NumGPUScreens > 0)

Dave Airlie airlied at gmail.com
Mon Sep 5 22:32:01 UTC 2016


On 5 September 2016 at 22:39, Laszlo Ersek <lersek at redhat.com> wrote:
> On 09/04/16 11:01, Hans de Goede wrote:
>> HI,
>>
>> On 04-09-16 03:11, Laszlo Ersek wrote:
>>> Aarch64/KVM virtual machines cannot use emulated graphics cards with
>>> linear framebuffers, due to architectural cache coherency issues. (For
>>> this reason, "qemu-system-aarch64" doesn't even include the "virtio-vga"
>>> device model.)
>>>
>>> Such guests can use the "virtio-gpu-pci" device well, through the
>>> "modesetting" driver. However, given that "virtio-gpu-pci" is never
>>> recognized as a primary graphics card (which is otherwise correct,
>>> generally speaking),
>>
>> Why is this otherwise correct, generally speaking ? AFAIK virtio-gpu-pci
>> is needed for Virgil, so I would expect it to become the default graphical
>> card in vms in the future, or is that what virtio-vga is for ?
>
> Yes. Both virtio-vga and virtio-gpu-pci share the VirtIO GPU Device
> part, but only the former has the VGA compat stuff (incl. the legacy
> framebuffer), and only the former qualifies as "primary graphics card"
> at the moment.

Primary means the card the firmware/BIOS shows up on, and I understand
in ARM world that probably doesn't mean much as the firmware/BIOS might
not show up on any.

On x86 the primary GPU is the one the BIOS inits first, not the onboard,
you can usually pick in the BIOS what the GPU boot order is, and Linux uses
whatever is the VGA card as the primary to respect that.

So on aarch64/arm we could have the kernel pick one GPU is there is only
one and mark it as primary. I'm not sure if this would need device tree support
or not etc.

In the absence of policy from the kernel, I'd rather not put the policy in the X
server code itself. As boot probe ordering could mean we'd pick different
primaries on different boots if things raced which doesn't seem ideal.

So I'd really prefer we try and solve this kernel side first, but I realise that
might not be practical.

Dave.


More information about the xorg-devel mailing list