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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Thu, Dec 03, 2009 at 04:33:28PM -0200, Mauro Carvalho Chehab wrote:
> Let me draw my view:
> 
> Em Thu, 3 Dec 2009 09:55:31 -0800
> Dmitry Torokhov <dmitry.torokhov@gmail.com> escreveu:
> 
> > No, please, wait just a minute. I know it is tempting to just merge
> > lirc_dev and start working, but can we first agree on the overall
> > subsystem structure before doing so. It is still quite inclear to me.
> > 
> > The open questions (for me at least):
> > 
> > - do we create a new class infrastructure for all receivers or only for
> >   ones plugged into lirc_dev? Remember that classifying objects affects
> >   how udev and friemds see them and may either help or hurt writing PnP
> >   rules.
> 
> IMO, I would create it as /sys/class/input/IR (just like the /mice). I

That will not work. Driver core does not support notion of subclasses,
Greg and Kay insist on flat class namespace. Mice do not belong to a
separate [sub]class, they all members of input class, with peculiar
directory structure.

IRs however, I believe, deserve a full-fledged class (since they are in
my view are parents to the input devices representing remotes). I would
argus for the following sysfs hierarchy for the main device tree:

/sys/devices/pcipci0000:00/../pci.../../irrcv0/input14/event16
/sys/devices/pcipci0000:00/../usb.../../irrcv1/input15/event17
					      /input16/event18

And corresponding class:

/sys/class/irrcv/irrcv0
                 irrcv1

and so on.

>
> don't see why do we need to different lirc than no-lirc drivers in the
> case of sysfs class.

I do agree that _all_ infrared receivers should belong to this class,
and not only ones utilizing lirc_dev.

> As devices with raw input capabilities will have
> another dev to communicate, this means that we'll need a /lirc node
> there to point to lirc dev.
> 
> > 
> > - do we intend to support in-kernel sotfware decoders?
> 
> Yes.
> 

Good.

> > - What is the structure? Do we organize them as a module to be used by driver
> >   directly or the driver "streams" the data to IR core and the core
> >   applies decoders (in the same fashion input events from drivers flow
> >   into input core and then distributed to all bound interfaces for
> >   processing/conversion/transmission to userspace)?
> 
> My plan is to expand ir-common.ko module and rename it to ir-core, to be 
> the IR core module for the evdev interface. I'm already working on it. 
> My idea for an architecture is that the lirc-core module will use 
> ir-common where the IR decoders will be, and the evdev interface.
>

How related lirc-core to the current lirc code? If it is not the same
maybe we should not call it lirc to avoid confusion.

 
> IMO, we should move them from /drivers/media/common to /drivers/input/ir.
> It makes sense to use kfifo to send the data to the in-kernel decoders.
> 

OK.

> > - how do we control which decoder should handle particular
> >   receiver/remote? Is it driver's decision, decoder's decision, user's
> >   or all of the above?
> 
> It should be all the above, since some hardware will only work with certain
> decoders (hardware limitation) or they may have already a raw mode->scancode
> legacy decoder. In the latter case, those decoders will be removed from
> the existing drivers, but this action will take some time.
> 
> Some sysfs attributes are needed to specify a list of the supported protocols
> and the currently used one. I'll prepare a proposed patch for it, after we
> finish aligning the requirements.
>  
> > - do we allow to have several decorers active at once for a receiver?
> 
> Yes, as an optional requirement, since some hardware won't support it.
> 
> > - who decides that we want to utilize lirc_dev? Driver's themselves, IR
> >   core (looking at the driver/device "capabilities"), something else?
> 
> Drivers that support raw mode, should interface via lirc-core, that will,
> in turn use ir-core.
> 
> Drivers that have in-hardware decode will directly use ir-core.
> 
> > - do we recognize and create input devices "on-fly" or require user
> >   intervention? Semantics for splitting into several input/event
> >   devices?
> 
> I don't have a strong opinion here. 
> 
> I don't see any way for doing it, except with very few protocols that
> sends vendor IDs. I don't care if this feature can be used by the
> drivers/decoders that could support it.
> 
> > Could anyone please draw me a picture, starting with a "receiver"
> > piece of hardware. I am not concerned much with how exactly receiver is
> > plugged into a particular subsystem (DVB/V4L etc) since it would be
> > _their_ implementation detail, but with the flow in/out of that
> > "receiver" device.
> 
> Not sure if I got your idea. Basically, what I see is:
> 
> 	For device drivers that work in raw mode:
> [IR physical device] ==> [IR receiver driver]  ==> [lirc-core] ==> [decoder] ==> [ir-core] ==> [evdev]
> 
> (eventually, we can merge decoder and ir-core into one module at the beginning,
> depending on the size of the decoders)
> 
> 	For device drivers that work only in evdev mode (those with hardware decoders):
> 
> [IR physical device] ==> [IR receiver driver]  ==> [ir-core] ==> [evdev]
>

Maybe we are talking about the same things and it is just names that are
confusing. I'd imagine something like this:


In-kernel decoding:

[IR physical device] => [IR receiver driver] => [IR core] => [decoder] => [input core] => [evdev]
							  => [decoder] => [input core] => [evdev]

Hardware decoder:
[IR physical device] => [IR receiver driver] => [IR core]
					     => [input core] => [evdev]

I.e we still register with IR core but driver communicates directly with input device.

Userspace decoging:
[IR physical device] => [IR receiver driver] => [IR core] => [lirc_dev] => [lircd] => [uinput] => [input core] => [evdev]

Essentially lirc_dev becomes a special case of decoder that, instead of
connecting inptu core and creating input devices passes the data to
userspace.

I did not show the block that you call ir-core since I expect it to be more
like a library rather than an object in overall structure.

 
> > 
> > Now as far as input core goes I see very limited number of changes that
> > may be needed:
> > 
> > - Allow to extend size of "scancode" in EVIOC{S,G}KEYCODE if we are
> >   unable to limit ourselves to 32 bits (keeping compatibility of course)
> 
> Yes, but the way EVIOC{S,G}KEYCODE currently works, it performs poorly when you have a
> table with 2^64 size. The table is very sparsed, but, as the key to get/set a code is
> the scancode, it is very hard to enumberate what are the actual entries there. The
> better is to use an index parameter for they, instead of using the scancode as such.
> 

evdev does not really care what you use as scancode. So nobody stops
your driver to report index as a scancode and accept index from the
ioctl. The true "scancode" will thus be competely hidden from userspace.
In fact a few drivers do just that.

-- 
Dmitry