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 [off-list ref] escreveu:

quoted

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.

quoted

- do we intend to support in-kernel sotfware decoders?

Yes.

Good.

quoted

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

quoted

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

quoted

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

quoted

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

quoted

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

quoted

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.

 

quoted

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