summaryrefslogtreecommitdiffstats
path: root/include/linux/keyboard.h
Commit message (Collapse)AuthorAgeFilesLines
* keyboard: advertise KT_DEAD2 extended diacriticalsSamuel Thibault2009-06-141-0/+1
| | | | | | | | | | | | | In addition to KT_DEAD which has limited support for diacriticals, there is KT_DEAD2 that can support 256 criticals, so let's advertise it in <linux/keyboard.h>. This lets userland know abut the drivers/char/keyboard.c function k_dead2, which supports more than the few trivial ones that k_dead supports. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Input: put ledstate in the keyboard notifierKarl Dahlke2008-04-151-0/+1
| | | | | | | | | | | Led state should be part of the key event, like shiftstate, and not grabbed asynchronously after the fact. [samuel.thibault@ens-lyon.org: various fixes] Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Console keyboard events and accessibilitySamuel Thibault2007-10-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some blind people use a kernel engine called Speakup which uses hardware synthesis to speak what gets displayed on the screen. They use the PC keyboard to control this engine (start/stop, accelerate, ...) and also need to get keyboard feedback (to make sure to know what they are typing, the caps lock status, etc.) Up to now, the way it was done was very ugly. Below is a patch to add a notifier list for permitting a far better implementation, see ChangeLog above for details. You may wonder why this can't be done at the input layer. The problem is that what people want to monitor is the console keyboard, i.e. all input keyboards that got attached to the console, and with the currently active keymap (i.e. keysyms, not only keycodes). This adds a keyboard notifier that such modules can use to get the keyboard events and possibly eat them, at several stages: - keycodes: even before translation into keysym. - unbound keycodes: when no keysym is bound. - unicode: when the keycode would get translated into a unicode character. - keysym: when the keycode would get translated into a keysym. - post_keysym: after the keysym got interpreted, so as to see the result (caps lock, etc.) This also provides access to k_handler so as to permit simulation of keypresses. [akpm@linux-foundation.org: various fixes] Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6Dmitry Torokhov2007-10-131-1/+3
|\ | | | | | | | | | | Conflicts: drivers/macintosh/adbhid.c
| * Input: add more Braille keycodesSamuel Thibault2007-09-051-1/+3
| | | | | | | | | | | | | | | | Some braille keyboards have 10 dots, so extend the Input braille keys definitions. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* | Input: keyboard - add CapsShift lockSamuel Thibault2007-10-111-1/+3
|/ | | | | | | | | There exists a CapsShift lock called KG_CAPSSHIFT, but no associated lock/slock, here is a patch which adds CapsShift lock and slock. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: add support for Braille devicesSamuel Thibault2006-04-021-0/+13
| | | | | | | | | | - Add KEY_BRL_* input keys and K_BRL_* keycodes; - Add emulation of how braille keyboards usually combine braille dots to the console keyboard driver; - Add handling of unicode U+28xy diacritics. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Linux-2.6.12-rc2Linus Torvalds2005-04-171-0/+431
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!