On Thursday 22 January 2015 13:52:46 Benjamin Tissoires wrote:
> On Jan 21 2015 or thereabouts, Peter Wu wrote:
> > On Wednesday 21 January 2015 10:16:04 Benjamin Tissoires wrote:
> > > Hi Peter,
> > >
> > > On Jan 21 2015 or thereabouts, Peter Wu wrote:
&
On Wednesday 21 January 2015 10:16:04 Benjamin Tissoires wrote:
> Hi Peter,
>
> On Jan 21 2015 or thereabouts, Peter Wu wrote:
> > Linux 3.19 changed the way in which devices get registered by
> > introducing a hid-logitech-hidpp module. The driver name therefore nee
Linux 3.19 changed the way in which devices get registered by
introducing a hid-logitech-hidpp module. The driver name therefore needs
to be adjusted.
Signed-off-by: Peter Wu
---
Hi,
This patch makes UPower recognize Logitech Unifying receivers again.
Benjamin, I have CC'ed you to let you
up_daemon_get_daemon takes a reference on UpDaemon, so it must be
properly dereferenced. Similar for up_daemon_get_devices_list which
references an UpDeviceList.
The display device was allocated in init, but never released either.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
---
src/linux/
up_wakeups_get_cmdline returns allocated memory and
up_wakeup_item_set_cmdline duplicates it. Therefore free the former
after setting it on the item.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
---
src/up-wakeups.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src
The name of each Logitech HID++ 2.0 Feature will now be freed.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
---
src/linux/hidpp-device.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/linux/hidpp-device.c b/src/linux/hidpp-device.c
index 106f55a..9a651
Reproducible by executing `upower -d` or by calling the DBus method
org.freedesktop.UPower.Device.GetStatistics(charging).
up_device_get_statistics ->
up_history_get_profile_data ->
up_stats_item_new.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
---
src/up-history.c | 2 +-
1 file cha
The control of value is transferred to up_daemon_queue_changed_property,
let it release the memory when an error occurs.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
---
src/up-daemon.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/up-daemon.c b/src/up-daemon.c
This makes it easier to find real memory leaks with valgrind. After
calling the up_backend_unplug functions, you cannot restart it with
up_backend_coldplug since the lists are cleared.
Tested with Linux only (not on *BSD; dummy compiles).
https://bugs.freedesktop.org/show_bug.cgi?id=82659
---
sr
dbus_g_method_return[_error] does not claim the passed parameters, the
caller must free it theirselves.
complex is filled with an GValueArray pointer (see
UP_DBUS_STRUCT_DOUBLE_DOUBLE) but its contents are not freed (memleak!).
This patch introduces a deprecation warning due to the use
g_value_arr
Fixes leaking some DBus objects on shutdown, causing noise in
gobject-list and valgrind logs.
https://bugs.freedesktop.org/show_bug.cgi?id=82659
---
src/up-main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/up-main.c b/src/up-main.c
index cb835b7..25f16d3 100644
---
g_variant_get for string types must be freed as documented at
https://developer.gnome.org/glib/stable/gvariant-format-strings.html#gvariant-format-strings-strings
Since we just want to compare it, use a pointer as documented at
https://developer.gnome.org/glib/stable/gvariant-format-strings.html#gv
call count (this happens when the battery percentage changes for
example).
https://bugs.freedesktop.org/show_bug.cgi?id=82659
Reported-by: Alexander Jesner
Signed-off-by: Peter Wu
---
src/up-daemon.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/up-
[1] and gobject-list with trace patches[2].
Feel free to add 'Signed-off-by: Peter Wu ' at
every patch if you like, I removed them because Bastien preferred it
that way.
You can also find these series at https://git.lekensteyn.nl/upower.git
branch daemo
On Friday 04 April 2014 17:24:04 David Heidelberger wrote:
> >> /* Finally, add the read+execute ACL for $USER */
> >> +#ifdef HAVE_ACL
> >> if (!add_acl (mount_dir, uid, error))
> >> +#else
> >> + if (chown (mount_dir, -1, gid) == -1)
> >
> > add_acl seems to repo
Hi David,
The overall patch looks fine to me, but it got mangled by your mail
client. Some minor nitpicks/comment below.
On Friday 04 April 2014 15:47:56 David Heidelberger wrote:
> From 310d26a9ad845c0a320692c873562b37c94cd102 Mon Sep 17 00:00:00 2001
> From: David Heidelberger
> Date: Thu, 1
Hi David,
On Thursday 27 March 2014 21:41:06 David Heidelberger wrote:
> This patch provide option to build and run udisks without ACL.
> Tested in full desktop environment.
>
> Signed-off-by: David Heidelberger
>
> v2: as replacement of ACL is used chown call.
> ---
> configure.ac
(2) When the K800 has fully charged (but with the cable still plugged
in), it will still report 0 as discharge level. "Full" is 100% by
definition, so let's fallback to that value.
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 7 ++-
1 file changed, 6
On Monday 02 September 2013 11:34:47 Martin Pitt wrote:
> Peter Wu [2013-09-02 11:22 +0200]:
> > > - hidpp_device_cmd():
> > >+ Do we need to check for EINTR in the write()? Or are all
> > >
> > > commands very tiny and thus the chance of EINTR
Hi,
On Monday 02 September 2013 17:41:17 Shih-Yuan Lee wrote:
> I use "if (foo = bar)" to replace the following two lines.
>
> foo = bar
> if (foo != NULL)
I meant using this instead:
if ((foo = bar))
GCC warning:
warning: suggest parentheses around assignment used as truth value [-
Wparen
Hi,
This looks fine to me, but wouldn't the compiler give a notice about:
if (foo = bar)
(when it thinks that you meant foo == bar instead?)
On Monday 02 September 2013 16:53:14 Shih-Yuan Lee wrote:
> From: "Shih-Yuan Lee (FourDollars)"
>
> First, checking the device path. If it contains '
Hi Martin,
Thank you for your feedback, a general review of the structure is also helful.
On Monday 02 September 2013 07:00:48 Martin Pitt wrote:
> I'm afraid I can't help much with the actual protocol bits, but some
> general/logic things that caught my eye:
>
> - hidpp_device_print_buffer()
>
Hi,
On Thursday 29 August 2013 18:00:32 Shih-Yuan Lee wrote:
> Hi,
>
> I'm sorry that previous output of "upowerd -v" is based on the latest
> linux kernel (3.2.0-52-generic) on Ubuntu 12.04, and it seems not to
> have much information.
> So I collect other outputs of "upowerd -v" from 3.5.0-39-g
On Wednesday 28 August 2013 23:37:12 Julien Danjou wrote:
> On Wed, Aug 28 2013, Peter Wu wrote:
> > Makes sense, please test the updated code in
> > https://git.lekensteyn.nl/upower/?h=hidpp-rework . There is still a FIXME,
> > currently I assume that the device is charg
> > A notification should appear within a second of the request.
>
> 17:33:40.645 Send report_id=10 short device=02 DEV2
> type=09 params=0F 01 01 00 17:33:40.676
> Recv report_id=11 long device=02 DEV2
> type=09 params=0F 01 01 00 00
(re-adding list)
On Wednesday 28 August 2013 16:19:31 Julien Danjou wrote:
> On Wed, Aug 28 2013, Peter Wu wrote:
> > It looks like you have two devices powered off (or out of range), namely
> > device index 4 and 3.
>
> That's right, that's a mouse and touc
On Wednesday 28 August 2013 10:48:13 Shih-Yuan Lee wrote:
> Thank you for your review.
>
> For https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1153488.
> The code base is a little old, so I made two patches for it.
> One is
> https://launchpadlibrarian.net/146285357/02-try-to-work-out-if-the
On Tuesday 27 August 2013 23:08:07 Julien Danjou wrote:
> >> I still the light meter I had implemented back then (don't know why it's
> >
> > "light meter"? You mean the current lux value? Where should it be
> > visible?
>
> Yes, that's what I meant. My initial patch (git log) implemented it.
So
On Tuesday 27 August 2013 18:09:13 Anton Vorontsov wrote:
> On Tue, Aug 27, 2013 at 12:19:45PM +0200, Peter Wu wrote:
> > UPower assumes a "scope" attribute[1] to determine whether a battery
> > powers
> > the system or something else. I see that the kernel patche
On Tuesday 27 August 2013 23:08:07 Julien Danjou wrote:
> On Tue, Aug 27 2013, Peter Wu wrote:
> >> I still the light meter I had implemented back then (don't know why it's
> >
> > "light meter"? You mean the current lux value? Where should it be
&g
Hi,
On Tuesday 27 August 2013 14:10:56 Timothée Ravier wrote:
> My laptop is a Sony VAIO VGN-FW4 (more in the dmesg log attached).
>
> I forgot to mention that my battery is currently dying which is probably
> part of the issue.
>
> [..]
>
> Which is missing one entry as:
>
> $ ls /sys/class/p
Hi Julien,
On Tuesday 27 August 2013 22:33:14 Julien Danjou wrote:
> Using Peter Wu's patchset fixes a few things, I get this instead:
>
> Device: /org/freedesktop/UPower/devices/keyboard_0003o046DoC52Bx0005
> native-path: /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/
> 2-1.1:1.
Hi,
On Monday 26 August 2013 14:40:21 Timothée Ravier wrote:
> I'm running an updated Arch Linux with Linux 3.10 / 3.11rc7, upower 0.9.21.
>
> My logs are filled with those lines:
>
> upowerd[927]: (upowerd:927): UPower-Linux-WARNING **: no voltage values,
> using 10V as approximation
>
> which
Hi,
UPower assumes a "scope" attribute[1] to determine whether a battery powers
the system or something else. I see that the kernel patches were queued for
3.3[2], but I cannot find these commits back in mainline.
Was that patchset dropped without anyone noticing? Anton and Richard, can you
sh
Hi,
On Friday 02 August 2013 18:07:53 Shih-Yuan Lee wrote:
> From: "Shih-Yuan Lee (FourDollars)"
>
> First, checking the device path. If it contains 'bluetooth', it is a
> bluetooth devices. Second, checking if there is an input folder. If there
> is mouse folder under the input folder, it is a
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
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
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
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) kn
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
This reduces spam in stderr (which is logged to the systemd journal).
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 7 +++
src/linux/up-device-unifying.c | 16 ++--
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/src/linux/hidpp-device.c b/src
++ 1.0 ping response (removed/broken by this patch).
- Validate responses, retry read if needed.
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 311 +++
1 file changed, 154 insertions(+), 157 deletions(-)
diff --git a/src/linux/hidpp-device.c
Removed while refactoring hidpp_device_cmd, now that the message
validation is in place, introduce the 1.0 check again.
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/linux/hidpp
This prevents matching the wrong response packet, for example when
a mouse is moved while a packet is read. As a result, the reads are
more reliable and log spam is reduced.
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 108 +--
1 file
When sending a ping request right after a device got paired, the ping
message gets lost (there is no response). Work around that by delaying
the initial packet exchange. 10 milliseconds seems to work, but let's
choose 30 ms to be fully safe.
Signed-off-by: Peter Wu
---
src/linux/up-d
don't, for example if the device was paired to another computer
while the computer carrying the receiver was powered off).
Actual removal of unpaired devices is done by the Logitech HID driver,
that should remove sysfs entries which can be detected by upower.
Signed-off-by: Peter Wu
---
The d7 battery register does not magically re-appear, therefore skip
this register once it is detected that the register is unusable.
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/src
The HID++ 1.0 Illuminated Keyboard K800 does not support the d7
register, instead is uses 07. Its observed behaviour is documented in
the ltunify repository[1].
[1]: https://git.lekensteyn.nl/ltunify/tree/registers.txt
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 56
This prevents the use of responses from other HID++ applications (such
as Solaar and ltunify).
Signed-off-by: Peter Wu
---
src/linux/hidpp-device.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/linux/hidpp-device.c b/src/linux/hidpp-device.c
index 6d02bf1
register).
Regards,
Peter
[1]: https://lekensteyn.nl/logitech-unifying.html#ltunify
Peter Wu (9):
hidpp: refactor to introduce structure in protocol
hidpp: validate messages, retry if invalid
hidpp: clear message queue before initiating new requests
hidpp: recognise HID++ 1.0 ping
50 matches
Mail list logo
