1. 07 7月, 2013 1 次提交
    • M
      Input: elantech - fix for newer hardware versions (v7) · 9eebed7d
      Matteo Delfino 提交于
      * Fix version recognition in elantech_set_properties
      
        The new hardware reports itself as v7 but the packets'
        structure is unaltered.
      
      * Fix packet type recognition in elantech_packet_check_v4
      
        The bitmask used for v6 is too wide, only the last three bits of
        the third byte in a packet (packet[3] & 0x03) are actually used to
        distinguish between packet types.
        Starting from v7, additional information (to be interpreted) is
        stored in the remaining bits (packets[3] & 0x1c).
        In addition, the value stored in (packet[0] & 0x0c) is no longer
        a constant but contains additional information yet to be deciphered.
        This change should be backwards compatible with v6 hardware.
      
      Additional-author: Giovanni Frigione <gio.frigione@gmail.com>
      Signed-off-by: NMatteo Delfino <kendatsuba@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      9eebed7d
  2. 03 7月, 2013 2 次提交
  3. 01 7月, 2013 5 次提交
  4. 28 6月, 2013 2 次提交
  5. 19 6月, 2013 5 次提交
  6. 14 6月, 2013 1 次提交
  7. 10 6月, 2013 1 次提交
    • D
      Input: evdev - flush queues during EVIOCGKEY-like ioctls · 48318028
      David Herrmann 提交于
      If userspace requests current KEY-state, they very likely assume that no
      such events are pending in the output queue of the evdev device.
      Otherwise, they will parse events which they already handled via
      EVIOCGKEY(). For XKB applications this can cause irreversible keyboard
      states if a modifier is locked multiple times because a CTRL-DOWN event is
      handled once via EVIOCGKEY() and once from the queue via read(), even
      though it should handle it only once.
      
      Therefore, lets do the only logical thing and flush the evdev queue
      atomically during this ioctl. We only flush events that are affected by
      the given ioctl.
      
      This only affects boolean events like KEY, SND, SW and LED. ABS, REL and
      others are not affected as duplicate events can be handled gracefully by
      user-space.
      
      Note: This actually breaks semantics of the evdev ABI. However,
      investigations showed that userspace already expects the new semantics and
      we end up fixing at least all XKB applications.
      All applications that are aware of this race-condition mirror the KEY
      state for each open-file and detect/drop duplicate events. Hence, they do
      not care whether duplicates are posted or not and work fine with this fix.
      
      Also note that we need proper locking to guarantee atomicity and avoid
      dead-locks. event_lock must be locked before queue_lock (see input-core).
      However, we can safely release event_lock while flushing the queue. This
      allows the input-core to proceed with pending events and only stop if it
      needs our queue_lock to post new events.
      This should guarantee that we don't block event-dispatching for too long
      while flushing a single event queue.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      48318028
  8. 09 6月, 2013 13 次提交
  9. 08 6月, 2013 10 次提交