6 ms·

I am now curious, though. How does Wayland handle key events? I have to imagine it only lets the active window listen in on key events, right? Maybe there's an

I am now curious, though. How does Wayland handle key events? I have to imagine it only lets the active window listen in on key events, right? Maybe there's an API for subsribing to specific key combinations?

chrisseaton 5y ago
> Maybe there's an API for subsribing to specific key combinations? Why would you ever let a non-focused application subscribe to any key combinations?
- pjc50 5y ago
  https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa https://docs.microsoft.com/en-us/windows/win32/api/winuser/n... : for global hotkeys.
  - deleted 5y ago
    [deleted]
  - chrisseaton 5y ago
    That doesn't seem like something that an application should be getting involved with. An application should only be able to manage its own windows and key presses to its own window.
    - R0b0t1 5y ago
      Problematic. Means you are relying on the DE for all UI development. With Windows and X11 the DE is reconfigurable to some extent by applications. There is also more to this, showing the Wayland security model is incoherent. If debugging is enabled on your system I can simply debug your root terminal and start injecting commands into memory.
      - zxzax 5y ago
        Wayland obviously cannot solve all security issues and privilege escalations in the underlying OS -- the solution to that problem would be to just disable debugging within that security context. In Wayland the situation is also not so much different from Windows, you would just reconfigure and extend the DE itself. You are already relying on them to provide most of the UI to an extent.
        R0b0t1 5y ago
        In regards to your first point, I am saying that Wayland does not do what it sets out to do and the proper way of doing it is a much larger problem than what Wayland can address. It is possibly better to avoid breaking everyone's stuff if you're just going to need to shortly do it again to fix the things Wayland does not and can not fix. For your latter point, Wayland is much different. In Windows there are ways to inject behavior into other programs or the UI elements. This exists so you can change the UI. Wayland's idea of security is very much against that, at least in the way it can be done on Windows/X11.
        zxzax 5y ago
        I don't know what you mean you'll need to break it again, this one particular hole is already plugged in Wayland. That won't cause additional breakage, and you'll still want to be plugging those additional holes like ptrace anyway. Input injection is being worked on in a different library, that brings a standard API that's supposed to work the same across Wayland, X11, and with sandboxed contexts: https://gitlab.freedesktop.org/libinput/libei https://gitlab.freedesktop.org/libinput/libei
    - reificator 5y ago
      So if I'm in my text editor and decide I want to change the currently playing song, I need to switch windows/contexts, press a hotkey or GUI button, and switch back? The current model where everything running can listen to everything you do is not acceptable, but that doesn't mean there's no usecases that strongly benefit from global hotkeys.
      - chrisseaton 5y ago
        > So if I'm in my text editor and decide I want to change the currently playing song, I need to switch windows/contexts, press a hotkey or GUI button, and switch back? Looks to me like something the DE should manage for you, not the application. But everyone seems to disagree with me!
        TeMPOraL 5y ago
        But how do you teach your DE to do new things for you? And what is your DE in the first place? The answer to both these questions is: an application. Think of applications hooking into global shortcuts as plugins for your DE.
        reificator 5y ago
        > Looks to me like something the DE should manage for you, not the application. > But everyone seems to disagree with me! The original post you responded to was suggesting that your DE, or at least something outside of your application, provide an API to register specific global hotkeys that you can listen for. In response, you said: > Why would you ever let a non-focused application subscribe to any key combinations? So to me when reading this thread, it looks like you're the one disagreeing with this idea. This is the first post of yours I've seen where you suggest this, and the thread begins with you shooting down the entire concept as ridiculous. Unless you're suggesting that the DE comes with a preconfigured set of global hotkeys and cannot be altered or extended, nor handled differently by different applications. In which case yes, I strongly disagree with that. There's a reasonable middleground between a free-for-all and nothing but what the DE already thought of, and that's a well-defined API boundary alongside per-application, per-feature permissions. Bonus points if the DE handles all key-combination assignment in a consistent UI and applications can only register a suggested keycombo, a context for when the hotkey should be activated, and a function to respond to the event.
    - TeMPOraL 5y ago
      Depends on an application. Plenty of applications have a legitimate reason to hook into global keyboard handlers, or otherwise instrument other applications or the system itself. Removing that capability would be crippling to the utility of a computer. It sort of works in the mobile space (+/- accessibility services, which are the way to get that functionality if you need it), but that's only because mobile devices are consumption-oriented; there's only so much you can do with them, and they eschew utility in order to streamline you into being monetized by third-party services.
    - simion314 5y ago
      Not all applications need to be a classic "windowed application". I know this is a rare use case, but the DE and the app need to work togheter to allow global shortcuts. I for example have a keyboard with many useless media keys , that I configured to run some specific scripts and some I could very easy set them up as Global shortcuts for some KDE apps. Not sure if other DEs would offer to setup global shortcuts for you. Probably something most users will use is screen recordings and screen readers , this applications need to have global shortcuts(and access to the screen and window elements)
