1. 26 Feb, 2010 2 commits
  2. 25 Feb, 2010 1 commit
  3. 22 Feb, 2010 6 commits
  4. 20 Feb, 2010 2 commits
  5. 19 Feb, 2010 3 commits
  6. 17 Feb, 2010 1 commit
  7. 11 Feb, 2010 7 commits
  8. 04 Feb, 2010 8 commits
  9. 01 Feb, 2010 1 commit
    • Alberto Panizzo's avatar
      Input: add imx-keypad driver to support the IMX Keypad Port · 76cdc083
      Alberto Panizzo authored
      The IMX family of Application Processors is shipped with a Keypad Port
      supported by this driver.
      
      The peripheral can control up to an 8x8 matrix key pad where all the
      scanning is done via software.  The hardware provides two interrupts:
      one for key presses (KDI) and one for all key releases (KRI). There is
      also a simple circuit for glitch reduction (said for synchronization)
      made by two series of 3 D-latches clocked by the keypad-clock that
      stabilize the interrupts sources. KDI and KRI are fired only if the
      respective conditions are maintained for at last 4 keypad-clock cycle.
      
      Since those circuits are poor for a correct debounce process (the
      keypad-clock frequency is 32K and bounces longer than 94us are not
      masked) the driver, when an interrupt arrives, samples the matrix
      with a period of 10ms until the readins are stable for
      IMX_KEYPAD_SCANS_FOR_STABILITY times (currently set at 3). After
      getting stable result appropriate events are sent through the input
      stack.
      
      If some keys are maintained pressed, the driver continues to scan
      the matrix with a longer period (60ms) to catch possible multiple
      key presses without overloading the cpu. This process ends when all
      keys are released.
      
      This driver is tested to build in kernel or as a module and follow
      the specification of Freescale Application processors:
      i.MX25 i.MX27 i.MX31 i.MX35 i.MX51 especially tested on i.MX31.
      Signed-off-by: default avatarAlberto Panizzo <maramaopercheseimorto@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      76cdc083
  10. 30 Jan, 2010 4 commits
    • Dmitry Torokhov's avatar
      Input: Mac button emulation - allow compiling as a module · 429722e1
      Dmitry Torokhov authored
      Not all systems require Mac-style button emulation, however distributions
      enable it by default so it is readily available. Allow compiling it as a
      module so it can be loaded only on systems that actually require it.
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      429722e1
    • Dmitry Torokhov's avatar
      Input: Mac button emulation - implement as an input filter · 99b089c3
      Dmitry Torokhov authored
      Current implementation of Mac mouse button emulation plugs into legacy
      keyboard driver, converts certain keys into button events on a separate
      device, and suppresses the real events from reaching tty. This worked
      well enough until user space started using evdev which was completely
      unaware of this arrangement and kept sending original key presses to
      its users. Change the implementation to use newly added input filter
      framework so that original key presses are not transmitted to any
      handlers.
      
      As a bonus remove SYSCTL dependencies from the code and use Kconfig
      instead; also do not create the emulated mouse device until user
      activates emulation.
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      99b089c3
    • Dmitry Torokhov's avatar
      Input: implement input filters · ef7995f4
      Dmitry Torokhov authored
      Sometimes it is desirable to suppress certain events from reaching
      input handlers and thus user space. One such example is Mac mouse
      button emulation code which catches certain key presses and converts
      them into button clicks as if they were emitted by a virtual mouse.
      The original key press events should be completely suppressed,
      otherwise user space will be confused, and while keyboard driver
      does it on its own evdev is blissfully unaware of this arrangement.
      
      This patch adds notion of 'filter' to the standard input handlers,
      which may flag event as filtered thus preventing it from reaching
      other input handlers. Filters don't (nor will they ever) have a
      notion of priority relative to each other, input core will run all
      of them first and any one of them may mark event as filtered.
      
      This patch is inspired by similar patch by Matthew Garret but the
      implementation and intended usage are quite different.
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      ef7995f4
    • Thadeu Lima de Souza Cascardo's avatar
      Input: uinput - remove BKL from uinput_open function · 45cdba4d
      Thadeu Lima de Souza Cascardo authored
      Commit 87029658 pushed down the BKL
      into uinput open function. However, there's nothing that needs locking
      in there.
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      45cdba4d
  11. 29 Jan, 2010 1 commit
  12. 25 Jan, 2010 2 commits
  13. 22 Jan, 2010 1 commit
  14. 21 Jan, 2010 1 commit