On 07/25/17 17:56, Gabriele Paoloni wrote:

Hi Laszlo

[...]

quoted

Having practically zero background in gfx development (either kernel or
Xorg), I think the problem is that vga_default_device() /
vga_set_default_device(), which -- apparently -- "boot_vga" is based
upon, come from "drivers/gpu/vga/vgaarb.c". Namely, the concept of
"primary / boot display device" is tied to the VGA arbiter, plus only a
PCI device can currently be marked as primary/boot display device.

Can these concepts be split from each other? (I can fully imagine that
this would result in a userspace visible interface change (or
addition),
so that e.g. "/sys/devices/**/boot_gpu" would have to be consulted by
display servers.)

(Sorry if I'm totally wrong.)

... Hm, reading the thread starter at
<https://www.mail-archive.com/linuxppc-
dev at lists.ozlabs.org/msg120851.html>,
and the references within... It looks like this work is motivated by
hardware that is supposed to be PCI, but actually breaks the specs. Is
that correct? If so, then I don't think I can suggest anything useful.

My understanding is that the current PCIe HW is specs compliant but the
vgaarb, in order to make a VGA device the default one, requires all the
bridges on top of such device to have the "VGA Enable" bit set (optional
bit in the PCI Express? to PCI/PCI-X Bridge Spec). I.e. all the bridges
on top have to support legacy VGA devices; and this is not mandatory
from the specs...right?

Sounds very plausible to me. And, I guess if the "boot GPU" concept were
split from the VGA arbiter, then the VGA arbiter's above requirement
(a) would not have to be disturbed, and
(b) would no longer interfere with the kind of hardware that's being
    discussed.

Thanks
Laszlo

BTW my VGA experience is limited too...this is just my understanding...

Gab

quoted

Specs exist so that hardware vendors and software authors follow them.
If hardware does not conform, then software should either refuse to
work
with it, or handle it with quirks, on a case-by-case basis. I guess
this
means that I don't agree with the

  broad[] suggest[ion] that a more generic solution would be better

which seems to disqualify me from the discussion, as it must have been
suggested by people with incomparably more experience than what I have
:)

Thanks
Laszlo