1. 22 1月, 2013 1 次提交
    • S
      Input: atkbd - fix multi-byte scancode handling on reconnect · be2d7e42
      Shawn Nematbakhsh 提交于
      On resume from suspend there is a possibility for multi-byte scancodes
      to be handled incorrectly. atkbd_reconnect disables the processing of
      scancodes in software by calling atkbd_disable, but the keyboard may
      still be active because no disconnect command was sent. Later, software
      handling is re-enabled. If a multi-byte scancode sent from the keyboard
      straddles the re-enable, only the latter byte(s) will be handled.
      
      In practice, this leads to cases where multi-byte break codes (ex. "e0
      4d" - break code for right-arrow) are misread as make codes ("4d" - make
      code for numeric 6), leading to one or more unwanted, untyped characters
      being interpreted.
      
      The solution implemented here involves sending command f5 (reset
      disable) to the keyboard prior to disabling software handling of codes.
      Later, the command to re-enable the keyboard is sent only after we are
      prepared to handle scancodes.
      Signed-off-by: NShawn Nematbakhsh <shawnn@chromium.org>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      be2d7e42
  2. 17 1月, 2013 1 次提交
  3. 24 4月, 2012 1 次提交
  4. 10 11月, 2011 1 次提交
  5. 13 7月, 2011 1 次提交
  6. 05 11月, 2010 1 次提交
    • B
      Input: atkbd - add 'terminal' parameter for IBM Terminal keyboards · 8c5188b6
      Benjamin LaHaise 提交于
      Many of the IBM Terminal keyboards from the 1980s and early 1990s communicate
      using a protocol similar, but not identical to the AT keyboard protocol.
      (Models known to be like this include 6110344, 6110668, 1390876, 1386887, and
      possibly others.)
      
      When the connector is rewired or adapter to an AT-DIN or PS/2 connector, they
      can be connected to a standard PC, with three caveats:
      
      a) They can only use scancode set 3; requests to use anything else are
      quietly ignored.
      b) The AT Command to request Make, Break and Repeat codes is not properly
      interpreted.
      c) The top function keys on a 122 key keyboard, and the arrow/edit keys in
      the middle of the board send non-standard scancodes.
      
      C) is easily taken care of in userspace, by use of setkeycodes
      B) can be taken care of by a userspace hack (that makes the kernel complain
      in dmesg)
      A) is fixable in theory, but on the keyboard i tested on (6110668), it seems
      to be detected unoverridably as Set 2, causing userspace oddities that make
      it harder to fix C).
      
      Enclosed is a small patch to the kernel that fixes A) and B) in the kernel,
      making it much easier to fix C) in userspace. It adds a single kernel
      command line parameter that overrides the detection that sets these boards
      as set 2, and instead of sending the Make-break-repeat command to the
      keyboard, it sends the make-break command, which is properly recognized by
      these keyboards. Software level key repeating seems to make up for the lack
      of hardware repeat codes perfectly.
      
      Without manually setting the command line parameter (tentatively named
      atkbd.terminal), this code has no effect, and the driver works exactly as
      before.
      
      See also:
      
      http://www.seasip.info/VintagePC/ibm_1390876.html
      http://www.seasip.info/VintagePC/ibm_6110344.html
      http://geekhack.org/showwiki.php?title=Island:7306Signed-off-by: NErika Quinn <erikas.aubade@gmail.com>
      Signed-off-by: NBenjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      8c5188b6
  7. 26 2月, 2010 1 次提交
    • D
      Input: atkbd - release previously reserved keycodes 248 - 254 · 4b70858b
      Dmitry Torokhov 提交于
      Keycodes in 248 - 254 range were reserved for special needs (scrolling)
      of atkbd driver. Now that the driver has been switched to use unsigned
      short keycodes instead of unsigned char we can release this range back
      into pull. We keep code 255 (ATKBD_KEY_NULL) reserved since users may
      have been using it to silence keys they do not care about since atkbd
      silently drops scancodes mapped to this keycode.
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      4b70858b
  8. 07 1月, 2010 1 次提交
  9. 06 1月, 2010 2 次提交
    • D
      Input: atkbd - fix canceling event_work in disconnect · 0ef7a26a
      Dmitry Torokhov 提交于
      We need to first unregister input device and only then cancel event work
      since events can arrive (and cause event work to get scheduled again)
      until input_unregister_device() returns.
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      0ef7a26a
    • E
      Input: serio - fix potential deadlock when unbinding drivers · 59b01513
      Eric W. Biederman 提交于
      sysfs_remove_group() waits for sysfs attributes to be removed, therefore
      we do not need to worry about driver-specific attributes being accessed
      after driver has been detached from the device. In fact, attempts to take
      serio->drv_mutex in attribute methods may lead to the following deadlock:
      
                                                sysfs_read_file()
                                                  fill_read_buffer()
                                                    sysfs_get_active_two()
                                                      psmouse_attr_show_helper()
                                                        serio_pin_driver()
      serio_disconnect_driver()
        mutex_lock(&serio->drv_mutex);
                                      <-------->        mutex_lock(&serio_drv_mutex);
          psmouse_disconnect()
            sysfs_remove_group(... psmouse_attr_group);
              ....
              sysfs_deactivate();
                wait_for_completion();
      
      Fix this by removing calls to serio_[un]pin_driver() and functions themselves
      and using driver-private mutexes to serialize access to attribute's set()
      methods that may change device state.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      59b01513
  10. 25 12月, 2009 1 次提交
  11. 05 12月, 2009 1 次提交
  12. 13 11月, 2009 1 次提交
  13. 22 10月, 2009 1 次提交
    • J
      Input: atkbd - add a quirk for OQO 01+ multimedia keys · e5713069
      Jamie Lentin 提交于
      OQO 01+ multimedia keys produce 6x on press, e0 6x upon release.
      As a result, Linux thinks that another key has been pressed (or is
      repeating), when it is actually a release of the same key. Mangle the
      release scancode when running on OQO so that driver recognizes it as
      such.
      
      Since the device does not have external PS/2 ports mangling is safe
      since there is no chance that an external keyboard is connected.
      Signed-off-by: NJamie Lentin <jm@lentin.co.uk>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      e5713069
  14. 18 10月, 2009 1 次提交
  15. 14 10月, 2009 2 次提交
  16. 21 9月, 2009 1 次提交
  17. 18 9月, 2009 1 次提交
  18. 04 9月, 2009 2 次提交
  19. 21 7月, 2009 1 次提交
  20. 13 7月, 2009 1 次提交
  21. 12 5月, 2009 1 次提交
  22. 15 4月, 2009 2 次提交
  23. 09 3月, 2009 2 次提交
  24. 11 1月, 2009 1 次提交
  25. 06 1月, 2009 1 次提交
  26. 30 12月, 2008 1 次提交
  27. 20 12月, 2008 2 次提交
  28. 12 11月, 2008 2 次提交
  29. 11 9月, 2008 2 次提交
  30. 30 6月, 2008 1 次提交
  31. 02 6月, 2008 1 次提交
  32. 28 5月, 2008 1 次提交