linux-kernel - Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Jun 2021 13:19:41 +0200
From:   Werner Sembach <wse@...edocomputers.com>
To:     Pekka Paalanen <ppaalanen@...il.com>
Cc:     sunpeng.li@....com, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        airlied@...ux.ie, amd-gfx@...ts.freedesktop.org,
        tzimmermann@...e.de, rodrigo.vivi@...el.com,
        alexander.deucher@....com, christian.koenig@....com
Subject: Re: [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property
 as feedback for userspace

Am 23.06.21 um 13:14 schrieb Pekka Paalanen:
> On Wed, 23 Jun 2021 12:17:40 +0200
> Werner Sembach <wse@...edocomputers.com> wrote:
>
>> Am 23.06.21 um 09:32 schrieb Pekka Paalanen:
>>> On Tue, 22 Jun 2021 11:48:52 +0000
>>> Simon Ser <contact@...rsion.fr> wrote:
>>>  
>>>> On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach <wse@...edocomputers.com> wrote:
>>>>  
>>>>> Unknown is when no monitor is connected or is when the
>>>>> connector/monitor is disabled.    
>>>> I think the other connector props (link-status, non-desktop, etc) don't
>>>> have a special "unset" value, and instead the value is set to a random
>>>> enum entry. User-space should ignore the prop on these disconnected
>>>> connectors anyways.  
>>> That sounds fine to me.  
>> Currently the only case for "not applicable" is when the monitor is
>> disconnected, but sicne the properties are so interdependent, there
>> might be a case in the future where e.g. a color format that has no
>> differentiation between full and limited arises. When there is no
>> special unset/not applicable option, the userspace has to know
>> exactly when an option is valid or not, possible requiring additional
>> logic.
>>
>> Setting a "not applicable" value allows userspace to be more dumb,
>> without much hassle on the kernelspace side.
> That's a good point too. So "not applicable" would be a value, but
> "unknown" would not be.
Ok, I have already renamed the "unknown" option to "not applicable" in my next revision (not yet posted to the mailing
list).
>
>
> Thanks,
> pq