Without atomic modesetting, we have no way to know whether or not our desired configuration is usable. It might fail for a number of reasons: scaling limits, bandwidth limits, global resource (e.g. decompression) unit contention, or really just anything. Not only this, but there is no good way to ensure that our configuration actually lands together in the same refresh cycle - hence the 'atomic' in atomic modesetting. Some drivers implement a synchronously blocking drmModeSetPlane, whereas others return immediately. Using overlay planes can thus decimate your framerate. The pre-atomic API is not extensible either, so we need numerous out clauses: fail if we're cropping or scaling (sometimes), or changing formats, or fencing, or ... Now we've had atomic support stable for a couple of releases, just remove support for doing anything more fancy than displaying our composited output and a cursor with drivers which don't support atomic modesetting. Support for using overlay planes was already disabled by default when using the legacy API, and required a debug key combination to toggle it on by flipping the sprites_are_broken variable. We can ensure that we never try to use it on legacy by simply ignoring the hotkey when in legacy mode. Signed-off-by: Daniel Stone <daniels@collabora.com>dev
parent
b0e16d4c53
commit
87fab1ca4e
Loading…
Reference in new issue