Yes, it does. But none of it cannot be fixed, HAL is the really big
offender in userspace, and laptop drivers are the really big offenders in
kernel space.
It is not clear to me if they are notifications or not. Does the firmware
act on the keys by itself? If it does, then they are notifications. If it
does not, then they are regular hot keys and there is no controversy whether
they belong on the input layer or not (they do).
Well, I better make it clear once again. Please excuse me the very direct
and acid tone in the rest of this email, I want to make certain points
crystal clear to everyone (and not just you, I do believe you are already
very aware of my position in this):
1. I am not against sending notification events through input (but see point
two below). However, AFAIK, Dmitry is. He said as much in the last thread
about it. I have added him to the CC list, he can make his position clear
in this thread, if I got it wrong.
Until I get a "you can do it" from Dmitry, forget about thinkpad-acpi
sending such events over the input layer. I believe in a coherent kernel
where the schizophrenia on the use of the various interfaces and subsystems
is kept to a bare minimum. If a subsystem maintainers tell me not to do
something, I won't do it.
2. I am against sending notification events through input **that look
exactly the same as regular events**. That is not a wise design choice IMO,
it is a very dirty hack.
I did propose ways to fix that properly, though (and to write the patches to
do so). Two simple and clean ways come to mind:
1. Add a new EV_* class for such events.
2. Alternatively, add a flags field to the higher bits of EV_*
class that could be used to mark events in a proper way.
And I am sure there are other ways too, so it *can* be done properly if it
is to be done at all. However, it was not accepted because Dmitry does not
want notifications going over the input subsystem as far as I recall from
that thread. Get Dmitry to accept a way to send notifications though the
input layer, and I will follow it.
3. We have a backlight class, a LED class, a rf-kill class and ALSA mixers.
Is there a real reason to pester Dmitry about the issue, if we can use these
alternate paths (that are indeed more generic and more suited for the job)?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
