* [PATCH 2/3] drm/fb: add support for not enabling fbcon on non-std displays
2017-10-16 4:29 [PATCH 1/3] drm: add connector info/property for non-std displays Dave Airlie
@ 2017-10-16 4:29 ` Dave Airlie
2017-10-16 4:29 ` [PATCH 3/3] drm/edid: quirk HTC vive headset as non-standard Dave Airlie
` (4 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: Dave Airlie @ 2017-10-16 4:29 UTC (permalink / raw)
To: dri-devel
From: Dave Airlie <airlied@redhat.com>
We don't want fbcon to get used on non-standard dislays,
don't pass them as enabled connectors to the fb helper setup.
This prevents my HMD from getting disorted fbcon, and from
affecting other displays console.
Signed-off-by: Dave Airlie <airlied@redhat.com>
---
drivers/gpu/drm/drm_fb_helper.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6a31d13f2f81..41ff51ca0396 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2033,6 +2033,9 @@ static bool drm_connector_enabled(struct drm_connector *connector, bool strict)
{
bool enable;
+ if (connector->display_info.non_std)
+ return false;
+
if (strict)
enable = connector->status == connector_status_connected;
else
@@ -2052,7 +2055,8 @@ static void drm_enable_connectors(struct drm_fb_helper *fb_helper,
connector = fb_helper->connector_info[i]->connector;
enabled[i] = drm_connector_enabled(connector, true);
DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- enabled[i] ? "yes" : "no");
+ connector->display_info.non_std ? "non standard" : enabled[i] ? "yes" : "no");
+
any_enabled |= enabled[i];
}
--
2.14.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 3/3] drm/edid: quirk HTC vive headset as non-standard.
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 ` Dave Airlie
2017-10-16 6:47 ` Thierry Reding
2017-10-16 6:41 ` [PATCH 1/3] drm: add connector info/property for non-std displays Thierry Reding
` (3 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Dave Airlie @ 2017-10-16 4:29 UTC (permalink / raw)
To: dri-devel
From: Dave Airlie <airlied@redhat.com>
This uses the EDID info from my HTC Vive to mark it as
non-standard.
Signed-off-by: Dave Airlie <airlied@redhat.com>
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4225052def37..b491b3c3cc1f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -159,6 +159,9 @@ static const struct edid_quirk {
/* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
{ "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
+
+ /* HTC Vive VR Headset */
+ { "HVR", 0xaa01, EDID_QUIRK_NON_STD_DEVICE },
};
/*
--
2.14.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 3/3] drm/edid: quirk HTC vive headset as non-standard.
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
0 siblings, 1 reply; 17+ messages in thread
From: Thierry Reding @ 2017-10-16 6:47 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 582 bytes --]
On Mon, Oct 16, 2017 at 02:29:09PM +1000, Dave Airlie wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> This uses the EDID info from my HTC Vive to mark it as
> non-standard.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> 1 file changed, 3 insertions(+)
I guess I was being naive for thinking that HMDs would come with a
special EDID extension. Google indicates that someone might have worked
on something called HMD-EXT to be standardized by VESA for EDID, but no
documents seem to exist for that.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] drm/edid: quirk HTC vive headset as non-standard.
2017-10-16 6:47 ` Thierry Reding
@ 2017-10-17 0:59 ` Pierre-Loup A. Griffais
0 siblings, 0 replies; 17+ messages in thread
From: Pierre-Loup A. Griffais @ 2017-10-17 0:59 UTC (permalink / raw)
To: Thierry Reding, Dave Airlie; +Cc: dri-devel
On 10/15/2017 11:47 PM, Thierry Reding wrote:
> On Mon, Oct 16, 2017 at 02:29:09PM +1000, Dave Airlie wrote:
>> From: Dave Airlie <airlied@redhat.com>
>>
>> This uses the EDID info from my HTC Vive to mark it as
>> non-standard.
>>
>> Signed-off-by: Dave Airlie <airlied@redhat.com>
>> ---
>> drivers/gpu/drm/drm_edid.c | 3 +++
>> 1 file changed, 3 insertions(+)
>
> I guess I was being naive for thinking that HMDs would come with a
> special EDID extension. Google indicates that someone might have worked
> on something called HMD-EXT to be standardized by VESA for EDID, but no
> documents seem to exist for that.
We had someone working with VESA on exactly that and I thought that had
shipped, but we found the same thing: the extension was never released
and there's not currently a standard way to tag HMDs at the EDID-level,
which is very unfortunate, as you'd want the lowest levels of the system
to be aware of the HMD-ness of a display. You would never want to bring
up a text console on one, or any sort of non-distorted content. I'll
look into getting that effort back on track, but in the meantime it
looks like an EDID blacklist somewhere might be our best bet.
Thanks,
- Pierre-Loup
>
> Thierry
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
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:41 ` Thierry Reding
2017-10-16 6:50 ` Dave Airlie
2017-10-16 9:26 ` Daniel Vetter
` (2 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Thierry Reding @ 2017-10-16 6:41 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1144 bytes --]
On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> This adds the infrastructure needed to quirk displays
> using edid and to mark them a non-standard.
>
> A non-standard display is one which doesn't work like
> a normal rectangular monitor or requires some transformation
> of the output by the rendering process to make sense.
>
> This is meant to cover head mounted devices like HTC Vive.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
> drivers/gpu/drm/drm_edid.c | 8 ++++++--
> include/drm/drm_connector.h | 5 +++++
> include/drm/drm_mode_config.h | 7 +++++++
> 4 files changed, 31 insertions(+), 2 deletions(-)
"non-standard" seems very ambiguous to me. If this is targetting HMDs in
particular, perhaps we can borrow a term from that. Without being really
familiar with that technology, a quick Google search suggests that these
devices are commonly referred to as operating in "direct mode". Perhaps
a boolean "direct-mode" property would be less ambiguous?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
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
0 siblings, 1 reply; 17+ messages in thread
From: Dave Airlie @ 2017-10-16 6:50 UTC (permalink / raw)
To: Thierry Reding; +Cc: dri-devel
On 16 October 2017 at 16:41, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
>> From: Dave Airlie <airlied@redhat.com>
>>
>> This adds the infrastructure needed to quirk displays
>> using edid and to mark them a non-standard.
>>
>> A non-standard display is one which doesn't work like
>> a normal rectangular monitor or requires some transformation
>> of the output by the rendering process to make sense.
>>
>> This is meant to cover head mounted devices like HTC Vive.
>>
>> Signed-off-by: Dave Airlie <airlied@redhat.com>
>> ---
>> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
>> drivers/gpu/drm/drm_edid.c | 8 ++++++--
>> include/drm/drm_connector.h | 5 +++++
>> include/drm/drm_mode_config.h | 7 +++++++
>> 4 files changed, 31 insertions(+), 2 deletions(-)
>
> "non-standard" seems very ambiguous to me. If this is targetting HMDs in
> particular, perhaps we can borrow a term from that. Without being really
> familiar with that technology, a quick Google search suggests that these
> devices are commonly referred to as operating in "direct mode". Perhaps
> a boolean "direct-mode" property would be less ambiguous?
I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic
features to specific technologies if we can avoid it, there may be other
requirements for connected displays we don't want to display on without
some special app that aren't HMDs.
I agree non-standard is a bit ambiguous, but I'm not happy direct mode
gives me any more useful info, anyone else got a name?
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-16 6:50 ` Dave Airlie
@ 2017-10-16 9:24 ` Daniel Vetter
2017-10-16 14:21 ` Alex Deucher
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Vetter @ 2017-10-16 9:24 UTC (permalink / raw)
To: Dave Airlie; +Cc: Thierry Reding, dri-devel
On Mon, Oct 16, 2017 at 04:50:16PM +1000, Dave Airlie wrote:
> On 16 October 2017 at 16:41, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie <airlied@redhat.com>
> >>
> >> This adds the infrastructure needed to quirk displays
> >> using edid and to mark them a non-standard.
> >>
> >> A non-standard display is one which doesn't work like
> >> a normal rectangular monitor or requires some transformation
> >> of the output by the rendering process to make sense.
> >>
> >> This is meant to cover head mounted devices like HTC Vive.
> >>
> >> Signed-off-by: Dave Airlie <airlied@redhat.com>
> >> ---
> >> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
> >> drivers/gpu/drm/drm_edid.c | 8 ++++++--
> >> include/drm/drm_connector.h | 5 +++++
> >> include/drm/drm_mode_config.h | 7 +++++++
> >> 4 files changed, 31 insertions(+), 2 deletions(-)
> >
> > "non-standard" seems very ambiguous to me. If this is targetting HMDs in
> > particular, perhaps we can borrow a term from that. Without being really
> > familiar with that technology, a quick Google search suggests that these
> > devices are commonly referred to as operating in "direct mode". Perhaps
> > a boolean "direct-mode" property would be less ambiguous?
>
> I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic
> features to specific technologies if we can avoid it, there may be other
> requirements for connected displays we don't want to display on without
> some special app that aren't HMDs.
>
> I agree non-standard is a bit ambiguous, but I'm not happy direct mode
> gives me any more useful info, anyone else got a name?
I'd have just gone with HMD. We're really bad at predicting the future,
every time we try to make things a bit too generic it bites us. And think
for leases it makes sense (since people are already talking about other
uses than just HMD pass-through), but for this prop, not so much.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-16 9:24 ` Daniel Vetter
@ 2017-10-16 14:21 ` Alex Deucher
2017-10-17 5:56 ` Andrzej Hajda
0 siblings, 1 reply; 17+ messages in thread
From: Alex Deucher @ 2017-10-16 14:21 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Thierry Reding, dri-devel
On Mon, Oct 16, 2017 at 5:24 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 16, 2017 at 04:50:16PM +1000, Dave Airlie wrote:
>> On 16 October 2017 at 16:41, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
>> >> From: Dave Airlie <airlied@redhat.com>
>> >>
>> >> This adds the infrastructure needed to quirk displays
>> >> using edid and to mark them a non-standard.
>> >>
>> >> A non-standard display is one which doesn't work like
>> >> a normal rectangular monitor or requires some transformation
>> >> of the output by the rendering process to make sense.
>> >>
>> >> This is meant to cover head mounted devices like HTC Vive.
>> >>
>> >> Signed-off-by: Dave Airlie <airlied@redhat.com>
>> >> ---
>> >> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
>> >> drivers/gpu/drm/drm_edid.c | 8 ++++++--
>> >> include/drm/drm_connector.h | 5 +++++
>> >> include/drm/drm_mode_config.h | 7 +++++++
>> >> 4 files changed, 31 insertions(+), 2 deletions(-)
>> >
>> > "non-standard" seems very ambiguous to me. If this is targetting HMDs in
>> > particular, perhaps we can borrow a term from that. Without being really
>> > familiar with that technology, a quick Google search suggests that these
>> > devices are commonly referred to as operating in "direct mode". Perhaps
>> > a boolean "direct-mode" property would be less ambiguous?
>>
>> I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic
>> features to specific technologies if we can avoid it, there may be other
>> requirements for connected displays we don't want to display on without
>> some special app that aren't HMDs.
>>
>> I agree non-standard is a bit ambiguous, but I'm not happy direct mode
>> gives me any more useful info, anyone else got a name?
>
> I'd have just gone with HMD. We're really bad at predicting the future,
> every time we try to make things a bit too generic it bites us. And think
> for leases it makes sense (since people are already talking about other
> uses than just HMD pass-through), but for this prop, not so much.
I'd vote for HMD too. non-standard is too ambiguous.
Alex
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-16 14:21 ` Alex Deucher
@ 2017-10-17 5:56 ` Andrzej Hajda
2017-10-17 5:59 ` Dave Airlie
0 siblings, 1 reply; 17+ messages in thread
From: Andrzej Hajda @ 2017-10-17 5:56 UTC (permalink / raw)
To: Alex Deucher, Daniel Vetter; +Cc: Thierry Reding, dri-devel
On 16.10.2017 16:21, Alex Deucher wrote:
> On Mon, Oct 16, 2017 at 5:24 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Mon, Oct 16, 2017 at 04:50:16PM +1000, Dave Airlie wrote:
>>> On 16 October 2017 at 16:41, Thierry Reding <thierry.reding@gmail.com> wrote:
>>>> On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
>>>>> From: Dave Airlie <airlied@redhat.com>
>>>>>
>>>>> This adds the infrastructure needed to quirk displays
>>>>> using edid and to mark them a non-standard.
>>>>>
>>>>> A non-standard display is one which doesn't work like
>>>>> a normal rectangular monitor or requires some transformation
>>>>> of the output by the rendering process to make sense.
>>>>>
>>>>> This is meant to cover head mounted devices like HTC Vive.
>>>>>
>>>>> Signed-off-by: Dave Airlie <airlied@redhat.com>
>>>>> ---
>>>>> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
>>>>> drivers/gpu/drm/drm_edid.c | 8 ++++++--
>>>>> include/drm/drm_connector.h | 5 +++++
>>>>> include/drm/drm_mode_config.h | 7 +++++++
>>>>> 4 files changed, 31 insertions(+), 2 deletions(-)
>>>> "non-standard" seems very ambiguous to me. If this is targetting HMDs in
>>>> particular, perhaps we can borrow a term from that. Without being really
>>>> familiar with that technology, a quick Google search suggests that these
>>>> devices are commonly referred to as operating in "direct mode". Perhaps
>>>> a boolean "direct-mode" property would be less ambiguous?
>>> I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic
>>> features to specific technologies if we can avoid it, there may be other
>>> requirements for connected displays we don't want to display on without
>>> some special app that aren't HMDs.
>>>
>>> I agree non-standard is a bit ambiguous, but I'm not happy direct mode
>>> gives me any more useful info, anyone else got a name?
>> I'd have just gone with HMD. We're really bad at predicting the future,
>> every time we try to make things a bit too generic it bites us. And think
>> for leases it makes sense (since people are already talking about other
>> uses than just HMD pass-through), but for this prop, not so much.
> I'd vote for HMD too. non-standard is too ambiguous.
Wouldn't then be better then to add some enum property with "HMD" as one
of values.
On the other side this property is currently used just to prevent fb
creation, what about naming property after its purpose? non-fb,
non-console, ...whatever.
Regards
Andrzej
>
> Alex
>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-17 5:56 ` Andrzej Hajda
@ 2017-10-17 5:59 ` Dave Airlie
0 siblings, 0 replies; 17+ messages in thread
From: Dave Airlie @ 2017-10-17 5:59 UTC (permalink / raw)
To: Andrzej Hajda; +Cc: Thierry Reding, dri-devel
On 17 October 2017 at 15:56, Andrzej Hajda <a.hajda@samsung.com> wrote:
> On 16.10.2017 16:21, Alex Deucher wrote:
>> On Mon, Oct 16, 2017 at 5:24 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Mon, Oct 16, 2017 at 04:50:16PM +1000, Dave Airlie wrote:
>>>> On 16 October 2017 at 16:41, Thierry Reding <thierry.reding@gmail.com> wrote:
>>>>> On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
>>>>>> From: Dave Airlie <airlied@redhat.com>
>>>>>>
>>>>>> This adds the infrastructure needed to quirk displays
>>>>>> using edid and to mark them a non-standard.
>>>>>>
>>>>>> A non-standard display is one which doesn't work like
>>>>>> a normal rectangular monitor or requires some transformation
>>>>>> of the output by the rendering process to make sense.
>>>>>>
>>>>>> This is meant to cover head mounted devices like HTC Vive.
>>>>>>
>>>>>> Signed-off-by: Dave Airlie <airlied@redhat.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
>>>>>> drivers/gpu/drm/drm_edid.c | 8 ++++++--
>>>>>> include/drm/drm_connector.h | 5 +++++
>>>>>> include/drm/drm_mode_config.h | 7 +++++++
>>>>>> 4 files changed, 31 insertions(+), 2 deletions(-)
>>>>> "non-standard" seems very ambiguous to me. If this is targetting HMDs in
>>>>> particular, perhaps we can borrow a term from that. Without being really
>>>>> familiar with that technology, a quick Google search suggests that these
>>>>> devices are commonly referred to as operating in "direct mode". Perhaps
>>>>> a boolean "direct-mode" property would be less ambiguous?
>>>> I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic
>>>> features to specific technologies if we can avoid it, there may be other
>>>> requirements for connected displays we don't want to display on without
>>>> some special app that aren't HMDs.
>>>>
>>>> I agree non-standard is a bit ambiguous, but I'm not happy direct mode
>>>> gives me any more useful info, anyone else got a name?
>>> I'd have just gone with HMD. We're really bad at predicting the future,
>>> every time we try to make things a bit too generic it bites us. And think
>>> for leases it makes sense (since people are already talking about other
>>> uses than just HMD pass-through), but for this prop, not so much.
>> I'd vote for HMD too. non-standard is too ambiguous.
>
> Wouldn't then be better then to add some enum property with "HMD" as one
> of values.
> On the other side this property is currently used just to prevent fb
> creation, what about naming property after its purpose? non-fb,
> non-console, ...whatever.
We are thinking "non-desktop". it's not just for fb creation, we don't
want X or wayland using it either.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-16 4:29 [PATCH 1/3] drm: add connector info/property for non-std displays Dave Airlie
` (2 preceding siblings ...)
2017-10-16 6:41 ` [PATCH 1/3] drm: add connector info/property for non-std displays Thierry Reding
@ 2017-10-16 9:26 ` Daniel Vetter
2017-10-16 10:09 ` Jani Nikula
2017-10-19 15:37 ` Daniel Stone
5 siblings, 0 replies; 17+ messages in thread
From: Daniel Vetter @ 2017-10-16 9:26 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel
On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> This adds the infrastructure needed to quirk displays
> using edid and to mark them a non-standard.
>
> A non-standard display is one which doesn't work like
> a normal rectangular monitor or requires some transformation
> of the output by the rendering process to make sense.
>
> This is meant to cover head mounted devices like HTC Vive.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
When adding new properties pls also patch up the properties docs we have
to explain what it's supposed to mean:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Otherwise makes sense I think to have the quirk list in the kernel,
especially since there's future standards in the works, so the quirk list
should be fairly small.
-Daniel
> ---
> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
> drivers/gpu/drm/drm_edid.c | 8 ++++++--
> include/drm/drm_connector.h | 5 +++++
> include/drm/drm_mode_config.h | 7 +++++++
> 4 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 704fc8934616..50a176483619 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -234,6 +234,10 @@ int drm_connector_init(struct drm_device *dev,
> config->link_status_property,
> 0);
>
> + drm_object_attach_property(&connector->base,
> + config->non_std_display_property,
> + 0);
> +
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
> }
> @@ -811,6 +815,11 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
> return -ENOMEM;
> dev->mode_config.link_status_property = prop;
>
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE, "non_standard");
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.non_std_display_property = prop;
> +
> return 0;
> }
>
> @@ -1194,6 +1203,10 @@ int drm_mode_connector_update_edid_property(struct drm_connector *connector,
> if (edid)
> size = EDID_LENGTH * (1 + edid->extensions);
>
> + drm_object_property_set_value(&connector->base,
> + dev->mode_config.non_std_display_property,
> + connector->display_info.non_std);
> +
> ret = drm_property_replace_global_blob(dev,
> &connector->edid_blob_ptr,
> size,
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 00ddabfbf980..4225052def37 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -82,6 +82,8 @@
> #define EDID_QUIRK_FORCE_6BPC (1 << 10)
> /* Force 10bpc */
> #define EDID_QUIRK_FORCE_10BPC (1 << 11)
> +/* Non standard display device (i.e. HMD) */
> +#define EDID_QUIRK_NON_STD_DEVICE (1 << 12)
>
> struct detailed_mode_closure {
> struct drm_connector *connector;
> @@ -4393,7 +4395,7 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
> }
>
> static void drm_add_display_info(struct drm_connector *connector,
> - struct edid *edid)
> + struct edid *edid, u32 quirks)
> {
> struct drm_display_info *info = &connector->display_info;
>
> @@ -4407,6 +4409,8 @@ static void drm_add_display_info(struct drm_connector *connector,
> info->max_tmds_clock = 0;
> info->dvi_dual = false;
>
> + info->non_std = !!(quirks & EDID_QUIRK_NON_STD_DEVICE);
> +
> if (edid->revision < 3)
> return;
>
> @@ -4627,7 +4631,7 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> * To avoid multiple parsing of same block, lets parse that map
> * from sink info, before parsing CEA modes.
> */
> - drm_add_display_info(connector, edid);
> + drm_add_display_info(connector, edid, quirks);
>
> /*
> * EDID spec says modes should be preferred in this order:
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b4285c40e1e4..5c3a1667458b 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -284,6 +284,11 @@ struct drm_display_info {
> * @hdmi: advance features of a HDMI sink.
> */
> struct drm_hdmi_info hdmi;
> +
> + /**
> + * @non_std: Non standard display device (HMD).
> + */
> + bool non_std;
> };
>
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 0b4ac2ebc610..a5a44aeccff4 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -728,6 +728,13 @@ struct drm_mode_config {
> */
> struct drm_property *suggested_y_property;
>
> + /**
> + * @non_std_display_property: Optional connector property with a hint
> + * that device isn't a standard display, and the console/desktop,
> + * should not be displayed on it.
> + */
> + struct drm_property *non_std_display_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
>
> --
> 2.14.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-16 4:29 [PATCH 1/3] drm: add connector info/property for non-std displays Dave Airlie
` (3 preceding siblings ...)
2017-10-16 9:26 ` Daniel Vetter
@ 2017-10-16 10:09 ` Jani Nikula
2017-10-19 15:37 ` Daniel Stone
5 siblings, 0 replies; 17+ messages in thread
From: Jani Nikula @ 2017-10-16 10:09 UTC (permalink / raw)
To: Dave Airlie, dri-devel
On Mon, 16 Oct 2017, Dave Airlie <airlied@gmail.com> wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> This adds the infrastructure needed to quirk displays
> using edid and to mark them a non-standard.
>
> A non-standard display is one which doesn't work like
> a normal rectangular monitor or requires some transformation
> of the output by the rendering process to make sense.
>
> This is meant to cover head mounted devices like HTC Vive.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
> drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
> drivers/gpu/drm/drm_edid.c | 8 ++++++--
> include/drm/drm_connector.h | 5 +++++
> include/drm/drm_mode_config.h | 7 +++++++
> 4 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 704fc8934616..50a176483619 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -234,6 +234,10 @@ int drm_connector_init(struct drm_device *dev,
> config->link_status_property,
> 0);
>
> + drm_object_attach_property(&connector->base,
> + config->non_std_display_property,
> + 0);
> +
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
> }
> @@ -811,6 +815,11 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
> return -ENOMEM;
> dev->mode_config.link_status_property = prop;
>
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE, "non_standard");
I'm completely lost about the rules for naming properties, and whether
we should aim to have some uniformity in the naming.
We have properties with lower case, upper case, and capitalized case. We
have properties with spaces, underscores, and hyphens. We have enum
property values with a similar mix, and the style in values doesn't even
always match the style in the property!
I share the concerns about the property name with Thierry and Daniel,
but if we decided to go with non-standard, the property could be named
"non-standard", "non standard", "non_standard", "Non-Standard",
"NON_STANDARD", and a few more combinations, and still I wouldn't be
able to say whether it's right or wrong.
Of the above, I guess I'd go for "non-standard" because it matches
English usage.
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.non_std_display_property = prop;
> +
> return 0;
> }
>
> @@ -1194,6 +1203,10 @@ int drm_mode_connector_update_edid_property(struct drm_connector *connector,
> if (edid)
> size = EDID_LENGTH * (1 + edid->extensions);
>
> + drm_object_property_set_value(&connector->base,
> + dev->mode_config.non_std_display_property,
> + connector->display_info.non_std);
> +
> ret = drm_property_replace_global_blob(dev,
> &connector->edid_blob_ptr,
> size,
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 00ddabfbf980..4225052def37 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -82,6 +82,8 @@
> #define EDID_QUIRK_FORCE_6BPC (1 << 10)
> /* Force 10bpc */
> #define EDID_QUIRK_FORCE_10BPC (1 << 11)
> +/* Non standard display device (i.e. HMD) */
> +#define EDID_QUIRK_NON_STD_DEVICE (1 << 12)
>
> struct detailed_mode_closure {
> struct drm_connector *connector;
> @@ -4393,7 +4395,7 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
> }
>
> static void drm_add_display_info(struct drm_connector *connector,
> - struct edid *edid)
> + struct edid *edid, u32 quirks)
> {
> struct drm_display_info *info = &connector->display_info;
>
> @@ -4407,6 +4409,8 @@ static void drm_add_display_info(struct drm_connector *connector,
> info->max_tmds_clock = 0;
> info->dvi_dual = false;
>
> + info->non_std = !!(quirks & EDID_QUIRK_NON_STD_DEVICE);
Nitpick, the !! are unnecessary for std bools.
BR,
Jani.
> +
> if (edid->revision < 3)
> return;
>
> @@ -4627,7 +4631,7 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> * To avoid multiple parsing of same block, lets parse that map
> * from sink info, before parsing CEA modes.
> */
> - drm_add_display_info(connector, edid);
> + drm_add_display_info(connector, edid, quirks);
>
> /*
> * EDID spec says modes should be preferred in this order:
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b4285c40e1e4..5c3a1667458b 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -284,6 +284,11 @@ struct drm_display_info {
> * @hdmi: advance features of a HDMI sink.
> */
> struct drm_hdmi_info hdmi;
> +
> + /**
> + * @non_std: Non standard display device (HMD).
> + */
> + bool non_std;
> };
>
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 0b4ac2ebc610..a5a44aeccff4 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -728,6 +728,13 @@ struct drm_mode_config {
> */
> struct drm_property *suggested_y_property;
>
> + /**
> + * @non_std_display_property: Optional connector property with a hint
> + * that device isn't a standard display, and the console/desktop,
> + * should not be displayed on it.
> + */
> + struct drm_property *non_std_display_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-16 4:29 [PATCH 1/3] drm: add connector info/property for non-std displays Dave Airlie
` (4 preceding siblings ...)
2017-10-16 10:09 ` Jani Nikula
@ 2017-10-19 15:37 ` Daniel Stone
2017-10-19 16:27 ` Keith Packard
5 siblings, 1 reply; 17+ messages in thread
From: Daniel Stone @ 2017-10-19 15:37 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel
Hi,
On 16 October 2017 at 06:29, Dave Airlie <airlied@gmail.com> wrote:
> This adds the infrastructure needed to quirk displays
> using edid and to mark them a non-standard.
>
> A non-standard display is one which doesn't work like
> a normal rectangular monitor or requires some transformation
> of the output by the rendering process to make sense.
>
> This is meant to cover head mounted devices like HTC Vive.
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.
Either way, I'm still not convinced doing this in the kernel makes any
sense. Seems like we'll need to keep doing it forever for every HMD
once we start now. Why not drop the in-kernel database, and go with a
userspace-side table: we already _have_ udev's hwdb, there's already a
decent enough sketch of an EDID database we could share between
Mutter/Weston/Xorg/..., and it's easier to deal with, distribute, and
hack. 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.
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-19 15:37 ` Daniel Stone
@ 2017-10-19 16:27 ` Keith Packard
2017-10-25 11:27 ` Daniel Stone
0 siblings, 1 reply; 17+ messages in thread
From: Keith Packard @ 2017-10-19 16:27 UTC (permalink / raw)
To: Daniel Stone, Dave Airlie; +Cc: dri-devel
[-- 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-19 16:27 ` Keith Packard
@ 2017-10-25 11:27 ` Daniel Stone
2017-10-25 19:34 ` Dave Airlie
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Stone @ 2017-10-25 11:27 UTC (permalink / raw)
To: Keith Packard; +Cc: dri-devel
Hi,
On 19 October 2017 at 17:27, Keith Packard <keithp@keithp.com> wrote:
> 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?
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] drm: add connector info/property for non-std displays
2017-10-25 11:27 ` Daniel Stone
@ 2017-10-25 19:34 ` Dave Airlie
0 siblings, 0 replies; 17+ messages in thread
From: Dave Airlie @ 2017-10-25 19:34 UTC (permalink / raw)
To: Daniel Stone; +Cc: Keith Packard, dri-devel
On 25 October 2017 at 21:27, Daniel Stone <daniel@fooishbar.org> wrote:
> Hi,
>
> On 19 October 2017 at 17:27, Keith Packard <keithp@keithp.com> wrote:
>> 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?
>
> 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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 17+ messages in thread