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 14:14:23 +0300
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Werner Sembach <wse@...edocomputers.com>
Cc:     Simon Ser <contact@...rsion.fr>, amd-gfx@...ts.freedesktop.org,
        sunpeng.li@....com, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        airlied@...ux.ie, 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

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.


Thanks,
pq

Content of type "application/pgp-signature" skipped