"proximity" attribute for input devices

"proximity" attribute for input devices

[Limonciello, Mario]

[Public]

Hello,

A problem was found that a Wacom device's stylus battery showed up in GNOME even though the stylus wasn't near by.
As part of discussing how to handle it Bastien proposes a new sysfs attribute "proximity" to let userspace know this.

He asked[1] to start the discussion on Linux-input ML.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=217062#c7

Thanks,

Re: "proximity" attribute for input devices

[Jason Gerecke]

Apologies for the delay in replying.

First off: as an immediate action, I'm thinking of changing the Wacom
driver to do lazy creation of the power_supply device. This would mean
that rather than creating it at the same time as the input device, we
would wait until we receive some kind of affirmative indication of a
battery being present. Most Wacom peripherals report battery status in
a "heartbeat" report that is sent every few seconds, so there wouldn't
be much change for the typical user (just a few-second delay between
connecting the hardware and a power_supply device being created). In
the case of the "component" devices that are built into laptops and
other computers, however, the battery status is only reported while
the pen is actually in proximity. For users like you who don't own (or
never use) a pen, this means that our driver would never create a
power_supply device -- preventing GNOME from showing a battery that
isn't relevant. I'm working on a patch set that does this but need a
bit more time to finish it.

That's only a partial solution, however. If a component user were to
bring a pen into prox even just briefly, then a power_supply device
would be created and not go away until the user reboots. The pen's
battery status will become stale at some point in time though --
self-discharge, use of the pen on another device, and even just simple
irrelevance if the user hasn't used the pen in a while (do I care that
the pen which I left at home is at 50% battery?). I agree that it
makes sense for userspace to hide the battery after a while due to
things like this. Are there new signals that the kernel should be
providing to userspace (e.g. an attribute that indicates if we're in
communication with power_supply? an attribute signaling that data
might be stale)? Or are the signals that are already provided
sufficient (e.g. should GNOME just hide power_supply devices that are
in an "Unknown" state? or maybe hide power_supplies which haven't been
updated in more than 1 hour?)

I've added the power_supply list and maintainer for some additional
viewpoints on the second paragraph... If there are questions about how
the Wacom hardware and its battery reporting works, I'm happy to
provide answers...

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....



On Thu, Feb 23, 2023 at 7:39 AM Limonciello, Mario
<Mario.Limonciello@amd.com> wrote:
>
> [Public]
>
> Hello,
>
> A problem was found that a Wacom device's stylus battery showed up in GNOME even though the stylus wasn't near by.
> As part of discussing how to handle it Bastien proposes a new sysfs attribute "proximity" to let userspace know this.
>
> He asked[1] to start the discussion on Linux-input ML.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=217062#c7
>
> Thanks,

Re: "proximity" attribute for input devices

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]

Hi,

On Fri, Mar 03, 2023 at 03:05:41PM -0800, Jason Gerecke wrote:
> Apologies for the delay in replying.
> 
> First off: as an immediate action, I'm thinking of changing the Wacom
> driver to do lazy creation of the power_supply device. This would mean
> that rather than creating it at the same time as the input device, we
> would wait until we receive some kind of affirmative indication of a
> battery being present. Most Wacom peripherals report battery status in
> a "heartbeat" report that is sent every few seconds, so there wouldn't
> be much change for the typical user (just a few-second delay between
> connecting the hardware and a power_supply device being created). In
> the case of the "component" devices that are built into laptops and
> other computers, however, the battery status is only reported while
> the pen is actually in proximity. For users like you who don't own (or
> never use) a pen, this means that our driver would never create a
> power_supply device -- preventing GNOME from showing a battery that
> isn't relevant. I'm working on a patch set that does this but need a
> bit more time to finish it.
>
> That's only a partial solution, however. If a component user were to
> bring a pen into prox even just briefly, then a power_supply device
> would be created and not go away until the user reboots. The pen's
> battery status will become stale at some point in time though --
> self-discharge, use of the pen on another device, and even just simple
> irrelevance if the user hasn't used the pen in a while (do I care that
> the pen which I left at home is at 50% battery?). I agree that it
> makes sense for userspace to hide the battery after a while due to
> things like this. Are there new signals that the kernel should be
> providing to userspace (e.g. an attribute that indicates if we're in
> communication with power_supply? an attribute signaling that data
> might be stale)? Or are the signals that are already provided
> sufficient (e.g. should GNOME just hide power_supply devices that are
> in an "Unknown" state? or maybe hide power_supplies which haven't been
> updated in more than 1 hour?)

