From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Jason Gerecke <killertofu@gmail.com>
Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
Bastien Nocera <hadess@hadess.net>,
"ping.cheng@wacom.com" <ping.cheng@wacom.com>,
"jason.gerecke@wacom.com" <jason.gerecke@wacom.com>,
linux-pm@vger.kernel.org
Subject: Re: "proximity" attribute for input devices
Date: Sat, 4 Mar 2023 02:09:29 +0100 [thread overview]
Message-ID: <c65e2dbc-c8f9-4481-85f1-4d1eb140a05f@mercury.local> (raw)
In-Reply-To: <CANRwn3Tb1JgLpCiYFZBO1+PDHWLT-yxEPQ0TQ19xGDWZR9pmoA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2023-03-04 1:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 15:29 "proximity" attribute for input devices Limonciello, Mario
2023-03-03 23:05 ` Jason Gerecke
2023-03-04 1:09 ` Sebastian Reichel [this message]
2023-03-06 20:43 ` Limonciello, Mario
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=c65e2dbc-c8f9-4481-85f1-4d1eb140a05f@mercury.local \
--to=sebastian.reichel@collabora.com \
--cc=Mario.Limonciello@amd.com \
--cc=hadess@hadess.net \
--cc=jason.gerecke@wacom.com \
--cc=killertofu@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=ping.cheng@wacom.com \
/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).