- yjftsjthsd-h 5y ago
  In order to implement https://www.semicomplete.com/projects/keynav/ https://www.semicomplete.com/projects/keynav/ (or anything else that listens for a specific key combo to activate)
  - chrisseaton 5y ago
    Isn't that kind of thing the responsibility of the desktop environment service? Not an application?
    - yjftsjthsd-h 5y ago
      I suppose the proper answer is that that very much depends on your philosophy of desktop environments; I happen to prefer modular desktops built out of separate programs from separate authors which may or may not even know about each other. This has the advantage of making it trivial to retrofit new features without needing to ask your DE upstream. Or to be more pithy: Okay, fine; what desktop environments implement keynav? With X11, I can make the answer be "(probably) all of them".
    - riskable 5y ago
      As long as the desktop environment provides a mechanism for applications to register their global shortcuts then all is well. However, without such a feature the application has to just listen for all keystrokes and check if it matches something the user's configured. Example: I've bound several scenes in OBS to keyboard shortcuts so that I can switch scenes no matter what application I'm in. I'm pretty sure OBS does this by listening to all keyboard events on the root window. It's not very efficient, but it works. Now imagine having to support a global shortcut daemon per DE that exists. I suppose someone would write an abstraction but really, it's something that FreeDesktop.org should provide (if it already doesn't).
- jeroenhd 5y ago
  WorkRave can't function well without it. Currently, it's working through a compatibility layer I think, but if that breaks, the application can't be made to work on Wayland AFAIK. Alternative shortcut managers might also run into trouble (say, clipboard managers with customizable shortcuts) although those could work with a simple permission prompt for each new shortcut. Very annoying and obtrusive to the user, but the security principles remain. There are also tools that extend some window managers with i3-like shortcuts and configurations; the config files are parsed on the fly and they need to work in the background. Then there's tools like AutoHotkey that can be great tools for productivity through scripting and custom shortcuts. A lot of AH's functionality can be replicated using the standard hotkey API, but not everything. There's also diagnostic tools (see Windows Steps Recorder) that record all keystrokes and generate a step by step report about what happened with screenshots as a guide. IMO global key capture should still be possible with the right capabilities set because there are valid use cases for it. Requiring additional permissions is fine IMO, but completely removing the option to do this is a pain.
- joaonmatos 5y ago
  Global Hotkeys for something like Quake terminal, or voice chat push-to-talk. Obviously I don't see why you would encumber the core protocol for it, but a subscription model for it as a wlroots or FreeDesktop portal could be interesting.
- reificator 5y ago
  > Why would you ever let a non-focused application subscribe to any key combinations? * Media playback controls * Hotkeys to take screnshots, or record videos * Quake style terminals * Ingame chat and game invites * Color pickers * Screen controls like F.lux * Window management hotkeys * Push-to-Talk in group voice calls And that's just what I personally use on my own machine. It's a massive security issue that any installed software can listen to any input activity or view/affect other windows, and that does need to be reigned in. But to claim that there's no legitimate utility to global hotkeys is absurd. We need robust permissions, not a completely crippled experience.
  - topaz0 5y ago
    In my experience most of these use cases are handled on linux by the window manager calling a script that sends a message to the relevant application, e.g. over dbus.
    - reificator 5y ago
      Sure, and that works fine. Just let my application tell the window manager: * What key events I care about. (I.E. what the keybind should be named in the settings UI) * What script or message to pass back to me when that event is activated. * What the default keycombo should be, if any.
    - michaelmrose 5y ago
      Some applications prefer to provide a ui for the user to configure a hotkey. This is naturally discoverable within the scope of the other settings in its preferences screen. Providing a cli interface for automation or binding a hotkey is imo more powerful and useful but its not discoverable. Doubly so for a controlling it over dbus. The logical thing is that since there is a substantial use case and a desire to limit applications access to global info is that a permission system ought to have been built into Wayland such that applications could request not only global access to the keyboard but permission to get a notification when a particular key press happened. Since this feature was a staple of desktop operating systems for decades it ought to have been part of the plan from the start.
- pdkl95 5y ago
  I am currently writing a utility to spy on Super Hexagon's KeyPress/KeyRelease XEvents with the goal of recording very precise timestamps for each event. Since the walls in the game arrive at a constant rate, I want to graph my keypress/keyrelease events modulo the time between walls. My success rate for finishing Hyper Hexagonest[1] is falling; being able to inspect recent attempts might reveal where my timing is drifting. (it's only ~25%-ish finished, unfortunately) [1] https://www.youtube.com/watch?v=JJ96olZr8DE https://www.youtube.com/watch?v=JJ96olZr8DE
