1. 20 12月, 2010 1 次提交
    • H
      Input: introduce device properties · 85b77200
      Henrik Rydberg 提交于
      Today, userspace sets up an input device based on the data it emits.
      This is not always enough; a tablet and a touchscreen may emit exactly
      the same data, for instance, but the former should be set up with a
      pointer whereas the latter does not need to. Recently, a new type of
      touchpad has emerged where the buttons are under the pad, which
      changes logic without changing the emitted data. This patch introduces
      a new ioctl, EVIOCGPROP, which enables user access to a set of device
      properties useful during setup. The properties are given as a bitmap
      in the same fashion as the event types, and are also made available
      via sysfs, uevent and /proc/bus/input/devices.
      Acked-by: NPing Cheng <pingc@wacom.com>
      Acked-by: NChase Douglas <chase.douglas@canonical.com>
      Acked-by: NDmitry Torokhov <dtor@mail.ru>
      Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
      85b77200
  2. 15 12月, 2010 1 次提交
    • D
      Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 · ab4e0192
      Dmitry Torokhov 提交于
      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: NHenrik Rydberg <rydberg@euromail.se>
      Acked-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      ab4e0192
  3. 01 12月, 2010 1 次提交
  4. 18 10月, 2010 2 次提交
    • D
      Input: evdev - fix EVIOCSABS regression · f9ce6eb5
      Daniel Mack 提交于
      448cd166 ("Input: evdev - rearrange ioctl handling") broke EVIOCSABS by
      checking for the wrong direction bit.
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Reported-by: NSven Neumann <s.neumann@raumfeld.com>
      Tested-by: NSven Neumann <s.neumann@raumfeld.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      f9ce6eb5
    • D
      Input: evdev - fix Ooops in EVIOCGABS/EVIOCSABS · 0a74a1df
      Daniel Mack 提交于
      This fixes a regression introduced by the dynamic allocation of absinfo
      for input devices. We need to bail out early for input devices which
      don't have absolute axis.
      
      [  929.664303] Pid: 2989, comm: input Not tainted 2.6.36-rc8+ #14 MS-7260/MS-7260
      [  929.664318] EIP: 0060:[<c12bdc01>] EFLAGS: 00010246 CPU: 0
      [  929.664331] EIP is at evdev_ioctl+0x4f8/0x59f
      [  929.664341] EAX: 00000040 EBX: 00000000 ECX: 00000006 EDX: f45a1efc
      [  929.664355] ESI: 00000000 EDI: f45a1efc EBP: f45a1f24 ESP: f45a1eb8
      [  929.664369]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  929.664402]  f470da74 f6a30e78 f462c240 00000018 bfe4a260 00000000 f45b06fc 00000000
      [  929.664429] <0> 000000c4 b769d000 c3544620 f470da74 f45b06fc f45b06fc f45a1f38 c107dd1f
      [  929.664458] <0> f4710b74 000000c4 00000000 00000000 00000000 0000029d 00000a74 f4710b74
      [  929.664500]  [<c107dd1f>] ? handle_mm_fault+0x2be/0x59a
      [  929.664513]  [<c12bd709>] ? evdev_ioctl+0x0/0x59f
      [  929.664524]  [<c1099d30>] ? do_vfs_ioctl+0x494/0x4d9
      [  929.664538]  [<c10432a1>] ? up_read+0x16/0x29
      [  929.664550]  [<c101c818>] ? do_page_fault+0x2ff/0x32d
      [  929.664564]  [<c108d048>] ? do_sys_open+0xc5/0xcf
      [  929.664575]  [<c1099db6>] ? sys_ioctl+0x41/0x61
      [  929.664587]  [<c1002710>] ? sysenter_do_call+0x12/0x36
      [  929.684570] ---[ end trace 11b83e923bd8f2bb ]---
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      0a74a1df
  5. 15 10月, 2010 1 次提交
    • A
      llseek: automatically add .llseek fop · 6038f373
      Arnd Bergmann 提交于
      All file_operations should get a .llseek operation so we can make
      nonseekable_open the default for future file operations without a
      .llseek pointer.
      
      The three cases that we can automatically detect are no_llseek, seq_lseek
      and default_llseek. For cases where we can we can automatically prove that
      the file offset is always ignored, we use noop_llseek, which maintains
      the current behavior of not returning an error from a seek.
      
      New drivers should normally not use noop_llseek but instead use no_llseek
      and call nonseekable_open at open time.  Existing drivers can be converted
      to do the same when the maintainer knows for certain that no user code
      relies on calling seek on the device file.
      
      The generated code is often incorrectly indented and right now contains
      comments that clarify for each added line why a specific variant was
      chosen. In the version that gets submitted upstream, the comments will
      be gone and I will manually fix the indentation, because there does not
      seem to be a way to do that using coccinelle.
      
      Some amount of new code is currently sitting in linux-next that should get
      the same modifications, which I will do at the end of the merge window.
      
      Many thanks to Julia Lawall for helping me learn to write a semantic
      patch that does all this.
      
      ===== begin semantic patch =====
      // This adds an llseek= method to all file operations,
      // as a preparation for making no_llseek the default.
      //
      // The rules are
      // - use no_llseek explicitly if we do nonseekable_open
      // - use seq_lseek for sequential files
      // - use default_llseek if we know we access f_pos
      // - use noop_llseek if we know we don't access f_pos,
      //   but we still want to allow users to call lseek
      //
      @ open1 exists @
      identifier nested_open;
      @@
      nested_open(...)
      {
      <+...
      nonseekable_open(...)
      ...+>
      }
      
      @ open exists@
      identifier open_f;
      identifier i, f;
      identifier open1.nested_open;
      @@
      int open_f(struct inode *i, struct file *f)
      {
      <+...
      (
      nonseekable_open(...)
      |
      nested_open(...)
      )
      ...+>
      }
      
      @ read disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      <+...
      (
         *off = E
      |
         *off += E
      |
         func(..., off, ...)
      |
         E = *off
      )
      ...+>
      }
      
      @ read_no_fpos disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ write @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      <+...
      (
        *off = E
      |
        *off += E
      |
        func(..., off, ...)
      |
        E = *off
      )
      ...+>
      }
      
      @ write_no_fpos @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ fops0 @
      identifier fops;
      @@
      struct file_operations fops = {
       ...
      };
      
      @ has_llseek depends on fops0 @
      identifier fops0.fops;
      identifier llseek_f;
      @@
      struct file_operations fops = {
      ...
       .llseek = llseek_f,
      ...
      };
      
      @ has_read depends on fops0 @
      identifier fops0.fops;
      identifier read_f;
      @@
      struct file_operations fops = {
      ...
       .read = read_f,
      ...
      };
      
      @ has_write depends on fops0 @
      identifier fops0.fops;
      identifier write_f;
      @@
      struct file_operations fops = {
      ...
       .write = write_f,
      ...
      };
      
      @ has_open depends on fops0 @
      identifier fops0.fops;
      identifier open_f;
      @@
      struct file_operations fops = {
      ...
       .open = open_f,
      ...
      };
      
      // use no_llseek if we call nonseekable_open
      ////////////////////////////////////////////
      @ nonseekable1 depends on !has_llseek && has_open @
      identifier fops0.fops;
      identifier nso ~= "nonseekable_open";
      @@
      struct file_operations fops = {
      ...  .open = nso, ...
      +.llseek = no_llseek, /* nonseekable */
      };
      
      @ nonseekable2 depends on !has_llseek @
      identifier fops0.fops;
      identifier open.open_f;
      @@
      struct file_operations fops = {
      ...  .open = open_f, ...
      +.llseek = no_llseek, /* open uses nonseekable */
      };
      
      // use seq_lseek for sequential files
      /////////////////////////////////////
      @ seq depends on !has_llseek @
      identifier fops0.fops;
      identifier sr ~= "seq_read";
      @@
      struct file_operations fops = {
      ...  .read = sr, ...
      +.llseek = seq_lseek, /* we have seq_read */
      };
      
      // use default_llseek if there is a readdir
      ///////////////////////////////////////////
      @ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier readdir_e;
      @@
      // any other fop is used that changes pos
      struct file_operations fops = {
      ... .readdir = readdir_e, ...
      +.llseek = default_llseek, /* readdir is present */
      };
      
      // use default_llseek if at least one of read/write touches f_pos
      /////////////////////////////////////////////////////////////////
      @ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read.read_f;
      @@
      // read fops use offset
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = default_llseek, /* read accesses f_pos */
      };
      
      @ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ... .write = write_f, ...
      +	.llseek = default_llseek, /* write accesses f_pos */
      };
      
      // Use noop_llseek if neither read nor write accesses f_pos
      ///////////////////////////////////////////////////////////
      
      @ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      identifier write_no_fpos.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ...
       .write = write_f,
       .read = read_f,
      ...
      +.llseek = noop_llseek, /* read and write both use no f_pos */
      };
      
      @ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write_no_fpos.write_f;
      @@
      struct file_operations fops = {
      ... .write = write_f, ...
      +.llseek = noop_llseek, /* write uses no f_pos */
      };
      
      @ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      @@
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = noop_llseek, /* read uses no f_pos */
      };
      
      @ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      @@
      struct file_operations fops = {
      ...
      +.llseek = noop_llseek, /* no read or write fn */
      };
      ===== End semantic patch =====
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Julia Lawall <julia@diku.dk>
      Cc: Christoph Hellwig <hch@infradead.org>
      6038f373
  6. 10 9月, 2010 1 次提交
    • M
      Input: add support for large scancodes · 8613e4c2
      Mauro Carvalho Chehab 提交于
      Several devices use a high number of bits for scancodes. One important
      group is the Remote Controllers. Some new protocols like RC-6 define a
      scancode space of 64 bits.
      
      The current EVIO[CS]GKEYCODE ioctls allow replace the scancode/keycode
      translation tables, but it is limited to up to 32 bits for scancode.
      
      Also, if userspace wants to clean the existing table, replacing it by
      a new one, it needs to run a loop calling the ioctls over the entire
      sparse scancode space.
      
      To solve those problems, this patch extends the ioctls to allow drivers
      handle scancodes up to 32 bytes long (the length could be extended in
      the future should such need arise) and allow userspace to query and set
      scancode to keycode mappings not only by scancode but also by index.
      
      Compatibility code were also added to handle the old format of
      EVIO[CS]GKEYCODE ioctls.
      
      Folded fixes by:
      - Dan Carpenter: locking fixes for the original implementation
      - Jarod Wilson: fix crash when setting keycode and wiring up get/set
                      handlers in original implementation.
      - Dmitry Torokhov: rework to consolidate old and new scancode handling,
                         provide options to act either by index or scancode.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      8613e4c2
  7. 20 8月, 2010 1 次提交
  8. 03 8月, 2010 3 次提交
  9. 16 7月, 2010 3 次提交
  10. 24 6月, 2010 3 次提交
  11. 09 3月, 2010 1 次提交
  12. 04 2月, 2010 1 次提交
  13. 06 1月, 2010 1 次提交
    • A
      Input: evdev - be less aggressive about sending SIGIO notifies · 30a589fd
      Adam Jackson 提交于
      When using realtime signals, we'll enqueue one signal for every event.
      This is unfortunate, because (for example) keyboard presses are three
      events: key, msc scancode, and syn.  They'll be enqueued fast enough in
      kernel space that all three events will be ready to read by the time
      userspace runs, so the first invocation of the signal handler will read
      all three events, but then the second two invocations still have to run
      to do no work.
      
      Instead, only send the SIGIO notification on syn events.  This is a
      slight abuse of SIGIO semantics, in principle it ought to fire as soon
      as any events are readable.  But it matches evdev semantics, which is
      more important since SIGIO is rather vaguely defined to begin with.
      Signed-off-by: NAdam Jackson <ajax@redhat.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      30a589fd
  14. 05 10月, 2009 1 次提交
  15. 14 7月, 2009 1 次提交
  16. 20 6月, 2009 1 次提交
  17. 11 5月, 2009 1 次提交
  18. 16 3月, 2009 1 次提交
    • J
      Rationalize fasync return values · 60aa4924
      Jonathan Corbet 提交于
      Most fasync implementations do something like:
      
           return fasync_helper(...);
      
      But fasync_helper() will return a positive value at times - a feature used
      in at least one place.  Thus, a number of other drivers do:
      
           err = fasync_helper(...);
           if (err < 0)
                   return err;
           return 0;
      
      In the interests of consistency and more concise code, it makes sense to
      map positive return values onto zero where ->fasync() is called.
      
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      60aa4924
  19. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      Al Viro 提交于
      As it is, all instances of ->release() for files that have ->fasync()
      need to remember to evict file from fasync lists; forgetting that
      creates a hole and we actually have a bunch that *does* forget.
      
      So let's keep our lives simple - let __fput() check FASYNC in
      file->f_flags and call ->fasync() there if it's been set.  And lose that
      crap in ->release() instances - leaving it there is still valid, but we
      don't have to bother anymore.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  20. 30 10月, 2008 1 次提交
  21. 28 10月, 2008 1 次提交
  22. 19 8月, 2008 1 次提交
  23. 09 8月, 2008 1 次提交
  24. 08 8月, 2008 1 次提交
  25. 30 6月, 2008 1 次提交
  26. 01 4月, 2008 1 次提交
  27. 31 3月, 2008 1 次提交
  28. 21 1月, 2008 1 次提交
  29. 20 10月, 2007 1 次提交
  30. 14 10月, 2007 1 次提交
  31. 13 10月, 2007 1 次提交
  32. 30 8月, 2007 1 次提交
  33. 01 8月, 2007 1 次提交