-
I was wondering if this would make sense: If a wayland compositor is running and supports SSD, use FDO backend. If SSD is not supported, try the GTK4 backend, if available. If no compositor is running, try the DRM backend. Otherwise if Xorg is running, use the X11 backend. If a WDYT? @aperezdc ? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
Yes, this makes total sense! As a matter of fact, in the devel/multiple-views branch I have automatic selection implemented: each module implements a GIO extension point and one of the functions in the interface allows querying the module whether it's usable in the current environment, and each module has a different priority, so they are probed in order until one of them claims that it can be instantiated. The main commit implementing that logic is d5243b5 and I am planning to port it to the |
Beta Was this translation helpful? Give feedback.
-
The “compositor is running” part is easy to check (try connecting) but the “and supports SSD” part is trickier because a compositor can support SSD, the client can request SSD, and yet the compositor may fail to comply with the requeast and tell the client to use CSD (e.g. the compositor may let the user configure which applications get to use SSD or CSD!). In practice, a Wayland client should be ready to use CSD regardless of what the compositor claims to support. We might want to use something like libdecoration instead 🤔 |
Beta Was this translation helpful? Give feedback.
-
FWIW, I have implemented automatic selection of platform plug-ins in PR #320 😉 |
Beta Was this translation helpful? Give feedback.
FWIW, I have implemented automatic selection of platform plug-ins in PR #320 😉