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

[Dave Airlie]

On 17 October 2017 at 15:56, Andrzej Hajda <a.hajda at samsung.com> wrote:
> 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.

We are thinking "non-desktop". it's not just for fb creation, we don't
want X or wayland using it either.

Dave.