RE: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@xxxxxxxxx]
> Sent: Wednesday, June 22, 2016 9:13 AM
> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> Cc: gabriele.mzt@xxxxxxxxx; mjg59@xxxxxxxxxxxxx; dvhart@xxxxxxxxxxxxx;
> kernel@xxxxxxxxxx; luto@xxxxxxxxxx; alex.hung@xxxxxxxxxxxxx; platform-
> driver-x86@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 3/4] dell-wmi: Add information about other WMI event
> codes
> 
> On Wednesday 22 June 2016 13:40:57 Mario_Limonciello@xxxxxxxx wrote:
> > > > You aren't seeing this on the DSDT of your Latitude right?
> > >
> > > Yes, I do not see it on Latitude.
> >
> > Thanks, the usage of this scan code is specific to consumer BIOSes.
> >
> > >
> > > > Gabriele,
> > > >
> > > > Your machine is from the year before XPS switched over to running the
> > > > Dell business client (eg Latitude, Precision, Optiplex) BIOS.
> > > >
> > > > The EC in that machine does have support for "Battery Health" via that
> > > > scancode.  On Windows it's used for relaying battery information to an
> > > > application called Quick Set.
> > >
> > > Do you have some details when it is send to OS? And how to read that
> that
> > > "battery health"?
> >
> > When a battery is removed or inserted this event is supposed to be
> received
> > by quickset over WMI and then Quickset will re-read battery information.
> 
> So event is sent only if battery is removed or inserted?
> 

Yeah, that's what my spec says, I haven't tested this on actual system to see.

I'm guessing what's going on is that during suspend ACPI battery drops
off system and comes back up on resume.

Maybe Gabriele can comment if any other times were noticed, but in any
case I think it's appropriate for dell-wmi driver when receiving this on WMI
to not do anything.  Sending KEY_BATTERY would be wrong behavior.

> > 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.
��.n��������+%������w��{.n������_���v��z����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux