Re: Supporting Battery Strength from my Bluetooth Mouse

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Mon, Nov 21, 2011 at 08:38:21AM -0800, Jeremy Fitzhardinge wrote:
> On 11/20/2011 02:26 AM, Jiri Kosina wrote:
> >> Given that this is a generic HID thing, where should it go?  Should 
> >> hid-core.c go around trying to create new power supplies?
> > If devices which present the battery status in a standard way start to 
> > appear, we definitely should make it more generic compared to the add-hoc 
> > handling we currently have in Wacom and Wiimote drivers.
> 
> OK.
> 
> > This would however force us to have a separate driver on HID bus for
> > such devices. I'd prefer to have this in generic code (we are handling
> > gazillions of devices just by hid-core/hid-input without any need for
> > additional hidbus driver) if possible. I haven't personally came
> > across many devices that would present bogus Battery status in their
> > report descriptor, but it'll probably require some more investigation.
> 
> I have no problem just doing it for all devices unconditionally (well,
> conditional on Battery Strength) if you don't think it would be a problem.
> 
> >> Bluetooth, for example, has a separate descriptor entry about whether 
> >> the device is battery powered which is much more likely to be accurate 
> >> than the generic HID descriptor, and it can call the power supply helper 
> >> as part of the HID setup.
> >>
> >> Does that sound reasonable?
> > Making the battery / power_supply initialization part of low-level HID 
> > transport initialization (usb/bluetooth) makes probably the most sense, 
> > yes.
> 
> Though unfortunately it looks like the SDP data that contains that
> information is only parsed by usermode, and so isn't available to the
> kernel.  That makes a generic HID-wide approach look more appealing.
> 
> > That depends a bit on the type of the event (EV_KEY has to handle 
> > auto-repeat for example, etc). See the switch in input_handle_event() 
> > which contains the logic behind what is happening when 'duplicate' event 
> > is coming through input core.
> 
> In this case, it will be EV_ABS/ABS_MISC which does have duplicates
> suppressed.

No, please do not try to route battery info through input subsystem;
power_supply seems to be the proper interface for it.

Thanks.

-- 
Dmitry