On Thursday 28 July 2016 20:49:30 Dmitry Torokhov wrote:
> On Thu, Jul 28, 2016 at 03:52:11PM +0000, Mario_Limonciello@xxxxxxxx
> wrote:
> > > - Even if something is a key/button/switch it does not
> > > necessarily need to be sent through input subsystem or we may
> > > want to wait until we add a new input event. This is because
> > > vendors love to come up with "value add" features that require
> > > vendor specific driver that noone ends up using. I mean, for the
> > > "WiFi catcher" do you have any kind of numbers for the users of
> > > the feature?
> >
> > Like I said, this particular feature hasn't been in use for quite a
> > few generations. In its time it was deemed "beneficial" in that
> > day because of the amount of time it took for waking up the
> > machine only to determine there was no available wifi nearby. It's
> > been superseded by other technology improvements.
> >
> > There are other types of "notification" only events that could be
> > useful to userspace. I don't think they need to all be generally
> > demonized with the connotation as a negative vendor specific value
> > add, there are plenty of generic things that userspace could
> > notify on
>
> Generic things should find a specific system they are part of (i.e.
> wifi notifications -> rflill, wifi switching -> input, etc), it is
> one-off that "sounded good" but are hard to discover by user and
> nobody ends up using that I am demonizing.
User (as consumer) of applications should not discovering such parts.
User just open/configure his favourite gnome/kde/unity/xface/...
application. But developers of wifi/power/led applications must know
where to find those events.
And I need to say, if I change wifi state via rfkill interface, I would
expect that also rfkill interface provides me information about changes.
If I change keyboard backlight level via LED interface, then I somehow
expect that LED interface should be able to tell me information that it
was changed (but that's not truth... yet).
> > that are essentially "killed" at the WMI driver today.
> >
> > Here's a few I find:
> > "Keyboard illumination toggle"
> > "Mic mute toggle"
> > "ALS sensor toggle"
> > " Rotation lock toggle"
> > "Airplane mode toggle"
>
> These all seem valid key events (unless they are not requests to
> execute said actions but rather notifiers of events already
> happened).
Previously "Keyboard illumination toggle" event was translated to
KEY_KBDILLUMTOGGLE, but it later after implementing dell::kbd_backlight
LED driver (software control via /sys/ of keyboard backlight) it was
changed to KE_IGNORE.
Reason was following: All userspace applications (KDE, Unity, upowerd)
understand KEY_KBDILLUMTOGGLE input event as "key for toggling keyboard
backlight level" was pressed. Their answer to that input key is to find
*::kbd_backlight led device in /sys/class/leds and switch keyboard
backlight level to next value.
Dell ACPI/firmware send "Keyboard illumination toggle" event every time
when keyboard backlight level is changed (software via driver or by HW
key press) and all above applications started infinite loop...
So there are difference between:
*) user pressed key with icon of "keyboard illumination", but hardware
did nothing
*) hardware changed keyboard illumination level (either by its own ---
e.g. because of long inactivity of user or user closed LID --- or as
reaction of user request via special driver)
Months ago we agreed that if pressing key with icon "keyboard
illumination" cause 1) emitting key press event (via ACPI/WMI) and also
2) hardware unconditionally change keyboard backlight level, then we
should not send that key press to userspace (as it was already processed
by hardware). Same is for hardware key which block WIFI (as userspace
react on input KEY_RFKILL to block all rfkills).
But I agree that could somehow inform userspace about changes which
hardware did. For rfkills we already support interface when rfkill
device send to userspace all change events.
For keyboard backlight we do not have notify interface yet, but I
proposed that LED subsystem could be extended, so select/poll syscalls
could be used on "brightness" sysfs node (which is used for changing LED
level).
> Are they "killed" because they are also delivered via i8042?
No, (at least on my machine they are sent via WMI).
> > > - In the same vein, we can come up with something generic to
> > > shuffle the crap over to userspace
> > > ("com.vendor.crap.morecrap..." over connector? I think I just
> > > threw into my mouth a little), but do we have consumer for this?
> >
> > I think it would be most equitable to shuffle all notification
> > events over to userspace with a generic connector and let
> > userspace maintainers decide which ones make sense to show to the
> > user.
> >
> > The most logical one to me will be adding patches into
> > gnome-settings-daemon and similar UI interfaces that already
> > display things like brightness and volume changes.
>
> Well, it is really easy to shove stuff up into userspace and say "let
> them deal with it", but we if stuff is useful and applicable to many
> devices, then I am sure there are more specific interfaces that would
> be better suited for such events, and one off will require writing
> "tray notification apps" that we all so love.
>
> Thanks.
--
Pali Rohár
pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
