[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] hid: Do not create input devices for feature reports
    On Fri, Feb 25, 2011 at 06:19:11PM +0100, Henrik Rydberg wrote:
    > Hi Benjamin,
    > > after some quick tests, I can deal with our two options (changing
    > > feature_mapping signature or not, and so calling feature_mapping
    > > before or after input_mapping).
    > Good, good.
    > > So, my questions are:
    > > - do we really need to change feature_mapping signature?
    > > - is feature_mapping tied to an input or to a device?
    > The input, output and feature reports are all found on the same level
    > in the HID protocol, so it makes sense to associate all reports with
    > the device itself, without any assumed association between different
    > reports. From a practical point of view, we may assign different input
    > nodes (input devices) to different input reports, so it is clear that
    > the mapping between hid device and input device is not 1-to-1.
    > For output devices, the only supported case is EV_LED, which passes
    > events to the input device. It is probably assumed that
    > HID_QUIRK_MULTI_INPUT is false for those devices. Jiri?

    I am probably late to the party fut the above is not true. Here is an
    example of an USB keyboard (wih LEDs) that is split into two:

    I: Bus=0003 Vendor=046d Product=c30e Version=0110
    N: Name="Logitech HID compliant keyboard"
    P: Phys=usb-0000:00:1d.0-1.2/input0
    U: Uniq=
    H: Handlers=sysrq kbd event3
    B: PROP=0
    B: EV=120013
    B: KEY=1000000000007 ff800000000007ff febeffdff3cfffff fffffffffffffffe
    B: MSC=10
    B: LED=7

    I: Bus=0003 Vendor=046d Product=c30e Version=0110
    N: Name="Logitech HID compliant keyboard"
    P: Phys=usb-0000:00:1d.0-1.2/input1
    U: Uniq=
    H: Handlers=kbd event4
    B: PROP=0
    B: EV=13
    B: KEY=fff ffffffffffffffff 2000000 387ad800d001 1e000000000000 0
    B: MSC=10

    This was done, most likely, because Logitech decided to reuse usage codes
    for different keys.



     \ /
      Last update: 2011-03-01 18:57    [W:0.037 / U:5.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site