Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Tue, 2017-06-06 at 09:25 +0200, Benjamin Tissoires wrote: > > 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. Richard should be able to cut a release, UPower hasn't had one since early last year, so it's time in any case :) > 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. Unless we added code to the obsolete version of UPower, we don't have a way to tell UPower to not use a particular device as a generic "power_supply" device.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Tue, 2017-06-06 at 09:25 +0200, Benjamin Tissoires wrote: > > 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. Richard should be able to cut a release, UPower hasn't had one since early last year, so it's time in any case :) > 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. Unless we added code to the obsolete version of UPower, we don't have a way to tell UPower to not use a particular device as a generic "power_supply" device.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
[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
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
[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
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Mon, 2017-06-05 at 07:53 -0700, Dave Hansen wrote: > On 06/05/2017 06:09 AM, Bastien Nocera wrote: > > > 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. > > > > I don't see how it's possible to retroactively fix user-space. > > It's not possible to retroactively change userspace. That why the > kernel tries so hard not to break it in the first place. Although > this > is in "minor annoyance" territory for me at the moment, this patch > causes a clear, user-visible issue with new kernels. > > The right way to do this is to have the kernel export the data in a > way > that does not confuse old userspace. Perhaps we should separate out > "power supplies that run the system" from "power supplies in a > perihperal". There's already such a property for it, "scope". I think that you don't realise that it's this version of UPower you're using (one major API version behind the current one) is buggy when it comes to handling kernel-created "power_supply". It's just that UPower used to do this itself, in user-space, and that it gets thoroughly confused when it accesses both the battery from user-space and kernel-space. > And, no, a config option isn't the right thing either. Because...? It's the best way to avoid exposing the feature for ancient user-spaces. The battery information will be gathered from user-space. It doesn't regress either.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Mon, 2017-06-05 at 07:53 -0700, Dave Hansen wrote: > On 06/05/2017 06:09 AM, Bastien Nocera wrote: > > > 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. > > > > I don't see how it's possible to retroactively fix user-space. > > It's not possible to retroactively change userspace. That why the > kernel tries so hard not to break it in the first place. Although > this > is in "minor annoyance" territory for me at the moment, this patch > causes a clear, user-visible issue with new kernels. > > The right way to do this is to have the kernel export the data in a > way > that does not confuse old userspace. Perhaps we should separate out > "power supplies that run the system" from "power supplies in a > perihperal". There's already such a property for it, "scope". I think that you don't realise that it's this version of UPower you're using (one major API version behind the current one) is buggy when it comes to handling kernel-created "power_supply". It's just that UPower used to do this itself, in user-space, and that it gets thoroughly confused when it accesses both the battery from user-space and kernel-space. > And, no, a config option isn't the right thing either. Because...? It's the best way to avoid exposing the feature for ancient user-spaces. The battery information will be gathered from user-space. It doesn't regress either.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On 06/05/2017 06:09 AM, Bastien Nocera wrote: >> 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. > I don't see how it's possible to retroactively fix user-space. It's not possible to retroactively change userspace. That why the kernel tries so hard not to break it in the first place. Although this is in "minor annoyance" territory for me at the moment, this patch causes a clear, user-visible issue with new kernels. The right way to do this is to have the kernel export the data in a way that does not confuse old userspace. Perhaps we should separate out "power supplies that run the system" from "power supplies in a perihperal". And, no, a config option isn't the right thing either.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On 06/05/2017 06:09 AM, Bastien Nocera wrote: >> 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. > I don't see how it's possible to retroactively fix user-space. It's not possible to retroactively change userspace. That why the kernel tries so hard not to break it in the first place. Although this is in "minor annoyance" territory for me at the moment, this patch causes a clear, user-visible issue with new kernels. The right way to do this is to have the kernel export the data in a way that does not confuse old userspace. Perhaps we should separate out "power supplies that run the system" from "power supplies in a perihperal". And, no, a config option isn't the right thing either.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Mon, 2017-06-05 at 10:01 +0200, 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. > > 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. I don't see how it's possible to retroactively fix user-space. The best (but oh so backwards) way to fix this might be to wrap the functionality in a config option, for user-spaces that can't update their version of UPower. I still think it's counter-productive, the only consumer for this information is UPower, and it's been modified to work-around the fact that the kernel didn't export this battery information. It now does.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Mon, 2017-06-05 at 10:01 +0200, 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. > > 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. I don't see how it's possible to retroactively fix user-space. The best (but oh so backwards) way to fix this might be to wrap the functionality in a config option, for user-spaces that can't update their version of UPower. I still think it's counter-productive, the only consumer for this information is UPower, and it's been modified to work-around the fact that the kernel didn't export this battery information. It now does.
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
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
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On 06/02/2017 12:29 AM, Benjamin Tissoires wrote: > On Jun 01 2017 or thereabouts, Bastien Nocera wrote: >> On Thu, 2017-06-01 at 11:06 -0700, Dave Hansen wrote: >>> On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: this is finally a rework of the series that provides kernel power_supply for hidpp devices. 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.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On 06/02/2017 12:29 AM, Benjamin Tissoires wrote: > On Jun 01 2017 or thereabouts, Bastien Nocera wrote: >> On Thu, 2017-06-01 at 11:06 -0700, Dave Hansen wrote: >>> On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: this is finally a rework of the series that provides kernel power_supply for hidpp devices. 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.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Jun 02 2017 or thereabouts, Bastien Nocera wrote: > On Fri, 2017-06-02 at 09:29 +0200, Benjamin Tissoires wrote: > > > > > Bastien, is is possible to have a simple udev rule that tells upower > > to > > ignore the battery device if builtin_power_supply is there? > > That way we can tell people running old upower to use this to be sure > > to > > ignore the kernel device and just rely on the upower hidpp support? > > I'm not sure where we'd ship that in a way that would make it work > differently based on the version of UPower. In UPower? Well, UPower > 0.99.x is the stable track for UPower, and the git master already has > support for this feature. > > I'm not sure what else would need to be done. I was more thinking at a snippet that we drop on this mailing list (here) that users can carefully copy/paste in their /etc and remove themself once they upgrade the system. Though OTOH, that's relying on users remembering that they have a special conf that need to be removed in a later update. Cheers, Benjamin
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Jun 02 2017 or thereabouts, Bastien Nocera wrote: > On Fri, 2017-06-02 at 09:29 +0200, Benjamin Tissoires wrote: > > > > > Bastien, is is possible to have a simple udev rule that tells upower > > to > > ignore the battery device if builtin_power_supply is there? > > That way we can tell people running old upower to use this to be sure > > to > > ignore the kernel device and just rely on the upower hidpp support? > > I'm not sure where we'd ship that in a way that would make it work > differently based on the version of UPower. In UPower? Well, UPower > 0.99.x is the stable track for UPower, and the git master already has > support for this feature. > > I'm not sure what else would need to be done. I was more thinking at a snippet that we drop on this mailing list (here) that users can carefully copy/paste in their /etc and remove themself once they upgrade the system. Though OTOH, that's relying on users remembering that they have a special conf that need to be removed in a later update. Cheers, Benjamin
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Fri, 2017-06-02 at 09:29 +0200, Benjamin Tissoires wrote: > > Bastien, is is possible to have a simple udev rule that tells upower > to > ignore the battery device if builtin_power_supply is there? > That way we can tell people running old upower to use this to be sure > to > ignore the kernel device and just rely on the upower hidpp support? I'm not sure where we'd ship that in a way that would make it work differently based on the version of UPower. In UPower? Well, UPower 0.99.x is the stable track for UPower, and the git master already has support for this feature. I'm not sure what else would need to be done.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Fri, 2017-06-02 at 09:29 +0200, Benjamin Tissoires wrote: > > Bastien, is is possible to have a simple udev rule that tells upower > to > ignore the battery device if builtin_power_supply is there? > That way we can tell people running old upower to use this to be sure > to > ignore the kernel device and just rely on the upower hidpp support? I'm not sure where we'd ship that in a way that would make it work differently based on the version of UPower. In UPower? Well, UPower 0.99.x is the stable track for UPower, and the git master already has support for this feature. I'm not sure what else would need to be done.
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Jun 01 2017 or thereabouts, Bastien Nocera wrote: > On Thu, 2017-06-01 at 11:06 -0700, Dave Hansen wrote: > > On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: > > > this is finally a rework of the series that provides kernel > > > power_supply > > > for hidpp devices. > > > > > > 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 :( > > > > Is this expected? > > You need to either disable the feature for the kernel, or upgrade to > the latest git master of UPower. Mixing both won't work. Use the devkit > mailing-list if you need a release of UPower. > Bastien, is is possible to have a simple udev rule that tells upower to ignore the battery device if builtin_power_supply is there? That way we can tell people running old upower to use this to be sure to ignore the kernel device and just rely on the upower hidpp support? Cheers, Benjamin
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Jun 01 2017 or thereabouts, Bastien Nocera wrote: > On Thu, 2017-06-01 at 11:06 -0700, Dave Hansen wrote: > > On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: > > > this is finally a rework of the series that provides kernel > > > power_supply > > > for hidpp devices. > > > > > > 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 :( > > > > Is this expected? > > You need to either disable the feature for the kernel, or upgrade to > the latest git master of UPower. Mixing both won't work. Use the devkit > mailing-list if you need a release of UPower. > Bastien, is is possible to have a simple udev rule that tells upower to ignore the battery device if builtin_power_supply is there? That way we can tell people running old upower to use this to be sure to ignore the kernel device and just rely on the upower hidpp support? Cheers, Benjamin
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Thu, 2017-06-01 at 11:06 -0700, Dave Hansen wrote: > On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: > > this is finally a rework of the series that provides kernel > > power_supply > > for hidpp devices. > > > > 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). > > Is this expected? You need to either disable the feature for the kernel, or upgrade to the latest git master of UPower. Mixing both won't work. Use the devkit mailing-list if you need a release of UPower. Cheers
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Thu, 2017-06-01 at 11:06 -0700, Dave Hansen wrote: > On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: > > this is finally a rework of the series that provides kernel > > power_supply > > for hidpp devices. > > > > 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). > > Is this expected? You need to either disable the feature for the kernel, or upgrade to the latest git master of UPower. Mixing both won't work. Use the devkit mailing-list if you need a release of UPower. Cheers
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: > this is finally a rework of the series that provides kernel power_supply > for hidpp devices. > > 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). Is this expected? > $ upower --dump > Device: /org/freedesktop/UPower/devices/battery_hidpp_battery_0 > native-path: hidpp_battery_0 > vendor: Logitech > model:Performance MX > serial: 101a-92-ca-86-1e > power supply: no > updated: Thu 01 Jun 2017 11:04:02 AM PDT (22 seconds ago) > has history: yes > has statistics: yes > battery > present: yes > rechargeable:yes > state: discharging > energy: 0 Wh > energy-empty:0 Wh > energy-full: 0 Wh > energy-full-design: 0 Wh > energy-rate: 0 W > percentage: 0% > capacity:100% > History (charge): > 14963401770.000 unknown > History (rate): > 14963401770.000 unknown $ upower --version UPower client version 0.9.23 UPower daemon version 0.9.23
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On 03/27/2017 07:59 AM, Benjamin Tissoires wrote: > this is finally a rework of the series that provides kernel power_supply > for hidpp devices. > > 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). Is this expected? > $ upower --dump > Device: /org/freedesktop/UPower/devices/battery_hidpp_battery_0 > native-path: hidpp_battery_0 > vendor: Logitech > model:Performance MX > serial: 101a-92-ca-86-1e > power supply: no > updated: Thu 01 Jun 2017 11:04:02 AM PDT (22 seconds ago) > has history: yes > has statistics: yes > battery > present: yes > rechargeable:yes > state: discharging > energy: 0 Wh > energy-empty:0 Wh > energy-full: 0 Wh > energy-full-design: 0 Wh > energy-rate: 0 W > percentage: 0% > capacity:100% > History (charge): > 14963401770.000 unknown > History (rate): > 14963401770.000 unknown $ upower --version UPower client version 0.9.23 UPower daemon version 0.9.23
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Mon, 2017-03-27 at 16:59 +0200, Benjamin Tissoires wrote: > Hi, > > this is finally a rework of the series that provides kernel > power_supply > for hidpp devices. > > This will allow upower to not handle those devices anymore and to > have more > immediate reportng of the device to the system. You can add my Tested-by to all the commits in this patchset, using a K750 solar keyboard and a T650 touchpad. Note that user-space support work is still ongoing, on top of the current upower master: https://bugs.freedesktop.org/show_bug.cgi?id=100359 Cheers
Re: [PATCH v3 00/19] Report power supply from hid-logitech-hidpp
On Mon, 2017-03-27 at 16:59 +0200, Benjamin Tissoires wrote: > Hi, > > this is finally a rework of the series that provides kernel > power_supply > for hidpp devices. > > This will allow upower to not handle those devices anymore and to > have more > immediate reportng of the device to the system. You can add my Tested-by to all the commits in this patchset, using a K750 solar keyboard and a T650 touchpad. Note that user-space support work is still ongoing, on top of the current upower master: https://bugs.freedesktop.org/show_bug.cgi?id=100359 Cheers
