drm/manager: Provide explicit lock api #1778
Conversation
Drakulix
force-pushed
the
feature/explicit-lock-drm-manager
branch
2 times, most recently
from
fd25a9f to
9c3b69e
Compare
Drakulix
force-pushed
the
feature/explicit-lock-drm-manager
branch
from
9c3b69e to
c28604c
Compare
|
Confirmed this does end up fixing our issues in cosmic. Especially changing the So without locks and careful order of the operations any thread might use the wrong resolution temporarily or any tests by the This is sufficient to get rid of the races, though this is still easier to shoot yourself in the foot than I would like it to be. |
Yeah, not sure how to resolve this. I guess at some point it would be great to have some kind of output abstraction across backends. |
Since #1778 we provide an api to explicitly lock the `DrmOutputManager` to apply multiple changes atomically without `DrmOutput`s being able to observe any inconsistent state. However as a side-effect of this, it has become impossible to re-assign a crtc to a different connector in one atomic opertion, as the lock on the `DrmOutputManager` prevents the `Drop`-implementation of `DrmOutput` to free any crtcs for re-use. This commit introduces a channel, if locking fails to deferr freeing the crtc to the locked manager.
Needs some testing in cosmic-comp, but I believe this is necessary to provide race-free state changes.
Note: We could potentially provide two variants of this api, the old one and the new one. I don't see a particular advantage to that approach other than preserving a relatively new and barely used api.