This repository has been archived by the owner on Nov 1, 2021. It is now read-only.
Add support for keyboard-shortcuts-inhibit #1817
Labels
Comments
michaelweiser
added a commit
to michaelweiser/wlroots
that referenced
this issue
Feb 15, 2020
The keyboard shortcuts inhibitor protocol is useful for remote desktop and virtualization software in order to request all keyboard events to be passed to it and (almost) none being resonded to by the compositor. This allows the session at the other end of the remote desktop connection or inside the virtual machine to be interacted with as usual (e.g. Alt+Tab to switch windows on the remote system instead of locally). Add the wayland protocol to the meson build files. Copy'n'search'n'replace the very similar idle inhibit protocol implementation. This already provides all the basic functionality: - creating and destroying inhibitors upon request by a client, - destruction in reaction to destruction of surfaces or displays, - a list of inhibitors to search through for existing ones as well as - a signal to be sent to the compositor upon registration of a new inhibitor. Beyond that we add the active and inactive events to be sent to the client and wire those to activate and deactivate functions for the compositor to call in confirmation of activation of a new inhibitor or (un-)suspending of an existing inhibitor e.g. in response to a special key combination entered by the user as suggested by the protocol. As mandated by the protocol, we check the existance of an inhibitor for a given surface and seat upon creation and return the error provided by the protocol for that purpose. As an optimisation we add a list of per-surface inhibitors to wlr_surface and a helper that looks up the inhibitor for a given seat and surface based on the focused surface being tracked in the seat's keyboard. This is done on the assumption that most compositors will want to know if the surface keyboard input would currently be sent to if it wasn't interpreted as compositor shortcuts has an inhibitor attached. This also avoids passing the inhibitor manager around to all the places such a check would be needed and then searching the list of all registered inhibitors. Signed-off-by: Michael Weiser <michael.weiser@gmx.de> Closes: swaywm#1817
michaelweiser
added a commit
to michaelweiser/wlroots
that referenced
this issue
Feb 16, 2020
The keyboard shortcuts inhibitor protocol is useful for remote desktop and virtualization software in order to request all keyboard events to be passed to it and (almost) none being resonded to by the compositor. This allows the session at the other end of the remote desktop connection or inside the virtual machine to be interacted with as usual (e.g. Alt+Tab to switch windows on the remote system instead of locally). Add the wayland protocol to the meson build files. Copy'n'search'n'replace the very similar idle inhibit protocol implementation. This already provides all the basic functionality: - creating and destroying inhibitors upon request by a client, - destruction in reaction to destruction of surfaces or displays, - a list of inhibitors to search through for existing ones as well as - a signal to be sent to the compositor upon registration of a new inhibitor. Beyond that we add the active and inactive events to be sent to the client and wire those to activate and deactivate functions for the compositor to call in confirmation of activation of a new inhibitor or (un-)suspending of an existing inhibitor e.g. in response to a special key combination entered by the user as suggested by the protocol. As mandated by the protocol, we check the existance of an inhibitor for a given surface and seat upon creation and return the error provided by the protocol for that purpose. As an optimisation we add a list of per-surface inhibitors to wlr_surface and a helper that looks up the inhibitor for a given seat and surface based on the focused surface being tracked in the seat's keyboard. This is done on the assumption that most compositors will want to know if the surface keyboard input would currently be sent to if it wasn't interpreted as compositor shortcuts has an inhibitor attached. This also avoids passing the inhibitor manager around to all the places such a check would be needed and then searching the list of all registered inhibitors. Signed-off-by: Michael Weiser <michael.weiser@gmx.de> Closes: swaywm#1817
michaelweiser
added a commit
to michaelweiser/wlroots
that referenced
this issue
Feb 17, 2020
The keyboard shortcuts inhibitor protocol is useful for remote desktop and virtualization software in order to request all keyboard events to be passed to it and (almost) none being resonded to by the compositor. This allows the session at the other end of the remote desktop connection or inside the virtual machine to be interacted with as usual (e.g. Alt+Tab to switch windows on the remote system instead of locally). Add the wayland protocol to the meson build files. Copy'n'search'n'replace the very similar idle inhibit protocol implementation. This already provides all the basic functionality: - creating and destroying inhibitors upon request by a client, - destruction in reaction to destruction of surfaces or displays, - a list of inhibitors to search through for existing ones as well as - a signal to be sent to the compositor upon registration of a new inhibitor. Beyond that we add the active and inactive events to be sent to the client and wire those to activate and deactivate functions for the compositor to call in confirmation of activation of a new inhibitor or (un-)suspending of an existing inhibitor e.g. in response to a special key combination entered by the user as suggested by the protocol. As mandated by the protocol, we check the existance of an inhibitor for a given surface and seat upon creation and return the error provided by the protocol for that purpose. Signed-off-by: Michael Weiser <michael.weiser@gmx.de> Closes: swaywm#1817
michaelweiser
added a commit
to michaelweiser/wlroots
that referenced
this issue
Feb 20, 2020
The keyboard shortcuts inhibitor protocol is useful for remote desktop and virtualization software in order to request all keyboard events to be passed to it and (almost) none being resonded to by the compositor. This allows the session at the other end of the remote desktop connection or inside the virtual machine to be interacted with as usual (e.g. Alt+Tab to switch windows on the remote system instead of locally). Add the wayland protocol to the meson build files. Copy'n'search'n'replace the very similar idle inhibit protocol implementation. This already provides all the basic functionality: - creating and destroying inhibitors upon request by a client, - destruction in reaction to destruction of surfaces or displays, - a list of inhibitors to search through for existing ones as well as - a signal to be sent to the compositor upon registration of a new inhibitor. Beyond that we add the active and inactive events to be sent to the client and wire those to activate and deactivate functions for the compositor to call in confirmation of activation of a new inhibitor or (un-)suspending of an existing inhibitor e.g. in response to a special key combination entered by the user as suggested by the protocol. As mandated by the protocol, we check the existance of an inhibitor for a given surface and seat upon creation and return the error provided by the protocol for that purpose. Signed-off-by: Michael Weiser <michael.weiser@gmx.de> Closes: swaywm#1817
filips
pushed a commit
to filips/wlroots
that referenced
this issue
Mar 15, 2020
The keyboard shortcuts inhibitor protocol is useful for remote desktop and virtualization software in order to request all keyboard events to be passed to it and (almost) none being resonded to by the compositor. This allows the session at the other end of the remote desktop connection or inside the virtual machine to be interacted with as usual (e.g. Alt+Tab to switch windows on the remote system instead of locally). Add the wayland protocol to the meson build files. Copy'n'search'n'replace the very similar idle inhibit protocol implementation. This already provides all the basic functionality: - creating and destroying inhibitors upon request by a client, - destruction in reaction to destruction of surfaces or displays, - a list of inhibitors to search through for existing ones as well as - a signal to be sent to the compositor upon registration of a new inhibitor. Beyond that we add the active and inactive events to be sent to the client and wire those to activate and deactivate functions for the compositor to call in confirmation of activation of a new inhibitor or (un-)suspending of an existing inhibitor e.g. in response to a special key combination entered by the user as suggested by the protocol. As mandated by the protocol, we check the existance of an inhibitor for a given surface and seat upon creation and return the error provided by the protocol for that purpose. Signed-off-by: Michael Weiser <michael.weiser@gmx.de> Closes: swaywm#1817
|
How does this work? Does the software itself have to support this in order for it to work? Thanks |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Used by VM software
The text was updated successfully, but these errors were encountered: