Hacking on ati_remote driver

Hacking on ati_remote driver

[George Spelvin]

I dusted off my ATI all-in-wonder remote and was trying to get it to
work with VLC (so far unsuccessfully; I'm still untangling the
multiple mapping layers between hardware scancode and X event), and
I had a look at the ati_remote.c driver.

I started hacking on it.  Mostly I thought the ati_remote_tbl[]
array was wastefully large.  It gets a lot simpler when you
realize that, in the 4-byte report, data[1] is actually a checksum
and not part of the keycode.  data[1] = data[2] + data[3] + 0xE5.

Having looked over the input layer documentation, I have decided that
the ati_remote driver could use some love.  I'd like to convert it to
use the generic scancode to keycode mapping and autorepeat logic.

However, RTFMing and RTFSing left me with a few questions:

- Should the keybit[] bitmap be an exact map of possible buttons, or
  is a superset okay?  The driver handles several models of remote,
  and the later ones added a few buttons.  Can I use a single superset
  scancode map, or is there some benefit to supplying an exact "which
  keys exist" list?  (EVIOCGBIT ioctl?)

- Is there some all-in-one function to report "scancode arrived" to the
  input layer, or do I have to call input_get_keycode and input_report_key
  separately?

- Is the input device required to ensure that the key-up keycode matches
  the key-down, even if someone reprograms the scancode map in between?

- I read somewhere that the EV_KEY event's value should be 0 for up,
  1 for down, and 2 for autorepeat.  But the input_report_key function
  canonicalizes values to 0/1.  What's the right value to use for
  autorepeat?

- The remote doesn't generate key-up events on most of its buttons.
  It does, however, have hardware autorepeat, so the current code figures
  it out with a timeout.  Should I synthesize key-up events this way,
  even though they're not very accurate?  Or can I just use the timeout
  to guess between key-down and autorepeat, and omit key-up events
  entirely?

- The receiver supports up to 16 transmitters.  Currently, they're all
  funneled through a single input device with a mask available in the
  device driver to suppress unwanted ones.  Is it worth splitting this
  into multiple input devices instead?  Or is there some other way I
  should pass the "channel number" into the input layer?

- Should the 0-9 buttons on the remote generate KEY_0 through KEY_9 or
  KEY_NUMERIC_0 through KEY_NUMERIC_9?

- More generally, the current driver has a few dubious default key
  code assignments.  Should I fix these or carefully preserve them for
  compatibility?

- Likewise, the ati_remote2 driver assigns remotes 1-16 (numbered 0-15
  in the internal protocol) to mask bits 0-15.  The ati_remote driver
  uses mask bits 1-16, and ignores bit 0.  The former convention
  makes more sense to me.  Convert ati_remote or preserve backward
  compatibility?

(Note that in either case, I'll segregate the backward compatibility
breaks into their own patches.)

Thank you for any guidance.


P.S.
I can also have a look at the remote wonder plus patches some folks
developed at
http://www.mythtv.org/wiki/ATI_Remote_Wonder_Plus

Re: Hacking on ati_remote driver

[Jarod Wilson]

On Wed, Sep 22, 2010 at 09:27:20PM -0400, George Spelvin wrote:
> I dusted off my ATI all-in-wonder remote and was trying to get it to
> work with VLC (so far unsuccessfully; I'm still untangling the
> multiple mapping layers between hardware scancode and X event), and
> I had a look at the ati_remote.c driver.
> 
> I started hacking on it.  Mostly I thought the ati_remote_tbl[]
> array was wastefully large.  It gets a lot simpler when you
> realize that, in the 4-byte report, data[1] is actually a checksum
> and not part of the keycode.  data[1] = data[2] + data[3] + 0xE5.
> 
> Having looked over the input layer documentation, I have decided that
> the ati_remote driver could use some love.  I'd like to convert it to
> use the generic scancode to keycode mapping and autorepeat logic.

IMO, ati_remote.c and ati_remote2.c should be adapted to use the ir-core
(soon to be rc-core) interfaces. I've got remote2 hardware myself, so
doing the conversion for that driver is already on my personal TODO list,
but its a long queue of more important things ahead of it first...

-- 
Jarod Wilson
jarod@redhat.com

Re: Hacking on ati_remote driver

[George Spelvin]

> IMO, ati_remote.c and ati_remote2.c should be adapted to use the ir-core
> (soon to be rc-core) interfaces. I've got remote2 hardware myself, so
> doing the conversion for that driver is already on my personal TODO list,
> but its a long queue of more important things ahead of it first...

