Remap keys without xmodmap or any X tools
Due to a coffee accident some numbers of my laptop's keyboard stopped working. I used xmodmap
to use F1, F2, etc, as replacements and saved the configs to ~/.Xmodmap
.
However, that caused a few problems.
I don't always use X on this computer, and without starting X
xmodmap
does not apply.It causes X to take more time to start.
For some reason it caused XFCE keyboard shortcuts that had nothing to do with any of the keys changed via
xmodmap
to stop working (in fact, all keyboard shortcuts stopped working, except for the window manager shortcuts). After a few minutes passed since I start X, the XFCE shortcuts start working normally again! This lag isn't very annoying, but is also an issue.
I imagine there is some kind of mapping that is read by the OS before X starts. Isn't there a way to change that mapping? Is it any way to change the keyboard mapping w/o using X tools? Im using Debian stable.
PS: Apparently the file that calls xmodmap .Xmodmap
on startx
is /etc/xdg/xfce4/xinitrc
. It's contents can be found here.
linux keyboard xorg xfce keymap
add a comment |
Due to a coffee accident some numbers of my laptop's keyboard stopped working. I used xmodmap
to use F1, F2, etc, as replacements and saved the configs to ~/.Xmodmap
.
However, that caused a few problems.
I don't always use X on this computer, and without starting X
xmodmap
does not apply.It causes X to take more time to start.
For some reason it caused XFCE keyboard shortcuts that had nothing to do with any of the keys changed via
xmodmap
to stop working (in fact, all keyboard shortcuts stopped working, except for the window manager shortcuts). After a few minutes passed since I start X, the XFCE shortcuts start working normally again! This lag isn't very annoying, but is also an issue.
I imagine there is some kind of mapping that is read by the OS before X starts. Isn't there a way to change that mapping? Is it any way to change the keyboard mapping w/o using X tools? Im using Debian stable.
PS: Apparently the file that calls xmodmap .Xmodmap
on startx
is /etc/xdg/xfce4/xinitrc
. It's contents can be found here.
linux keyboard xorg xfce keymap
7
Have you thought about removing the keyboard and literally washing it? It will take a day to dry out, but is perfectly safe. Also, replacing a laptop keyboard is relatively inexpensive (~$25) compared to the aggravation of re-training your fingers.
– jdh
Mar 18 '14 at 19:29
I realize it's been a while since this was asked and the information's likely no longer needed, but on the "no unanswered questions" principle I added an answer below. Hopefully it will be of some use to someone, even if it's not the original asker.
– FeRD
Jul 25 '14 at 8:55
If a coffee accident made your keyboard shortcut unresponsive at times, like in OP's question - not working for a short time after X has started - for example, probably it may be that the modifier buttons are electrically closed due to the coffee leftovers under the buttons. This will make the computer think that Ctrl+Alt+S is pressed when you press Ctrl+S for example. Runxev
in a terminal and press each key of your keyboard and check whether the KeyUp event is detected.
– fz_salam
Jul 17 '16 at 9:53
add a comment |
Due to a coffee accident some numbers of my laptop's keyboard stopped working. I used xmodmap
to use F1, F2, etc, as replacements and saved the configs to ~/.Xmodmap
.
However, that caused a few problems.
I don't always use X on this computer, and without starting X
xmodmap
does not apply.It causes X to take more time to start.
For some reason it caused XFCE keyboard shortcuts that had nothing to do with any of the keys changed via
xmodmap
to stop working (in fact, all keyboard shortcuts stopped working, except for the window manager shortcuts). After a few minutes passed since I start X, the XFCE shortcuts start working normally again! This lag isn't very annoying, but is also an issue.
I imagine there is some kind of mapping that is read by the OS before X starts. Isn't there a way to change that mapping? Is it any way to change the keyboard mapping w/o using X tools? Im using Debian stable.
PS: Apparently the file that calls xmodmap .Xmodmap
on startx
is /etc/xdg/xfce4/xinitrc
. It's contents can be found here.
linux keyboard xorg xfce keymap
Due to a coffee accident some numbers of my laptop's keyboard stopped working. I used xmodmap
to use F1, F2, etc, as replacements and saved the configs to ~/.Xmodmap
.
However, that caused a few problems.
I don't always use X on this computer, and without starting X
xmodmap
does not apply.It causes X to take more time to start.
For some reason it caused XFCE keyboard shortcuts that had nothing to do with any of the keys changed via
xmodmap
to stop working (in fact, all keyboard shortcuts stopped working, except for the window manager shortcuts). After a few minutes passed since I start X, the XFCE shortcuts start working normally again! This lag isn't very annoying, but is also an issue.
I imagine there is some kind of mapping that is read by the OS before X starts. Isn't there a way to change that mapping? Is it any way to change the keyboard mapping w/o using X tools? Im using Debian stable.
PS: Apparently the file that calls xmodmap .Xmodmap
on startx
is /etc/xdg/xfce4/xinitrc
. It's contents can be found here.
linux keyboard xorg xfce keymap
linux keyboard xorg xfce keymap
edited Mar 16 '14 at 0:30
Alex
asked Mar 16 '14 at 0:24
AlexAlex
1,00941529
1,00941529
7
Have you thought about removing the keyboard and literally washing it? It will take a day to dry out, but is perfectly safe. Also, replacing a laptop keyboard is relatively inexpensive (~$25) compared to the aggravation of re-training your fingers.
– jdh
Mar 18 '14 at 19:29
I realize it's been a while since this was asked and the information's likely no longer needed, but on the "no unanswered questions" principle I added an answer below. Hopefully it will be of some use to someone, even if it's not the original asker.
– FeRD
Jul 25 '14 at 8:55
If a coffee accident made your keyboard shortcut unresponsive at times, like in OP's question - not working for a short time after X has started - for example, probably it may be that the modifier buttons are electrically closed due to the coffee leftovers under the buttons. This will make the computer think that Ctrl+Alt+S is pressed when you press Ctrl+S for example. Runxev
in a terminal and press each key of your keyboard and check whether the KeyUp event is detected.
– fz_salam
Jul 17 '16 at 9:53
add a comment |
7
Have you thought about removing the keyboard and literally washing it? It will take a day to dry out, but is perfectly safe. Also, replacing a laptop keyboard is relatively inexpensive (~$25) compared to the aggravation of re-training your fingers.
– jdh
Mar 18 '14 at 19:29
I realize it's been a while since this was asked and the information's likely no longer needed, but on the "no unanswered questions" principle I added an answer below. Hopefully it will be of some use to someone, even if it's not the original asker.
– FeRD
Jul 25 '14 at 8:55
If a coffee accident made your keyboard shortcut unresponsive at times, like in OP's question - not working for a short time after X has started - for example, probably it may be that the modifier buttons are electrically closed due to the coffee leftovers under the buttons. This will make the computer think that Ctrl+Alt+S is pressed when you press Ctrl+S for example. Runxev
in a terminal and press each key of your keyboard and check whether the KeyUp event is detected.
– fz_salam
Jul 17 '16 at 9:53
7
7
Have you thought about removing the keyboard and literally washing it? It will take a day to dry out, but is perfectly safe. Also, replacing a laptop keyboard is relatively inexpensive (~$25) compared to the aggravation of re-training your fingers.
– jdh
Mar 18 '14 at 19:29
Have you thought about removing the keyboard and literally washing it? It will take a day to dry out, but is perfectly safe. Also, replacing a laptop keyboard is relatively inexpensive (~$25) compared to the aggravation of re-training your fingers.
– jdh
Mar 18 '14 at 19:29
I realize it's been a while since this was asked and the information's likely no longer needed, but on the "no unanswered questions" principle I added an answer below. Hopefully it will be of some use to someone, even if it's not the original asker.
– FeRD
Jul 25 '14 at 8:55
I realize it's been a while since this was asked and the information's likely no longer needed, but on the "no unanswered questions" principle I added an answer below. Hopefully it will be of some use to someone, even if it's not the original asker.
– FeRD
Jul 25 '14 at 8:55
If a coffee accident made your keyboard shortcut unresponsive at times, like in OP's question - not working for a short time after X has started - for example, probably it may be that the modifier buttons are electrically closed due to the coffee leftovers under the buttons. This will make the computer think that Ctrl+Alt+S is pressed when you press Ctrl+S for example. Run
xev
in a terminal and press each key of your keyboard and check whether the KeyUp event is detected.– fz_salam
Jul 17 '16 at 9:53
If a coffee accident made your keyboard shortcut unresponsive at times, like in OP's question - not working for a short time after X has started - for example, probably it may be that the modifier buttons are electrically closed due to the coffee leftovers under the buttons. This will make the computer think that Ctrl+Alt+S is pressed when you press Ctrl+S for example. Run
xev
in a terminal and press each key of your keyboard and check whether the KeyUp event is detected.– fz_salam
Jul 17 '16 at 9:53
add a comment |
2 Answers
2
active
oldest
votes
First, the good news
The Linux system console absolutely has its own set of keyboard mappings, which can be managed using the tools from the kbd
package, specifically dumpkeys
and showkey
for discovery and loadkeys
to load in a customized mapping. The SuperUser question How to change console keymap in Linux? has an answer with good information on how to use these tools.
Now, the bad news
While it's true that those tools will allow you to remap the keys on the Linux console, without involving xmodmap
or requiring that X be running, they will only affect the keymappings on the virtual text console. The changes will have absolutely no effect in the graphical environment, because X's XInput/evdev system reads from the input devices directly and does its own processing.
So, if you were hoping to avoid using xmodmap
by just remapping on the console and having it apply everywhere, I'm afraid that won't work. In fact, you'd need to remap both the console (using loadkeys
) and X11 (using a method like xmodmap
), to use the same keyboard layout everywhere.
The solution to the xmodmap
slowness (and bugginess, since its remappings are glitchy and non-persistent in desktop environments that use layout switching) would be to define an entirely new keyboard layout based off of whatever layout you were previously using, rather than applying runtime modifications. On X startup, you'd load that new, remapped layout instead of whatever you're using now. (It seems this is now the only way to reliably modify the keyboard layout in recent Ubuntus — and possibly other distros — as their xmodmap
is no longer useful.)
For information on defining and using a custom xkb
keyboard layout, see:
Howto: Custom keyboard layout definitions in the Ubuntu Community Wiki.
How to modify a keyboard layout in Linux, a blog post by Romano Giannetti.
Both were written this year (2014), so the information should be current. The Ubuntu wiki information should be applicable to any distro, for the most part, as they all use the xkb
system in X.
Wonderful! That was exactly what I was looking for. However, as you mentioned in the comments, it's no longer the case, since I got a new notebook. I cannot test the answer, but since it's exactly what I was looking for I'm pretty sure it'd work, or at least give an alternative to xmodmap. Thanks!
– Alex
Jul 29 '14 at 4:32
add a comment |
There are actually ways to remap at a level low enough to apply to the whole system, X11 or not, and they've become more important than ever now that we're seeing uptake of Wayland compositors which neglect to expose a UI for libinput's remapping support.
You basically need to reconfigure how the kernel's input layer translates raw scancodes into keycodes before they reach the console or the evdev API that X11 and Wayland sit on top of.
I'm aware of two ways to do that:
Modify the hardware database (
hwdb
) entry for your keyboard. udev lets you do that by adding rules files to/etc/udev/hwdb.d/
and triggering a database rebuild withsystemd-hwdb update
, and then forcing it to be applied without a restart viaudevadm trigger
.
This ArchiWiki page has full instructions and explicitly says that it'll work for both X11 and console input.
There's a daemon named evdevremapkeys which was specifically written for remapping key events on evdev devices to monkey-patch remapping support into evdev clients which don't support them, like Wayland compositors.
It basically uses the same approach as userspace drivers like G15Daemon which need to compensate for non-standard input devices. (Open up the evdev device, swallow any events it intends to remap, so nothing else listening on the device can see them, then emit the corrected events via the
uinput
API for creating kernel-level input devices from userspace.)
There's actually anioctl
that can be used to set the mappings without need for a demon or hwdb, but for some reason there don't seem to be any standard tools available for this (I had to write my own tool to experiment).
– dirkt
Jan 25 at 12:13
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f729585%2fremap-keys-without-xmodmap-or-any-x-tools%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
First, the good news
The Linux system console absolutely has its own set of keyboard mappings, which can be managed using the tools from the kbd
package, specifically dumpkeys
and showkey
for discovery and loadkeys
to load in a customized mapping. The SuperUser question How to change console keymap in Linux? has an answer with good information on how to use these tools.
Now, the bad news
While it's true that those tools will allow you to remap the keys on the Linux console, without involving xmodmap
or requiring that X be running, they will only affect the keymappings on the virtual text console. The changes will have absolutely no effect in the graphical environment, because X's XInput/evdev system reads from the input devices directly and does its own processing.
So, if you were hoping to avoid using xmodmap
by just remapping on the console and having it apply everywhere, I'm afraid that won't work. In fact, you'd need to remap both the console (using loadkeys
) and X11 (using a method like xmodmap
), to use the same keyboard layout everywhere.
The solution to the xmodmap
slowness (and bugginess, since its remappings are glitchy and non-persistent in desktop environments that use layout switching) would be to define an entirely new keyboard layout based off of whatever layout you were previously using, rather than applying runtime modifications. On X startup, you'd load that new, remapped layout instead of whatever you're using now. (It seems this is now the only way to reliably modify the keyboard layout in recent Ubuntus — and possibly other distros — as their xmodmap
is no longer useful.)
For information on defining and using a custom xkb
keyboard layout, see:
Howto: Custom keyboard layout definitions in the Ubuntu Community Wiki.
How to modify a keyboard layout in Linux, a blog post by Romano Giannetti.
Both were written this year (2014), so the information should be current. The Ubuntu wiki information should be applicable to any distro, for the most part, as they all use the xkb
system in X.
Wonderful! That was exactly what I was looking for. However, as you mentioned in the comments, it's no longer the case, since I got a new notebook. I cannot test the answer, but since it's exactly what I was looking for I'm pretty sure it'd work, or at least give an alternative to xmodmap. Thanks!
– Alex
Jul 29 '14 at 4:32
add a comment |
First, the good news
The Linux system console absolutely has its own set of keyboard mappings, which can be managed using the tools from the kbd
package, specifically dumpkeys
and showkey
for discovery and loadkeys
to load in a customized mapping. The SuperUser question How to change console keymap in Linux? has an answer with good information on how to use these tools.
Now, the bad news
While it's true that those tools will allow you to remap the keys on the Linux console, without involving xmodmap
or requiring that X be running, they will only affect the keymappings on the virtual text console. The changes will have absolutely no effect in the graphical environment, because X's XInput/evdev system reads from the input devices directly and does its own processing.
So, if you were hoping to avoid using xmodmap
by just remapping on the console and having it apply everywhere, I'm afraid that won't work. In fact, you'd need to remap both the console (using loadkeys
) and X11 (using a method like xmodmap
), to use the same keyboard layout everywhere.
The solution to the xmodmap
slowness (and bugginess, since its remappings are glitchy and non-persistent in desktop environments that use layout switching) would be to define an entirely new keyboard layout based off of whatever layout you were previously using, rather than applying runtime modifications. On X startup, you'd load that new, remapped layout instead of whatever you're using now. (It seems this is now the only way to reliably modify the keyboard layout in recent Ubuntus — and possibly other distros — as their xmodmap
is no longer useful.)
For information on defining and using a custom xkb
keyboard layout, see:
Howto: Custom keyboard layout definitions in the Ubuntu Community Wiki.
How to modify a keyboard layout in Linux, a blog post by Romano Giannetti.
Both were written this year (2014), so the information should be current. The Ubuntu wiki information should be applicable to any distro, for the most part, as they all use the xkb
system in X.
Wonderful! That was exactly what I was looking for. However, as you mentioned in the comments, it's no longer the case, since I got a new notebook. I cannot test the answer, but since it's exactly what I was looking for I'm pretty sure it'd work, or at least give an alternative to xmodmap. Thanks!
– Alex
Jul 29 '14 at 4:32
add a comment |
First, the good news
The Linux system console absolutely has its own set of keyboard mappings, which can be managed using the tools from the kbd
package, specifically dumpkeys
and showkey
for discovery and loadkeys
to load in a customized mapping. The SuperUser question How to change console keymap in Linux? has an answer with good information on how to use these tools.
Now, the bad news
While it's true that those tools will allow you to remap the keys on the Linux console, without involving xmodmap
or requiring that X be running, they will only affect the keymappings on the virtual text console. The changes will have absolutely no effect in the graphical environment, because X's XInput/evdev system reads from the input devices directly and does its own processing.
So, if you were hoping to avoid using xmodmap
by just remapping on the console and having it apply everywhere, I'm afraid that won't work. In fact, you'd need to remap both the console (using loadkeys
) and X11 (using a method like xmodmap
), to use the same keyboard layout everywhere.
The solution to the xmodmap
slowness (and bugginess, since its remappings are glitchy and non-persistent in desktop environments that use layout switching) would be to define an entirely new keyboard layout based off of whatever layout you were previously using, rather than applying runtime modifications. On X startup, you'd load that new, remapped layout instead of whatever you're using now. (It seems this is now the only way to reliably modify the keyboard layout in recent Ubuntus — and possibly other distros — as their xmodmap
is no longer useful.)
For information on defining and using a custom xkb
keyboard layout, see:
Howto: Custom keyboard layout definitions in the Ubuntu Community Wiki.
How to modify a keyboard layout in Linux, a blog post by Romano Giannetti.
Both were written this year (2014), so the information should be current. The Ubuntu wiki information should be applicable to any distro, for the most part, as they all use the xkb
system in X.
First, the good news
The Linux system console absolutely has its own set of keyboard mappings, which can be managed using the tools from the kbd
package, specifically dumpkeys
and showkey
for discovery and loadkeys
to load in a customized mapping. The SuperUser question How to change console keymap in Linux? has an answer with good information on how to use these tools.
Now, the bad news
While it's true that those tools will allow you to remap the keys on the Linux console, without involving xmodmap
or requiring that X be running, they will only affect the keymappings on the virtual text console. The changes will have absolutely no effect in the graphical environment, because X's XInput/evdev system reads from the input devices directly and does its own processing.
So, if you were hoping to avoid using xmodmap
by just remapping on the console and having it apply everywhere, I'm afraid that won't work. In fact, you'd need to remap both the console (using loadkeys
) and X11 (using a method like xmodmap
), to use the same keyboard layout everywhere.
The solution to the xmodmap
slowness (and bugginess, since its remappings are glitchy and non-persistent in desktop environments that use layout switching) would be to define an entirely new keyboard layout based off of whatever layout you were previously using, rather than applying runtime modifications. On X startup, you'd load that new, remapped layout instead of whatever you're using now. (It seems this is now the only way to reliably modify the keyboard layout in recent Ubuntus — and possibly other distros — as their xmodmap
is no longer useful.)
For information on defining and using a custom xkb
keyboard layout, see:
Howto: Custom keyboard layout definitions in the Ubuntu Community Wiki.
How to modify a keyboard layout in Linux, a blog post by Romano Giannetti.
Both were written this year (2014), so the information should be current. The Ubuntu wiki information should be applicable to any distro, for the most part, as they all use the xkb
system in X.
edited Mar 20 '17 at 10:17
Community♦
1
1
answered Jul 25 '14 at 8:51
FeRDFeRD
850711
850711
Wonderful! That was exactly what I was looking for. However, as you mentioned in the comments, it's no longer the case, since I got a new notebook. I cannot test the answer, but since it's exactly what I was looking for I'm pretty sure it'd work, or at least give an alternative to xmodmap. Thanks!
– Alex
Jul 29 '14 at 4:32
add a comment |
Wonderful! That was exactly what I was looking for. However, as you mentioned in the comments, it's no longer the case, since I got a new notebook. I cannot test the answer, but since it's exactly what I was looking for I'm pretty sure it'd work, or at least give an alternative to xmodmap. Thanks!
– Alex
Jul 29 '14 at 4:32
Wonderful! That was exactly what I was looking for. However, as you mentioned in the comments, it's no longer the case, since I got a new notebook. I cannot test the answer, but since it's exactly what I was looking for I'm pretty sure it'd work, or at least give an alternative to xmodmap. Thanks!
– Alex
Jul 29 '14 at 4:32
Wonderful! That was exactly what I was looking for. However, as you mentioned in the comments, it's no longer the case, since I got a new notebook. I cannot test the answer, but since it's exactly what I was looking for I'm pretty sure it'd work, or at least give an alternative to xmodmap. Thanks!
– Alex
Jul 29 '14 at 4:32
add a comment |
There are actually ways to remap at a level low enough to apply to the whole system, X11 or not, and they've become more important than ever now that we're seeing uptake of Wayland compositors which neglect to expose a UI for libinput's remapping support.
You basically need to reconfigure how the kernel's input layer translates raw scancodes into keycodes before they reach the console or the evdev API that X11 and Wayland sit on top of.
I'm aware of two ways to do that:
Modify the hardware database (
hwdb
) entry for your keyboard. udev lets you do that by adding rules files to/etc/udev/hwdb.d/
and triggering a database rebuild withsystemd-hwdb update
, and then forcing it to be applied without a restart viaudevadm trigger
.
This ArchiWiki page has full instructions and explicitly says that it'll work for both X11 and console input.
There's a daemon named evdevremapkeys which was specifically written for remapping key events on evdev devices to monkey-patch remapping support into evdev clients which don't support them, like Wayland compositors.
It basically uses the same approach as userspace drivers like G15Daemon which need to compensate for non-standard input devices. (Open up the evdev device, swallow any events it intends to remap, so nothing else listening on the device can see them, then emit the corrected events via the
uinput
API for creating kernel-level input devices from userspace.)
There's actually anioctl
that can be used to set the mappings without need for a demon or hwdb, but for some reason there don't seem to be any standard tools available for this (I had to write my own tool to experiment).
– dirkt
Jan 25 at 12:13
add a comment |
There are actually ways to remap at a level low enough to apply to the whole system, X11 or not, and they've become more important than ever now that we're seeing uptake of Wayland compositors which neglect to expose a UI for libinput's remapping support.
You basically need to reconfigure how the kernel's input layer translates raw scancodes into keycodes before they reach the console or the evdev API that X11 and Wayland sit on top of.
I'm aware of two ways to do that:
Modify the hardware database (
hwdb
) entry for your keyboard. udev lets you do that by adding rules files to/etc/udev/hwdb.d/
and triggering a database rebuild withsystemd-hwdb update
, and then forcing it to be applied without a restart viaudevadm trigger
.
This ArchiWiki page has full instructions and explicitly says that it'll work for both X11 and console input.
There's a daemon named evdevremapkeys which was specifically written for remapping key events on evdev devices to monkey-patch remapping support into evdev clients which don't support them, like Wayland compositors.
It basically uses the same approach as userspace drivers like G15Daemon which need to compensate for non-standard input devices. (Open up the evdev device, swallow any events it intends to remap, so nothing else listening on the device can see them, then emit the corrected events via the
uinput
API for creating kernel-level input devices from userspace.)
There's actually anioctl
that can be used to set the mappings without need for a demon or hwdb, but for some reason there don't seem to be any standard tools available for this (I had to write my own tool to experiment).
– dirkt
Jan 25 at 12:13
add a comment |
There are actually ways to remap at a level low enough to apply to the whole system, X11 or not, and they've become more important than ever now that we're seeing uptake of Wayland compositors which neglect to expose a UI for libinput's remapping support.
You basically need to reconfigure how the kernel's input layer translates raw scancodes into keycodes before they reach the console or the evdev API that X11 and Wayland sit on top of.
I'm aware of two ways to do that:
Modify the hardware database (
hwdb
) entry for your keyboard. udev lets you do that by adding rules files to/etc/udev/hwdb.d/
and triggering a database rebuild withsystemd-hwdb update
, and then forcing it to be applied without a restart viaudevadm trigger
.
This ArchiWiki page has full instructions and explicitly says that it'll work for both X11 and console input.
There's a daemon named evdevremapkeys which was specifically written for remapping key events on evdev devices to monkey-patch remapping support into evdev clients which don't support them, like Wayland compositors.
It basically uses the same approach as userspace drivers like G15Daemon which need to compensate for non-standard input devices. (Open up the evdev device, swallow any events it intends to remap, so nothing else listening on the device can see them, then emit the corrected events via the
uinput
API for creating kernel-level input devices from userspace.)
There are actually ways to remap at a level low enough to apply to the whole system, X11 or not, and they've become more important than ever now that we're seeing uptake of Wayland compositors which neglect to expose a UI for libinput's remapping support.
You basically need to reconfigure how the kernel's input layer translates raw scancodes into keycodes before they reach the console or the evdev API that X11 and Wayland sit on top of.
I'm aware of two ways to do that:
Modify the hardware database (
hwdb
) entry for your keyboard. udev lets you do that by adding rules files to/etc/udev/hwdb.d/
and triggering a database rebuild withsystemd-hwdb update
, and then forcing it to be applied without a restart viaudevadm trigger
.
This ArchiWiki page has full instructions and explicitly says that it'll work for both X11 and console input.
There's a daemon named evdevremapkeys which was specifically written for remapping key events on evdev devices to monkey-patch remapping support into evdev clients which don't support them, like Wayland compositors.
It basically uses the same approach as userspace drivers like G15Daemon which need to compensate for non-standard input devices. (Open up the evdev device, swallow any events it intends to remap, so nothing else listening on the device can see them, then emit the corrected events via the
uinput
API for creating kernel-level input devices from userspace.)
answered Jan 25 at 10:16
ssokolowssokolow
60669
60669
There's actually anioctl
that can be used to set the mappings without need for a demon or hwdb, but for some reason there don't seem to be any standard tools available for this (I had to write my own tool to experiment).
– dirkt
Jan 25 at 12:13
add a comment |
There's actually anioctl
that can be used to set the mappings without need for a demon or hwdb, but for some reason there don't seem to be any standard tools available for this (I had to write my own tool to experiment).
– dirkt
Jan 25 at 12:13
There's actually an
ioctl
that can be used to set the mappings without need for a demon or hwdb, but for some reason there don't seem to be any standard tools available for this (I had to write my own tool to experiment).– dirkt
Jan 25 at 12:13
There's actually an
ioctl
that can be used to set the mappings without need for a demon or hwdb, but for some reason there don't seem to be any standard tools available for this (I had to write my own tool to experiment).– dirkt
Jan 25 at 12:13
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f729585%2fremap-keys-without-xmodmap-or-any-x-tools%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
7
Have you thought about removing the keyboard and literally washing it? It will take a day to dry out, but is perfectly safe. Also, replacing a laptop keyboard is relatively inexpensive (~$25) compared to the aggravation of re-training your fingers.
– jdh
Mar 18 '14 at 19:29
I realize it's been a while since this was asked and the information's likely no longer needed, but on the "no unanswered questions" principle I added an answer below. Hopefully it will be of some use to someone, even if it's not the original asker.
– FeRD
Jul 25 '14 at 8:55
If a coffee accident made your keyboard shortcut unresponsive at times, like in OP's question - not working for a short time after X has started - for example, probably it may be that the modifier buttons are electrically closed due to the coffee leftovers under the buttons. This will make the computer think that Ctrl+Alt+S is pressed when you press Ctrl+S for example. Run
xev
in a terminal and press each key of your keyboard and check whether the KeyUp event is detected.– fz_salam
Jul 17 '16 at 9:53