Ok, I have been doing some research. Seems like we can have some short term
mixed approach as Adrien suggested. But I want to share with you what I've
learnt.
On current driver model, once a usb hid device is plugged, root collections
are iterated and a handler may be added per collection. In fact, a
collection can be handled by 0 to N handlers available. Handlers try to
avoid overlap, so typically, a collection is handled by only one handler.
Keyboard handler is perhaps too generic and maybe this is why it seems like
a default handler, but it isn't.
Handlers expose themselves at user space using a path like
/dev/input/tablet/usb/0 or /dev/input/keyboard/ps2/0. So input server
add-ons have some filtering already done.
If we expose the hid device on user space, lets say /dev/input/hid/usb/0,
Input add-ons will have to probe the device, that is, request the report
descriptor, parse it and look for known usages. Another possibility is
having a single input add-on handling all HID devices.
Thinking about BJoystick, it will need to probe all hid devices each time
the joystick count is requested.
I just wanted to expose those things I had some bad feelings about it. What
do you think?
El lun, 28 mar 2022 a las 21:19, Fredrik Holmqvist (<
fredrik.holmqvist@xxxxxxxxx>) escribió:
Den mån 28 mars 2022 kl 21:11 skrev Adrien Destugues <
pulkomandy@xxxxxxxxxxxxx>:
I'm not sure if one driver per ACPI event is a great design. Maybe we
need a better protocol.
It will also make it easier to add more events from ACPI, I think.
But routing these events directly to the power_daemon seems good to me.
Even when input_server
is crashed, you can still use this to cleanly power off the system, for
example.
As far as I understand, vendors tend to map special buttons to ACPI, so
not just power related. Think FN + F<number>
An example: https://wiki.gentoo.org/wiki/ACPI/ThinkPad-special-buttons
/Fredrik Holmqvist, TQH
