[PATCH 1/3] drm: add connector info/property for non-std displays

[Daniel Stone]

Hi,

On 19 October 2017 at 17:27, Keith Packard <keithp at keithp.com> wrote:
> Daniel Stone <daniel at fooishbar.org> writes:
>> Why not add a client cap which hides 'non-standard' displays
>> completely from non-aware clients? That way you can keep the connected
>> status as is, and clients either never see the HMD or will be able to
>> check the property.
>
> Most clients are display servers, and it looks like we're settling on
> using the display server as the way to enumerate all of the displays (as
> direct enumeration through DRM non-master FDs involve rather drastic
> permissions changes in the kernel).
>
> This means that display servers are going to have to change to both see
> these displays while keeping them from being part of the desktop. So,
> while I guess it might be useful to hide HMD from existing display
> servers with a bit like this, I don't think there's any particular
> long-term benefit?

I totally agree with you. On the other hand, this gives symmetry to
making sure we don't put fbcon into someone's retinas: if we're doing
that, why not also hide it from legacy userspace which isn't going to
be aware of HMD characteristics?

The display server enumeration/lease model means that display servers
are still going to have to be explicitly aware of HMDs, so somehow
hiding them from legacy display servers makes about as much sense as
hiding fbcon. Assuming we do have the database in the kernel.

>> Either way, I'm still not convinced doing this in the kernel makes any
>> sense.
>
> fbdev. We want to keep the HMD dark until there's something 'real' to
> show on it.
>
> If you accept that fbdev needs to know this, then there's no way to
> avoid maintaining a database in the kernel. Maybe what we need is some
> way to load additional database entries into the kernel at boot time
> from a file in the initrd? And if you want a user-space database too,
> then maybe the kernel data should be generated from that and dumped into
> the initrd? One version of the truth is hard enough to deal with; I'd
> hate to have two.

Yes, I'd still rather userspace prime the kernel, and keep the
database out of the kernel. The only gap this leaves is early boot,
but the VBIOS will have already lit the HMD up at boot anyway, so
you've already lost.

>> We need the shared EDID library anyway in order to deal with the quirk
>> tables replicated between the kernel/Xorg currently, so that's going
>> to happen pretty soon regardless of whether or not the kernel gets its
>> own database.
>
> Yeah, we'll presumably need this support in the Vulkan KHR_display
> extension too, so sharing EDID support up in user space between all of
> these entities seems like a great idea.

Yeah. That doesn't currently exist, but it's something I'd happily
throw some of our time at quite shortly. If it avoids creating and
supporting both uABI and duplicate databases forever, then it seems
like the best thing to do.

Cheers,
Daniel