lkml.org 
[lkml]   [2012]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC 0/5] hid: Extending the device-driver matching mechanism
    Hi Benjamin,

    > So, I made a few tests yesterday, and I have now a clearer idea about
    > this solution:
    >
    > generally, I like it. Furthermore, it should help us build new classes
    > of devices without involving hid-core, which is great.
    > However, I have a few minors concerns, and a major one.
    >
    > The major one comes with patch 3: introducing the hid_parse function
    > in usbhid is great but it interferes with report_fixup mechanism. That
    > means that several drivers won't work with this solution.

    Yes, as noted in the commit message, that part is a work in
    progress. Going through all the drivers using report_fixup, the
    majority only uses device information, some use a driver-specific
    quirk which again boils down to a specific device. All drivers are
    present in the special_driver list in hid-core.

    The simplest solution is probably to defer parsing for drivers known
    from the device list. Even better would be if there was a mechanism to
    avoid that list altogether... considering the USB/BT device as
    separate from the HID device, it might even make sense to split the
    drivers that way. Most drivers would drive the HID devices,
    kickstarted by the generic usbhid driver. Some drivers would need to
    intervene on the USB/BT level instead, for instance by fixing up the
    reports.

    > Now the minors:
    > - as mentioned, the patches do not apply on Jiri's tree, which means
    > that we are missing the detection of the serial protocol (see comment
    > in patch 4).

    Ok, thanks. In a couple of weeks I should rebase the patches to 3.4,
    and will deal with it then.

    > - shouldn't we introduce the same behavior for bluetooth (hidp)
    > devices -> to be able to separate the handling of the magicmouse for
    > instance)?

    Yes, although I have not looked into the details yet.

    > - as the hid_parse function is already called, shouldn't we remove the
    > calls in the other drivers?

    Maybe, maybe not - it depends on if there will be a deferral
    mechanism. Hopefully it will become clear as we go along.

    Thanks!
    Henrik


    \
     
     \ /
      Last update: 2012-04-03 12:57    [W:0.024 / U:120.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site