Gerd Knorr wrote:
Ole Andre Schistad <oschista@xxxxxxxxx> writes:
How do I program this? If I try to load a map through kbd -f, the
program exits with the following:
/dev/input/event0
device has no map
Which kernel? That works with 2.6.x only, the 2.4.x input layer
doesn't support that yet ...
Aha that explains rather a lot actually ;) So in other words, the only
way to modify the default keymap in a 2.4 kernel at the moment would be
to edit the headers and recompile. Presumably this code will eventually
be downported from the dev kernels?
Alternatively, if only I could get lirc to recognize the remote all of
these would be gone. The CVS version is actually seeing the
keypresses, and I can record a config file with irrecord - it just
doesn't work. Has anyone had time to experiment with lirc's evdev
support yet?
Several people are using this ...
Yes, it took me some digging but I finally found out how to use the
evdev with lirc. Since other people might be looking for an answer I'll
explain the details below:
irrecord does not work with the eventN devices. It registers the
buttonpresses, but it fails to figure out the timings etc for the remote
control, so none of the configs I generated with irrecord ever worked.
However; there's no need to figure out these extra parameters when using
the eventN device anyway, so what you can do is just write a plain
lircd.conf file with just the code to button mappings and it'll work fine.
First off, you need the CVS version of lirc since the evdev support
hasn't been implenented in any of the release versions yet. Goto
www.lirc.org for the details.
run ./configure and select Driver configuration > 0 - Other > 4 Linux
Input Layer, save and run configure. Once the program is compiled and
installed, you'll need to start lircd with the -d /dev/input/eventN
parameter, so put this into your lircd init script.
Now start irw and tail /var/log/lircd - the button codes will show up in
the log as you press them. For each button press you get two evens in
the log - the button down and up. The button down all start with 0x00
while the button up events start with 0x80 - you'll want to use the
former, otherwise you have to let go of the button before it reacts.
Basically just press the buttons in order, cut the resulting code in the
log tail window and paste them into your lircd.conf. Once you're done
you should have a file that looks like this:
begin remote
name Cinergy
begin codes
POW 0x00010074
APP 0x00010094
ZOOM 0x00010174
1 0x0001004f
2 0x00010050
... etc
end codes
end remote
Now restart lircd, run irw again, and you should see each keypress with
their name mappings in the output of irw. You'll also get an unknown
event every time - that's the keyup event which lirc does not
understand, but it doesn't matter.
Hope this may be of help to someone - it took me long enough to figure
out for myself, probably because I'm thick but anyway.. :)
Now for my questions:
Geerd: The 1016 snapshot which I'm using has a misbehaviour when you run
it with repeat on (ie, the default setting) in that it does not register
the button up event properly, resulting in an infinite repetition of the
keypress. Obviously this makes it impossible to use, so I had to turn
off repetitions. This does work well enough - as a matter of fact,
holding down a button will generate repeats even with this turned off in
the driver, so. I suspect that the remote itself may be sending on-off
pulses rather than just on-on-on-on-off when you hold a button down.
Would be nice to know though, becase it would be preferable if the
remote did not send keyup (or stop sending keydown) until one actually
let go of the key, since this is how many programs expect their input to
behave. As I said though this is probably hardwired into the remote
itself and impossible to fix in software.
Question two is wether or not you can turn off the keyboard emulation in
the driver - this is necessary when running lirc, since you're basically
generating two events for every keypress in all programs that support
both keyboard and lircd input.. rather hard to browse through file
listings etc in other words. Can this be turned off without commenting
out the relevant portions of the code and recompiling?
Also there seems to be some problems with the input buffer - this could
be lirc's fault rather than the driver - but quite often a button press
doesn't become visible until you press another button, as if the input
queue was being filled in batches rather than in realtime. Anyone notice
this as well?
So thanks for the help everyone, I got there in the end. Cheers!
--
Ole Andre
