lirc for 2.5/2.6 kernels - 20030802

This is the fourth version of my patch for use LIRC drivers under 2.5/2.6 kernels.

As usual, you can find it at
http://flameeyes.web.ctonet.it/lirc/patch-lirc-20030802.diff.bz2

I changed the naming scheme, because I tried and the patch applies also in earliers and (probably) futures kernels, and call it only "patch-lirc.diff" will confuse about the versions. I think a datestamp is the best choice for now.

If you want to get this applied to the official tree (I hope you want ;-), you probably should start with smaller patch. I killed all drivers but lirc_gpio, to make patch smaller/easier to check.

* What does "For now don't try to use as static version" comment in lirc_gpio mean. Does it only work as a module?

* This looks like it should be integrated with drivers/input. After all remote control is just a strange keyboard. What are reasons that can't be done?

Quoted 3 lines

* This looks like it should be integrated with drivers/input. After all remote control is just a strange keyboard. What are reasons that can't be done?

This is a port of the drivers from lirc project (http://lirc.sf.net/),
I'm not going to rewrite it, also because the support for lirc in user software is present in many programs, like xine, xawdecode, xmms (with plugin) and so on.
The lirc_client library is simple and flexible, and the project is consolidated, i don't see the need to change it, also because can be a problem for backport in the 2.4 kernels.

* What does "For now don't try to use as static version" comment in lirc_gpio mean. Does it only work as a module?

Quoted 10 lines

This is the fourth version of my patch for use LIRC drivers under 2.5/2.6 kernels.

As usual, you can find it at
http://flameeyes.web.ctonet.it/lirc/patch-lirc-20030802.diff.bz2

I changed the naming scheme, because I tried and the patch applies also in earliers and (probably) futures kernels, and call it only "patch-lirc.diff" will confuse about the versions. I think a datestamp is the best choice for now.

If you want to get this applied to the official tree (I hope you want ;-), you probably should start with smaller patch. I killed all drivers but lirc_gpio, to make patch smaller/easier to check.

Its now small enough to inline, and that's good.

Few questions:

* What does "For now don't try to use as static version" comment in lirc_gpio mean. Does it only work as a module?

Quoted 3 lines

Quoted 3 lines

* This looks like it should be integrated with drivers/input. After all remote control is just a strange keyboard. What are reasons that can't be done?

I know about lirc project, and I'd like to see it merged, but if lirc uses wrong interface, it is unsuitable for the kernel.

Motivation for having same code for infrared controls and normal
keyboards: normal keyboards tend to have "play"/"stop"/"vol+"/"vol-" keys these days; certainly HP omnibook xe3 has them. It would be nice to handle them in an uniform way.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

* This looks like it should be integrated with drivers/input. After all remote control is just a strange keyboard. What are reasons that can't be done?

Because for most drivers the decoding is done in user space by the lircd daemon.

[...]

Quoted 2 lines

I know about lirc project, and I'd like to see it merged, but if lirc uses wrong interface, it is unsuitable for the kernel.

Is it the wrong interface?

Quoted 4 lines

Motivation for having same code for infrared controls and normal
keyboards: normal keyboards tend to have "play"/"stop"/"vol+"/"vol-" keys these days; certainly HP omnibook xe3 has them. It would be nice to handle them in an uniform way.

No problem. Feed these keys to lircd. Voila: uniform interface to all applications.

I converted lirc_gpio into input/ layer (and killed support for hardware I do not have; sorry but it was essential to keep code small). Ported driver looks like this; I believe it looks better than old code. Patch is here.

Quoted 4 lines · Pavel Machek

I converted lirc_gpio into input/ layer (and killed support for hardware I do not have; sorry but it was essential to keep code small). Ported driver looks like this; I believe it looks better than old code. Patch is here.

You can here see the problem... not all tv cards use the same remote, the switch doesn't work with my remote for example, so we have 2 possibilities:

a) hardcode all the possible remotes adding these as new one come up, this is a big work in the kernel source, and also we lost compatibility with remotes that use the same frequency of the ones with the tv card, and that now can be used.

b) create an userspace utility that read the input layer for codes an then translates them in user-definable commands. This is what lircd do now...

IMHO, the solution used now is the more flexible of the two.

Signature · 7 lines

Flameeyes <[email protected]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 8 lines

Quoted 4 lines

I converted lirc_gpio into input/ layer (and killed support for hardware I do not have; sorry but it was essential to keep code small). Ported driver looks like this; I believe it looks better than old code. Patch is here.

You can here see the problem... not all tv cards use the same remote, the switch doesn't work with my remote for example, so we have 2 possibilities:

Quoted 8 lines

a) hardcode all the possible remotes adding these as new one come up, this is a big work in the kernel source, and also we lost compatibility with remotes that use the same frequency of the ones with the tv card, and that now can be used.

