udev rule for mapping dot to ctrl-enter
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
I need to remap the key with scancode 070037 to left ctrl + enter. So far I succeeded in remapping it to enter by creating a file 90-custom-presenter.hwdb with the following content.
# Logitech Presenter
keyboard:usb:b0003v046DpC515*
KEYBOARD_KEY_070037=enter
I assume this is correct because lsusb gives me
Bus 003 Device 018: ID 046d:c515 Logitech, Inc. Cordless 2.4 GHz Presenter Presentation remote control
and evtest confirms that the scancode I am looking for is 70037
Event: time 1521756520.173637, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.173637, type 1 (EV_KEY), code 52 (KEY_DOT), value 1
Event: time 1521756520.173637, -------------- SYN_REPORT ------------
Event: time 1521756520.277633, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.277633, type 1 (EV_KEY), code 52 (KEY_DOT), value 0
Event: time 1521756520.277633, -------------- SYN_REPORT ------------
After running udevadm hwdb --update
as root I would have expected that this maps the former "dot" key to enter but it does not. This raises two questions:
- Why does this not map as expected?
- Once it works as expected, how could I map this to ctrl-enter?
I am running Ubuntu 14.04 LTS.
linux ubuntu keyboard udev
add a comment |Â
up vote
4
down vote
favorite
I need to remap the key with scancode 070037 to left ctrl + enter. So far I succeeded in remapping it to enter by creating a file 90-custom-presenter.hwdb with the following content.
# Logitech Presenter
keyboard:usb:b0003v046DpC515*
KEYBOARD_KEY_070037=enter
I assume this is correct because lsusb gives me
Bus 003 Device 018: ID 046d:c515 Logitech, Inc. Cordless 2.4 GHz Presenter Presentation remote control
and evtest confirms that the scancode I am looking for is 70037
Event: time 1521756520.173637, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.173637, type 1 (EV_KEY), code 52 (KEY_DOT), value 1
Event: time 1521756520.173637, -------------- SYN_REPORT ------------
Event: time 1521756520.277633, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.277633, type 1 (EV_KEY), code 52 (KEY_DOT), value 0
Event: time 1521756520.277633, -------------- SYN_REPORT ------------
After running udevadm hwdb --update
as root I would have expected that this maps the former "dot" key to enter but it does not. This raises two questions:
- Why does this not map as expected?
- Once it works as expected, how could I map this to ctrl-enter?
I am running Ubuntu 14.04 LTS.
linux ubuntu keyboard udev
If this thing is in fact just a keyboard, thenxmodmap
would probably be the place to start. It is specifically designed for such things.
â Joe
Mar 23 at 22:21
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I need to remap the key with scancode 070037 to left ctrl + enter. So far I succeeded in remapping it to enter by creating a file 90-custom-presenter.hwdb with the following content.
# Logitech Presenter
keyboard:usb:b0003v046DpC515*
KEYBOARD_KEY_070037=enter
I assume this is correct because lsusb gives me
Bus 003 Device 018: ID 046d:c515 Logitech, Inc. Cordless 2.4 GHz Presenter Presentation remote control
and evtest confirms that the scancode I am looking for is 70037
Event: time 1521756520.173637, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.173637, type 1 (EV_KEY), code 52 (KEY_DOT), value 1
Event: time 1521756520.173637, -------------- SYN_REPORT ------------
Event: time 1521756520.277633, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.277633, type 1 (EV_KEY), code 52 (KEY_DOT), value 0
Event: time 1521756520.277633, -------------- SYN_REPORT ------------
After running udevadm hwdb --update
as root I would have expected that this maps the former "dot" key to enter but it does not. This raises two questions:
- Why does this not map as expected?
- Once it works as expected, how could I map this to ctrl-enter?
I am running Ubuntu 14.04 LTS.
linux ubuntu keyboard udev
I need to remap the key with scancode 070037 to left ctrl + enter. So far I succeeded in remapping it to enter by creating a file 90-custom-presenter.hwdb with the following content.
# Logitech Presenter
keyboard:usb:b0003v046DpC515*
KEYBOARD_KEY_070037=enter
I assume this is correct because lsusb gives me
Bus 003 Device 018: ID 046d:c515 Logitech, Inc. Cordless 2.4 GHz Presenter Presentation remote control
and evtest confirms that the scancode I am looking for is 70037
Event: time 1521756520.173637, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.173637, type 1 (EV_KEY), code 52 (KEY_DOT), value 1
Event: time 1521756520.173637, -------------- SYN_REPORT ------------
Event: time 1521756520.277633, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70037
Event: time 1521756520.277633, type 1 (EV_KEY), code 52 (KEY_DOT), value 0
Event: time 1521756520.277633, -------------- SYN_REPORT ------------
After running udevadm hwdb --update
as root I would have expected that this maps the former "dot" key to enter but it does not. This raises two questions:
- Why does this not map as expected?
- Once it works as expected, how could I map this to ctrl-enter?
I am running Ubuntu 14.04 LTS.
linux ubuntu keyboard udev
edited Mar 23 at 18:01
asked Mar 22 at 22:10
Udo Klein
1214
1214
If this thing is in fact just a keyboard, thenxmodmap
would probably be the place to start. It is specifically designed for such things.
â Joe
Mar 23 at 22:21
add a comment |Â
If this thing is in fact just a keyboard, thenxmodmap
would probably be the place to start. It is specifically designed for such things.
â Joe
Mar 23 at 22:21
If this thing is in fact just a keyboard, then
xmodmap
would probably be the place to start. It is specifically designed for such things.â Joe
Mar 23 at 22:21
If this thing is in fact just a keyboard, then
xmodmap
would probably be the place to start. It is specifically designed for such things.â Joe
Mar 23 at 22:21
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
You did not identify your Linux distribution, which may or may not use the same version of udev as my Debian 9 does, so this may or may not apply to your system.
On my system, /lib/udev/hwdb.d/60-keyboard.hwdb
has some informative comments:
# Note: The format of the "evdev:" prefix match key is a
# contract between the rules file and the hardware data, it might
# change in later revisions to support more or better matches, it
# is not necessarily expected to be a stable ABI.
#
# Supported hardware matches are:
# - Generic input devices match:
# evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
...
There is no mention of a keyboard:usb
hardware match in the list.
So, unless you have documentation specific to your Linux distribution and version to tell you otherwise, or your actual system default .hwdb
files use the keyboard:usb
syntax, try replacing your keyboard:usb:b0003v046DpC515*
with:
evdev:input:b0003v046DpC515*
The problem with making the presenter's "dot" key to Control+Enter is that the .hwdb file can only map a scancode to a (single) keycode. It cannot insert a sequence of key codes. To map a key to Control+Enter at this stage, you would have to insert an extra event in addition to modifying the actual key event, and do the same thing with the corresponding key release event.
Your desktop environment might include a more versatile keyboard mapping/shortcut feature, which might serve your needs better. You might have to first use the hwdb rules to map the presenter's key to some otherwise unused key code, and then the desktop environment's feature to map that key code to Control+Enter.
1
agree, udev is the wrong tool for this job. xkb might do it (but ugly and hacky); a macro program would be more suitable. it might be reasonable to use udev to map the key to something likeF20
that will absolutely positively not be recognized as.
, if desired, before using a macro program to turn that keystroke into the final result.
â quixotic
Mar 23 at 6:48
also note that in/lib/udev/hwdb.d/60-keyboard.hwdb
, the keymapping lines are indented with a single space, which the questioner's example is missing.
â quixotic
Mar 23 at 6:50
I fixed the question, it now gives the version I am running.
â Udo Klein
Mar 23 at 17:15
I added the extra space. Nothing. Also in my 60-keyboard.hwdb it states # Supported hardware matches are: # - USB keyboards identified by the usb kernel modalias: # keyboard:usb:vXXXXpYYYY*
â Udo Klein
Mar 23 at 18:02
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
You did not identify your Linux distribution, which may or may not use the same version of udev as my Debian 9 does, so this may or may not apply to your system.
On my system, /lib/udev/hwdb.d/60-keyboard.hwdb
has some informative comments:
# Note: The format of the "evdev:" prefix match key is a
# contract between the rules file and the hardware data, it might
# change in later revisions to support more or better matches, it
# is not necessarily expected to be a stable ABI.
#
# Supported hardware matches are:
# - Generic input devices match:
# evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
...
There is no mention of a keyboard:usb
hardware match in the list.
So, unless you have documentation specific to your Linux distribution and version to tell you otherwise, or your actual system default .hwdb
files use the keyboard:usb
syntax, try replacing your keyboard:usb:b0003v046DpC515*
with:
evdev:input:b0003v046DpC515*
The problem with making the presenter's "dot" key to Control+Enter is that the .hwdb file can only map a scancode to a (single) keycode. It cannot insert a sequence of key codes. To map a key to Control+Enter at this stage, you would have to insert an extra event in addition to modifying the actual key event, and do the same thing with the corresponding key release event.
Your desktop environment might include a more versatile keyboard mapping/shortcut feature, which might serve your needs better. You might have to first use the hwdb rules to map the presenter's key to some otherwise unused key code, and then the desktop environment's feature to map that key code to Control+Enter.
1
agree, udev is the wrong tool for this job. xkb might do it (but ugly and hacky); a macro program would be more suitable. it might be reasonable to use udev to map the key to something likeF20
that will absolutely positively not be recognized as.
, if desired, before using a macro program to turn that keystroke into the final result.
â quixotic
Mar 23 at 6:48
also note that in/lib/udev/hwdb.d/60-keyboard.hwdb
, the keymapping lines are indented with a single space, which the questioner's example is missing.
â quixotic
Mar 23 at 6:50
I fixed the question, it now gives the version I am running.
â Udo Klein
Mar 23 at 17:15
I added the extra space. Nothing. Also in my 60-keyboard.hwdb it states # Supported hardware matches are: # - USB keyboards identified by the usb kernel modalias: # keyboard:usb:vXXXXpYYYY*
â Udo Klein
Mar 23 at 18:02
add a comment |Â
up vote
2
down vote
You did not identify your Linux distribution, which may or may not use the same version of udev as my Debian 9 does, so this may or may not apply to your system.
On my system, /lib/udev/hwdb.d/60-keyboard.hwdb
has some informative comments:
# Note: The format of the "evdev:" prefix match key is a
# contract between the rules file and the hardware data, it might
# change in later revisions to support more or better matches, it
# is not necessarily expected to be a stable ABI.
#
# Supported hardware matches are:
# - Generic input devices match:
# evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
...
There is no mention of a keyboard:usb
hardware match in the list.
So, unless you have documentation specific to your Linux distribution and version to tell you otherwise, or your actual system default .hwdb
files use the keyboard:usb
syntax, try replacing your keyboard:usb:b0003v046DpC515*
with:
evdev:input:b0003v046DpC515*
The problem with making the presenter's "dot" key to Control+Enter is that the .hwdb file can only map a scancode to a (single) keycode. It cannot insert a sequence of key codes. To map a key to Control+Enter at this stage, you would have to insert an extra event in addition to modifying the actual key event, and do the same thing with the corresponding key release event.
Your desktop environment might include a more versatile keyboard mapping/shortcut feature, which might serve your needs better. You might have to first use the hwdb rules to map the presenter's key to some otherwise unused key code, and then the desktop environment's feature to map that key code to Control+Enter.
1
agree, udev is the wrong tool for this job. xkb might do it (but ugly and hacky); a macro program would be more suitable. it might be reasonable to use udev to map the key to something likeF20
that will absolutely positively not be recognized as.
, if desired, before using a macro program to turn that keystroke into the final result.
â quixotic
Mar 23 at 6:48
also note that in/lib/udev/hwdb.d/60-keyboard.hwdb
, the keymapping lines are indented with a single space, which the questioner's example is missing.
â quixotic
Mar 23 at 6:50
I fixed the question, it now gives the version I am running.
â Udo Klein
Mar 23 at 17:15
I added the extra space. Nothing. Also in my 60-keyboard.hwdb it states # Supported hardware matches are: # - USB keyboards identified by the usb kernel modalias: # keyboard:usb:vXXXXpYYYY*
â Udo Klein
Mar 23 at 18:02
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You did not identify your Linux distribution, which may or may not use the same version of udev as my Debian 9 does, so this may or may not apply to your system.
On my system, /lib/udev/hwdb.d/60-keyboard.hwdb
has some informative comments:
# Note: The format of the "evdev:" prefix match key is a
# contract between the rules file and the hardware data, it might
# change in later revisions to support more or better matches, it
# is not necessarily expected to be a stable ABI.
#
# Supported hardware matches are:
# - Generic input devices match:
# evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
...
There is no mention of a keyboard:usb
hardware match in the list.
So, unless you have documentation specific to your Linux distribution and version to tell you otherwise, or your actual system default .hwdb
files use the keyboard:usb
syntax, try replacing your keyboard:usb:b0003v046DpC515*
with:
evdev:input:b0003v046DpC515*
The problem with making the presenter's "dot" key to Control+Enter is that the .hwdb file can only map a scancode to a (single) keycode. It cannot insert a sequence of key codes. To map a key to Control+Enter at this stage, you would have to insert an extra event in addition to modifying the actual key event, and do the same thing with the corresponding key release event.
Your desktop environment might include a more versatile keyboard mapping/shortcut feature, which might serve your needs better. You might have to first use the hwdb rules to map the presenter's key to some otherwise unused key code, and then the desktop environment's feature to map that key code to Control+Enter.
You did not identify your Linux distribution, which may or may not use the same version of udev as my Debian 9 does, so this may or may not apply to your system.
On my system, /lib/udev/hwdb.d/60-keyboard.hwdb
has some informative comments:
# Note: The format of the "evdev:" prefix match key is a
# contract between the rules file and the hardware data, it might
# change in later revisions to support more or better matches, it
# is not necessarily expected to be a stable ABI.
#
# Supported hardware matches are:
# - Generic input devices match:
# evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
...
There is no mention of a keyboard:usb
hardware match in the list.
So, unless you have documentation specific to your Linux distribution and version to tell you otherwise, or your actual system default .hwdb
files use the keyboard:usb
syntax, try replacing your keyboard:usb:b0003v046DpC515*
with:
evdev:input:b0003v046DpC515*
The problem with making the presenter's "dot" key to Control+Enter is that the .hwdb file can only map a scancode to a (single) keycode. It cannot insert a sequence of key codes. To map a key to Control+Enter at this stage, you would have to insert an extra event in addition to modifying the actual key event, and do the same thing with the corresponding key release event.
Your desktop environment might include a more versatile keyboard mapping/shortcut feature, which might serve your needs better. You might have to first use the hwdb rules to map the presenter's key to some otherwise unused key code, and then the desktop environment's feature to map that key code to Control+Enter.
answered Mar 23 at 6:27
telcoM
10.6k11132
10.6k11132
1
agree, udev is the wrong tool for this job. xkb might do it (but ugly and hacky); a macro program would be more suitable. it might be reasonable to use udev to map the key to something likeF20
that will absolutely positively not be recognized as.
, if desired, before using a macro program to turn that keystroke into the final result.
â quixotic
Mar 23 at 6:48
also note that in/lib/udev/hwdb.d/60-keyboard.hwdb
, the keymapping lines are indented with a single space, which the questioner's example is missing.
â quixotic
Mar 23 at 6:50
I fixed the question, it now gives the version I am running.
â Udo Klein
Mar 23 at 17:15
I added the extra space. Nothing. Also in my 60-keyboard.hwdb it states # Supported hardware matches are: # - USB keyboards identified by the usb kernel modalias: # keyboard:usb:vXXXXpYYYY*
â Udo Klein
Mar 23 at 18:02
add a comment |Â
1
agree, udev is the wrong tool for this job. xkb might do it (but ugly and hacky); a macro program would be more suitable. it might be reasonable to use udev to map the key to something likeF20
that will absolutely positively not be recognized as.
, if desired, before using a macro program to turn that keystroke into the final result.
â quixotic
Mar 23 at 6:48
also note that in/lib/udev/hwdb.d/60-keyboard.hwdb
, the keymapping lines are indented with a single space, which the questioner's example is missing.
â quixotic
Mar 23 at 6:50
I fixed the question, it now gives the version I am running.
â Udo Klein
Mar 23 at 17:15
I added the extra space. Nothing. Also in my 60-keyboard.hwdb it states # Supported hardware matches are: # - USB keyboards identified by the usb kernel modalias: # keyboard:usb:vXXXXpYYYY*
â Udo Klein
Mar 23 at 18:02
1
1
agree, udev is the wrong tool for this job. xkb might do it (but ugly and hacky); a macro program would be more suitable. it might be reasonable to use udev to map the key to something like
F20
that will absolutely positively not be recognized as .
, if desired, before using a macro program to turn that keystroke into the final result.â quixotic
Mar 23 at 6:48
agree, udev is the wrong tool for this job. xkb might do it (but ugly and hacky); a macro program would be more suitable. it might be reasonable to use udev to map the key to something like
F20
that will absolutely positively not be recognized as .
, if desired, before using a macro program to turn that keystroke into the final result.â quixotic
Mar 23 at 6:48
also note that in
/lib/udev/hwdb.d/60-keyboard.hwdb
, the keymapping lines are indented with a single space, which the questioner's example is missing.â quixotic
Mar 23 at 6:50
also note that in
/lib/udev/hwdb.d/60-keyboard.hwdb
, the keymapping lines are indented with a single space, which the questioner's example is missing.â quixotic
Mar 23 at 6:50
I fixed the question, it now gives the version I am running.
â Udo Klein
Mar 23 at 17:15
I fixed the question, it now gives the version I am running.
â Udo Klein
Mar 23 at 17:15
I added the extra space. Nothing. Also in my 60-keyboard.hwdb it states # Supported hardware matches are: # - USB keyboards identified by the usb kernel modalias: # keyboard:usb:vXXXXpYYYY*
â Udo Klein
Mar 23 at 18:02
I added the extra space. Nothing. Also in my 60-keyboard.hwdb it states # Supported hardware matches are: # - USB keyboards identified by the usb kernel modalias: # keyboard:usb:vXXXXpYYYY*
â Udo Klein
Mar 23 at 18:02
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f432952%2fudev-rule-for-mapping-dot-to-ctrl-enter%23new-answer', 'question_page');
);
Post as a guest
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
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
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
If this thing is in fact just a keyboard, then
xmodmap
would probably be the place to start. It is specifically designed for such things.â Joe
Mar 23 at 22:21