1. 15 Dec, 2010 1 commit
    • Dmitry Torokhov's avatar
      Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 · ab4e0192
      Dmitry Torokhov authored
      The desire to keep old names for the EVIOCGKEYCODE/EVIOCSKEYCODE while
      extending them to support large scancodes was a mistake. While we tried
      to keep ABI intact (and we succeeded in doing that, programs compiled
      on older kernels will work on newer ones) there is still a problem with
      recompiling existing software with newer kernel headers.
      
      New kernel headers will supply updated ioctl numbers and kernel will
      expect that userspace will use struct input_keymap_entry to set and
      retrieve keymap data. But since the names of ioctls are still the same
      userspace will happily compile even if not adjusted to make use of the
      new structure and will start miraculously fail in the field.
      
      To avoid this issue let's revert EVIOCGKEYCODE/EVIOCSKEYCODE definitions
      and add EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 so that userspace can explicitly
      select the style of ioctls it wants to employ.
      Reviewed-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      Acked-by: default avatarJarod Wilson <jarod@redhat.com>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      ab4e0192
  2. 11 Dec, 2010 1 commit
  3. 08 Dec, 2010 1 commit
  4. 07 Dec, 2010 1 commit
  5. 01 Dec, 2010 5 commits
  6. 22 Nov, 2010 1 commit
  7. 18 Nov, 2010 1 commit
  8. 16 Nov, 2010 1 commit
  9. 15 Nov, 2010 1 commit
  10. 11 Nov, 2010 3 commits
  11. 04 Nov, 2010 2 commits
    • Benjamin LaHaise's avatar
      Input: atkbd - add 'terminal' parameter for IBM Terminal keyboards · 8c5188b6
      Benjamin LaHaise authored
      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: default avatarErika Quinn <erikas.aubade@gmail.com>
      Signed-off-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      8c5188b6
    • Jesse Barnes's avatar
      Input: i8042 - add Sony VAIOs to MUX blacklist · 73b14484
      Jesse Barnes authored
      The Sony VPCZ1 doesn't support active multiplexing and trying to enable
      it causes keyboard to stop working. Since most (all?) VAIOs do not have
      external PS/2 ports nor they implement active multiplexing properly, and
      trying to enable MUX usually messes up keyboard/touchpad, let's simply
      disable MUX probing based on board name (VAIO).
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      73b14484
  12. 03 Nov, 2010 3 commits
  13. 01 Nov, 2010 10 commits
  14. 31 Oct, 2010 9 commits