On Mon, 21 Nov 2011, Jeremy Fitzhardinge wrote: > > 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. It definitely is something we should at least try. It might turn out that there are way too many devices out there which break horribly with this, but hey, it's defined by spec, so it'd be strange not to even try to support it properly :) > >> 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. I agree. So I take it that you are now working on that, is my understanding correct? Thanks a lot, -- Jiri Kosina SUSE Labs -- 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
