1. 19 11月, 2013 1 次提交
  2. 13 11月, 2013 1 次提交
  3. 11 11月, 2013 1 次提交
    • F
      HID: don't ignore eGalax/D-Wav/EETI HIDs · 95d50b6c
      Forest Bond 提交于
      Certain devices with class HID, protocol None did not work with the HID
      driver at one point, and as a result were bound to usbtouchscreen
      instead as of commit 139ebe8d ("Input: usbtouchscreen - fix eGalax HID
      ignoring").  This change was prompted by the following report:
      
      https://lkml.org/lkml/2009/1/25/127
      
      Unfortunately, the device mentioned in this report is no longer
      available for testing.
      
      We've recently discovered that some devices with class HID, protocol
      None do not work with usbtouchscreen, but do work with usbhid.  Here is
      the report that made this evident:
      
      http://comments.gmane.org/gmane.linux.kernel.input/31710
      
      Driver binding for these devices has flip-flopped a few times, so both
      of the above reports were regressions.
      
      This situation would appear to leave us with no easy way to bind every
      device to the right driver.  However, in my own testing with several
      devices I have not found a device with class HID that does not work with
      the current HID driver.  It is my belief that changes to the HID driver
      since the original report have likely fixed the issue(s) that made it
      unsuitable at the time, and that we should prefer it over usbtouchscreen
      for these devices.  In particular, HID quirks affecting these devices
      were added/removed in the following commits since then:
      
      fe6065dc HID: add multi-input quirk for eGalax Touchcontroller
      77933c35 Merge branch 'egalax' into for-linus
      ebd11fec HID: Add quirk for eGalax touch controler.
      d34c4aa4 HID: add no-get quirk for eGalax touch controller
      
      This patch makes the HID driver no longer ignore eGalax/D-Wav/EETI
      devices with class HID.  If there are in fact devices with class HID
      that still do not work with the HID driver, we will see another round of
      regressions.  In that case I propose we investigate why the device is
      not working with the HID driver rather than re-introduce regressions for
      functioning HID devices by again binding them to usbtouchscreen.
      
      The corresponding change to usbtouchscreen will be made separately.
      Signed-off-by: NForest Bond <forest.bond@rapidrollout.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      95d50b6c
  4. 08 11月, 2013 1 次提交
  5. 30 10月, 2013 2 次提交
  6. 25 10月, 2013 2 次提交
  7. 21 10月, 2013 1 次提交
  8. 18 10月, 2013 1 次提交
    • N
      HID: Fix unit exponent parsing again · ad0e669b
      Nikolai Kondrashov 提交于
      Revert some changes done in 77463838.
      
      Revert all changes done in hidinput_calc_abs_res as it mistakingly used
      "Unit" item exponent nibbles to affect resolution value. This wasn't
      breaking resolution calculation of relevant axes of any existing
      devices, though, as they have only one dimension to their units and thus
      1 in the corresponding nible.
      
      Revert to reading "Unit Exponent" item value as a signed integer in
      hid_parser_global to fix reading specification-complying values. This
      fixes resolution calculation of devices complying to the HID standard,
      including Huion, KYE, Waltop and UC-Logic graphics tablets which have
      their report descriptors fixed by the drivers.
      
      Explanations follow.
      
      There are two "unit exponents" in HID specification and it is important
      not to mix them. One is the global "Unit Exponent" item and another is
      nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
      
      The "Unit Exponent" value is just a signed integer and is used to scale
      the integer resolution unit values, so fractions can be expressed.
      
      The nibbles of "Unit" value are used to select the unit system (nibble
      0), and presence of a particular basic unit type in the unit formula and
      its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
      complement and zero means absence of the unit type.
      
      Taking the representation example of (integer) joules from the
      specification:
      
      [mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
      
      the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
      "Unit" value would be 0xE121, signifying:
      
      Nibble  Part        Value   Meaning
      -----   ----        -----   -------
      0       System      1       SI Linear
      1       Length      2       Centimeters^2
      2       Mass        1       Grams
      3       Time        -2      Seconds^-2
      
      To give the resolution in e.g. hundredth of joules the "Unit Exponent"
      item value should have been -9.
      
      See also the examples of "Unit" values for some common units in the same
      chapter.
      
      However, there is a common misunderstanding about the "Unit Exponent"
      value encoding, where it is assumed to be stored the same as nibbles in
      "Unit" item. This is most likely due to the specification being a bit
      vague and overloading the term "unit exponent". This also was and still
      is proliferated by the official "HID Descriptor Tool", which makes this
      mistake and stores "Unit Exponent" as such. This format is also
      mentioned in books such as "USB Complete" and in Microsoft's hardware
      design guides.
      
      As a result many devices currently on the market use this encoding and
      so the driver should support them.
      Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
      Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ad0e669b
  9. 09 10月, 2013 1 次提交
  10. 02 10月, 2013 1 次提交
  11. 13 9月, 2013 2 次提交
  12. 04 9月, 2013 1 次提交
  13. 02 9月, 2013 1 次提交
  14. 29 8月, 2013 1 次提交
    • K
      HID: validate HID report id size · 43622021
      Kees Cook 提交于
      The "Report ID" field of a HID report is used to build indexes of
      reports. The kernel's index of these is limited to 256 entries, so any
      malicious device that sets a Report ID greater than 255 will trigger
      memory corruption on the host:
      
      [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
      [ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b
      
      CVE-2013-2888
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: stable@kernel.org
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      43622021
  15. 27 8月, 2013 2 次提交
  16. 26 8月, 2013 1 次提交
  17. 29 7月, 2013 1 次提交
  18. 22 7月, 2013 1 次提交
    • J
      HID: fix data access in implement() · 27ce4050
      Jiri Kosina 提交于
      implement() is setting bytes in LE data stream. In case the data is not
      aligned to 64bits, it reads past the allocated buffer. It doesn't really
      change any value there (it's properly bitmasked), but in case that this
      read past the boundary hits a page boundary, pagefault happens when
      accessing 64bits of 'x' in implement(), and kernel oopses.
      
      This happens much more often when numbered reports are in use, as the
      initial 8bit skip in the buffer makes the whole process work on values
      which are not aligned to 64bits.
      
      This problem dates back to attempts in 2005 and 2006 to make implement()
      and extract() as generic as possible, and even back then the problem
      was realized by Adam Kroperlin, but falsely assumed to be impossible
      to cause any harm:
      
        http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
      
      I have made several attempts at fixing it "on the spot" directly in
      implement(), but the results were horrible; the special casing for processing
      last 64bit chunk and switching to different math makes it unreadable mess.
      
      I therefore took a path to allocate a few bytes more which will never make
      it into final report, but are there as a cushion for all the 64bit math
      operations happening in implement() and extract().
      
      All callers of hid_output_report() are converted at the same time to allocate
      the buffer by newly introduced hid_alloc_report_buf() helper.
      
      Bruno noticed that the whole raw_size test can be dropped as well, as
      hid_alloc_report_buf() makes sure that the buffer is always of a proper
      size.
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      27ce4050
  19. 15 7月, 2013 1 次提交
  20. 13 7月, 2013 1 次提交
  21. 04 7月, 2013 1 次提交
    • B
      HID: kye: Add report fixup for Genius Gila Gaming mouse · 3685c18e
      Benjamin Tissoires 提交于
      Genius Gila Gaming Mouse presents an obviously wrong report descriptor.
      the Consumer control (report ID 3) is the following:
      0x05, 0x0c,                    // Usage Page (Consumer Devices)       105
      0x09, 0x01,                    // Usage (Consumer Control)            107
      0xa1, 0x01,                    // Collection (Application)            109
      0x85, 0x03,                    //   Report ID (3)                     111
      0x19, 0x00,                    //   Usage Minimum (0)                 113
      0x2a, 0xff, 0x7f,              //   Usage Maximum (32767)             115
      0x15, 0x00,                    //   Logical Minimum (0)               118
      0x26, 0xff, 0x7f,              //   Logical Maximum (32767)           120
      0x75, 0x10,                    //   Report Size (16)                  123
      0x95, 0x03,                    //   Report Count (3)                  125
      0x81, 0x00,                    //   Input (Data,Arr,Abs)              127
      0x75, 0x08,                    //   Report Size (8)                   129
      0x95, 0x01,                    //   Report Count (1)                  131
      0x81, 0x01,                    //   Input (Cnst,Arr,Abs)              133
      0xc0,                          // End Collection                      135
      
      So the first input whithin this report has a count of 3 but a usage range
      of 32768. So this value is obviously wrong as it should not be greater than
      the report count.
      
      Fixes:
      https://bugzilla.redhat.com/show_bug.cgi?id=959721Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      3685c18e
  22. 03 7月, 2013 1 次提交
  23. 03 6月, 2013 1 次提交
  24. 29 5月, 2013 1 次提交
    • J
      HID: add driver for ELO 4000/4500 · d23efc19
      Jiri Slaby 提交于
      This is a driver for ELO 4000/4500 devices which report themselves as
      HID devices, but do not really send HID events on touch. So we
      introduce a new HID 'quirk' driver with a raw_event handler where we
      take care of those events.
      
      What we need additionally is an input_configured hook, because the
      device does not mention anything about PRESSURE and TOUCH in its
      report descriptor, but it actually generate those. So we set the bits
      in the corresponding input_dev in that hook.
      
      Thanks to Petr Ostadal who was willing to test the driver. The rest of
      Cc's listed below had something to do with that driver over the years
      in our enterprise tree.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Tested-by: NPetr Ostadal <postadal@suse.cz>
      Cc: Oliver Neukum <oliver@neukum.org>
      Cc: Vojtech Pavlik <vojtech@suse.cz>
      Cc: Egbert Eich <eich@suse.com>
      Cc: Libor Pechacek <lpechacek@suse.cz>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d23efc19
  25. 28 5月, 2013 3 次提交
  26. 23 5月, 2013 1 次提交
    • V
      HID: ignore Jabra speakerphones HID interface · 31b9779c
      Vincent Palatin 提交于
      Add a quirk to ignore Jabra speakerphone 410 and 510 devices HID
      interface.
      On those devices, the USB audio interface is working nicely,
      but the HID interface is not working with the kernel usbhid driver,
      and it requires a specific userspace program.
      We could unbind it from userspace but just attaching the usbhid driver has
      sometimes nasty effects:
      either confusing the device state machine or triggering a storm of volume key
      events making eventual sound UI blinking like crazy.
      Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      31b9779c
  27. 06 5月, 2013 1 次提交
    • J
      HID: debug: fix RCU preemption issue · 1deb9d34
      Jiri Kosina 提交于
      Commit 2353f2be ("HID: protect hid_debug_list") introduced mutex
      locking around debug_list access to prevent SMP races when debugfs
      nodes are being operated upon by multiple userspace processess.
      
      mutex is not a proper synchronization primitive though, as the hid-debug
      callbacks are being called from atomic contexts.
      
      We also have to be careful about disabling IRQs when taking the lock
      to prevent deadlock against IRQ handlers.
      
      Benjamin reports this has also been reported in RH bugzilla as bug #958935.
      
       ===============================
       [ INFO: suspicious RCU usage. ]
       3.9.0+ #94 Not tainted
       -------------------------------
       include/linux/rcupdate.h:476 Illegal context switch in RCU read-side critical section!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       4 locks held by Xorg/5502:
        #0:  (&evdev->mutex){+.+...}, at: [<ffffffff81512c3d>] evdev_write+0x6d/0x160
        #1:  (&(&dev->event_lock)->rlock#2){-.-...}, at: [<ffffffff8150dd9b>] input_inject_event+0x5b/0x230
        #2:  (rcu_read_lock){.+.+..}, at: [<ffffffff8150dd82>] input_inject_event+0x42/0x230
        #3:  (&(&usbhid->lock)->rlock){-.....}, at: [<ffffffff81565289>] usb_hidinput_input_event+0x89/0x120
      
       stack backtrace:
       CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
       Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
        0000000000000001 ffff8800689c7c38 ffffffff816f249f ffff8800689c7c68
        ffffffff810acb1d 0000000000000000 ffffffff81a03ac7 000000000000019d
        0000000000000000 ffff8800689c7c90 ffffffff8107cda7 0000000000000000
       Call Trace:
        [<ffffffff816f249f>] dump_stack+0x19/0x1b
        [<ffffffff810acb1d>] lockdep_rcu_suspicious+0xfd/0x130
        [<ffffffff8107cda7>] __might_sleep+0xc7/0x230
        [<ffffffff816f7770>] mutex_lock_nested+0x40/0x3a0
        [<ffffffff81312ac4>] ? vsnprintf+0x354/0x640
        [<ffffffff81553cc4>] hid_debug_event+0x34/0x100
        [<ffffffff81554197>] hid_dump_input+0x67/0xa0
        [<ffffffff81556430>] hid_set_field+0x50/0x120
        [<ffffffff8156529a>] usb_hidinput_input_event+0x9a/0x120
        [<ffffffff8150d89e>] input_handle_event+0x8e/0x530
        [<ffffffff8150df10>] input_inject_event+0x1d0/0x230
        [<ffffffff8150dd82>] ? input_inject_event+0x42/0x230
        [<ffffffff81512cae>] evdev_write+0xde/0x160
        [<ffffffff81185038>] vfs_write+0xc8/0x1f0
        [<ffffffff81185535>] SyS_write+0x55/0xa0
        [<ffffffff81704482>] system_call_fastpath+0x16/0x1b
       BUG: sleeping function called from invalid context at kernel/mutex.c:413
       in_atomic(): 1, irqs_disabled(): 1, pid: 5502, name: Xorg
       INFO: lockdep is turned off.
       irq event stamp: 1098574
       hardirqs last  enabled at (1098573): [<ffffffff816fb53f>] _raw_spin_unlock_irqrestore+0x3f/0x70
       hardirqs last disabled at (1098574): [<ffffffff816faaf5>] _raw_spin_lock_irqsave+0x25/0xa0
       softirqs last  enabled at (1098306): [<ffffffff8104971f>] __do_softirq+0x18f/0x3c0
       softirqs last disabled at (1097867): [<ffffffff81049ad5>] irq_exit+0xa5/0xb0
       CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
       Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
        ffffffff81a03ac7 ffff8800689c7c68 ffffffff816f249f ffff8800689c7c90
        ffffffff8107ce60 0000000000000000 ffff8800689c7fd8 ffff88006a62c800
        ffff8800689c7d10 ffffffff816f7770 ffff8800689c7d00 ffffffff81312ac4
       Call Trace:
        [<ffffffff816f249f>] dump_stack+0x19/0x1b
        [<ffffffff8107ce60>] __might_sleep+0x180/0x230
        [<ffffffff816f7770>] mutex_lock_nested+0x40/0x3a0
        [<ffffffff81312ac4>] ? vsnprintf+0x354/0x640
        [<ffffffff81553cc4>] hid_debug_event+0x34/0x100
        [<ffffffff81554197>] hid_dump_input+0x67/0xa0
        [<ffffffff81556430>] hid_set_field+0x50/0x120
        [<ffffffff8156529a>] usb_hidinput_input_event+0x9a/0x120
        [<ffffffff8150d89e>] input_handle_event+0x8e/0x530
        [<ffffffff8150df10>] input_inject_event+0x1d0/0x230
        [<ffffffff8150dd82>] ? input_inject_event+0x42/0x230
        [<ffffffff81512cae>] evdev_write+0xde/0x160
        [<ffffffff81185038>] vfs_write+0xc8/0x1f0
        [<ffffffff81185535>] SyS_write+0x55/0xa0
        [<ffffffff81704482>] system_call_fastpath+0x16/0x1b
      Reported-by: Nmajianpeng <majianpeng@gmail.com>
      Reported-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
      Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      1deb9d34
  28. 01 5月, 2013 1 次提交
  29. 30 4月, 2013 2 次提交
  30. 29 4月, 2013 1 次提交
  31. 19 4月, 2013 1 次提交
  32. 04 4月, 2013 1 次提交
  33. 29 3月, 2013 1 次提交