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

Dave Airlie airlied at gmail.com
Wed Oct 25 19:34:26 UTC 2017


On 25 October 2017 at 21:27, Daniel Stone <daniel at fooishbar.org> wrote:
> 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?

Not sure it really does, at the moment if you have a kernel without these
patches you get fbcon in your brain. Upgrade your kernel and it goes away.

If your X server puts moire pattern in your brain, you upgrade your X server
and no more moire in your brain.

btw I'm more about not having HMD fbcon wreck other fbcons due to the
cloning we do, I'm not as worried about it being in your retinas.

I don't really like having the kernel hide devices, tagging them with properties
is one thing, but actively hiding them from userspace doesn't seem
like something
we want to pursue, though the suggestion has some merit.

Dave.


More information about the dri-devel mailing list