| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The keyboard driver (for legacy keyboards) reports the same
keycodes for some inet keys as for the extra keys (Henkan and
Muhenkan) on Japanese 106 keyboards.
So on these keyboards Japanese users either loose their extra
keys or some multimedia keys.
In:
commit bd9d0ced6154de583c96573585f428618017fca3
Fix henkan key on jp106 keyboard with inet media keys
the Henkan/Muhenkan keys were reintroduced.
A better fix will map one of the two sets to different and still
unused keycodes.
A patch for the xf86-input-keyboard driver moves the two inet keys
into the range above 0xfb.
This patch contains the corresponding changes to xkeyboard-config.
Both the legacy keyboard driver and xkeyboard-config will have to
be updated simultaniously otherwise users will loose the two affected
multmedia keys.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
|
|
|
|
|
|
|
| |
Also adding some blank lines for consistency, unfolding some lines,
and tweaking a few comments and removing useless ones.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
|
|
|
|
| |
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From checking the usage of KEY_CYCLEWINDOWS in the linux sources, it
seems to be meant for task switching, rather than rotating the screen
as XF86RotateWindows traditionally does. In turn, KEY_DIRECTION is what
some kernel platform modules already use for the "rotate display" key
in certain tablet models.
So in order to make things consistent, it makes more sense to map
KEY_DIRECTION to XF86RotateWindows, and KEY_CYCLEWINDOWS to XF86TaskPane
as it's the closest offered behavior.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
|
|
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=54171
Signed-off-by: James M Leddy <jm.leddy@gmail.com>
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=59878
|
|
|
|
|
|
|
|
|
| |
According to symbols/inet this keycode is used by two keyboard models:
logitech_g15 and apple.
Thus it should not be used for a fake keycode that gets assigned to a
virtual modifier.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
|
| |
|
|
|
|
| |
Ugh, sorry.
|
|
|
|
|
|
| |
Notably absent are any and all changes to the .po files as there _has_
to be a way not to do them by hand... Unfortunately, I was unable to
find it.
|
|
|
|
|
|
| |
Notably absent are any and all changes to the .po files as there _has_
to be a way not to do them by hand... Unfortunately, I was unable to
find it.
|
|
|
|
| |
Signed-off-by: Alexandr Shadchin <Alexandr.Shadchin@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apple's Expose and Dashboard keys (F3 and F4) have correct keycodes
reported by evdev, but are not mapped. This adds the required keycodes
and symbols, using the symbols XF86LaunchA and XF86LaunchB, which allows
the keys to be used in compiz configuration.
(This patch has been included in Ubuntu since 2010.)
Bug: #34351
Ref.: https://bugs.launchpad.net/ubuntu/+bug/520519
Signed-off-by: Bryce Harrington <bryce@canonical.com>
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=32653
|
|
|
|
|
|
|
|
| |
The IT and DE keyboard were mapped looking at real hardware that I have,
but the US one was done looking at:
http://upload.wikimedia.org/wikipedia/commons/1/18/T-Mobile_G1_launch_event_2.jpg
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=31333
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=5783
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=28972
|
|
|
|
| |
http://bugs.freedesktop.org/show_bug.cgi?id=25835
|
|
|
|
| |
K6C maps to Eject in common media section
|
| |
|
|
|
|
|
|
|
|
| |
This only applies to laptops that actually have a trackstick and the
matching key. However, since FK22 is unused otherwise, we might as well
apply it to all models.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
| |
http://bugs.freedesktop.org/show_bug.cgi?id=22303
|
|
|
|
| |
http://bugs.freedesktop.org/show_bug.cgi?id=22261
|
|
|
|
|
|
|
|
|
|
|
| |
Currently no evdev key is mapped to libX11 1.2 XF86AudioForward key.
After the mapping we have:
KEY_BACK -> XF86Back
KEY_FORWARD -> XF86Forward
KEY_REWIND -> XF86AudioRewind
KEY_FASTFORWARD -> XF86AudioForward
Signed-off-by: Rami Ylimaki <ext-rami.ylimaki@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Hey Sergey,
This is one I'm not 100% sure of, but if you could have a look at it - much
appreciated. Just adding another set of the newer symbols to media_common and
acpi_common.
Cheers,
Peter
|
|
|
|
|
|
|
|
|
| |
Last patch for today :)
We've been shipping this one for a year or so in Fedora, adding the default
multi-media keys to the pc105 model.
This isn't as necessary anymore since the default use of evdev (which includes
it anyway), but nice for completeness.
|
|
|
|
|
|
|
| |
See the matching thread on linux-acpi:
http://marc.info/?l=linux-acpi&m=123599248818696&w=2
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Better than defining two levels with the same symbol.
Note that we have to force it as a ONE_LEVEL, otherwise the default
Pointer_EnableKeys will be tacked on automatically.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
polish too
|