linux-kernel - Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Nov 2009 19:28:03 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Krzysztof Halasa <khc@...waw.pl>
CC:	Christoph Bartelmus <lirc@...telmus.de>, jarod@...sonet.com,
	awalls@...ix.net, dmitry.torokhov@...il.com, j@...nau.net,
	jarod@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was:
 Re: [PATCH 1/3 v2] lirc core device driver infrastructure

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@...hat.com> 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, defined
as:

struct ir_scancode {
        u16     scancode;
        u32     keycode;
};

Changing scancode to u32 is as easy as edit a file - it is currently 16 just because
all currently supported IR's and protocols have 16 bits only - there's no in-kernel
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 output
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 way);
	- 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 handling
those events anyway.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/