Just what I want, more scope creep... I'm not immovably opposed to a
larger conversion job, but can you tell me that the ir-core/rc-core
layer gives me over the raw input layer?  I see how there are a bunch
of utilities for decoding raw pulse streams, but there's only one
RC_DRIVER_SCANCODE driver, imon.c, and even that seems to use the RC6
protocol sometimes.

Looking at the code leads to a few obvious questions:
ir-common.h:
	Why is the linux keycode u32, when the input layer's
	key codes are __u16?  And why is keypressed an int
	rather than a bool?

	And why is the type __u64?  It appears top be a bitmap,
	with about 6 values defined so far...

ir-sysfs.c:
	Why is store_protocol, which appears to be turning an ASCII
	string into an ir_type bitmap, documented as "triggered by
	READING /sys/class/rc/rc?/current_protocol"?  Why doesn't that
	code support the rc6 protocol?

In general, I'm bit confused about what it means to change_protocol
to a bitmap with multiple bits set.  Are you sure ir_type needs to be
a bitmap?  The only place I can see its bitmapness actually used is in
show_supported_protocols(), and that could be replaced by an array of a
few chars or something.  (Most devices support only one or two protocols.)
Reserving 0 for "end of list" would make the structure initialization
simpler.

One thing that would be nice is to have the permissions on the sysfs
protocol file depend on the existence of a change_protocol method.

Um.. I also notice that change_protocol isn't even supported on
non-RC_DRIVER_SCANCODE drivers.  Is this all a big kludge invented for
the imon driver?

ir-functions.c: Is ir->last_bit actually used for anything?  I can't
find an assignement to a non-zero value anywhere...
Oh, wait, drivers/media/video/cx23885/cx23885-input.c and
drivers/media/video/saa7134/saa7134-input.c
Does that need to be in the generic structure?

Re: Hacking on ati_remote driver

[Jarod Wilson]

On Mon, Sep 27, 2010 at 10:42:19AM -0400, George Spelvin wrote:
> > IMO, ati_remote.c and ati_remote2.c should be adapted to use the ir-core
> > (soon to be rc-core) interfaces. I've got remote2 hardware myself, so
> > doing the conversion for that driver is already on my personal TODO list,
> > but its a long queue of more important things ahead of it first...
> 
> Just what I want, more scope creep... I'm not immovably opposed to a
> larger conversion job, but can you tell me that the ir-core/rc-core
> layer gives me over the raw input layer?

- Hopefully, a simplified interface, with less code duplication. Quite a
few remote drivers reimplement the same things over and over. I've not
actually looked at ati_remote.c to see exactly what its got, but
ati_remote2.c has some low-level evbit, keybit, __set_bit, etc.,
manipulations that would mostly disappear w/ir-core, in favor of using
common shared code.

- Userspace remote-specific manipulation tools in v4l-utils

- Sysfs hooks that reveal its a remote in the first place -- which may be
  of benefit to a userspace daemon, udev loading a new keymap
  automatically, or to media center apps that want to look directly at a
  remote control's input device until such time as X sucks less and will
  pass through keycodes larger than 8-bit.

> I see how there are a bunch
> of utilities for decoding raw pulse streams, but there's only one
> RC_DRIVER_SCANCODE driver, imon.c, and even that seems to use the RC6
> protocol sometimes.

imon is always scancode, but some of the devices can be configured to use
one device or another. One of them is an RC6A MCE remote. But it still
does decoding in hardware and passes along scancodes. There's tm6000 in
staging that is RC_DRIVER_SCANCODE, and I swear more devices under
drivers/media/ are scancode-only and simply haven't been ported fully over
to ir-core just yet, but I could be wrong about that.

> Looking at the code leads to a few obvious questions:
> ir-common.h:
> 	Why is the linux keycode u32, when the input layer's
> 	key codes are __u16?  And why is keypressed an int
> 	rather than a bool?
> 
> 	And why is the type __u64?  It appears top be a bitmap,
> 	with about 6 values defined so far...

ir-common.h is going away RSN, this is from an older pre-{ir,rc}-core IR
layer in the media tree. Its not used by imon, mceusb or streamzap,
anyway.

> ir-sysfs.c:
> 	Why is store_protocol, which appears to be turning an ASCII
> 	string into an ir_type bitmap, documented as "triggered by
> 	READING /sys/class/rc/rc?/current_protocol"?  Why doesn't that
> 	code support the rc6 protocol?

