It’s very simplified case of WayPipe which routes Wayland communication over network and adds network transparency to Wayland protocol. An initial idea popped out in discussion to create a proxy between Firefox and Wayland compositor to cache messages and prevent compositor message queue overflow. īut Firefox needs to solve the crashes caused by message jam right now as it’s shipped to wide audience. There are various discussions going on, but they’re stalled too as well as discussion about PIP – Picture-in-Picture Wayland protocol extension implementation. The most visible example is Wayland compositor crash which takes down all applications, there isn’t any recovery point available. Once the connection is lost / disconnected, there isn’t any way how it can be restored and Wayland client is terminated. Unfortunately Wayland protocol doesn’t implement any kind of display connection management. It may be a bug in application itself (an event loop is not processed) or it’s caused by input devices like 1000 Hz mouse which generates too many events. It usually means Wayland client doesn’t read messages from Wayland display socket fast enough and compositor message output buffer is full. Mutter (and maybe other ones) terminates Wayland client if it’s recognized as stalled. One of Firefox Wayland top crash bug is a Lost connection to Wayland compositor one. Wayland merged window manager (like Metacity) and renderer (X11) to one block. In X11 world an underlying X.Org implementation is the same for every desktop environment and there are differences introduced by window managers. There are three main Wayland compositors (Mutter/Gnome, KWin/KDE and WLRoots/Sway) and every compositor behaves differently in some corner cases not exactly defined by Wayland standards (or bents the specification somehow). Wayland clients (applications) may face various difficulties not primary caused by them.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |