-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implemented & Planned Wayland protocols #781
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Should the KDE SSD and virtual-keyboard-v1 protocols be supported still? We have xdg-decoration and the v2 of the virtual keyboard protocols already. If clients don't support them, it would probably be better to fix the clients than work around their issues. |
Especially kde-decoration is incredibly small and not really a maintenance burden, but (funnily enough) GTK of all toolkits has not yet moved to xdg-decoration. There is an open PR to fix that, but that one hasn't received attention in years... |
For readers: I've made a PR upstream to fix the issue, and in the process, caused the world to burn: |
Is wp_explicit_synchronization-v1 really obscure? The only user is likely to be Mesa but Mesa is used by just about everything. |
@DemiMarie the ecosystem is still implicitly synced right now, so the v1 protocol is mostly irrelevant - time would be better put towards the v2 protocol and migrating to that. |
@orowith2os ah, okay |
My reasoning when assigning the low priority icons was "are there any compositors that use this protocol", and information on that was gathered by my wlprobe tool (basically wayland-info but outputs JSON). Output of those probes is being published in compositor support section of wayland.app eg. https://wayland.app/protocols/linux-explicit-synchronization-unstable-v1#compositor-support So unless the global is not visible to regular clients (like xwayland_keyboard_grab-v1) this basically means that no mainstream compositor advertises this global. If that's not the case, I might need to remove that badge. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Is wlr input inhibitor planned? I tried today swaylock-effects and requires it (on Niri). |
No. The main use case of this protocol has been replaced by ext-session-lock. swaylock-effects should be updated to use the new protocol (as does upstream swaylock). |
Oh, cool, thanks. Seems there are commits on that project to use the newer protocol. Probably not released yet. Regards |
Core
Stable
Staging
Unstable
Unstandardised
Feel free to edit this as needed.
The text was updated successfully, but these errors were encountered: