On Mon, 20 Apr 2020 10:15:39 +0000 Simon Ser <contact@xxxxxxxxxxx> wrote: > On Monday, April 20, 2020 10:27 AM, Pekka Paalanen <ppaalanen@xxxxxxxxx> 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:
pgpvBaKpzTenV.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
