Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 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
  3. 03 8月, 2010 3 次提交
  5. 16 7月, 2010 3 次提交
  7. 24 6月, 2010 3 次提交
  9. 09 3月, 2010 1 次提交
  11. 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
  15. 05 10月, 2009 1 次提交
  17. 14 7月, 2009 1 次提交
  19. 20 6月, 2009 1 次提交
  21. 11 5月, 2009 1 次提交
  23. 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
  25. 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
  27. 30 10月, 2008 1 次提交
  29. 28 10月, 2008 1 次提交
  31. 19 8月, 2008 1 次提交
  33. 09 8月, 2008 1 次提交
  35. 08 8月, 2008 1 次提交
  37. 30 6月, 2008 1 次提交
  39. 01 4月, 2008 1 次提交
  41. 31 3月, 2008 1 次提交
  43. 21 1月, 2008 1 次提交
  45. 20 10月, 2007 1 次提交
  47. 14 10月, 2007 1 次提交
  49. 13 10月, 2007 1 次提交
  51. 30 8月, 2007 1 次提交
  53. 01 8月, 2007 1 次提交
  55. 10 7月, 2007 1 次提交
  57. 04 6月, 2007 1 次提交
    • D
      Input: reduce raciness when input handlers disconnect · 1dfa2812
      由 Dmitry Torokhov 提交于 
      There is a race between input handler's release() and disconnect()
methods: when input handler disconnects it wakes up all regular
users and then process to walk user list to wake up async. users.
While disconnect() walks the list release() removes elements of
the same list causing oopses.

While this is not a substibute for proper locking we can reduce
odds of getting an oops if we wake up normal readers after walking
the list.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      1dfa2812
  59. 12 5月, 2007 1 次提交
  61. 09 5月, 2007 1 次提交
  63. 03 5月, 2007 2 次提交
  65. 12 4月, 2007 1 次提交