haupauge remote keycode for av7110_loadkeys
Hi,
I attached keycodes for http://www.hauppauge.eu/boutique_us/images_produits/1111111.jpg remote.
Can it be added to dvb-apps/util/av7110_loadkeys/ repo.
Matthieu
PS : this is more or less a duplicate of keycode in ir_codes_hauppauge_new (ir-kbd-i2c.c) and it could be useful to merge them. But I like better the av7110_loadkeys approch, because with ir-kbd-i2c you can't use other remote without modifying the source code.
0x3d KEY_POWER0x3b KEY_GOTO
0x1c KEY_TV0x18 KEY_VIDEO0x19 KEY_AUDIO0x1a KEY_MHP0x1b KEY_EPG0x0c KEY_RADIO
0x14 KEY_UP0x16 KEY_LEFT0x17 KEY_RIGHT0x15 KEY_DOWN0x25 KEY_ENTER
0x1f KEY_EXIT0x0d KEY_MENU
0x10 KEY_VOLUMEUP0x11 KEY_VOLUMEDOWN0x20 KEY_CHANNELUP0x21 KEY_CHANNELDOWN0x12 KEY_PREVIOUS
0x0f KEY_MUTE0x32 KEY_REWIND0x35 KEY_PLAY0x34 KEY_FASTFORWARD0x37 KEY_RECORD0x36 KEY_STOP0x30 KEY_PAUSE0x24 KEY_PREVIOUSSONG0x1e KEY_NEXTSONG
0x00 KEY_00x01 KEY_10x02 KEY_20x03 KEY_30x04 KEY_40x05 KEY_50x06 KEY_60x07 KEY_70x08 KEY_80x09 KEY_90x0a KEY_TEXT0x0e KEY_SUBTITLE
0x0b KEY_RED0x2e KEY_GREEN0x38 KEY_YELLOW0x29 KEY_BLUE
Quoted 5 lines · On Mon, 19 Jan 2009 21:35:52 +0100 matthieu castet <[email protected]>…
Hi,
I attached keycodes for
http://www.hauppauge.eu/boutique_us/images_produits/1111111.jpg remote.
Quoted 8 lines
Can it be added to dvb-apps/util/av7110_loadkeys/ repo.
Matthieu
PS : this is more or less a duplicate of keycode in
ir_codes_hauppauge_new(ir-kbd-i2c.c) and it could be useful to merge them. But I like better theav7110_loadkeysapproch, because with ir-kbd-i2c you can't use other remote without modifying the source code.
Matthieu,
You can replace the ir-kbd-i2c keys using the standard input ioctls for it. Take a look at v4l2-apps/util/keycode app. It allows you to read and replace any IR keycodes on the driver that properly implements the event support (including ir-kbd-i2c).
Cheers,
Mauro
Hi,
Quoted 10 lines · Mauro Carvalho Chehab
On Mon, 19 Jan 2009 21:35:52 +0100
matthieu castet <[email protected]> wrote:Matthieu,
You can replace the ir-kbd-i2c keys using the standard input ioctls for it. Take a look at v4l2-apps/util/keycode app. It allows you to read and replace any IR keycodes on the driver that properly implements the event support (including ir-kbd-i2c).
great I wasn't aware of this.
But this doesn't seem very friendly : all remote keycodes are in kernel.
If you want to change the remote, you have to do/provide the keycode for your remote even if it is already in kernel.
Matthieu
Quoted 17 lines · matthieu castet
Hi,
Quoted 5 lines · Mauro Carvalho Chehab
On Mon, 19 Jan 2009 21:35:52 +0100
matthieu castet <[email protected]> wrote:Quoted 8 lines
Matthieu,
You can replace the ir-kbd-i2c keys using the standard input ioctls for it.
Take a look at v4l2-apps/util/keycode app. It allows you to read and replace
any IR keycodes on the driver that properly implements the event support (including ir-kbd-i2c).
Quoted 6 lines
great I wasn't aware of this.
But this doesn't seem very friendly : all remote keycodes are in kernel. If you want to change the remote, you have to do/provide the keycode for your remote even if it is already in kernel.Matthieu
Matthieu,
Your assessment of the current situation is correct. Yes, it's a pretty annoying situation. It does have the upside that we automatically provide the right keycodes for whatever remote comes by default with a particular product, but obviously it is a mess if you want to use some different remote and if your remote wasn't supported, adding support requires a kernel recompile.
Devin
Signature · 3 lines
Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller
Quoted 26 lines · On Tue, 20 Jan 2009 14:50:26 -0500 "Devin Heitmueller"…
Quoted 17 lines · matthieu castet
Hi,
Quoted 5 lines · Mauro Carvalho Chehab
On Mon, 19 Jan 2009 21:35:52 +0100
matthieu castet <[email protected]> wrote:Quoted 8 lines
Matthieu,
You can replace the ir-kbd-i2c keys using the standard input ioctls for it.
Take a look at v4l2-apps/util/keycode app. It allows you to read and replace
any IR keycodes on the driver that properly implements the event support (including ir-kbd-i2c).Quoted 6 lines
great I wasn't aware of this.
But this doesn't seem very friendly : all remote keycodes are in kernel. If you want to change the remote, you have to do/provide the keycode for your remote even if it is already in kernel.Matthieu
Quoted 8 lines
Matthieu,
Your assessment of the current situation is correct. Yes, it's a pretty annoying situation. It does have the upside that we automatically provide the right keycodes for whatever remote comes by default with a particular product, but obviously it is a mess if you want to use some different remote and if your remote wasn't supported, adding support requires a kernel recompile.
No. Replacing the keycodes is as easy as adding something like this on your rc.local, or adding an equivalent udev rule:
./v4l2-apps/util/keycode /dev/input/event3 ./v4l2-apps/util/keycodes/avertv_303
This will replace the keys of the input device (assumed above that the event device is event3) by the keys at avertv_303 file.
The in-kernel tables are just the default ones for that device.
Cheers,
Mauro
Quoted 10 lines · Mauro Carvalho Chehab
Quoted 6 lines
Your assessment of the current situation is correct. Yes, it's a pretty annoying situation. It does have the upside that we automatically provide the right keycodes for whatever remote comes by default with a particular product, but obviously it is a mess if you want to use some different remote and if your remote wasn't supported, adding support requires a kernel recompile.
No. Replacing the keycodes is as easy as adding something like this on your rc.local, or adding an equivalent udev rule:
Quoted 6 lines
./v4l2-apps/util/keycode
/dev/input/event3./v4l2-apps/util/keycodes/avertv_303This will replace the keys of the input device (assumed above that the event device is event3) by the keys at
avertv_303file.The in-kernel tables are just the default ones for that device.
I guess the thing I disagree with is the notion that what you have described is "easy".
* It requires keymaps being maintained both in-kernel and out-of-kernel
* It doesn't work with all drivers (like the dib0700)
* It doesn't let you select a different in-kernel keymap unless you translate it to a file that can be passed to the keycode utility
* The interactions with lircd is inconsistent across drivers.
I'm all in favor of some way for making sure the correct default keymap is selected for a given device, but the current approach is pretty haphazard.
Devin
Signature · 3 lines
Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller
Quoted 17 lines · On Tue, 20 Jan 2009 17:36:02 -0500 "Devin Heitmueller"…
Quoted 15 lines · Mauro Carvalho Chehab
Quoted 6 lines
Your assessment of the current situation is correct. Yes, it's a pretty annoying situation. It does have the upside that we automatically provide the right keycodes for whatever remote comes by default with a particular product, but obviously it is a mess if you want to use some different remote and if your remote wasn't supported, adding support requires a kernel recompile.
No. Replacing the keycodes is as easy as adding something like this on your rc.local, or adding an equivalent udev rule:
./v4l2-apps/util/keycode
/dev/input/event3./v4l2-apps/util/keycodes/avertv_303This will replace the keys of the input device (assumed above that the event device is event3) by the keys at
avertv_303file.
Quoted 8 lines
Quoted 1 line
The in-kernel tables are just the default ones for that device.
I guess the thing I disagree with is the notion that what you have described is "easy".
* It requires keymaps being maintained both in-kernel and out-of-kernel
* It doesn't let you select a different in-kernel keymap unless you translate it to a file that can be passed to the keycode utility
make keycode gets all in-kernel tables and converts them into files used by keycode program. So, all in-kernel tables are got (from almost all devices).
Quoted 1 line
* It doesn't work with all drivers (like the dib0700)
Unfortunately, dib0700 doesn't properly implement the input interface.
Quoted 1 line
* The interactions with lircd is inconsistent across drivers.
I've stopped using LIRC a long time ago. It used to be hard to configure, and to produce huge dumps of errors, if the device got disconnected by removing the module or the usb stick. Not sure what changed on lirc since then.
I agree that the IR tables need some adjustments to make they more consistent. For example, IMO, it is a really bad idea to map any IR key into KEY_POWER, since, if you press it wanting to stop your video app, it will, instead, power down the machine. KEY_POWER2 is better, since it can be handled only at the video apps.
Cheers,
Mauro
Quoted 3 lines · Mauro Carvalho Chehab
Quoted 1 line
* It doesn't work with all drivers (like the dib0700)
Unfortunately, dib0700 doesn't properly implement the input interface.
This is something I wanted to rework but had not gotten around to it yet.
Quoted 5 lines
Quoted 1 line
* The interactions with lircd is inconsistent across drivers.
I've stopped using LIRC a long time ago. It used to be hard to configure, and to produce huge dumps of errors, if the device got disconnected by removing the module or the usb stick. Not sure what changed on lirc since then.
You may not be using lircd, but I am quite confident that others do, based on the traffic on the ML. In fact, some use lircd to work around their devices not working with dib0700, so any change to make dib0700 more consistent with some of the other devices will likely result in breakage for those users.
Quoted 5 lines
I agree that the IR tables need some adjustments to make they more consistent. For example, IMO, it is a really bad idea to map any IR key into
KEY_POWER, since, if you press it wanting to stop your video app, it will, instead, power down the machine.KEY_POWER2is better, since it can be handled only at the video apps.
Does this approach handle things like keymaps that are not for RC5 based remote controls? Also, how does this approach allow for telling the IR receiver what format to capture in (NEC/RC5/RC6)?
Admittedly I don't know the answers to these questions myself, which is why both the dib0700 and em28xx drivers only support RC5, even though both chips support other formats (the dib0700 supports RC5/RC6 and the em28xx supports NEC/RC5/RC6). If we had a consistent scheme for specifying what format a keymap is in, I could make sure the chip is in the correct mode (I have all the relevant information for both chips).
The real question lies in where to draw the line between what should be done in userland versus what should be done in the kernel? At one end of the spectrum, you could argue that the kernel should really be representing the devices as RC5/RC6 receivers, and all the translation to keycodes should be done in userland by something such as lircd, and on the other end of the spectrum is that everything should be in kernel and there should never be a need for lircd and there should just be an API for loading any lirc keymap into the kernel.
The whole topic is a *huge* source of confusion for most people, including the developers, given that the approach varies by device and the variety of ways people workaround the condition of "my remote doesn't work", some of which involve the use of lircd.
Devin
Signature · 3 lines
Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller
Quoted 8 lines · On Tue, 20 Jan 2009 18:20:10 -0500 "Devin Heitmueller"…
Quoted 3 lines · Mauro Carvalho Chehab
Quoted 1 line
* It doesn't work with all drivers (like the dib0700)
Unfortunately, dib0700 doesn't properly implement the input interface.
This is something I wanted to rework but had not gotten around to it yet.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
* The interactions with lircd is inconsistent across drivers.
I've stopped using LIRC a long time ago. It used to be hard to configure, and to produce huge dumps of errors, if the device got disconnected by removing the module or the usb stick. Not sure what changed on lirc since then.
You may not be using lircd, but I am quite confident that others do, based on the traffic on the ML.
Yes, I know.
Quoted 11 lines
In fact, some use lircd to work
around their devices not working with dib0700, so any change to make dib0700 more consistent with some of the other devices will likely result in breakage for those users.Quoted 5 lines
I agree that the IR tables need some adjustments to make they more consistent. For example, IMO, it is a really bad idea to map any IR key into
KEY_POWER, since, if you press it wanting to stop your video app, it will, instead, power down the machine.KEY_POWER2is better, since it can be handled only at the video apps.
Quoted 3 lines
Does this approach handle things like keymaps that are not for RC5 based remote controls? Also, how does this approach allow for telling the IR receiver what format to capture in (NEC/RC5/RC6)?
There's no interface to specify a different format, even on drivers like bttv where several formats are supported. It should be noticed that the way the IR is captured depends on the specific device. Some uses a GPIO pin for receiving IR, and the kernel driver implements the decoding protocol. On those, it shouldn't be hard to add an ioctl to allow selecting a different protocol to decode.
Other devices has a micro-controller that translates the manufacturer's chosen protocol into scan codes. For those, probably we can't change the IR format, since the IR decoder is written inside the controller firmware or FPGA.
The same driver supports more than one type of IR. So, in order to allow the format change, we'll need to implement a per-board IR capability flag.
Quoted 4 lines
Admittedly I don't know the answers to these questions myself, which is why both the dib0700 and em28xx drivers only support RC5, even though both chips support other formats (the dib0700 supports RC5/RC6 and the em28xx supports NEC/RC5/RC6).
The em28xx driver also supports I2C based IR's, where a micro-controller handles the IR protocol decoding.
Quoted 4 lines
If we had a consistent scheme
for specifying what format a keymap is in, I could make sure the chip is in the correct mode (I have all the relevant information for both chips).
We may discuss this with event guys to see the better way for implementing it.
Quoted 8 lines
The real question lies in where to draw the line between what should be done in userland versus what should be done in the kernel? At one end of the spectrum, you could argue that the kernel should really be representing the devices as RC5/RC6 receivers, and all the translation to keycodes should be done in userland by something such as lircd, and on the other end of the spectrum is that everything should be in kernel and there should never be a need for lircd and there should just be an API for loading any lirc keymap into the kernel.
In general, the truth is located between the two endpoints.
Quoted 1 line
From my POV, the big gain with lirc is the capability of associating an IR
event wit a set of key/applications. For sure, this should be kept on userspace. On the other hand, kernel knows more about device specifics. So, it is better if kernel will be in charge of implementing the better way to generate a keycode, based on the hardware, using a scancode to keycode table given by userspace.
So, the solution needs both userspace and kernelspace.
Quoted 4 lines
The whole topic is a *huge* source of confusion for most people, including the developers, given that the approach varies by device and the variety of ways people workaround the condition of "my remote doesn't work", some of which involve the use of lircd.
True.
Cheers,
Mauro
Hi,
Am Dienstag, den 20.01.2009, 18:20 -0500 schrieb Devin Heitmueller:
Quoted 47 lines
Quoted 3 lines · Mauro Carvalho Chehab
Quoted 1 line
* It doesn't work with all drivers (like the dib0700)
Unfortunately, dib0700 doesn't properly implement the input interface.
This is something I wanted to rework but had not gotten around to it yet.
Quoted 5 lines
Quoted 1 line
* The interactions with lircd is inconsistent across drivers.
I've stopped using LIRC a long time ago. It used to be hard to configure, and to produce huge dumps of errors, if the device got disconnected by removing the module or the usb stick. Not sure what changed on lirc since then.
You may not be using lircd, but I am quite confident that others do, based on the traffic on the ML. In fact, some use lircd to work around their devices not working with dib0700, so any change to make dib0700 more consistent with some of the other devices will likely result in breakage for those users.
Quoted 5 lines
I agree that the IR tables need some adjustments to make they more consistent. For example, IMO, it is a really bad idea to map any IR key into
KEY_POWER, since, if you press it wanting to stop your video app, it will, instead, power down the machine.KEY_POWER2is better, since it can be handled only at the video apps.Does this approach handle things like keymaps that are not for RC5 based remote controls? Also, how does this approach allow for telling the IR receiver what format to capture in (NEC/RC5/RC6)?
Admittedly I don't know the answers to these questions myself, which is why both the dib0700 and em28xx drivers only support RC5, even though both chips support other formats (the dib0700 supports RC5/RC6 and the em28xx supports NEC/RC5/RC6). If we had a consistent scheme for specifying what format a keymap is in, I could make sure the chip is in the correct mode (I have all the relevant information for both chips).
The real question lies in where to draw the line between what should be done in userland versus what should be done in the kernel? At one end of the spectrum, you could argue that the kernel should really be representing the devices as RC5/RC6 receivers, and all the translation to keycodes should be done in userland by something such as lircd, and on the other end of the spectrum is that everything should be in kernel and there should never be a need for lircd and there should just be an API for loading any lirc keymap into the kernel.
Quoted 5 lines
The whole topic is a *huge* source of confusion for most people, including the developers, given that the approach varies by device and the variety of ways people workaround the condition of "my remote doesn't work", some of which involve the use of lircd.
that is right.
But some must at least hack a remote at all.
I had hard times to realize that there are remotes without dedicated remote chips/controllers only triggering an IRQ, which just was only quite recently in a state for that driver to have a chance to implement it specifically.
Without it lircd doesn't exist either in such cases.
Cheers,
Hermann