From: "Keith Packard" <keithp@keithp.com>
To: Daniel Stone <daniel@fooishbar.org>, Dave Airlie <airlied@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/3] drm: add connector info/property for non-std displays
Date: Thu, 19 Oct 2017 09:27:32 -0700 [thread overview]
Message-ID: <87d15jp0gb.fsf@keithp.com> (raw)
In-Reply-To: <CAPj87rNLUP+NH=GZo9VDj652OrELp6AgnfwAvbO+m51HzzFPAQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1894 bytes --]
Daniel Stone <daniel@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?
> 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.
> 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.
--
-keith
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-10-19 16:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 4:29 [PATCH 1/3] drm: add connector info/property for non-std displays Dave Airlie
2017-10-16 4:29 ` [PATCH 2/3] drm/fb: add support for not enabling fbcon on " Dave Airlie
2017-10-16 4:29 ` [PATCH 3/3] drm/edid: quirk HTC vive headset as non-standard Dave Airlie
2017-10-16 6:47 ` Thierry Reding
2017-10-17 0:59 ` Pierre-Loup A. Griffais
2017-10-16 6:41 ` [PATCH 1/3] drm: add connector info/property for non-std displays Thierry Reding
2017-10-16 6:50 ` Dave Airlie
2017-10-16 9:24 ` Daniel Vetter
2017-10-16 14:21 ` Alex Deucher
2017-10-17 5:56 ` Andrzej Hajda
2017-10-17 5:59 ` Dave Airlie
2017-10-16 9:26 ` Daniel Vetter
2017-10-16 10:09 ` Jani Nikula
2017-10-19 15:37 ` Daniel Stone
2017-10-19 16:27 ` Keith Packard [this message]
2017-10-25 11:27 ` Daniel Stone
2017-10-25 19:34 ` Dave Airlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d15jp0gb.fsf@keithp.com \
--to=keithp@keithp.com \
--cc=airlied@gmail.com \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.