linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).