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

[Andrzej Hajda]

On 16.10.2017 16:21, Alex Deucher wrote:
> On Mon, Oct 16, 2017 at 5:24 AM, Daniel Vetter <daniel at 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 at gmail.com> wrote:
>>>> On Mon, Oct 16, 2017 at 02:29:07PM +1000, Dave Airlie wrote:
>>>>> From: Dave Airlie <airlied at 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 at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel