Tiny Core Linux
Tiny Core Extensions => TCE Corepure64 => Topic started by: GNUser on October 14, 2020, 07:32:15 AM
-
I'm on TCL11 64bit with Xorg-7.7. The v4l2-utils.tcz extension is loaded. I'm using an infrared remote control with appropriate ir receiver ("HP media center" set). Alas, Xorg is not responding to some buttons that are critical for me :'(
As two examples:
1) Xorg should interpret the remote's stop button as XF86AudioStop
2) Xorg should interpret a custom button on the remote as the letter "o"
My ir keymap file correctly maps the ir scancodes to appropriate kernel keycodes:
$ cat /opt/rc6_mce_custom
---snip---
0x800f040f KEY_O
0x800f0419 KEY_STOPCD
---snip---
The ir keymap file loads without any problems:
$ sudo ir-keytable -p lirc,rc-6 -w /opt/rc6_mce_custom
Read rc6_mce table
Wrote 63 keycode(s) to driver
Protocols changed to lirc rc-6
The kernel seems to be doing the right thing when I press the two buttons in question:
$ sudo ir-keytable --test
Testing events. Please, press CTRL-C to abort.
47.718236: event type EV_MSC(0x04): scancode = 0x800f040f
47.718236: event type EV_KEY(0x01) key_down: KEY_O(0x0018)
47.718236: event type EV_SYN(0x00).
47.846267: event type EV_KEY(0x01) key_up: KEY_O(0x0018)
47.846267: event type EV_SYN(0x00).
50.114266: event type EV_MSC(0x04): scancode = 0x800f0419
50.114266: event type EV_KEY(0x01) key_down: KEY_STOPCD(0x00a6)
50.114266: event type EV_SYN(0x00).
50.246522: event type EV_KEY(0x01) key_up: KEY_STOPCD(0x00a6)
50.246522: event type EV_SYN(0x00).
But, sadly, Xorg does not respond in any way to these two buttons:
$ xev
-> nothing happens when I press the two buttons
The issue occurs regardless of whether I'm using xf86-input-libinput.tcz or xf86-input-evdev.tcz.
Do you have any ideas about what needs to happen in order for Xorg to respond to these two button presses?
-
Does /var/log/Xorg.0.log show that the remote control has been assigned an event?
-
Yes:
$ cat /var/log/Xorg.0.log | grep -i remote | grep -i event
[ 25.927] (II) config/udev: Adding input device Media Center Ed. eHome Infrared Remote Transceiver (1934:5168) (/dev/input/event7)
[ 25.927] (**) Media Center Ed. eHome Infrared Remote Transceiver (1934:5168): always reports core events
[ 25.927] (**) evdev: Media Center Ed. eHome Infrared Remote Transceiver (1934:5168): Device: "/dev/input/event7"
[ 26.350] (II) config/udev: Adding input device Media Center Ed. eHome Infrared Remote Transceiver (1934:5168) (/dev/input/event7)
[ 26.350] (**) Media Center Ed. eHome Infrared Remote Transceiver (1934:5168): always reports core events
[ 26.350] (**) evdev: Media Center Ed. eHome Infrared Remote Transceiver (1934:5168): Device: "/dev/input/event7"
-
Did you apply those keymap changes before starting X?
-
No, I applied them after starting X.
-
Loading the custom keymap before X did the trick. It was just a matter of putting this line in /opt/bootlocal.sh:
ir-keytable -p lirc,rc-6 -w /opt/rc6_mce_custom
Now X reacts to the keypresses. Thank you, curaga!!
-
Hi GNUser
You might want to read this post:
http://forum.tinycorelinux.net/index.php/topic,23698.msg148996.html#msg148996
While that post specifically refers to kmaps.tcz, it applies to anything that needs to run before X starts.
If you don't want to read what I posted, the answer is, place your command in bootsync.sh , not bootlocal.sh.
Or as I recently wrote:
Hi stephanmg
Things that need to run before a GUI are started (like kmaps) should go into /opt/bootsync.sh.
Things that need to run after a GUI are started (like starting a GUI app) should go into ~/.X.d.
Things that are not sensitive to when they are started should go into /opt/bootlocal.sh which runs in the background.
----- Snip -----
-
Hi, Rich. Thank you very much for that. I guess it worked in bootlocal.sh by sheer luck. I'll put it in bootsync.sh instead.
Thread may be marked as solved :)
-
Hi GNUser
... I guess it worked in bootlocal.sh by sheer luck. ...
For years, placing kmaps in bootlocal.sh appeared to work, mostly. Using bootlocal.sh when a command must
be started in the console does not guarantee failure, however, you also cannot guarantee your command ran
before X started.
Thread may be marked as solved :)
Done. ;D