Um... what? I see:

 * This routine is a callback routine for changing the IR protocol type.
 * It is trigged by writing to /sys/class/rc/rc?/protocols.
  
And it definitely supports rc6.

> In general, I'm bit confused about what it means to change_protocol
> to a bitmap with multiple bits set.  Are you sure ir_type needs to be
> a bitmap?  The only place I can see its bitmapness actually used is in
> show_supported_protocols(), and that could be replaced by an array of a
> few chars or something.  (Most devices support only one or two protocols.)
> Reserving 0 for "end of list" would make the structure initialization
> simpler.

May or may not need to be a bitmap, I didn't write that part. Mauro may be
able to shed some light here. Generally, you'll only change_protocol to a
single proto (that's the case w/imon), but there could be receivers where
more than one can be enabled simultaneously.

> One thing that would be nice is to have the permissions on the sysfs
> protocol file depend on the existence of a change_protocol method.
> 
> Um.. I also notice that change_protocol isn't even supported on
> non-RC_DRIVER_SCANCODE drivers.  Is this all a big kludge invented for
> the imon driver?

No. It existed before the imon driver. git grep for change_protocol, and
you'll see its used in a number of places besides imon.c.

> ir-functions.c: Is ir->last_bit actually used for anything?  I can't
> find an assignement to a non-zero value anywhere...
> Oh, wait, drivers/media/video/cx23885/cx23885-input.c and
> drivers/media/video/saa7134/saa7134-input.c
> Does that need to be in the generic structure?

Not sure, haven't ever touched it myself.

-- 
Jarod Wilson
jarod@redhat.com

Re: Hacking on ati_remote driver

[Mauro Carvalho Chehab]

Em 27-09-2010 13:07, Jarod Wilson escreveu:
> On Mon, Sep 27, 2010 at 10:42:19AM -0400, George Spelvin wrote:
>>> IMO, ati_remote.c and ati_remote2.c should be adapted to use the ir-core
>>> (soon to be rc-core) interfaces. I've got remote2 hardware myself, so
>>> doing the conversion for that driver is already on my personal TODO list,
>>> but its a long queue of more important things ahead of it first...
>>
>> Just what I want, more scope creep... I'm not immovably opposed to a
>> larger conversion job, but can you tell me that the ir-core/rc-core
>> layer gives me over the raw input layer?
> 
> - Hopefully, a simplified interface, with less code duplication. Quite a
> few remote drivers reimplement the same things over and over. I've not
> actually looked at ati_remote.c to see exactly what its got, but
> ati_remote2.c has some low-level evbit, keybit, __set_bit, etc.,
> manipulations that would mostly disappear w/ir-core, in favor of using
> common shared code.
> 
> - Userspace remote-specific manipulation tools in v4l-utils
> 
> - Sysfs hooks that reveal its a remote in the first place -- which may be
>   of benefit to a userspace daemon, udev loading a new keymap
>   automatically, or to media center apps that want to look directly at a
>   remote control's input device until such time as X sucks less and will
>   pass through keycodes larger than 8-bit.
> 
>> I see how there are a bunch
>> of utilities for decoding raw pulse streams, but there's only one
>> RC_DRIVER_SCANCODE driver, imon.c, and even that seems to use the RC6
>> protocol sometimes.
> 
> imon is always scancode, but some of the devices can be configured to use
> one device or another. One of them is an RC6A MCE remote. But it still
> does decoding in hardware and passes along scancodes. There's tm6000 in
> staging that is RC_DRIVER_SCANCODE, and I swear more devices under
> drivers/media/ are scancode-only and simply haven't been ported fully over
> to ir-core just yet, but I could be wrong about that.

dib0700 is also scancode only, already ported to rc core. Also, partially
ported, we have saa7134 and em28xx drivers (only scancode).

>> Looking at the code leads to a few obvious questions:
>> ir-common.h:
>> 	Why is the linux keycode u32, when the input layer's
>> 	key codes are __u16?  And why is keypressed an int
>> 	rather than a bool?
>>
>> 	And why is the type __u64?  It appears top be a bitmap,
>> 	with about 6 values defined so far...
> 
> ir-common.h is going away RSN, this is from an older pre-{ir,rc}-core IR
> layer in the media tree. Its not used by imon, mceusb or streamzap,
> anyway.

The type is to handle the different IR protocols. As it is a bitmap, I
opted to define it as u64, as I was afraid that we might run out of space
with just 32 bits.

>> ir-sysfs.c:
>> 	Why is store_protocol, which appears to be turning an ASCII
>> 	string into an ir_type bitmap, documented as "triggered by
>> 	READING /sys/class/rc/rc?/current_protocol"?  Why doesn't that
>> 	code support the rc6 protocol?
> 
> Um... what? I see:
> 
>  * This routine is a callback routine for changing the IR protocol type.
>  * It is trigged by writing to /sys/class/rc/rc?/protocols.
>   
> And it definitely supports rc6.

George, you're probably looking at an older implementation.

>> In general, I'm bit confused about what it means to change_protocol
>> to a bitmap with multiple bits set.  Are you sure ir_type needs to be
>> a bitmap?  The only place I can see its bitmapness actually used is in
>> show_supported_protocols(), and that could be replaced by an array of a
>> few chars or something.  (Most devices support only one or two protocols.)
>> Reserving 0 for "end of list" would make the structure initialization
>> simpler.
> 
> May or may not need to be a bitmap, I didn't write that part. Mauro may be
> able to shed some light here. Generally, you'll only change_protocol to a
> single proto (that's the case w/imon), but there could be receivers where
> more than one can be enabled simultaneously.

The same bitmap is also used by raw decoders. So, you may enable just a few
protocols. There are some devices with scancodes that are able to handle
more than one protocol at the same time. So, a bitmap is more flexible than
a list of values.
> 
>> One thing that would be nice is to have the permissions on the sysfs
>> protocol file depend on the existence of a change_protocol method.
>>
>> Um.. I also notice that change_protocol isn't even supported on
>> non-RC_DRIVER_SCANCODE drivers.  Is this all a big kludge invented for
>> the imon driver?
> 
> No. It existed before the imon driver. git grep for change_protocol, and
> you'll see its used in a number of places besides imon.c.

This were unified at the newer implementations. From userspace POV, both
raw and non-raw IR's now have the same way to enable/disable protocols.

>> ir-functions.c: Is ir->last_bit actually used for anything?  I can't
>> find an assignement to a non-zero value anywhere...
>> Oh, wait, drivers/media/video/cx23885/cx23885-input.c and
>> drivers/media/video/saa7134/saa7134-input.c
>> Does that need to be in the generic structure?
> 
> Not sure, haven't ever touched it myself.
> 
ir-functions will die as soon as we move all drivers to use rc-core.

Cheers,
Mauro.

Re: Hacking on ati_remote driver

[George Spelvin]

Thank you both for your replies.

To start with, a major misunderstanding on my part:
after some initial grepping, I limited the vast majority of my
investigations to drivers/media/IR, not realizing that the drivers are
all over drivers/media.  And I forgot about staging completely.

>>> Looking at the code leads to a few obvious questions:
>>> ir-common.h:
>>> 	Why is the linux keycode u32, when the input layer's
>>> 	key codes are __u16?  And why is keypressed an int
>>> 	rather than a bool?
>>>
>>> 	And why is the type __u64?  It appears top be a bitmap,
>>> 	with about 6 values defined so far...
>> 
>> ir-common.h is going away RSN, this is from an older pre-{ir,rc}-core IR
>> layer in the media tree. Its not used by imon, mceusb or streamzap,
>> anyway.

[Another quote]
> ir-functions will die as soon as we move all drivers to use rc-core.

Okay, so I'm confused: what *is* the {ir,rc}-core?
Can you tell me which header files constitute the interface?
Obviously I've been looking at the wrong stuff.

include/media/ir-core.h and drivers/media/IR/ir-core-priv.h?
Or just the former?


> The type is to handle the different IR protocols. As it is a bitmap, I
> opted to define it as u64, as I was afraid that we might run out of space
> with just 32 bits.

I can see how a bit-banged implementation could try multiple receive
protocols.  Although reserving bit 31 for magic purposes is a bit bizarre.

>>> ir-sysfs.c:
>>> 	Why is store_protocol, which appears to be turning an ASCII
>>> 	string into an ir_type bitmap, documented as "triggered by
>>> 	READING /sys/class/rc/rc?/current_protocol"?  Why doesn't that
>>> 	code support the rc6 protocol?
>> 
>> Um... what? I see:
>> 
>>  * This routine is a callback routine for changing the IR protocol type.
>>  * It is trigged by writing to /sys/class/rc/rc?/protocols.
>>   
>> And it definitely supports rc6.
>
> George, you're probably looking at an older implementation.

Indeed, I was looking at Linus' v2.6.35.  It's changed in the .36-rcX
series.

>>> Just what I want, more scope creep... I'm not immovably opposed to a
>>> larger conversion job, but can you tell me that the ir-core/rc-core
>>> layer gives me over the raw input layer?
>>
>> - Hopefully, a simplified interface, with less code duplication. Quite a
>> few remote drivers reimplement the same things over and over. I've not
>> actually looked at ati_remote.c to see exactly what its got, but
>> ati_remote2.c has some low-level evbit, keybit, __set_bit, etc.,
>> manipulations that would mostly disappear w/ir-core, in favor of using
>> common shared code.

This is just the input device wrappers in ir-keytable.c, particularly
__ir_input_register?  This is actually somewhat inconvenient, as this
code separates the remote (get_rc_map()) from the receiver hardare.
Great for generic protocols, but an unnecessary complication for one
tightly coupled to the receiver.

It's not like the input layer values that you're talking about are
that hard to use.

And can it handle the 8-way mouse pad on the remote?


I notice a lot of remotes have dense scancode assignments, so you could
provide an alternative map representation.  So keymaps/rc-flyvideo.c
would turn into:

static __u16 flyvideo[] = {
        KEY_POWER,	/* 0x00: Power */
	0,
        KEY_ZOOM,	/* 0x02: Fullscreen */
        KEY_1,
        KEY_2,
        KEY_3,
        KEY_AGAIN,	/* 0x06: Recall */
        KEY_4,
        KEY_5,
        KEY_6,
        KEY_ANGLE,	/* no label, may be used as the PAUSE button */
        KEY_7,
        KEY_8,
        KEY_9,
        KEY_MODE,	/* 0x0e: Air/Cable */
        KEY_0,
        KEY_ENTER,	/* 0x10: Enter */
        KEY_VIDEO,	/* 0x11: Video */
        KEY_CHANNELUP,	/* 0x12: Channel + */
        KEY_CHANNELDOWN,/* 0x13: Channel - */
        KEY_VOLUMEUP,	/* 0x14: Volume + */
        KEY_AUDIO,	/* 0x15: Audio */
	0,
        KEY_VOLUMEDOWN,	/* 0x17: Volume - */
        KEY_TUNER,	/* 0x18: AV Source */
        KEY_BACK,	/* 0x19: Rewind  ( <<< ) */
        KEY_LANGUAGE,	/* 0x1a: Stereo */
        KEY_MUTE,	/* 0x1b: Mute */
	0, 0, 0,
        KEY_FORWARD	/* 0x1f: Forward ( >>> ) */
};


>> - Userspace remote-specific manipulation tools in v4l-utils
>> 
>> - Sysfs hooks that reveal its a remote in the first place -- which may be
>>   of benefit to a userspace daemon, udev loading a new keymap
>>   automatically, or to media center apps that want to look directly at a
>>   remote control's input device until such time as X sucks less and will
>>   pass through keycodes larger than 8-bit.

Um, and does this consist of anything other than /sys/class/rc/$NAME/protocols?
Just to play devil's advocate here, how does that help me?

Re: Hacking on ati_remote driver

[Mauro Carvalho Chehab]

Em 28-09-2010 16:04, George Spelvin escreveu:

> [Another quote]
>> ir-functions will die as soon as we move all drivers to use rc-core.
> 
> Okay, so I'm confused: what *is* the {ir,rc}-core?
> Can you tell me which header files constitute the interface?
> Obviously I've been looking at the wrong stuff.
> 
> include/media/ir-core.h and drivers/media/IR/ir-core-priv.h?
> Or just the former?

include/media/ir-core.h should have everything that a driver needs to work
with rc-core (please notice that have some includes inside). The 
ir-core-priv.h is meant to be used internally inside the subsystem, 
for example, to connect RC decoders. The subsystem is new, so, maybe you
may find the need of adding something more there, or to export an internal
interface to your drivers. In this case, just sent us a patch ;)

>> The type is to handle the different IR protocols. As it is a bitmap, I
>> opted to define it as u64, as I was afraid that we might run out of space
>> with just 32 bits.
> 
> I can see how a bit-banged implementation could try multiple receive
> protocols.  Although reserving bit 31 for magic purposes is a bit bizarre.

Better to think big than small in this case ;) When I started, I had no
idea how many protocols we would need there, since there are some "special
cases" where the normal demod doesn't handle (for example, a RC5-variant
with one extra bit, found on one specific device model).