b) create an userspace utility that read the input layer for codes an then translates them in user-definable commands. This is what lircd do now...

what about

c) hardcode the basic decoding and use a mapping table which can be configure from userspace ... (like dvbs haupauge or xmodmap)

c) hardcode the basic decoding and use a mapping table which can be configure from userspace ... (like dvbs haupauge or xmodmap)

Quoted 4 lines

I converted lirc_gpio into input/ layer (and killed support for hardware I do not have; sorry but it was essential to keep code small). Ported driver looks like this; I believe it looks better than old code. Patch is here.

You can here see the problem... not all tv cards use the same remote, the switch doesn't work with my remote for example, so we have 2 possibilities:

a) hardcode all the possible remotes adding these as new one come up, this is a big work in the kernel source, and also we lost compatibility with remotes that use the same frequency of the ones with the tv card, and that now can be used.

I guess a) is okay. There are not *so* many remote controls out there.

I guess thats okay; if I want decoder-that-decodes-anything, I need one that connects to serial port and has non-trivial configuration.

We can drop /dev/lirc*, and use input events with received codes, but I think that lircd is still needed to translate them into userland commands...

Quoted 4 lines

We can drop /dev/lirc*, and use input events with received codes, but I think that lircd is still needed to translate them into userland commands...

That translation isn't done by lircd, but by the lirc_client library. This is no reason for keeping lircd as event dispatcher, the input layer would do equally well (with liblirc_client picking up events from /dev/input/event<x> instead of lircd).

Quoted 8 lines

Quoted 3 lines

We can drop /dev/lirc*, and use input events with received codes, but I think that lircd is still needed to translate them into userland commands...

That translation isn't done by lircd, but by the lirc_client library. This is no reason for keeping lircd as event dispatcher, the input layer would do equally well (with liblirc_client picking up events from /dev/input/event<x> instead of lircd).

IMHO there's one problem:

If a remote control has e.g. a "1" key this doesn't mean that a user wants a "1" to be written into your editor while editing source code. The "1" key on a remote control simply has a differnt _meaning_ than the "1" key on your keyboard -- depending of course on what the user thinks this key should mean.

- users should be able to prevent remote keys from being fed into the normal keyboard input queue; non lirc aware programs should not recieve these events
(OTOH, if you use an IR keyboard...)

- IR events should reach the applications independant of X keyboard focus (well, maybe; the user should be able to decide)

Quoted 9 lines · Gerd Knorr

Quoted 4 lines

We can drop /dev/lirc*, and use input events with received codes, but I think that lircd is still needed to translate them into userland commands...

That translation isn't done by lircd, but by the lirc_client library. This is no reason for keeping lircd as event dispatcher, the input layer would do equally well (with liblirc_client picking up events from /dev/input/event<x> instead of lircd).

IMHO there's one problem:

If a remote control has e.g. a "1" key this doesn't mean that a user wants a "1" to be written into your editor while editing source code. The "1" key on a remote control simply has a differnt _meaning_ than the "1" key on your keyboard -- depending of course on what the user thinks this key should mean.

- users should be able to prevent remote keys from being fed into the normal keyboard input queue; non lirc aware programs should not recieve these events
(OTOH, if you use an IR keyboard...)

- IR events should reach the applications independant of X keyboard focus (well, maybe; the user should be able to decide)

With the current input subsystem, the only possiblity is lircd grabbing the remote events with EVIOCGRAB, and passing them on to the applications.

Quoted 11 lines

Quoted 8 lines

Quoted 3 lines

We can drop /dev/lirc*, and use input events with received codes, but I think that lircd is still needed to translate them into userland commands...

That translation isn't done by lircd, but by the lirc_client library. This is no reason for keeping lircd as event dispatcher, the input layer would do equally well (with liblirc_client picking up events from /dev/input/event<x> instead of lircd).

IMHO there's one problem:

Quoted 5 lines

If a remote control has e.g. a "1" key this doesn't mean that a user wants a "1" to be written into your editor while editing source code. The "1" key on a remote control simply has a differnt _meaning_ than the "1" key on your keyboard -- depending of course on what the user thinks this key should mean.

That's what BTN_1 is for. ;)

Quoted 17 lines

Quoted 16 lines

Quoted 8 lines

Quoted 3 lines

We can drop /dev/lirc*, and use input events with received codes, but I think that lircd is still needed to translate them into userland commands...

That translation isn't done by lircd, but by the lirc_client library. This is no reason for keeping lircd as event dispatcher, the input layer would do equally well (with liblirc_client picking up events from /dev/input/event<x> instead of lircd).

IMHO there's one problem:

If a remote control has e.g. a "1" key this doesn't mean that a user wants a "1" to be written into your editor while editing source code. The "1" key on a remote control simply has a differnt _meaning_ than the "1" key on your keyboard -- depending of course on what the user thinks this key should mean.

Quoted 1 line

That's what BTN_1 is for. ;)

