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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
