Message-ID: <01ef781fb68f4ea8965d1ea5e01016b3@ausx13mpc120.AMER.DELL.COM>
Date:	Mon, 1 Aug 2016 22:41:27 +0000
From:	<Mario_Limonciello@...l.com>
To:	<pali.rohar@...il.com>, <dmitry.torokhov@...il.com>
CC:	<dvhart@...radead.org>, <linux-kernel@...r.kernel.org>,
	<platform-driver-x86@...r.kernel.org>, <pavel@....cz>
Subject: RE: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@...il.com]
> Sent: Thursday, July 28, 2016 2:23 PM
> To: Dmitry Torokhov <dmitry.torokhov@...il.com>
> Cc: Limonciello, Mario <Mario_Limonciello@...l.com>;
> dvhart@...radead.org; linux-kernel@...r.kernel.org; platform-driver-
> x86@...r.kernel.org; pavel@....cz
> Subject: Re: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s
> 
> On Thursday 28 July 2016 20:49:30 Dmitry Torokhov wrote:
> > On Thu, Jul 28, 2016 at 03:52:11PM +0000, Mario_Limonciello@...l.com
> > 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).

It really depends upon the vendor's implementation and that key's particular
implementation.  Some of the ones that are KE_IGNORE'ed by the wmi driver
will send something on i8042, others won't.

The ones I'm particularly interested about are the ones that are "NOTIFY" only
and only come across on WMI.

On Windows these are picked up by some application or a filter driver and a 
notification event is shown.

> 
> > > > - 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.
> 

I guess I don't see the use case on reacting to events like I said above
in userspace other than the basic libnotify toast popup.

That at least relays the message to the user that "something" happened
when that key was pressed.  Either FW or kernel would do the actual
activities but userspace would have to do the notification.

Powered by blists - more mailing lists