linux-kernel - RE: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jul 2016 15:36:19 +0000
From:	<Mario_Limonciello@...l.com>
To:	<pali.rohar@...il.com>
CC:	<dvhart@...radead.org>, <linux-kernel@...r.kernel.org>,
	<platform-driver-x86@...r.kernel.org>
Subject: RE: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s

> > >
> > > Anyway, what is "Wifi Catcher"? HW switch buttton which
> > > enable/disable wifi? Or something else?
> >
> > Wifi catcher was a special hardware switch slider switch.  When the
> > machine was turned in S3 the sliding the switch beyond the on
> > position would scan for available wifi networks and light up an LED
> > if some from your predefined list were found.
> >
> > When the machine was on, it would open up the applet that let you
> > configure the behavior for the switch in S3.
> 
> Hm... maybe it better fit KEY_WLAN then? Just speculation.
> 

Yeah, I think that's a good fit.  I'll adjust that when I resubmit the
rugged patch shortly.

> > > > So there should be no "real" clash here.
> > >
> > > Problem can be in future. This driver is unified for all Dell
> > > products with wmi interface and so future product could do some
> > > nasty things...
> >
> > I agree with Darren here.
> >
> > At least on Dell side we're creating new codes for "new" buttons and
> > the limitation is really on the kernel side for how many KEY_PROG#
> > or similar functions they can be re-assigned to.
> 
> Ok.
> 
> > Maybe it's time to think of another way to get this information to
> > userspace rather that always translating them into key codes?
> 
> If event is generated by pressing key, button or hw switch, then input
> key is correct way. If there is no KEY define which fit for new vendor
> hw button, then I think we should start discussion with input subsystem
> how to handle such situation.
> 
> > There's a lot that are marked as KE_IGNORE because the kernel can't
> > do anything interesting with them as no 1-1 mapping exists to a
> > keycode.
> 
> Most marked as KE_IGNORE are because duplicate event is sent via
> keyboard controller or via other subsystem (e.g. rfkill).
> 
> But events which are not keys or buttons should not be sent via input
> devices. At least I think it is against usage of input devices.
> 
> Events like "battery was removed" or "keyboard backlight was changed" or
> "battery lifetime decreased under X %" can be useful for userspace
> applications. I agree. But I think we do not have any subsystem or
> interface for sending them from kernel to userspace.
> 
> If we start talking about creating interface for it, I would rather see
> something more generic, not Dell-only specific or created specially for
> Dell machines which will not fit for others...
> 

I don't think it needs to be Dell specific, I'm sure plenty of other platform
drivers would use it too.

If this interface is created we can figure out which ones really are useful
notifications to userspace.