Re: [PATCH 0/9] HID++ (Logitech Unifying) protocol fixes

2013-08-19 Thread Peter Wu
On Monday 19 August 2013 19:19:04 Julien Danjou wrote: > > Three new patches (on top of the previous ones) are available at > > https://git.lekensteyn.nl/upower/log/?h=hidpp-rework > > > > - hidpp: improve HID++ version detection, fix uninit var > > - hidpp: fix properties for unreachable devices

Re: [PATCH 0/9] HID++ (Logitech Unifying) protocol fixes

2013-08-19 Thread Julien Danjou
On Mon, Aug 19 2013, Peter Wu wrote: > Thank you for testing. For these patch series, I have focused on proper usage > of the HID++ protocol, I did not consider properties such as is-present. > > I just looked at the is-present property and can confirm that is is still > "true" even if the device

Re: [PATCH 0/9] HID++ (Logitech Unifying) protocol fixes

2013-08-19 Thread Peter Wu
Hi Julien, On Thursday 15 August 2013 23:02:51 Julien Danjou wrote: > On Thu, Aug 15 2013, Julien Danjou wrote: > > I've tested the whole patch series, and it works fine. It actually seems > > to fix a small issue I had with the assocaited devices being marked as > > present while not. The hardwar

[PATCH 2/3] hidpp: fix properties for unreachable devices

2013-08-19 Thread Peter Wu
From: Peter Wu This includes "is-present" and "state" (which will be marked "unknown"). "percentage" is not touched since it is still an indication of the battery level, changing it to zero is not helpful. Previously, properties were never updated because the refresh would fail when the battery

[PATCH 1/3] hidpp: improve HID++ version detection, fix uninit var

2013-08-19 Thread Peter Wu
From: Peter Wu Do not assume HID++ 1.0 when device is unreachable. This allows up_device_unifying_refresh() to be optimized to stop sending a ping message at every refresh for HID++ 1.0 devices. priv->version will now always contain 0 when the real HID++ version of a device is not (yet) known, c

[PATCH 3/3] hidpp: remove unnecessary HID++ 2.0 code

2013-08-19 Thread Peter Wu
From: Peter Wu The device name and type can be queried from the receiver which does not mind if a paired device is using HID++ 2.0 or 1.0. Therefore remove the hidpp20-specific code which also removes indirection of an uninitialised "map" variable. The following code was buggy: msg.feature_