On Monday, April 20, 2020 2:22 PM, Pekka Paalanen ppaalanen@gmail.com wrote:
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.
Agreed.
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.
Interestingly, setting it to BAD is a no-op (BAD is silently discarded):
/* Never downgrade from GOOD to BAD on userspace's request here, * only hw issues can do that. * * For an atomic property the userspace doesn't need to be able * to understand all the properties, but needs to be able to * restore the state it wants on VT switch. So if the userspace * tries to change the link_status from GOOD to BAD, driver * silently rejects it and returns a 0. This prevents userspace * from accidently breaking the display when it restores the * state. */ if (state->link_status != DRM_LINK_STATUS_GOOD) state->link_status = val;
So restoring the "sane default" would be work, even if the link happens to be BAD when saving said "sane defaults".
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.
Yes, that's a good description of the problem.
I see two main solutions here: either the kernel provides the default values in its property descriptions (e.g. drmModeGetProperty), either user-space can ask the kernel to reset properties to their default values.