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

[Pekka Paalanen]

On Mon, 20 Apr 2020 10:15:39 +0000
Simon Ser <contact at emersion.fr> wrote:

> 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?  

I meant fbcon, not fbdev above.

> 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.

Indeed. So the display manager might get sensible defaults, but the
session compositor might not. Or maybe boot splash uses KMS already, so
even display manager doesn't get all-defaults state.

It seems we really do need "sane defaults" from the kernel explicitly.
Writing a userspace tool to save it at boot time before any KMS program
runs would be awkward.

> > 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.

What if userspace writes BAD?

BAD cannot be default state, so getting default state from somewhere
would solve this property's restoring as well. Reading back the true
current value could accidentally return BAD.


Just to reiterate for everyone, the important thing here is to figure
out how userspace is supposed to reset unknown properties to sensible
defaults. Once we know how that should work, we can review whether new
properties support or break that.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200420/aec019b5/attachment.sig>