On Wed, Jun 03, 2020 at 01:27:55PM +0000, Simon Ser wrote:
When user-space performs an atomic commit on a connector with a "BAD"
link-status without resetting the property to "GOOD", it gets
implicitly reset. This might make the atomic commit fail if the modeset
is unsuccessful.I think this was what Daniel was saying that the kernel should require ALLOW_MODESET to be set for the automatic reset, right?
Actually this paragraph isn't true. link-status is only reset to GOOD for legacy modeset.
But right now this doesn't matter since no driver reads the link-status property value as far as I can tell. Note, only i915 sets link-status to BAD.
It's magic ... change in link status results in connectors_change (or something like that), which forces the modeset (and first recomputation of mode state) that fixes everything up.
But yeah I entirely missed that the autoreset to GOOD only happens in legacy modeset.
I guess we might have some atomic compositors with slightly suboptimal handling of link status failure :-/
I'm fine with how the doc is written now. But if ALLOW_MODESET becomes a requirement for the automatic reset, I suspect there is a risk to regress Weston, assuming the automatic reset used to be successful.
Right now a commit without ALLOW_MODESET won't reset link-status to GOOD, but also won't re-train the link on i915. So I think it's fine to require ALLOW_MODESET.
Should drivers read the value of the link-status property? Or should we ignore user-space writes to the property and only require ALLOW_MODESET to re-train the link?
Well without allow_modeset it'll fail, that's the problem. But since we dont automatically restore, I think the only problem is that existing atomic userspace might be stuck on a bad link for a while ... -Daniel