>>>> Just what I want, more scope creep... I'm not immovably opposed to a
>>>> larger conversion job, but can you tell me that the ir-core/rc-core
>>>> layer gives me over the raw input layer?
>>>
>>> - Hopefully, a simplified interface, with less code duplication. Quite a
>>> few remote drivers reimplement the same things over and over. I've not
>>> actually looked at ati_remote.c to see exactly what its got, but
>>> ati_remote2.c has some low-level evbit, keybit, __set_bit, etc.,
>>> manipulations that would mostly disappear w/ir-core, in favor of using
>>> common shared code.
> 
> This is just the input device wrappers in ir-keytable.c, particularly
> __ir_input_register?  This is actually somewhat inconvenient, as this
> code separates the remote (get_rc_map()) from the receiver hardare.
> Great for generic protocols, but an unnecessary complication for one
> tightly coupled to the receiver.

On a few cases, it is not required to allow changing the scancodes for a table
(e. g. in the case where the hardware has some logic to prevent the usage of 
any other different remote model), but almost all IR hardware allows you to use 
a remote with a different set of scancodes (sometimes requiring the usage of
the same protocol) to work. By splitting the keymaps, userspace apps can replace
the scancode table, if the user wants to use this feature.

Even in the case where the hardware doesn't allow the usage of a different
remote controller (for example, Bluetooth remotes), user may want to
change the keycode tables, for example associating scancode 0x12345678 to KEY_F1,
instead of KEY_F2.

