Add a DRM/KMS backend

[notgull]

This adds a DRM/KMS based backend to the system, as per #42. This system finds a CRTC and a connector, then uses that to create a frame buffer and a DUMB buffer that it can render to.

All of this is untested, hence the draft status.

I'm not going to be the maintainer for this backend, as I'm self-imposing a limit of two backends on myself. If anyone else with DRM/KMS experience or a motivating use case wants to maintain this backend, let me know. Otherwise I've marked it as unmaintained.

Closes #42

[notgull]

I've tested this on my computer and it seems to work for my use case, so I think it's ready.

[tronical]

Awesome stuff, btw! Two small comments inside.

[ids1024]

Well, the BorrowStack hack would work here.

But it looks like DumbMapping is already just a wrapper around a &'a mut [u8], so could just open a PR for drm-rs to implement AsRef<[u8]> in addition to the AsMut<[u8]> implementation.

[notgull]

Tested on my laptop

[ids1024]

page_flip only queues a page flip. If an application were presenting buffers repeatedly without waiting, I believe it could overwrite a buffer while/before it appears on screen.

So I believe like on Wayland, buffer_mut should wait for buffer release. I guess it would have to poll the device fd, and use drm::control::device::receive_events to see if it's gotten Event::PageFlip yet.

...but would Winit or another "windowing" backend using DRM also poll the same fd? Is there any way to manage this?

[ids1024]

The example currently fails on the laptop I'm using since it has an Nvidia card, which for some reason is card0, while the only connected connector is on the iGPU, card1.

There isn't a good way to determine the right output, and the display probably shouldn't try to deal with setting all connected outputs, but maybe it should iterate over cards and chose the first one it finds a connector on?

[notgull]

page_flip only queues a page flip. If an application were presenting buffers repeatedly without waiting, I believe it could overwrite a buffer while/before it appears on screen.

So I believe like on Wayland, buffer_mut should wait for buffer release. I guess it would have to poll the device fd, and use drm::control::device::receive_events to see if it's gotten Event::PageFlip yet.

...but would Winit or another "windowing" backend using DRM also poll the same fd? Is there any way to manage this?

I'm not sure if there is a way to do this on DRM. Please tell me if I'm wrong, but I think the current way of doing things is the only way.

[ids1024]

I guess buffer_mut could have a comment noting it blocks for buffer release on Wayland, and on DRM, should not be called until after waiting for pageflip?

Looking at https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/dri2/platform_drm.c and https://github.com/libsdl-org/SDL/blob/main/src/video/kmsdrm/SDL_kmsdrmopengles.c, it seems like EGL manages this in some way with functions called gbm_surface_lock_front_buffer and gbm_surface_lock_front_buffer, but I don't entirely follow the logic there and it's not clear that anything like that could make sense in softbuffer. I guess that's something Glutin would have to deal with for DRM support.

[notgull]

I guess buffer_mut could have a comment noting it blocks for buffer release on Wayland, and on DRM, should not be called until after waiting for pageflip?

Done.

I was mostly following rust-windowing/glutin#1403, which appears to use fencing in a way that I don't know how to accommodate in softbuffer with DUMB buffers. As far as I know there's not a real way to say "fence a DUMB buffer off" like there is in GBM.

[ids1024]

Seems like DIRTYFB is returning ENOSYS. Removing that call makes the example work.

I guess that's expected with some drivers? Don't know if simply ignoring ENOSYS and doing nothing else is correct here. DRM isn't the best documented thing in the world...