linux-kernel - Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp

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:   Mon, 5 Jun 2017 10:01:45 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
cc:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Bastien Nocera <hadess@...ess.net>,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp

On Fri, 2 Jun 2017, Dave Hansen wrote:

> >>>> This will allow upower to not handle those devices anymore and to
> >>>> have more
> >>>> immediate reportng of the device to the system.
> >>> FWIW, I'm on Ubuntu 14.04, and upower *is* reporting my mouse battery
> >>> as
> >>> if it were a laptop battery.  It's mostly garbage, and always reports
> >>> 0%, which makes upower always tell me my laptop is 2/3 charged (I
> >>> have 2
> >>> real batteries).
> > Well, the exported battery might be sending levels instead of
> > pourcentages. And upower needs to be upgraded to handle those :(
> 
> It sounds like there are a number of things here where newer kernels are
> breaking older userspace.  It's also causing some very end-user visible
> effects, like having folks' systems auto shut down because upower thinks
> their batteries are dead.
> 
> Old versions of upower are obviously confused here.  It would be really
> nice to ensure that newer kernels don't break it like this.
> 
> IOW, it would be really nice if this were treated like a regression,
> because it's tantalizingly close.

I agree with Dave. If there is no solution found in time for -rc5, 
reverting to previous state would be the proper way to go.

-- 
Jiri Kosina
SUSE Labs