By splitting the keycode tables, they can be moved entirely to userspace, and
let udev to load the table that the user wants.

> It's not like the input layer values that you're talking about are
> that hard to use.
> 
> And can it handle the 8-way mouse pad on the remote?

Well, it may handle, but maybe the better is to have a separate input device
for mouse events.

> I notice a lot of remotes have dense scancode assignments, so you could
> provide an alternative map representation.  So keymaps/rc-flyvideo.c
> would turn into:
> 
> static __u16 flyvideo[] = {
>         KEY_POWER,	/* 0x00: Power */
> 	0,
>         KEY_ZOOM,	/* 0x02: Fullscreen */
>         KEY_1,
>         KEY_2,
>         KEY_3,
>         KEY_AGAIN,	/* 0x06: Recall */
>         KEY_4,
>         KEY_5,
>         KEY_6,
>         KEY_ANGLE,	/* no label, may be used as the PAUSE button */
>         KEY_7,
>         KEY_8,
>         KEY_9,
>         KEY_MODE,	/* 0x0e: Air/Cable */
>         KEY_0,
>         KEY_ENTER,	/* 0x10: Enter */
>         KEY_VIDEO,	/* 0x11: Video */
>         KEY_CHANNELUP,	/* 0x12: Channel + */
>         KEY_CHANNELDOWN,/* 0x13: Channel - */
>         KEY_VOLUMEUP,	/* 0x14: Volume + */
>         KEY_AUDIO,	/* 0x15: Audio */
> 	0,
>         KEY_VOLUMEDOWN,	/* 0x17: Volume - */
>         KEY_TUNER,	/* 0x18: AV Source */
>         KEY_BACK,	/* 0x19: Rewind  ( <<< ) */
>         KEY_LANGUAGE,	/* 0x1a: Stereo */
>         KEY_MUTE,	/* 0x1b: Mute */
> 	0, 0, 0,
>         KEY_FORWARD	/* 0x1f: Forward ( >>> ) */
> };

There are a few cases where the hardware only outputs 8 bits. Yet, most of
the time, the issue were in the way V4L used to handle keycodes, limiting
it to have only 7 bits, at max, due to an old limitation at input layer
(solved on kernel 2.6.22). 

>>> - Userspace remote-specific manipulation tools in v4l-utils
>>>
>>> - Sysfs hooks that reveal its a remote in the first place -- which may be
>>>   of benefit to a userspace daemon, udev loading a new keymap
>>>   automatically, or to media center apps that want to look directly at a
>>>   remote control's input device until such time as X sucks less and will
>>>   pass through keycodes larger than 8-bit.
> 
> Um, and does this consist of anything other than /sys/class/rc/$NAME/protocols?
> Just to play devil's advocate here, how does that help me?

The ir-keytable app understands all sysfs nodes at /sys/class/rc, and also
implements the logic to replace the keycode tables, via input/event ioctl.
It were written to allow dynamically loading a new keycode table, during udev
add event, by reading a file with the keycode table that are associated to each
remote controller.

Cheers,
Mauro