Re: HID-generic + HID-ANOTHER interaction problems

On Fri, 16 Nov 2012, Adam Sutton wrote:

I'm using a small distro (OpenELEC) that's targeted at providing a media
centre system based on XBMC.

Personally I use a USB/IR remote control that had a custom hid driver
(hid-spinelplus) generated by someone in the community and modified by
Stephen Raue (the OpenELEC maintainer). This was working fine up until
fairly recently when it seems changes in the HID stack appear to have
broken things.

quoted

From what I can tell the problem relates to hid-generic. Specifically this

module appears to be checked before hid-spinelplus (and others?) during
driver discovery. Since hid-generic will also match my device it steals it
before hid-spinelplus and I lose most of the functionality. Simply removing
hid-generic fixes things for me, but is obviously not a solution for the
wider community.

One thing I'm not sure about is whether this relates to the fact that OE
builds in all modules rather than dynamically loading them (since its very
stripped down anyway). One idea Stephen had was that we might make the
hid-generic driver dynamically load so that it should be loaded after the
others. I've not had a chance to test this and don't know whether it will
work or is really the right solution.

Any thoughts/ideas greatly appreciated?

Hi,

two answers to this:

- you can manually unbind hid-generic from your device and bind your 
  driver to it. This is achieved through 'bind' and 'unbind' files in 
  sysfs under /sys/bus/hid/...
- there is a in-kernel list of devices that have special driver, so that 
  hid-generic is not driving those and defers to the specialized driver. 
  This is hid_have_special_driver[] in hid-core.c.
  The best thing I'd suggest is submitting the driver to me for upstream 
  vanilla kernel inclusion, together with the hid_have_special_driver[] 
  addition. Once it's merged, you could stop caring about it, and it'll 
  work all the time with never kernels automatically

-- 
Jiri Kosina
SUSE Labs