rust-windowing
Survive wayland compositor crash/restart
Wayland compositors can support reconnecting applications after a compositor crash by keeping their socket alive. This has been implemented in Qt and works great on KDE Plasma. It would be quite nice if winit could also profit from this feature.
For more info on how this could be done, as well as existing implementations in toolkits please take a look at https://invent.kde.org/plasma/kwin/-/wikis/Restarting#adding-support-to-your-toolkit-or-standalone-application
In case you're not quite convinced, here are a couple of good reasons for supporting this.
Please let me know if this should also or instead be reported in Alacritty for example
I'm not quite sure whether winit should support it internally, since one can try create the loop back again, like we can't do that automatically, because you clearly just kill all the objects and you need to replace/recreate everything back again on the client side.
QT can do so, because it's a GUI toolkit and it controls pretty much everything. The main issue is that wl_display changes, thus you need to restart wgpu, etc, which we don't have direct control over. In general, downstream can try to recreate the event loop and try to start back again?
I've noticed you're a contributor to both projects. Should I report this downstream in Alacritty, or is there something to this that is better solved in winit?
If this is impossible or unsuitable for solving in winit please feel free to close this issue.
If this is impossible or unsuitable for solving in winit please feel free to close this issue.
Nah, just keep it here.
@kchibisov if you are sure this isn't solvable in Winit, the issue should be moved or closed.
There're 2 approaches with all of that: throw an error that tells that you have been disconnected, but you can e.g. reconnect. Given that you have to destroy everything and re-create it kind of makes sense.
However what I think is that maybe we could have a separate state where users could transition to and then transition back when error happens, so winit will try to reconnect, and if it succeeds we transition back and users rebuild their stuff during such transition?
The issue is that a lot of resources that are not managed by winit should be dealt with, like OpenGL/Vulkan drivers etc, but state transitions are probably not a bad idea. Though, unless we have 0.31 I'm not sure things will change here.
The original restart is possible though, since IO error is forwarded and application can implement it by itself.
Or maybe wire it to suspend/resume with something that tells that connection got invalidated and restart will be performed, so it's a bit more seemless.
Though, there's unsafe(mesa extension) and safe(drop all the thing) way from a rust point of view.