Getting the Linux console to ignore a usb remote control?
Hi all, I'm connected an mceusb remote control to a Raspberry Pi and plan to use it to control my audio system. I'm directly reading data from /dev/input/event0, which is all well and good (can't be bothered with lirc, it's too much trouble). The one catch to this is that the mceusb remote appears to the system as a keyboard, so while I'm pressing keys, they will be also going to the system console, and I can see from syslog that these keypresses are going to /bin/login (obviously): Sep 16 07:22:47 tart login[31297]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', Authentication failure This is less than ideal, so can anyone think of any way to stop the usb remote from being seen as a keyboard, or to get the system to ignore it? I'm not running X on the system, it's just a console-based. Cheers, Paul -- Paul Dwerryhouse paul@dwerryhouse.com.au
On 16.09.14 10:33, Paul Dwerryhouse wrote:
Sep 16 07:22:47 tart login[31297]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', Authentication failure
This is less than ideal, so can anyone think of any way to stop the usb remote from being seen as a keyboard, or to get the system to ignore it? I'm not running X on the system, it's just a console-based.
ISTM that killing the getty on /dev/tty1 ought to do that. Looking here: $ ps -ef | grep getty root 962 1 0 18:15 tty4 00:00:00 /sbin/getty -8 38400 tty4 root 965 1 0 18:15 tty5 00:00:00 /sbin/getty -8 38400 tty5 root 971 1 0 18:15 tty2 00:00:00 /sbin/getty -8 38400 tty2 root 972 1 0 18:15 tty3 00:00:00 /sbin/getty -8 38400 tty3 root 974 1 0 18:15 tty6 00:00:00 /sbin/getty -8 38400 tty6 root 1490 1 0 18:15 tty1 00:00:00 /sbin/getty -8 38400 tty1 erik 2829 1730 0 18:36 pts/1 00:00:00 grep getty we could try killing PID 1490 (which might respawn), but in the old days I'd edit /etc/inittab to not start one on /dev/tty1 in the first place. However, since ubuntu went over to Upstart, there does not seem to be any /etc/inittab. Ah, here it is: $ more /etc/init/tty1.conf # tty1 - getty # # This service maintains a getty on tty1 from the point the system is # started until it is shut down again. start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -8 38400 tty1 ----------------------- Comment out those 4 lines, and see how you go. (It does not seem that these files are auto generated in response to starting of my four xterms, since tty1.conf is from 2010-04-02.) If you try this fix, it would be fun to hear how you fare. Erik -- "Research is what I'm doing when I don't know what I'm doing." -Wernher Von Braun
On 16/09/14 18:54, Erik Christiansen wrote:
ISTM that killing the getty on /dev/tty1 ought to do that. Looking here:
Thanks, but that's not quite what I'm after. That will prevent logging in from the console at all (with a real keyboard), which I might want, one day. What I'm trying to do is effectively say to the system: "This remote here is just a remote. It's not a keyboard. Tell me what buttons are being pressed (through /dev/input/*), but don't treat them as input to any console" - in much the same way as if I plugged an Xbox-controller into the system, it wouldn't treat it as a keyboard. Cheers, Paul -- Paul Dwerryhouse
Paul Dwerryhouse writes:
On 16/09/14 18:54, Erik Christiansen wrote:
ISTM that killing the getty on /dev/tty1 ought to do that. Looking here:
Thanks, but that's not quite what I'm after. That will prevent logging in from the console at all (with a real keyboard), which I might want, one day.
You can just do Alt+F2 or Alt+Right to switch to a VT that is still running getty & login.
"This remote here is just a remote. It's not a keyboard. Tell me what buttons are being pressed (through /dev/input/*), but don't treat them as input to any console"
We use lirc here, and AFAIK no keyboard input is sent. We use MCEUSB remotes (like you), but OTHER kinds of remotes (especially the ones with a USB receiver dongle) DO appear as keyboards to the OS, such that pressing e.g. Volume Up appears equivalent to pressing the same XF86VolumeUp key on a USB keyboard with media keys. My best guesses are 1. your remote is weird and doing both kinds; or 2. lircd acquires an exclusive lock on that input device. I can't be bothered digging into that for you; sorry.
Erik Christiansen writes:
start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345]
respawn exec /sbin/getty -8 38400 tty1
Comment out those 4 lines, and see how you go.
Just comment out the "start on", preferably. If you're feeling more angry, you can rm it (conffiles preserve this across upgrades) or dpkg-divert it. I'm not convinced this will actually help -- I would expect the input to continue going through, just to a tty where nothing was running. In which case, a clearer approch might be in rc.local # switch to an unused VT, # so IR remote's silly "keyboard" input doesn't # create login(8) failures in auth.log. chvt 8 I didn't mention it before because I'd rather the actual problem was fixed, but I don't know how to go about that.
participants (3)
-
Erik Christiansen -
Paul Dwerryhouse -
trentbuck＠gmail.com