linux-kernel - Re: [PATCH 1/2] HID: logitech-hidpp: add battery support for HID++ 2.0 devices

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, 11 Jul 2016 13:03:01 +0200
From:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:	Bastien Nocera <hadess@...ess.net>
Cc:	Peter Hutterer <peter.hutterer@...-t.net>,
	Jiri Kosina <jikos@...nel.org>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Nestor Lopez Casado <nlopezcasad@...itech.com>
Subject: Re: [PATCH 1/2] HID: logitech-hidpp: add battery support for HID++
 2.0 devices

On Jul 08 2016 or thereabouts, Bastien Nocera wrote:
> On Fri, 2016-07-08 at 16:35 +0200, Bastien Nocera wrote:
> > On Wed, 2016-06-29 at 19:28 +1000, Peter Hutterer wrote:
> > > +static int hidpp_battery_get_property(struct power_supply *psy,
> > > +                                     enum power_supply_property
> > > psp,
> > > +                                     union power_supply_propval
> > > *val)
> > > +{
> > > +       struct hidpp_device *hidpp = power_supply_get_drvdata(psy);
> > > +       int ret = 0;
> > > +
> > > +       switch(psp) {
> > > +               case POWER_SUPPLY_PROP_STATUS:
> > > +                       val->intval = hidpp->battery.status;
> > > +                       break;
> > > +               case POWER_SUPPLY_PROP_CAPACITY:
> > > +                       val->intval = hidpp->battery.level;
> > > +                       break;
> > > +               default:
> > 
> > You forgot to handle POWER_SUPPLY_PROP_SCOPE. This means that UPower
> > thinks it's supplying power to the computer to which it is connected.
> > 
> > Should be set to "POWER_SUPPLY_SCOPE_DEVICE". This should fix it.
> 
> I've also noticed that my keyboard appears 4 times:
> $ cat /sys/class/power_supply/*/device/input/input*/name
> Logitech K750
> Logitech K750
> Logitech Rechargeable Touchpad T650
> Logitech K750
> Logitech K750

I just tested it again, and it appears we create a power_supply node at
each connect event. Switching the device off and on creates a lot of
those :)

That's easy to fix

> 
> By the way, instead of giving fake values when starting up, you should
> use the ONLINE property instead. That way, when the property changes to
> 1, UPower can start taking the capacity value into account. In the
> meanwhile, it would be ignored.

I couldn't managed to get this working. I played with ONLINE and
PRESENT, but each time the battery was reported with the fake values.

The problem we also see with the Logitech devices is that they do not
provide the battery capacity at all while charging. I think UPower
caches the last known value, and we should probably do the same (and use
the provided hints to give a rough idea depending on the charging
status).

> 
> Finally, things like the serial number and model name and manufacturer
> should be replicated in the power_supply, so that UPower can use them
> too.

That should be easy enough to do.

> 
> Fixing UPower to not do its user-space poking when a device appears
> would be quite complicated. First, the unifier device will show up,
> then as a child, the power_supply subsystem device, so we cannot just
> probe when devices appear, as it would be in the wrong order for us.
> 
> Would it be possible to add a sysfs file that's there in those newer
> versions of the kernel with this patch included? That way, I'd change
> the lines in:
> http://cgit.freedesktop.org/upower/tree/rules/95-upower-csr.rules
> 
> From:
> ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", DRIVER=="logitech-
> hidpp-device", ENV{UPOWER_BATTERY_TYPE}="unifying"
> to:
> ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", DRIVER=="logitech-
> hidpp-device", TEST!="builtin_power_supply",
> ENV{UPOWER_BATTERY_TYPE}="unifying"
> 
> For example.

Seems like a reasonable thing to do. Especially because the power_supply
node is created when the device first gets connected, which means that
you'll see the input node first and then the power supply at some point,
later, or maybe never.

Cheers,
Benjamin

> 
> Sorry about not being able to test this before it was merged for
> inclusion.
> 
> Cheers