- tjalfi 5y ago
  PureText[0] is a Windows application I use regularly. It adds a keyboard shortcut for pasting as plain text. [0] https://stevemiller.net/puretext/ https://stevemiller.net/puretext/
ashafer 5y ago
iirc it's pretty much completely up to the compositor. The spec is worded to allow "focus" to enter a surface and deliver events to it, but it never specifies under what conditions the compositor should do so. So the compositor chooses what surface to deliver events to based on its own desires (like letting pointer focus enter background apps) and the users input. I think there is a protocol (used by Xwayland?) to allow a client to get events from any window if the compositor/user allows it
- Cloudef 5y ago
  That's how it is. It's up to compositor to decide what events to send to what clients. Usually this means compositor only forwards input events to the focused surface.

chrisseaton 5y ago

> Maybe there's an API for subsribing to specific key combinations? Why would you ever let a non-focused application subscribe to any key combinations?

pjc50 5y ago
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa https://docs.microsoft.com/en-us/windows/win32/api/winuser/n... : for global hotkeys.
- deleted 5y ago
  [deleted]
- chrisseaton 5y ago
  That doesn't seem like something that an application should be getting involved with. An application should only be able to manage its own windows and key presses to its own window.
  - R0b0t1 5y ago
    Problematic. Means you are relying on the DE for all UI development. With Windows and X11 the DE is reconfigurable to some extent by applications. There is also more to this, showing the Wayland security model is incoherent. If debugging is enabled on your system I can simply debug your root terminal and start injecting commands into memory.
    - zxzax 5y ago
      Wayland obviously cannot solve all security issues and privilege escalations in the underlying OS -- the solution to that problem would be to just disable debugging within that security context. In Wayland the situation is also not so much different from Windows, you would just reconfigure and extend the DE itself. You are already relying on them to provide most of the UI to an extent.
      - R0b0t1 5y ago
        In regards to your first point, I am saying that Wayland does not do what it sets out to do and the proper way of doing it is a much larger problem than what Wayland can address. It is possibly better to avoid breaking everyone's stuff if you're just going to need to shortly do it again to fix the things Wayland does not and can not fix. For your latter point, Wayland is much different. In Windows there are ways to inject behavior into other programs or the UI elements. This exists so you can change the UI. Wayland's idea of security is very much against that, at least in the way it can be done on Windows/X11.
        zxzax 5y ago
        I don't know what you mean you'll need to break it again, this one particular hole is already plugged in Wayland. That won't cause additional breakage, and you'll still want to be plugging those additional holes like ptrace anyway. Input injection is being worked on in a different library, that brings a standard API that's supposed to work the same across Wayland, X11, and with sandboxed contexts: https://gitlab.freedesktop.org/libinput/libei https://gitlab.freedesktop.org/libinput/libei
  - reificator 5y ago
    So if I'm in my text editor and decide I want to change the currently playing song, I need to switch windows/contexts, press a hotkey or GUI button, and switch back? The current model where everything running can listen to everything you do is not acceptable, but that doesn't mean there's no usecases that strongly benefit from global hotkeys.
    - chrisseaton 5y ago
      > So if I'm in my text editor and decide I want to change the currently playing song, I need to switch windows/contexts, press a hotkey or GUI button, and switch back? Looks to me like something the DE should manage for you, not the application. But everyone seems to disagree with me!
      - TeMPOraL 5y ago
        But how do you teach your DE to do new things for you? And what is your DE in the first place? The answer to both these questions is: an application. Think of applications hooking into global shortcuts as plugins for your DE.
      - reificator 5y ago
        > Looks to me like something the DE should manage for you, not the application. > But everyone seems to disagree with me! The original post you responded to was suggesting that your DE, or at least something outside of your application, provide an API to register specific global hotkeys that you can listen for. In response, you said: > Why would you ever let a non-focused application subscribe to any key combinations? So to me when reading this thread, it looks like you're the one disagreeing with this idea. This is the first post of yours I've seen where you suggest this, and the thread begins with you shooting down the entire concept as ridiculous. Unless you're suggesting that the DE comes with a preconfigured set of global hotkeys and cannot be altered or extended, nor handled differently by different applications. In which case yes, I strongly disagree with that. There's a reasonable middleground between a free-for-all and nothing but what the DE already thought of, and that's a well-defined API boundary alongside per-application, per-feature permissions. Bonus points if the DE handles all key-combination assignment in a consistent UI and applications can only register a suggested keycombo, a context for when the hotkey should be activated, and a function to respond to the event.
  - TeMPOraL 5y ago
    Depends on an application. Plenty of applications have a legitimate reason to hook into global keyboard handlers, or otherwise instrument other applications or the system itself. Removing that capability would be crippling to the utility of a computer. It sort of works in the mobile space (+/- accessibility services, which are the way to get that functionality if you need it), but that's only because mobile devices are consumption-oriented; there's only so much you can do with them, and they eschew utility in order to streamline you into being monetized by third-party services.
  - simion314 5y ago
    Not all applications need to be a classic "windowed application". I know this is a rare use case, but the DE and the app need to work togheter to allow global shortcuts. I for example have a keyboard with many useless media keys , that I configured to run some specific scripts and some I could very easy set them up as Global shortcuts for some KDE apps. Not sure if other DEs would offer to setup global shortcuts for you. Probably something most users will use is screen recordings and screen readers , this applications need to have global shortcuts(and access to the screen and window elements)