Can't you just unregister the power-supply device if there hasn't
been any heartbeat for some minutes and go back to the init state
(i.e. the one where you are waiting for a heartbeat to appear for
the first time)?

> I've added the power_supply list and maintainer for some additional
> viewpoints on the second paragraph... If there are questions about how
> the Wacom hardware and its battery reporting works, I'm happy to
> provide answers...

I think the problem you have is quite specific to the Wacom
hardware. Usually wireless devices are either connected or
disconnected and drivers unregister the battery device on
disconnect. So I think this logic belongs into Wacom specific
code and not in generic power-supply core code.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: "proximity" attribute for input devices

[Limonciello, Mario]

[Public]



> -----Original Message-----
> From: Sebastian Reichel <sebastian.reichel@collabora.com>
> Sent: Friday, March 3, 2023 19:09
> To: Jason Gerecke <killertofu@gmail.com>
> Cc: Limonciello, Mario <Mario.Limonciello@amd.com>; linux-
> input@vger.kernel.org; Bastien Nocera <hadess@hadess.net>;
> ping.cheng@wacom.com; jason.gerecke@wacom.com; linux-
> pm@vger.kernel.org
> Subject: Re: "proximity" attribute for input devices
> 
> Hi,
> 
> On Fri, Mar 03, 2023 at 03:05:41PM -0800, Jason Gerecke wrote:
> > Apologies for the delay in replying.
> >
> > First off: as an immediate action, I'm thinking of changing the Wacom
> > driver to do lazy creation of the power_supply device. This would mean
> > that rather than creating it at the same time as the input device, we
> > would wait until we receive some kind of affirmative indication of a
> > battery being present. Most Wacom peripherals report battery status in
> > a "heartbeat" report that is sent every few seconds, so there wouldn't
> > be much change for the typical user (just a few-second delay between
> > connecting the hardware and a power_supply device being created). In
> > the case of the "component" devices that are built into laptops and
> > other computers, however, the battery status is only reported while
> > the pen is actually in proximity. For users like you who don't own (or
> > never use) a pen, this means that our driver would never create a
> > power_supply device -- preventing GNOME from showing a battery that
> > isn't relevant. I'm working on a patch set that does this but need a
> > bit more time to finish it.
> >
> > That's only a partial solution, however. If a component user were to
> > bring a pen into prox even just briefly, then a power_supply device
> > would be created and not go away until the user reboots. The pen's
> > battery status will become stale at some point in time though --
> > self-discharge, use of the pen on another device, and even just simple
> > irrelevance if the user hasn't used the pen in a while (do I care that
> > the pen which I left at home is at 50% battery?). I agree that it
> > makes sense for userspace to hide the battery after a while due to
> > things like this. Are there new signals that the kernel should be
> > providing to userspace (e.g. an attribute that indicates if we're in
> > communication with power_supply? an attribute signaling that data
> > might be stale)? Or are the signals that are already provided
> > sufficient (e.g. should GNOME just hide power_supply devices that are
> > in an "Unknown" state? or maybe hide power_supplies which haven't
> been
> > updated in more than 1 hour?)
> 
> Can't you just unregister the power-supply device if there hasn't
> been any heartbeat for some minutes and go back to the init state
> (i.e. the one where you are waiting for a heartbeat to appear for
> the first time)?
> 
> > I've added the power_supply list and maintainer for some additional
> > viewpoints on the second paragraph... If there are questions about how
> > the Wacom hardware and its battery reporting works, I'm happy to
> > provide answers...
> 
> I think the problem you have is quite specific to the Wacom
> hardware. Usually wireless devices are either connected or
> disconnected and drivers unregister the battery device on
> disconnect. So I think this logic belongs into Wacom specific
> code and not in generic power-supply core code.

Conceivably can the input device come and go too when in and out of
proximity?  If so, you may be able to just tie the power supply creation
and destruction directly to the creation and destruction of that input
device.