wayland: add and implement EventLoopExtDrm

[mahkoh]

This extension trait allows general-purpose applications to query the preferred GPU device so that they do not engage the dedicated GPU unnecessarily.

Without such a hint, applications are likely to choose the first available device which will always be the dedicated GPU which is undesirable on mobile devices.

Similarly, on desktop dual-GPU systems where the integrated GPU is otherwise unused, it is preferred for all applications to use the dedicated GPU.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

[mahkoh]

I don't care enough about X to implement this. But it is possible by using the Dri3Open request to get a DRM fd and then calling stat on it.

[kchibisov]

Do we need it on EventLoop itself? In general though, we can just have it entirely in winit-wayland, I also don't care about X11 and not even sure if touching DRI on it is a good idea.

[mahkoh]

In general though, we can just have it entirely in winit-wayland

What would the API look like?

[kchibisov]

I guess pretty much the same as of now, just entirely inside the winit-wayland, so user would get API from the winit-wayland directly and it wouldn't reside in winit.

[mahkoh]

I still don't see how that would work unless you're saying that winit should create a whole separate connection just to fetch this property.

[kchibisov]

Do you need it on EventLoop itself? I'll add that myself if that wasn't clear, but basically, what I want is to have API in winit-wayland not in winit itself, so user after downcasting to winit-wayland's type can invoke the API they want, etc, etc.

[mahkoh]

That would be possible but it is not in sync with the rest of the API as they are right now. Currently the extensions look like this:

pub trait EventLoopExtWayland {
    fn is_wayland(&self) -> bool;
}

pub trait WindowExtWayland {
    fn xdg_toplevel(&self) -> Option<NonNull<c_void>>;
}

If they were changed to

pub trait EventLoopExtWayland {
    fn as_wayland_event_loop(&self) -> Option<&WaylandEventLoop>;
}

pub trait WindowExtWayland {
    fn as_wayland_window(&self) -> Option<&WaylandWindow>;
}

then it would make sense to define this on WaylandEventLoop directly.

[kchibisov]

Yeah, that's the end intent for those things, I'm just busy with other things to finish, though, I can just do it later on myself and we leave this PR as is pretty much.

[mahkoh]

I agree that that design would ultimately be better because the individual functions (xdg_toplevel, etc.) don't have to return Options then.

This PR can wait until the new design is fleshed out.