RE: "proximity" attribute for input devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Public]



> -----Original Message-----
> From: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx>
> Sent: Friday, March 3, 2023 19:09
> To: Jason Gerecke <killertofu@xxxxxxxxx>
> Cc: Limonciello, Mario <Mario.Limonciello@xxxxxxx>; linux-
> input@xxxxxxxxxxxxxxx; Bastien Nocera <hadess@xxxxxxxxxx>;
> ping.cheng@xxxxxxxxx; jason.gerecke@xxxxxxxxx; linux-
> pm@xxxxxxxxxxxxxxx
> 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.




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux