Message-Id: <201607282122.40816@pali>
Date:	Thu, 28 Jul 2016 21:22:40 +0200
From:	Pali Rohár <pali.rohar@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	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).

> > > - 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@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists