haupauge remote keycode for av7110_loadkeys

haupauge remote keycode for av7110_loadkeys

[matthieu castet]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

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.

[-- Attachment #2: hauppauge_grey2.rc5 --]
[-- Type: text/plain, Size: 665 bytes --]


0x3d KEY_POWER
0x3b KEY_GOTO

0x1c KEY_TV
0x18 KEY_VIDEO
0x19 KEY_AUDIO
0x1a KEY_MHP
0x1b KEY_EPG
0x0c KEY_RADIO

0x14 KEY_UP
0x16 KEY_LEFT
0x17 KEY_RIGHT
0x15 KEY_DOWN
0x25 KEY_ENTER

0x1f KEY_EXIT
0x0d KEY_MENU

0x10 KEY_VOLUMEUP
0x11 KEY_VOLUMEDOWN
0x20 KEY_CHANNELUP
0x21 KEY_CHANNELDOWN
0x12 KEY_PREVIOUS

0x0f KEY_MUTE
0x32 KEY_REWIND
0x35 KEY_PLAY
0x34 KEY_FASTFORWARD
0x37 KEY_RECORD
0x36 KEY_STOP
0x30 KEY_PAUSE
0x24 KEY_PREVIOUSSONG
0x1e KEY_NEXTSONG

0x00 KEY_0
0x01 KEY_1
0x02 KEY_2
0x03 KEY_3
0x04 KEY_4
0x05 KEY_5
0x06 KEY_6
0x07 KEY_7
0x08 KEY_8
0x09 KEY_9
0x0a KEY_TEXT
0x0e KEY_SUBTITLE

0x0b KEY_RED
0x2e KEY_GREEN
0x38 KEY_YELLOW
0x29 KEY_BLUE

Re: haupauge remote keycode for av7110_loadkeys

[Mauro Carvalho Chehab]

On Mon, 19 Jan 2009 21:35:52 +0100
matthieu castet <castet.matthieu@free.fr> wrote:

> 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.

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

Re: haupauge remote keycode for av7110_loadkeys

[matthieu castet]

Hi,

Mauro Carvalho Chehab wrote:
> On Mon, 19 Jan 2009 21:35:52 +0100
> matthieu castet <castet.matthieu@free.fr> 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

Re: haupauge remote keycode for av7110_loadkeys

[Devin Heitmueller]

On Tue, Jan 20, 2009 at 2:43 PM, matthieu castet
<castet.matthieu@free.fr> wrote:
> Hi,
>
> Mauro Carvalho Chehab wrote:
>>
>> On Mon, 19 Jan 2009 21:35:52 +0100
>> matthieu castet <castet.matthieu@free.fr> 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

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

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: haupauge remote keycode for av7110_loadkeys

[Mauro Carvalho Chehab]

On Tue, 20 Jan 2009 14:50:26 -0500
"Devin Heitmueller" <devin.heitmueller@gmail.com> wrote:

> On Tue, Jan 20, 2009 at 2:43 PM, matthieu castet
> <castet.matthieu@free.fr> wrote:
> > Hi,
> >
> > Mauro Carvalho Chehab wrote:
> >>
> >> On Mon, 19 Jan 2009 21:35:52 +0100
> >> matthieu castet <castet.matthieu@free.fr> 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
> 
> 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

Re: haupauge remote keycode for av7110_loadkeys

[Devin Heitmueller]

On Tue, Jan 20, 2009 at 5:18 PM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
>> 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.

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

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: haupauge remote keycode for av7110_loadkeys

[Mauro Carvalho Chehab]

On Tue, 20 Jan 2009 17:36:02 -0500
"Devin Heitmueller" <devin.heitmueller@gmail.com> wrote:

> On Tue, Jan 20, 2009 at 5:18 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> >> 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.
> 
> 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).

> * It doesn't work with all drivers (like the dib0700)

Unfortunately, dib0700 doesn't properly implement the input interface.

> * 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

Re: haupauge remote keycode for av7110_loadkeys

[Devin Heitmueller]

On Tue, Jan 20, 2009 at 6:01 PM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
>> * 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.

>> * 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.

> 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.

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

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: haupauge remote keycode for av7110_loadkeys

[Mauro Carvalho Chehab]

On Tue, 20 Jan 2009 18:20:10 -0500
"Devin Heitmueller" <devin.heitmueller@gmail.com> wrote:

> On Tue, Jan 20, 2009 at 6:01 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> >> * 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.
> 
> >> * 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.

> 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.
> 
> > 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.
> 
> 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.

> 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.

> 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.

> 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.

>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.
 
> 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

Re: haupauge remote keycode for av7110_loadkeys

[hermann pitton]

Hi,

Am Dienstag, den 20.01.2009, 18:20 -0500 schrieb Devin Heitmueller:
> On Tue, Jan 20, 2009 at 6:01 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> >> * 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.
> 
> >> * 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.
> 
> > 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.
> 
> 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.
> 

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