On 11/26/2009 04:14 AM, Gerd Hoffmann wrote:
On 11/26/09 07:23, Jarod Wilson wrote:
Well, when mythtv was started, I don't know that there were many
input layer remotes around... lirc was definitely around though.
lirc predates the input layer IR drivers by years, maybe even the input
layer itself.
That was my guess, but I didn't have a timeline in front of me. :)
The main reason for the input layer IR drivers appearing was lirc not
being mainline. A in-kernel driver (bttv in that case) which depends on
a out-of-tree subsystem for IR support was simply a pain in the ass for
both maintainer (/me back then) and users.
At least for IR hardware which allows access to the raw samples it
certainly makes sense to support lirc, additional to the current (or
improved) input layer support.
I'm liking the idea of a hybrid approach, where IR devices can support
both lirc and input device interfaces. I think its the most
regression-proof for end-users, if done correctly, which is one of my
biggest concerns.
The lirc support in mythtv actually relies on mapping remote button
names as defined in lircd.conf to keyboard key strokes. As mentioned
elsewhere in this beast of a thread, mythtv doesn't currently support
things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but
I intend on fixing that...
lircd can handle the input layer as input as well, so you actually can
remap things via lircd even for pure input layer drivers. mythtv
handling KEY_VOLUMEUP directly would be more elegant though.
Yeah, no, I know lircd can attach to an input device. But even if you do
that, you have to have a mapping that converts KEY_VOLUMEUP as captured
by lircd into (iirc) right-bracket (]) for mythtv to actually consume
it. Directly handling definitely needs to be added to mythtv.
--
Jarod Wilson
jarod@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