yjftsjthsd-h 5y ago
In order to implement https://www.semicomplete.com/projects/keynav/ https://www.semicomplete.com/projects/keynav/ (or anything else that listens for a specific key combo to activate)
- chrisseaton 5y ago
  Isn't that kind of thing the responsibility of the desktop environment service? Not an application?
  - yjftsjthsd-h 5y ago
    I suppose the proper answer is that that very much depends on your philosophy of desktop environments; I happen to prefer modular desktops built out of separate programs from separate authors which may or may not even know about each other. This has the advantage of making it trivial to retrofit new features without needing to ask your DE upstream. Or to be more pithy: Okay, fine; what desktop environments implement keynav? With X11, I can make the answer be "(probably) all of them".
  - riskable 5y ago
    As long as the desktop environment provides a mechanism for applications to register their global shortcuts then all is well. However, without such a feature the application has to just listen for all keystrokes and check if it matches something the user's configured. Example: I've bound several scenes in OBS to keyboard shortcuts so that I can switch scenes no matter what application I'm in. I'm pretty sure OBS does this by listening to all keyboard events on the root window. It's not very efficient, but it works. Now imagine having to support a global shortcut daemon per DE that exists. I suppose someone would write an abstraction but really, it's something that FreeDesktop.org should provide (if it already doesn't).
jeroenhd 5y ago
WorkRave can't function well without it. Currently, it's working through a compatibility layer I think, but if that breaks, the application can't be made to work on Wayland AFAIK. Alternative shortcut managers might also run into trouble (say, clipboard managers with customizable shortcuts) although those could work with a simple permission prompt for each new shortcut. Very annoying and obtrusive to the user, but the security principles remain. There are also tools that extend some window managers with i3-like shortcuts and configurations; the config files are parsed on the fly and they need to work in the background. Then there's tools like AutoHotkey that can be great tools for productivity through scripting and custom shortcuts. A lot of AH's functionality can be replicated using the standard hotkey API, but not everything. There's also diagnostic tools (see Windows Steps Recorder) that record all keystrokes and generate a step by step report about what happened with screenshots as a guide. IMO global key capture should still be possible with the right capabilities set because there are valid use cases for it. Requiring additional permissions is fine IMO, but completely removing the option to do this is a pain.
joaonmatos 5y ago
Global Hotkeys for something like Quake terminal, or voice chat push-to-talk. Obviously I don't see why you would encumber the core protocol for it, but a subscription model for it as a wlroots or FreeDesktop portal could be interesting.
reificator 5y ago
> Why would you ever let a non-focused application subscribe to any key combinations? * Media playback controls * Hotkeys to take screnshots, or record videos * Quake style terminals * Ingame chat and game invites * Color pickers * Screen controls like F.lux * Window management hotkeys * Push-to-Talk in group voice calls And that's just what I personally use on my own machine. It's a massive security issue that any installed software can listen to any input activity or view/affect other windows, and that does need to be reigned in. But to claim that there's no legitimate utility to global hotkeys is absurd. We need robust permissions, not a completely crippled experience.
- topaz0 5y ago
  In my experience most of these use cases are handled on linux by the window manager calling a script that sends a message to the relevant application, e.g. over dbus.
  - reificator 5y ago
    Sure, and that works fine. Just let my application tell the window manager: * What key events I care about. (I.E. what the keybind should be named in the settings UI) * What script or message to pass back to me when that event is activated. * What the default keycombo should be, if any.
  - michaelmrose 5y ago
    Some applications prefer to provide a ui for the user to configure a hotkey. This is naturally discoverable within the scope of the other settings in its preferences screen. Providing a cli interface for automation or binding a hotkey is imo more powerful and useful but its not discoverable. Doubly so for a controlling it over dbus. The logical thing is that since there is a substantial use case and a desire to limit applications access to global info is that a permission system ought to have been built into Wayland such that applications could request not only global access to the keyboard but permission to get a notification when a particular key press happened. Since this feature was a staple of desktop operating systems for decades it ought to have been part of the plan from the start.
pdkl95 5y ago
I am currently writing a utility to spy on Super Hexagon's KeyPress/KeyRelease XEvents with the goal of recording very precise timestamps for each event. Since the walls in the game arrive at a constant rate, I want to graph my keypress/keyrelease events modulo the time between walls. My success rate for finishing Hyper Hexagonest[1] is falling; being able to inspect recent attempts might reveal where my timing is drifting. (it's only ~25%-ish finished, unfortunately) [1] https://www.youtube.com/watch?v=JJ96olZr8DE https://www.youtube.com/watch?v=JJ96olZr8DE
tjalfi 5y ago
PureText[0] is a Windows application I use regularly. It adds a keyboard shortcut for pasting as plain text. [0] https://stevemiller.net/puretext/ https://stevemiller.net/puretext/

ashafer 5y ago

iirc it's pretty much completely up to the compositor. The spec is worded to allow "focus" to enter a surface and deliver events to it, but it never specifies under what conditions the compositor should do so. So the compositor chooses what surface to deliver events to based on its own desires (like letting pointer focus enter background apps) and the users input. I think there is a protocol (used by Xwayland?) to allow a client to get events from any window if the compositor/user allows it

Cloudef 5y ago
That's how it is. It's up to compositor to decide what events to send to what clients. Usually this means compositor only forwards input events to the focused surface.