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.
Now I need to work out the control flow. What's the best place to hook
in "register something if something is present in the descriptor"?
J
--
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
