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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
