[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6fdb239b17254606861aab4723b26599@ausx13mpc124.AMER.DELL.COM>
Date: Wed, 22 Jun 2016 14:34:01 +0000
From: <Mario_Limonciello@...l.com>
To: <pali.rohar@...il.com>
CC: <gabriele.mzt@...il.com>, <mjg59@...f.ucam.org>,
<dvhart@...radead.org>, <kernel@...pniu.pl>, <luto@...nel.org>,
<alex.hung@...onical.com>, <platform-driver-x86@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/4] dell-wmi: Add information about other WMI event codes
> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@...il.com]
> Sent: Wednesday, June 22, 2016 9:31 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: gabriele.mzt@...il.com; mjg59@...f.ucam.org; dvhart@...radead.org;
> kernel@...pniu.pl; luto@...nel.org; alex.hung@...onical.com; platform-
> driver-x86@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event
> codes
>
> On Wednesday 22 June 2016 14:28:37 Mario_Limonciello@...l.com wrote:
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:pali.rohar@...il.com]
> > > Sent: Wednesday, June 22, 2016 9:24 AM
> > > To: Limonciello, Mario <Mario_Limonciello@...l.com>
> > > Cc: gabriele.mzt@...il.com; mjg59@...f.ucam.org;
> dvhart@...radead.org;
> > > kernel@...pniu.pl; luto@...nel.org; alex.hung@...onical.com;
> platform-
> > > driver-x86@...r.kernel.org; linux-kernel@...r.kernel.org
> > > Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI
> event
> > > codes
> > >
> > > On Wednesday 22 June 2016 14:21:25 Mario_Limonciello@...l.com
> wrote:
> > > > > > For Linux I don’t think this is necessary and a NOOP is appropriate.
> > > > > >
> > > > > > There is also a second place that some older laptops had a battery
> > > "hotkey"
> > > > > > that would also emit 0xE00E. This was also picked up by quickset
> and
> > > would
> > > > > > show battery information.
> > > > > >
> > > > > > This shouldn't be blocked by kernel, I'd expect if someone wants to
> > > bind
> > > > > this
> > > > > > to another application from userspace they should be able to.
> > > > >
> > > > > Great! Can I send patch after which 0xe00e will be send to input layer
> as
> > > > > event KEY_BATTERY?
> > > > >
> > > >
> > > > Well that's why I was mentioning this in two places. If it's received from
> > > keyboard
> > > > recoding it as KEY_BATTERY sounds appropriate to me. If it's received
> from
> > > WMI,
> > > > it really shouldn't be set as anything for Linux to do.
> > > >
> > > > I don't think any apps will benefit from the notification to re-read
> battery
> > > > Information today.
> > >
> > > I mean for dell-wmi.c code.
> > > Why it should not be set to anything on Linux?
> > >
> >
> > On Windows Quickset is a separate application from built-in Windows
> battery
> > applet. It shows similar types of information as gnome-power-manager
> does,
> > but because it's not part of the OS, it doesn't get notifications like this so
> > special BIOS hooks are in place for it to know when to re-read battery
> > information.
> >
> > On Linux, there are already infrastructure for battery removal and adding
> > notifications from ACPI. Sending this up to user space won't be useful.
>
> Errr. I mean WMI event 0xe00e which you wrote is emitted when user press
> battery key. And I think this event should be sent by dell-wmi.c as
> KEY_BATTERY.
>
No, I mean 0xe00e scancode is emitted when user presses the battery key on
older laptops. I'm only mentioning it because it happens to have the same
scancode as is received for WMI for another purpose and I wanted to make sure
it was clear what both are for.
This button press isn't emitted via WMI, it's over standard serio.
The event received over WMI for battery refresh that shares the same code shouldn't
be emitted as KEY_BATTERY to the OS is all I was trying to say.
Powered by blists - more mailing lists