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@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
