Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)

[Simon Ser]

On Monday, April 20, 2020 10:27 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> The only "random" KMS state is the properties the userspace KMS
> program does not know that are set on start-up. I have been assuming
> that as long as you had fbdev active before the KMS program started,
> the unknown properties have "harmless" default values. And maybe even at
> driver device init if fbdev does not exist?

Note, this is not the case when using e.g. a display manager. In the
past there have been cases of a display manager setting a hw cursor
and launching a compositor not supporting hw cursors. This results in
a stuck hw cursor.

> Btw. I searched for all occurrences of link_status in
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html and it seems it
> only has two possible values, good and bad, and no mention whether it
> is writable. Looks like it's writable. There does not seem to be a) an
> explanation how exactly it needs to the handled (writing it does
> something? what can you write?) or b) any way discern between kernel
> and userspace set values like HDCP "Content Protection" has.

User-space needs to reset the value to GOOD when recovering from a BAD
value.