(In reply to Alastor Wu [:alwu] from comment #6)
Except for keyboard events, I wonder how would the hardware headset events are handling? Are they going to be converted to certain keyboard keycodes and then we can use same mechanism to capture them?
MediaPlayer framework on OSX could handle headset events as well, but I don't know how they would be handled on Windows and Linux. Any ideas?
I think we make the mistake of thinking about Keys here at all. While Keys work when in foreground and there are ways to capture them in the background, this is only some "legacy" or "simple" way of solving things.
MPRIS for instance allows me to use the KDEConnect App on Linux, so I can control Media with my Smartphone, as long as I am in the same local network.
For Windows I'd suspect a headset maybe even having configurable buttons and then some software/driver decides what to do (thinking of gaming headsets, at least).
Both are things we don't need to worry about, as the OS should take care of it and translate it into the desired API.
For Windows: Since my keyboard triggers SMTC without any special knowledge, I guess the OS converts the keycode (as long as no one handles it?) to SMTC.
For Linux: I have no intel here what the Desktop Environment is doing, but I suspect they do it just the same. And if a certain headset doesn't react, then it's a thing between the headset and the DE.
So: Keys would be only relevant when the desired API isn't available, which means Windows < 8.1 or Desktop Environments without D-Bus or MPRIS Handling.
TBH I think we have a few bugs where we mix up keys and media api in general and even pulled in some bug about web extensions global shortcuts which is only related because the example web extension provides like a media session implementation.