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

From: Pekka Paalanen <ppaalanen@gmail.com>
To: Simon Ser <contact@emersion.fr>
Cc: Benjamin Berg <bberg@redhat.com>, David Airlie <airlied@linux.ie>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Christian Kellner <ckellner@redhat.com>,
	Javier Martinez Canillas <javierm@redhat.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Pearson <mpearson@lenovo.com>,
	Rajat Jain <rajatja@google.com>,
	Nitin Joshi1 <njoshi1@lenovo.com>
Subject: Re: Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)
Date: Mon, 20 Apr 2020 15:22:35 +0300	[thread overview]
Message-ID: <20200420152235.3473851f@eldfell.localdomain> (raw)
In-Reply-To: <eT7Xq1DV3kIBOemufORRm39_VF3D9VD08jWCOHvl2IcqmNXqpgtgDGtPcpT_CnQjhIzqth_VdU_A8U1dCFj02JzayLcYCdUlz_5Y-i2tNXk=@emersion.fr>

[-- Attachment #1.1: Type: text/plain, Size: 2233 bytes --]

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

> On Monday, April 20, 2020 10:27 AM, Pekka Paalanen <ppaalanen@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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel