Winit: Implement kms backend?

[goddessfreya]

Right, so there was some chatter about implementing a kmsmod backend like SDL's. Mouse input could be provided by a library outside of winit that uses evdev.

Such a backend would allow us to run applications in the tty, without the presence of X11/Wayland/DirectFB, which I'm sure would open up a lot of silly possibilities. To use alacritty as an example, such a backend would allow it to replace similar projects like kmscon, which I think would kind of be nifty.

@chrisduerr What's your opinion on running alacritty in the tty?

[Osspial]

Could you provide a link to the SDL discussion and what exactly kmsmod is? I can't seem to find either from some quick google searches.

[chrisduerr]

@chrisduerr What's your opinion on running alacritty in the tty?

Running Alacritty itself in the TTY seems a bit pointless tbh, since it builds on GUI and GPU Acceleration at its foundation, but doesn't provide much functionality when it comes to window management (it instead outsources that to the WM).

However, it would be possible to rewrite the renderer of Alacritty for a TTY backend, but at that point it would probably be easier to just skip glutin/winit completely.

However I've never had any interest in replacing my console, so maybe other people have different opinions here. I don't think it wouldn't be fun to play around with, but I would never upstream support for a PR that implements this since it's just a load of mostly unnecessary (to me) complexity.

And I feel like that might be similar for winit/glutin in general. I'd be curious why this was requested. Which kind of application should this support and who's the target audience? Since many features of winit/glutin probably don't exist there anyways, would it maybe be better to just write a completely separate toolkit? What can winit/glutin provide here that wouldn't have to be written from scratch?

Also additional platforms of course always mean additional work and maintenance overhead. Testing in CI might be difficult and it is probably even more work than just testing linux with a display server. So who would be willing to maintain it? Initial implementation is one thing, but often maintainership is even harder than the initial support.

Of course these are just my two cents, making guesses about a chat conversation I haven't been part of, but in general I'm not immediately in love with the idea.

[goddessfreya]

Could you provide a link to the SDL discussion and what exactly kmsmod is? I can't seem to find either from some quick google searches.

Discussion took place on discord. Go to the gamedev channel on the rust community discord and search for there's one thing winit doesn't do as far as i know that i would like to: run straight out of a terminal.

https://wiki.archlinux.org/index.php/Kernel_mode_setting

[goddessfreya]

but doesn't provide much functionality when it comes to window management (it instead outsources that to the WM).

You're in luck, nor does kmscon.

And I feel like that might be similar for winit/glutin in general. I'd be curious _why_ this was requested. Which kind of application should this support and who's the target audience?

This was suggested for the shits and giggles.

Since many features of winit/glutin probably don't exist there anyways, would it maybe be better to just write a completely separate toolkit? What can winit/glutin provide here that wouldn't have to be written from scratch?

Well the idea was to get existing programs using glutin working in the tty with minimal changes to them. It could be a separate library, of course, but it's going to end up exposing the same api as winit/glutin. Also, most of the features should be present, if we use kmsmod with evdev. If the computer supports hardware cursors, mouse support would even be present. If not, a software impl could probably be schemed up in a separate library.

Testing in CI might be difficult and it is probably even more work than just testing linux with a display server. So who would be willing to maintain it?

Currently we don't test programs in the CI, just make sure they compile. I'd argue testing this backend would be easier than others. Ctrl-alt-F2, cd into glutin, then cargo run --example window, or something like that.

Also additional platforms of course always mean additional work and maintenance overhead. [...] Initial implementation is one thing, but often maintainership is even harder than the initial support.

Agreed. The person who submits it should proably also maintain it. (Altho I suspect this backend will require minimal maintenance.

[vberger]

For what it's worth, this is very similar in scope to what smithay does, if you only keep the backend part and disable the wayland-clients-handling features.

[NickeZ]

If I understand correctly, this would be very cool for security sensitive "embedded" and/or "kiosk" applications where you don't want to run the X11 stack or other c-software full of possible leaks.

[Lokathor]

Yeah the point is that low end devices (raspberry pi, odroid, etc) can have things to display but not want to put an x11 session in RAM.

[aleksander]

So something like kmscube would be possible? Cool!

[cheako]

kmscon isn't maintained anymore, I'll just call this virtual console? To write an abstraction layer for an application to choose from winit and an internal handler for virtual console might be just the same as writing a eventloop for winit. I'd like to get a feeling for how well something like winit/src/platform_impl/linux/vc would be received?

[Lokathor]

SDL2 supports DirectFB in their docs and I was able to get it to open a fullscreen window on my rpi without turning on X. Was it probably going through DirectFB when it did that? Should we support DirectFB as a driver?

[goddessfreya]

kmscon isn't maintained anymore,

kmscon != kms.

[jamadazi]

Everyone is going on about using this for alacritty for a kms-based console. While that is cool, it is just one use case. I'd like to point out other awesome use cases for this functionality:

1. GUIs for embedded systems. If you only have one single fullscreen application that should have total control of everything and the user should directly interact with. It would be nice for that application to run without requiring X11 or a wayland compositor or anything of that sort. Just launch it and it takes care of its display and rendering and input on its own however it likes (using this proposed winit functionality).

2. Games. This would allow to develop a game that effectively has direct access to the display, GPU, input, etc. This would remove any overhead that would otherwise come from the windowing system protocol / compositor and result in the best possible performance and latency.

[nezticle]

I see this as very analogous to what we have in Qt with the EGLFS platform: https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/eglfs
This itself has a lot of complication because there are a couple of different approaches to actually get the EGLDisplay and EGLSurface (fbdev, drm/kms), and then further there are sometimes vendor specific tricks you have to do as well. In the case of the EGLFS plugin there are additional plugins to handle this, which is much more complicated than the current platforms support. So maybe check out EGLFS for some inspiration for how this could look/work here.