backend/drm: rework atomic support

[emersion]

This one is probably going to be controversial.

Right now we have a single DRM backend using both the legacy API and the atomic API. Both are abstracted behind wlr_drm_interface, which mostly mimicks the legacy API. However, using the atomic API in the backend doesn't provide any benefit and costs us an interface and two different implementations.

To really take advantage of the atomic API, we need to either add a new atomic backend or completely rework wlr_drm_interface. I'm not sure it's a good idea to go down the wlr_drm_interface route, because a whole lot of logic will diverge between legacy and atomic, and a lot of features will be atomic-only.

Also note that the kernel automatically adds legacy support to atomic drivers. So it's not like we'd support less hardware by using only the legacy API.

[ascent12]

I'll agree that wlr_drm_interface is crap, and is just atomic bolted on top of legacy. Most of the functions in it can be chucked out, and basically become test_state (no-op on legacy) and apply_state, instead of throwing atomic out altogether.
I actually started some work doing this, but lost motivation. I really should pick that back up.

[emersion]

Most of the functions in it can be chucked out, and basically become test_state (no-op on legacy) and apply_state, instead of throwing atomic out altogether.

That would be the "rework wlr_drm_interface" route. I'd be interested to see how that plays out, especially when we start adding more atomic-only features.

I really should pick that back up.

Please do :)

[emersion]

This issue is now mostly addressed. The main remaining piece is VRR.