Ahha, I thought BTN_1 would be first mouse button ;-). Will fix that.

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

IMHO there's one problem:

If a remote control has e.g. a "1" key this doesn't mean that a user wants a "1" to be written into your editor while editing source code. The "1" key on a remote control simply has a differnt _meaning_ than the "1" key on your keyboard -- depending of course on what the user thinks this key should mean.

Quoted 3 lines

Quoted 1 line

That's what BTN_1 is for. ;)

Ahha, I thought BTN_1 would be first mouse button ;-). Will fix that.

No, that'd be BTN_LEFT.

Quoted 1 line · Pavel Machek

Ahha, I thought BTN_1 would be first mouse button ;-). Will fix that.

No, that'd be BTN_LEFT.

Quoted 3 lines · Vojtech Pavlik

Quoted 1 line · Pavel Machek

Ahha, I thought BTN_1 would be first mouse button ;-). Will fix that.

No, that'd be BTN_LEFT.

Urp. My mouse has 7 buttons (ok, 5, one of which is a scrollwheel and generates 3 different events). Which left button do you mean? ;)

http://www.microsoft.com/catalog/display.asp?subid=22&site=10561
Fortunately for the coders, it doesn't come in a wireless version yet. ;)

Quoted 5 lines

If a remote control has e.g. a "1" key this doesn't mean that a user wants a "1" to be written into your editor while editing source code. The "1" key on a remote control simply has a differnt _meaning_ than the "1" key on your keyboard -- depending of course on what the user thinks this key should mean.

That's what BTN_1 is for. ;)

This is no reason for keeping lircd as event dispatcher, the input layer would do equally well (with liblirc_client picking up events from /dev/input/event<x> instead of lircd).

On Mon, 11 Aug 2003, Gerd Knorr wrote:

Would this allow you to have one reciever and different remote controles (used for different programs in the end)?

Quoted 1 line

I guess a) is okay. There are not *so* many remote controls out there.

I think more than one per card model. Other Kworld Card have different remote than mine, as you can see on my homepage, my lircd.conf isn't one of the ones in lirc remotes list.

Quoted 2 lines

I guess thats okay; if I want decoder-that-decodes-anything, I need one that connects to serial port and has non-trivial configuration.

But I can't take a new tv card, plug it into my machine, start up, configure the remote, and use xine.

Also, from user apps dev view, I think is more difficult to check for input events knowing that every remote has different buttons, instead of configure the .lircrc and use lirc_client for receive directly software-commands.

We can drop /dev/lirc*, and use input events with received codes, but I think that lircd is still needed to translate them into userland commands...

I actually want to "Take a new tv card, plug it into machine, start up, use xine", without configuring remote ;-).

I think the right way is for application to just use buttons it knows about. We already have some multimedia buttons on keyboard and some more on remote...

I believe we should be able to make it work without lircd, but input events with received codes is still better than current situation.

Quoted 5 lines

a) hardcode all the possible remotes adding these as new one come up, this is a big work in the kernel source, and also we lost compatibility with remotes that use the same frequency of the ones with the tv card, and that now can be used.

I guess a) is okay. There are not *so* many remote controls out there.

Quoted 5 lines

Quoted 4 lines

a) hardcode all the possible remotes adding these as new one come up, this is a big work in the kernel source, and also we lost compatibility with remotes that use the same frequency of the ones with the tv card, and that now can be used.

Quoted 1 line

I guess a) is okay. There are not *so* many remote controls out there.

That's not true, unless you just count the remotes that come packaged with the TV cards. But you might be able to buy all-in-one type remote controls which work with the TV card's IR receiver (it's also possible to connect a different IR-sensor to the TV card's IR input). It would be nice to be able to configure the keys then.

drivers/media/dvb/ttpci/av7110_ir.c does it this way (default map for Hauppauge, loadable keymaps in linuxtv.org CVS).

I converted lirc_gpio into input/ layer (and killed support for hardware I do not have; sorry but it was essential to keep code small). Ported driver looks like this; I believe it looks better than old code. Patch is here.

Quoted 4 lines

I converted lirc_gpio into input/ layer (and killed support for hardware I do not have; sorry but it was essential to keep code small). Ported driver looks like this; I believe it looks better than old code. Patch is here.

And IMHO it will be even better if it is linked directly into the bttv driver and bttv itself registers as input device. All the complicated probing using the functions exported by bttv will go away. The whole construct is only needed because lirc isn't part of the standard kernel ...

Hi!

Yes, that might be even better. I'd like to have ir drivers at one place, but if theres enough advantage the other way...

Quoted 2 lines

Yes, that might be even better. I'd like to have ir drivers at one place, but if theres enough advantage the other way...

Yes, there is: I can just put the IR info into the card database. The poll thread can go away, instead I can hook gpio readouts into the IRQ handler. Probing is just one or two lines in bttv-cards.c, ...