From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
Bastien Nocera <hadess@hadess.net>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
Date: Tue, 6 Jun 2017 09:25:49 +0200 [thread overview]
Message-ID: <20170606072549.GS1293@mail.corp.redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.20.1706050959500.30709@cbobk.fhfr.pm>
[Sorry for the delay, public holiday yesterday and I wasn't home]
On Jun 05 2017 or thereabouts, Jiri Kosina wrote:
> 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.
Believe me, I really try to avoid any regression. However, in this
situation, it's a user space bug and the only solution to not hit the
user space bug from the kernel is to not export the extra device, or
teach your upower daemon to ignore this particular device through a
udev rule (if that's possible, I'll check that today).
>
> 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.
>
Well, as Bastien said, the issue is that old user space is buggy, and
even if we postpone the switch to 4.13, there will always be someone who
did not updated upower and who will complain.
As soon as I started the development of this series, Bastien upgraded
upower with the required changes, and usually the development cycle of
the kernel gives plenty of time for users to upgrade their user space
tools before the kernel hits mainline.
[...after a little bit of digging...]
I tried today with a Fedora 25 and the shipped upower that doesn't have
the bits Bastien worked on last March.
I couldn't expose the bug as reported here. The reason being what
Bastien said, there is a "scope" property exported by the kernel device
which is set to "Device" telling upower to ignore the device completely
in this version.
A git blame game gives me 28c8653ed8d43 being the original addition of
the "scope" handling and this commit is dated "Wed Apr 18 16:46:41 2012
+0100". It was shipped in UPOWER_0_9_16, and there has been 7 minor
releases of upower since, and there has been the final 1.0 branch since
too.
So, no, I don't think this is a regression if you are running a 5 year
old user space that doesn't handle properties introduced in kernel v3.4.
Any HID keyboard you plug in that exports a battery will show the very
same upower bug, and there has been countless since 2012.
Cheers,
Benjamin
next prev parent reply other threads:[~2017-06-06 7:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-27 14:59 [PATCH v3 00/19] Report power supply from hid-logitech-hidpp Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 01/19] HID: logitech-dj: allow devices to request full pairing information Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 02/19] HID: logitech-hidpp: Add scope to battery Benjamin Tissoires
2017-04-06 9:48 ` Jiri Kosina
2017-04-06 9:57 ` Benjamin Tissoires
2017-04-06 18:34 ` Jiri Kosina
2017-03-27 14:59 ` [PATCH v3 03/19] HID: logitech-hidpp: make sure we only register one battery per device Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 04/19] HID: logitech-hidpp: do not query the name through HID++ for 1.0 devices Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 05/19] HID: logitech-hidpp: create a capabilities bits field Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 06/19] HID: logitech-hidpp: rework probe path for unifying devices Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 07/19] HID: logitech-hidpp: retrieve the HID++ device name when available Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 08/19] HID: logitech-hidpp: rework hidpp_connect_event() Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 09/19] HID: logitech-hidpp: handle battery events in hidpp_raw_hidpp_event() Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 10/19] HID: logitech-hidpp: forward device info in power_supply Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 11/19] HID: logitech-hidpp: create the battery for all types of HID++ devices Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 12/19] HID: logitech-hidpp: return an error if the queried feature is not present Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 13/19] HID: logitech-hidpp: notify battery on connect Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 14/19] HID: logitech-hidpp: battery: provide ONLINE property Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 15/19] HID: logitech-hidpp: rename battery level into capacity Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 16/19] HID: logitech-hidpp: battery: provide CAPACITY_LEVEL Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 17/19] HID: logitech-hidpp: add support for battery status for the K750 Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 18/19] HID: logitech-hidpp: enable HID++ 1.0 battery reporting Benjamin Tissoires
2017-03-27 14:59 ` [PATCH v3 19/19] HID: logitech-hidpp: add a sysfs file to tell we support power_supply Benjamin Tissoires
2017-03-27 16:23 ` [PATCH v3 00/19] Report power supply from hid-logitech-hidpp Bastien Nocera
2017-06-01 18:06 ` Dave Hansen
2017-06-01 19:26 ` Bastien Nocera
2017-06-02 7:29 ` Benjamin Tissoires
2017-06-02 12:54 ` Bastien Nocera
2017-06-02 13:47 ` Benjamin Tissoires
2017-06-02 14:10 ` Dave Hansen
2017-06-05 8:01 ` Jiri Kosina
2017-06-05 13:09 ` Bastien Nocera
2017-06-05 14:53 ` Dave Hansen
2017-06-05 16:22 ` Bastien Nocera
2017-06-06 7:25 ` Benjamin Tissoires [this message]
2017-06-06 7:46 ` Bastien Nocera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170606072549.GS1293@mail.corp.redhat.com \
--to=benjamin.tissoires@redhat.com \
--cc=dave.hansen@intel.com \
--cc=hadess@hadess.net \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).