linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4B17AA6A.9060702@redhat.com>
Date:	Thu, 03 Dec 2009 13:09:14 +0100
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Jarod Wilson <jarod@...sonet.com>
CC:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jonsmirl@...il.com, khc@...waw.pl, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

On 12/03/09 05:29, Jarod Wilson wrote:
> On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
>
>>> Anyway, we shouldn't postpone lirc drivers addition due to that.
>>> There are still lots of work to do before we'll be able to split
>>> the tables from the kernel drivers.
>>
>> Indeed.  The sysfs bits are future work for both lirc and evdev
>> drivers.  There is no reason to make the lirc merge wait for it.
>
> At this point, my plan is to try to finish cleaning up lirc_dev and
> lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
> and resubmit them next week.

Good plan IMHO.  Having lirc_dev merged quickly allows in-kernel drivers 
start supporting lirc.

One final pass over the lirc interface would be good, taking the chance 
to fixup anything before the ABI is set in stone with the mainline 
merge.  Things to look at:

   (1) Make sure ioctl structs are 32/64 bit invariant.
   (2) Maybe add some reserved fields to allow extending later
       without breaking the ABI.
   (3) Someone suggested a 'commit' ioctl which would activate
       the parameters set in (multiple) previous ioctls.  Makes sense?
   (4) Add a ioctl to enable/disable evdev event submission for
       evdev/lirc hybrid drivers.

> I'm still on the fence over what to do about lirc_imon. The driver
> supports essentially 3 generations of devices. First-gen is very old
> imon parts that don't do onboard decoding. Second-gen is the devices
> that all got (insanely stupidly) tagged with the exact same usb
> device ID (0x15c2:0xffdc), some of which have an attached VFD, some
> with an attached LCD, some with neither, some that are actually RF
> parts, but all (I think) of which do onboard decoding. Third-gen is
> the latest stuff, which is all pretty sane, unique device IDs for
> unique devices, onboard decoding, etc.

Do have second-gen and third-gen devices have a 'raw mode'?  If so, then 
there should be a lirc interface for raw data access.

> So the lirc_imon I submitted supports all device types, with the
> onboard decode devices defaulting to operating as pure input devices,
> but an option to pass hex values out via the lirc interface (which is
> how they've historically been used -- the pure input stuff I hacked
> together just a few weeks ago), to prevent functional setups from
> being broken for those who prefer the lirc way.

Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.

Historically it has also been used to pass decoded data (i.e. rc5) from 
devices with onboard decoding, but for that in-kernel mapping + input 
layer really fits better.

> What I'm debating is whether this should be split into two drivers,
> one for the older devices that don't do onboard decoding (which would
> use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy',
> and one that is a pure input driver, not unlike the ati_remote{,2}
> drivers, with no lirc_dev dependency at all, probably called simply
> 'imon'.

i.e. lirc_imon would support first+second gen, and imon third-gen 
devices, without overlap?

 > But if I split it out, there may end up being a
> fair amount of code duplication,

You could try to split common code into a third module used by the other 
two.  Or have one module for all devices which is a evdev/lirc hybrid.

cheers,
   Gerd

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