Isn’t Consumer controls a keyboard device from the user POV? Sending key events?
Most of the time… but not always. Some act as switches, some as push buttons, there are even knobs in -n/n bit range. Also, you don’t want to generate key repeat events on most of consumer usages.
Horizontal mouse wheel is a consumer usage with -n/n values.
How should the generated events be presented to the end user application?
That needs a deeper analysis but I find there is no need for many of them to be presented at end user applications. Volume up/down, Brightness, WWW or Calculator should be handled only at input_server.
However others like Play/Pause, Next/Previous need to be pushed to end user applications. How? I don’t have the answer. For this use case mapping as key strokes may do the trick. But this is something that can be done at input_server.
On Windows unless I’m mistaken, everything is presented to end upser applications, and tasks just set global hotkeys for those.
1 Like
It doesnt harm really…
Do you have any example of a Windows app hooking one of those events?
Like any other keyboard events. For example Play/Pause, Next/Previous keys can control currently focused media player window. Non-focused windows can get events with BView::SetEventMask.
Yeah that use case can be presented as unmapped key strokes but I would not be tempted to present them as keys because there are consumer usages that don’t work as keys.
On older versions of Windows (eg. XP), you needed to install “hotkey” apps from your notebook manufacturer because the shell, by itself, did not handle most of them. More recent versions of Windows do that for you.
As far as the Win32 api goes, you can use the user32 function RegisterHotKey to register a global hotkey that is handled by the window. AFAIK VLC uses this.
I’m not sure about that. I would find it useful to be able to configure these in Shortcuts preferences as any other shortcuts. So the special casing should not be in the input stack. These should be just keys or at least just regular events following the normal path.
Then it’s up to input_server add-ons to decide wether to let these things go to apps, or intercept them and do something special with them.
2 Likes
Yes, let user decide what to do using shortcut preferences would be cool.
But I think, in first place, we have to push all events generated by HID devices to user-space, no matter if input server is just feed by basic ones. That would open the gates for any simple third party app to catch any weird button, knob or rgb light from its device. And of course, for Haiku to provide a better default handling of devices.
I also want to emphasize that consumer usages can’t be all faked as key strokes. We can hardcode a list of most used ones if we want to keep shortcut preferences as it is.
I’ve been some time reading hid code and analyzing how to move to user space. I still don’t have clear if it is possible to keep an hybrid model working while some hid drivers run at kernel and others are ported to user space. Also, it is a big task :\
Concerning the media keys like Play/Pause, on macOS Big Sur (which I use on my work MacBook), the media keys can play and pause videos playing in the browser. There is an icon in the menu bar which shows what will be controlled. It can be a browser tab in the background. I haven’t tested other things like a normal media player but I assume those can be assigned as well. In previous versions of macOS I used an app for this as well (https://beardedspice.github.io/), though it probably still works.
Anyhow, my point is that it would be nice if things like media keys, maybe volume keys, or whatever could be set to go to a particular app to allow for something like this. Or if they produced some standard message. Or some combination of that. It wouldn’t just be about “launching” an app based on the key press, but more like always sending the event to a particular app. Part of this might be the much needed Shortcut preferences revamp.
I think redisigning it is in order, especially because a huge chunk of functionality of applications. That is capabilities discovered through getsuites is inacessible now.
Ideally the new preferences would take a “Press key combo now” aproach to shortcuts so it doesn’t matter that much whether the key is known or not (I mean hey, if you connect a flfire to your computer and want to bind that, why not?)
This should then be “easily” bound to running applications or running specific functions in applications, for example the “play/pause music” function for a media player.
As for binding the keys to not keystrokes, I don’t know. Yes there are controls that are not buttons, but that seems like a bad reason to not bind any of them to buttons, all HID and non-HID media keys I have at home are actuall buttons 
.
(I had adjusted the PS/2 Driver to forward events for keypresses of media keys, according to what osdev wiki has, there is one button i have unbound and one error in the code. But i have not fixed it since the keymap doesn’t forward this currently at all, hence the idea to increase the size of the keymap structure. PS/2 is unlikely to get a “huge” number of new keys anyhow)
One idea I had for the new shortcut preferences was to have a list of “default” actions provided by the system, which would be stuff like “Mail → Open application/x-vnd.Be.URL.mailto” Or user facing “Mail Button → open new draft email”
Users may then be able to just deactivate those rules and provide their own. etc.
2 Likes
Not on gerrit so reply here:
https://review.haiku-os.org/c/haiku/+/5253
“Also, there are some keys proposed that I couldn’t find on HID Consumer tables: Shutdown,sleep, wake, airplane mode… Where do they come from? ACPI? And what scancode do we assign them? I know it is not fully related to this patch but I feel I had to add it here.”
All the keycoded added in https://review.haiku-os.org/c/haiku/+/1695 Have already been added to the PS/2 driver.
https://review.haiku-os.org/c/haiku/+/1675
The patch is at such not a proposed set of keycodes but rather one the PS/2 driver is already emmiting, my keyboard has one sleep button for example.
If you want to change the keycodes it may make sense to replace them in the PS/2 driver aswell.
Edit: Might make sense to discuss this over email more than here though.
I realized this weekend ps/2 driver was already mapping media keys 
Edit: Might make sense to discuss this over email more than here though.
I moved to forums because it seems this is more popular than mail list :\
Yes, I mean I only replied here because I can’t access gerrit and wasn’t sure what your email is. Email makes more sense to me, the popularity aspect doesn’t matter that much, it seems to me that quite often technical discussions on the forum get derailed completely while I’ve never seen that happen to email lists.
Maybe it’s because there is almost no one still using the mailing lists. Back when it was the main communication channel, things would derail all the time, and the complete lack of moderation tools didn’t help. Now there is not a lot of people on the mailing lists, and no discussions going on, so there is nothing to derail.
3 Likes
Ok, here I am again. We had some discussions on gerrit but it went too much offtopic. Not really offtopic but… we seem to agree that Input stack needs some changes but we don’t share an opinion on what or how.
This is what I would like to do:
- All input drivers use the same protocol: An ioctl query returns device name, type and all events this device is capable of. Events are small packets with: timestamp, event type, event value. Yes, this is a clone of what Linux does with evdev, but to be fair it is a simple protocol on both kernel and user space side.
- A kernel side helper class, lets name it InputDevice. This class not only reduces boilerplate on current input device drivers, but also allows wmi/acpi/platform drivers to send input events (brightness, rfkill…)
- Linux seems to use a custom scancode map not aligned with USB. In fact, they not even all USB Consumer usages. (No support for usb golf irons! What a shame!). I propose to stick to USB HUT codes, we already have constants for them and are collision free.
- I would keep consumer events as keystrokes, not the best of designs but it works that way on… all OS? We can change that on the future.
Using HID as wire protocol has been discussed, but for me, it is a no go. It is a hard to parse protocol designed to have a low memory and bandwidth footprint.
4 Likes
The idea was, we have to parse it anyway, it is indeed a complex protocol, so it would be easier to parse it in userspace. This way, kernel side HID drivers would be extremely simple.
But it’s just an idea, apparently you’re the one going to write the code, so you don’t have to listen and especially agree to all ideas, otherwise things will never get anywhere. Write it the way you think is best, and in any case it will be better than what we have now.
Are you going to ask Haiku inc to sponsor purchase of an USB golf iron for testing purpose? 
2 Likes
Also the trip to St Andrews to perform tests. We need to be sure that it works in real conditions… 
1 Like