Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <> writes:
>> The removal of the existing keymaps from kernel depends on having an
>> application
>> to be called from udev to load the proper keymaps when a device is probed.
>> After having it for a while, we should deprecate the in-kernel keymaps
>> and move them to userspace.
> Sounds like a plan.
>> I also think that it is important to remove the 7 bits limitation from
>> all drivers
>> and re-generate the keymaps, since they'll change after it.
> I think the existing space/mark media drivers need to be reworked
> completely.

Nah. the changes aren't big. The first part of the change were already done
for 2.6.32: instead of having a vector of 128 elements, where the element order
used to be the masked scancode, we now have a table of scancode x keycode, 

struct ir_scancode {
        u16     scancode;
        u32     keycode;

Changing scancode to u32 is as easy as edit a file - it is currently 16 just 
all currently supported IR's and protocols have 16 bits only - there's no 
implementation for RC6 mode 6 yet. However, increasing it above to 64 bits will 
break on
32 bits kernels (and above 64 bits, on all architectures), due to the current 
API limits.

this change is currently limited to the ir keytables, but I have a patch 
already done
extending this change for the drivers to work directly with the new table.

The next step is to replace the ir->mask_keycode at the drivers to a value that
gets the entire scancode. We may still need a mask there, since not all drivers 
a 32 bits scancode.

Also, there's no single "space/mark" media driver. All drivers that support 
pulse/space also support in-hardware IR decoding, in order to support the 
different types of devices. They generally support several ways to get keys:
        - serial pulse/space decoding on one GPIO pin (most pci hardware have);
        - serial pulse/space decoding via a IRQ enabled GPIO pin (several 
saa7134 IR's use this way);
        - i2c IR's (common on several popular devices);
        - parallel scancode output via gpio pins several cx88 IR's use this 
        - direct IR hardware decoding done by the video chipset 
                (DibCom and newer em28xx hardware, for example).

So, the driver input complexity is needed to support all those different ways. 

So, rewriting it would likely cause regressions.

I agree that there are some cleanups that should be done for the serial 
pulse/space raw
decoding. By adding a lirc interface, we'll need to have a common code for 
those events anyway.

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to
More majordomo info at

Reply via email to