Mailing List Archive: Linux: Kernel

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

1 2 3 4 5 6 7

View All

Index | Next | Previous | View Threaded

mchehab at redhat

Nov 23, 2009, 4:36 AM

Post #1 of 163 (926 views)
Permalink

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

Mauro Carvalho Chehab wrote:

> Jarod Wilson wrote:
> 1) As I said before, this code adds a new input API. So, you should
> get input people's ack about it. It seems fine for me;

>> Index: b/drivers/input/lirc/lirc.h
>> ===================================================================
>> --- /dev/null
>> +++ b/drivers/input/lirc/lirc.h
>
> Hmm... as you're defining the kernel userspace interface, it would
> be better to put the header under include/linux.

It seems that I ran away from one important discussion here...

In fact, it seemed better to start a thread to discuss the API issues in
separate, an then adequate the code to do whatever decided.

-

The way the out-of-tree lirc driver works is by outputing (and inputing)
a raw sequence of pulses and spaces that have several different IR protocols,
like NEC, RC4, RC5, RC6 and pulse-distance protocols. On the other hand,
the current Input event interface (and the IR drivers at V4L/DVB code) does
is to have in-kernel code that converts those sequences or pulse/space into
a keystroke representation, outputing it to userspace.

To make things a little more complicated, it is also possible for some devices
to output IR codes. Let's first discuss the IR input case. IMO, whatever we define
for input, we should do also for output.

There's some advantages and disadvantages of both strategies, being the most
notable ones:

Raw pulse/space allows reception of IR's from all different variations of
the IR protocols. However:
it means a more complex setup at userspace, since the user must
use a daemon to decode IR code;
user must inform the IR type and the kernel driver that will receive
those keystrokes.

Event input has the advantage that the keystrokes will provide an unique
representation that is independent of the device. Considering the common case
where the lirc driver will be associated with a media input device, the
IR type can be detected automatically on kernel. However, advanced users may
opt to use other IR types than what's provided with the device they bought.

It should also be noticed that not all the already-existing IR drivers on kernel can
provide a lirc interface, since several devices have their own IR decoding chips
inside the hardware. On some cases, the hardware can be programmed to receive more
than one IR protocol type, where on others, the manufacturer provides IR decoding
capabilities only for the protocol they decided to provide together with their
hardware.

IMO, there are two different approaches that can be taken:

1) Just add lirc API as-is and let's have two different ways to get IR events
on kernel, and have two different API's for IR;

2) create a lirc kernel API, and have a layer there to decode IR protocols and
output them via the already existing input layer. In this case, all we need to do,
in terms of API, is to add a way to set the IR protocol that will be decoded,
and to enumberate the capabilities. The lirc API, will be an in-kernel API to
communicate with the devices that don't have IR protocols decoding capabilities
inside the hardware.

So, the basic question that should be decided is: should we create a new
userspace API for raw IR pulse/space or it would be better to standardize it
to always use the existing input layer?

Comments?

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

khc at pm

Nov 23, 2009, 6:14 AM

Post #2 of 163 (901 views)
Permalink

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

Mauro Carvalho Chehab <mchehab [at] redhat> writes:

> Event input has the advantage that the keystrokes will provide an unique
> representation that is independent of the device.

This can hardly work as the only means, the remotes have different keys,
the user almost always has to provide customized key<>function mapping.

> Considering the common case
> where the lirc driver will be associated with a media input device, the
> IR type can be detected automatically on kernel. However, advanced users may
> opt to use other IR types than what's provided with the device they
> bought.

I think most users would want to do that, though I don't have hard
numbers of course. Why use a number of RCs simultaneously while one will
do?

> It should also be noticed that not all the already-existing IR drivers
> on kernel can provide a lirc interface, since several devices have
> their own IR decoding chips inside the hardware.

Right. I think they shouldn't use lirc interface, so it doesn't matter.

> 2) create a lirc kernel API, and have a layer there to decode IR
> protocols and output them via the already existing input layer. In
> this case, all we need to do, in terms of API, is to add a way to set
> the IR protocol that will be decoded, and to enumberate the
> capabilities. The lirc API, will be an in-kernel API to communicate
> with the devices that don't have IR protocols decoding capabilities
> inside the hardware.

I think this makes a lot of sense.
But: we don't need a database of RC codes in the kernel (that's a lot of
data, the user has to select the RC in use anyway so he/she can simply
provide mapping e.g. RC5<>keycode).

We do need RCx etc. protocols implementation in the kernel for the input
layer.

"lirc" interface: should we be sending time+on/off data to userspace, or
the RC5 etc. should be implemented in the kernel? There is (?) only
a handful of RC protocols, implementing them in the kernel and passing
only information such as proto+group+code+press/release etc. should be
more efficient.

Perhaps the raw RCx data could be sent over the input layer as well?
Something like the raw keyboard codes maybe?

We need to handle more than one RC at a time, of course.

> So, the basic question that should be decided is: should we create a new
> userspace API for raw IR pulse/space

I think so, doing the RCx proto handling in the kernel (but without
RCx raw code <> key mapping in this case due to multiple controllers
etc.). Though it could probably use the input layer as well(?).

> or it would be better to standardize it
> to always use the existing input layer?

I'd optionally provide a keyboard-alike input layer interface, with
mappings (proto + raw code <> key) provided by userspace program.
This should also work with multiple remotes.

Then the existing drivers (such as saa713x with GPIO+IRQ-driven IR
receiver (IR signal on/off generating IRQ)) should be converted.

I think we shouldn't at this time worry about IR transmitters.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dheitmueller at kernellabs

Nov 23, 2009, 7:20 AM

Post #3 of 163 (895 views)
Permalink

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

On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa <khc [at] pm> wrote:
> I think this makes a lot of sense.
> But: we don't need a database of RC codes in the kernel (that's a lot of
> data, the user has to select the RC in use anyway so he/she can simply
> provide mapping e.g. RC5<>keycode).

Just bear in mind that with the current in-kernel code, users do *not
* have to manually select the RC code to use if they are using the
default remote that shipped with the product. This helps alot for
those unfamiliar with LIRC, since their product "works out of the box"
with the remote the product came with. I agree though, that the user
should be able to easily change the RC to be used if he/she decides to
use a remote other than the default.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

stefanr at s5r6

Nov 23, 2009, 8:19 AM

Post #4 of 163 (893 views)
Permalink

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

james at mastros

Nov 23, 2009, 8:53 AM

Post #5 of 163 (896 views)
Permalink

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

2009/11/23 Devin Heitmueller <dheitmueller [at] kernellabs>:
> Just bear in mind that with the current in-kernel code, users do *not
> * have to manually select the RC code to use if they are using the
> default remote that shipped with the product.
This could still happen, if LIRC checks the identifiers of the
reciving device, and has a database that tells it mappings between
those devices and the remote controls that shipped with them.
However, it occours to me that the IR circumstances map pretty well to
what happens with ps/2 and serial devices now:

1: There are a variety of drivers for serio computer-side hardware,
each of which speaks the serio interface to the next-higher level.
These corrospond to the drivers for IR recievers.
2: There's a raw serio interface, for those wishing to do strange things.
3: There's also a variety of things that take data, using the kernel
serio API, and decode it into input events -- the ps2 keyboard driver,
the basic mouse driver, the advanced mice drivers. This is where the
interface falls down a little bit -- the ps2 keyboard driver is the
closest analogue to what I'm suggesting. The ps2 keyboard driver
creates scancode events, which map nicely to what the keyboard is
sending -- these are, for ex, rc5 codes. It will also produce
key-up/key-down events, if it has a keymap loaded. (This is the
difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
to it at boottime, so it works out-of-box. This isn't really possible
with an IR remote -- though perhaps rc5 is standarized enough, I don't
think other protocols neccessarly are.)

Userspace would have to load a keymap; those don't really belong in
kernel code. Of course, userspace could look at the device
identifiers to pick a reasonable default keymap if it's not configured
to load another, solving the out-of-box experince.

Why is this such a contentious point? I can understand wanting to
keep uncommon decoding algos out of the kernel, and keymaps, but at
the same time, they are currently there, in multiple drivers, and
while colesing them into a single place each makes sense, I'm not
convinced that moving them out completely makes all that much sense.
Having an explicit layer between the raw pulse/space layer and the
decoders means that usespace can hook in there, and create scancode
events, if it wishes to, but for the majority of remotes that use just
a couple of encoding schemes, the code can stay in the kernel. Of
course, devices that do the decoding in hardware would not implement
the raw interface, but simply create the scancode/keycode events.

-=- James Mastros
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

james at mastros

Nov 23, 2009, 9:05 AM

Post #6 of 163 (895 views)
Permalink

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

2009/11/23 Devin Heitmueller <dheitmueller [at] kernellabs>:
> Just bear in mind that with the current in-kernel code, users do *not
> * have to manually select the RC code to use if they are using the
> default remote that shipped with the product.
This could still happen, if LIRC checks the identifiers of the
reciving device, and has a database that tells it mappings between
those devices and the remote controls that shipped with them.
However, it occours to me that the IR circumstances map pretty well to
what happens with ps/2 and serial devices now:

1: There are a variety of drivers for serio computer-side hardware,
each of which speaks the serio interface to the next-higher level.
These corrospond to the drivers for IR recievers.
2: There's a raw serio interface, for those wishing to do strange things.
3: There's also a variety of things that take data, using the kernel
serio API, and decode it into input events -- the ps2 keyboard driver,
the basic mouse driver, the advanced mice drivers. This is where the
interface falls down a little bit -- the ps2 keyboard driver is the
closest analogue to what I'm suggesting. The ps2 keyboard driver
creates scancode events, which map nicely to what the keyboard is
sending -- these are, for ex, rc5 codes. It will also produce
key-up/key-down events, if it has a keymap loaded. (This is the
difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
to it at boottime, so it works out-of-box. This isn't really possible
with an IR remote -- though perhaps rc5 is standarized enough, I don't
think other protocols neccessarly are.)

Userspace would have to load a keymap; those don't really belong in
kernel code. Of course, userspace could look at the device
identifiers to pick a reasonable default keymap if it's not configured
to load another, solving the out-of-box experince.

-=- James Mastros
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dheitmueller at kernellabs

Nov 23, 2009, 9:12 AM

Post #7 of 163 (893 views)
Permalink

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

On Mon, Nov 23, 2009 at 12:05 PM, James Mastros <james [at] mastros> wrote:
> 2009/11/23 Devin Heitmueller <dheitmueller [at] kernellabs>:
>> Just bear in mind that with the current in-kernel code, users do *not
>> * have to manually select the RC code to use if they are using the
>> default remote that shipped with the product.
> This could still happen, if LIRC checks the identifiers of the
> reciving device, and has a database that tells it mappings between
> those devices and the remote controls that shipped with them.
> However, it occours to me that the IR circumstances map pretty well to
> what happens with ps/2 and serial devices now:
>
> 1: There are a variety of drivers for serio computer-side hardware,
> each of which speaks the serio interface to the next-higher level.
> These corrospond to the drivers for IR recievers.
> 2: There's a raw serio interface, for those wishing to do strange things.
> 3: There's also a variety of things that take data, using the kernel
> serio API, and decode it into input events -- the ps2 keyboard driver,
> the basic mouse driver, the advanced mice drivers. �This is where the
> interface falls down a little bit -- the ps2 keyboard driver is the
> closest analogue to what I'm suggesting. �The ps2 keyboard driver
> creates scancode events, which map nicely to what the keyboard is
> sending -- these are, for ex, rc5 codes. �It will also produce
> key-up/key-down events, if it has a keymap loaded. �(This is the
> difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
> to it at boottime, so it works out-of-box. �This isn't really possible
> with an IR remote -- though perhaps rc5 is standarized enough, I don't
> think other protocols neccessarly are.)
>
> Userspace would have to load a keymap; those don't really belong in
> kernel code. �Of course, userspace could look at the device
> identifiers to pick a reasonable default keymap if it's not configured
> to load another, solving the out-of-box experince.

I think perhaps before we go much further into this, we may wish to
come up with a set of use cases and expected behavior. I worry that
part of the problem here is people are thinking of how their
particular cards behave, and few people have a holistic picture of all
the possible scenarios. Whatever implementation we come up, we should
be confident that it meets the requirements of *all* the various
hardware implementations.

I will try to draft up some requirements/use cases if people think
this would be worthwhile.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mchehab at redhat

Nov 23, 2009, 9:29 AM

Post #8 of 163 (893 views)
Permalink

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

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab [at] redhat> writes:
>
>> Event input has the advantage that the keystrokes will provide an unique
>> representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have different keys,
> the user almost always has to provide customized key<>function mapping.

Key mapping can be easily changed via input interface, as noticed by others.

>> Considering the common case
>> where the lirc driver will be associated with a media input device, the
>> IR type can be detected automatically on kernel. However, advanced users may
>> opt to use other IR types than what's provided with the device they
>> bought.
>
> I think most users would want to do that, though I don't have hard
> numbers of course. Why use a number of RCs simultaneously while one will
> do?

If you're building a dedicated hardware to act as a MCE, it makes sense to
use just one IR to control your TV and your hardware, but the common usage
is to add a TV board or stick to your desktop to see TV. For this,
the standard IR fits well.

>> It should also be noticed that not all the already-existing IR drivers
>> on kernel can provide a lirc interface, since several devices have
>> their own IR decoding chips inside the hardware.
>
> Right. I think they shouldn't use lirc interface, so it doesn't matter.

If you see patch 3/3, of the lirc submission series, you'll notice a driver
that has hardware decoding, but, due to lirc interface, the driver generates
pseudo pulse/space code for it to work via lirc interface.

It is very bad to have two interfaces for the same thing, because people
may do things like that.

Also, there are some cases where the same V4L driver can receive IR scancodes
directly for one board, while for others, it needs to get pulse/space decoding.

So, it makes sense to have an uniform way for doing it.

>> 2) create a lirc kernel API, and have a layer there to decode IR
>> protocols and output them via the already existing input layer. In
>> this case, all we need to do, in terms of API, is to add a way to set
>> the IR protocol that will be decoded, and to enumberate the
>> capabilities. The lirc API, will be an in-kernel API to communicate
>> with the devices that don't have IR protocols decoding capabilities
>> inside the hardware.
>
> I think this makes a lot of sense.
> But: we don't need a database of RC codes in the kernel (that's a lot of
> data, the user has to select the RC in use anyway so he/she can simply
> provide mapping e.g. RC5<>keycode).

This is an interesting discussion. We currently have lots of such tables in
kernel, but it can be a good idea to have it loaded by udev during boot time.

> We do need RCx etc. protocols implementation in the kernel for the input
> layer.

Yes. We already have this. See bttv, saa7134 and cx88 for several of such
protocol decoding.

> "lirc" interface: should we be sending time+on/off data to userspace, or
> the RC5 etc. should be implemented in the kernel? There is (?) only
> a handful of RC protocols, implementing them in the kernel and passing
> only information such as proto+group+code+press/release etc. should be
> more efficient.
>
> Perhaps the raw RCx data could be sent over the input layer as well?
> Something like the raw keyboard codes maybe?
>
> We need to handle more than one RC at a time, of course.

Are you meaning that we should do more than one RC per input event interface?
If so, why do you think we need to handle more than one IR protocol at the same time?
I think this will just make the driver more complex without need. Also, I'm
not sure if this would work well for all protocols.

>> So, the basic question that should be decided is: should we create a new
>> userspace API for raw IR pulse/space
>
> I think so, doing the RCx proto handling in the kernel (but without
> RCx raw code <> key mapping in this case due to multiple controllers
> etc.). Though it could probably use the input layer as well(?).

Since the key mapping table can be changed anytime, I don't see this as an issue.
If we are doing protocol handling in kernel, we just need to add some extensions
to the existing input event API to properly handle the IR protocol type.

> I think we shouldn't at this time worry about IR transmitters.

Agreed. We can postpone this discussion after solving the IR receivers

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

dmitry.torokhov at gmail

Nov 23, 2009, 9:37 AM

Post #9 of 163 (893 views)
Permalink

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

On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab [at] redhat> writes:
>
> > Event input has the advantage that the keystrokes will provide an unique
> > representation that is independent of the device.
>
> This can hardly work as the only means, the remotes have different keys,
> the user almost always has to provide customized key<>function mapping.
>

Is it true? I would expect the remotes to have most of the keys to have
well-defined meanings (unless it is one of the programmable remotes)...

>
> Perhaps the raw RCx data could be sent over the input layer as well?
> Something like the raw keyboard codes maybe?
>

Curreently the "scan" codes in the input layer serve just to help users
to map whatever the device emits into a proper input event code so that
the rest of userspace would not have to care and would work with all
types of devices (USB, PS/2, etc).

I would not want to get to the point where the raw codes are used as a
primary data source.

> We need to handle more than one RC at a time, of course.
>
> > So, the basic question that should be decided is: should we create a new
> > userspace API for raw IR pulse/space
>
> I think so, doing the RCx proto handling in the kernel (but without
> RCx raw code <> key mapping in this case due to multiple controllers
> etc.). Though it could probably use the input layer as well(?).
>

I think if the data is used to do the primary protocol decoding then it
should be a separate interface that is processed by someone and then fed
into input subsystem (either in-kernel or through uinput).

Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for
keys and buttons on all devices.

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

mchehab at redhat

Nov 23, 2009, 9:39 AM

Post #10 of 163 (894 views)
Permalink

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

Stefan Richter wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab <mchehab [at] redhat> writes:
>>
>>> Event input has the advantage that the keystrokes will provide an unique
>>> representation that is independent of the device.
>> This can hardly work as the only means, the remotes have different keys,
>> the user almost always has to provide customized key<>function mapping.
>
> Modern input drivers in the mainline kernel have a scancode-to-keycode
> translation table (or equivalent) which can be overwritten by userspace.
> The mechanism to do that is the EVIOCSKEYCODE ioctl.

This mechanism is already used by all V4L drivers and several DVB drivers.

> (This is no recommendation for lirc. I have no idea whether a
> pulse/space -> scancode -> keycode translation would be practical there.)

pulse/space -> scancode translation is already done by several existing drivers.

For example, there are several bttv and saa7134 devices that polls (or receive
IRQ interrupts) to detect pulses (and the absense of them) in order to create
a pulse/space code. The conversion from pulse/space to scancode is done inside
the driver, with the help of some generic routines and based on the protocol
specifications.

The conversion from the scancode to a keycode is done based on in-kernel keycode
tables that can be changed from userspace with EVIOCSKEYCODE ioctl.

I can't see any technical reason why not doing the same for the lirc drivers,
except for one issue:

Those devices where the decoding is done by software can support any IR protocols.
So, it is possible to buy a device with a NEC IR, and use a RC5 IR to control it.

However, currently, there's no way to inform the kernel to use a different algorithm
to translate the kernel.

This can be solved by adding a few ioctls to enumerate the supported protocols and
to select the one(s) that will be handled by the kernel driver.

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

mchehab at redhat

Nov 23, 2009, 9:50 AM

Post #11 of 163 (895 views)
Permalink

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

James Mastros wrote:
> 2009/11/23 Devin Heitmueller <dheitmueller [at] kernellabs>:
>> Just bear in mind that with the current in-kernel code, users do *not
>> * have to manually select the RC code to use if they are using the
>> default remote that shipped with the product.
> This could still happen, if LIRC checks the identifiers of the
> reciving device, and has a database that tells it mappings between
> those devices and the remote controls that shipped with them.

True, but this means that everyone with an IR will need to use lirc.

/me thinks that, whatever decided with those lirc drivers, this should be applied also to the existing V4L/DVB drivers.

IMO, it would be better to load the tables at the boot time (or at the
corresponding hotplug event, for USB devices).

> However, it occours to me that the IR circumstances map pretty well to
> what happens with ps/2 and serial devices now:
>
> 1: There are a variety of drivers for serio computer-side hardware,
> each of which speaks the serio interface to the next-higher level.
> These corrospond to the drivers for IR recievers.
> 2: There's a raw serio interface, for those wishing to do strange things.
> 3: There's also a variety of things that take data, using the kernel
> serio API, and decode it into input events -- the ps2 keyboard driver,
> the basic mouse driver, the advanced mice drivers.

Seems an interesting model.

> This is where the
> interface falls down a little bit -- the ps2 keyboard driver is the
> closest analogue to what I'm suggesting. The ps2 keyboard driver
> creates scancode events, which map nicely to what the keyboard is
> sending -- these are, for ex, rc5 codes. It will also produce
> key-up/key-down events, if it has a keymap loaded. (This is the
> difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
> to it at boottime, so it works out-of-box. This isn't really possible
> with an IR remote -- though perhaps rc5 is standarized enough, I don't
> think other protocols neccessarly are.)

Even with RC5, there are some vendors that implement it differently on his
IR (for example, using VCR and/or TV group for the keys).

> Userspace would have to load a keymap; those don't really belong in
> kernel code. Of course, userspace could look at the device
> identifiers to pick a reasonable default keymap if it's not configured
> to load another, solving the out-of-box experince.

I like this idea. We currently have hundreds of IR keymaps already in kernel.
It seems good to remove from kernel and let udev load those.

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

jarod at wilsonet

Nov 23, 2009, 11:17 AM

Post #12 of 163 (886 views)
Permalink

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

I'm a bit short on time to write up a more complete reply to anything in this thread at the moment, but a few quick notes interspersed below.

On Nov 23, 2009, at 12:29 PM, Mauro Carvalho Chehab wrote:

> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab <mchehab [at] redhat> writes:
...
>>> Considering the common case
>>> where the lirc driver will be associated with a media input device, the
>>> IR type can be detected automatically on kernel. However, advanced users may
>>> opt to use other IR types than what's provided with the device they
>>> bought.
>>
>> I think most users would want to do that, though I don't have hard
>> numbers of course. Why use a number of RCs simultaneously while one will
>> do?
>
> If you're building a dedicated hardware to act as a MCE, it makes sense to
> use just one IR to control your TV and your hardware, but the common usage
> is to add a TV board or stick to your desktop to see TV. For this,
> the standard IR fits well.

The main use case that I have personal experience using IR and capture devices is with MythTV. Its not at all uncommon for a MythTV user to have a setup where the capture devices are attached to a completely different system from the system where the IR part needs to be. MythTV is client-server -- the backend server does the video capture via the capture devices, and the frontend client plays back the video, and its the frontend client that you navigate via an IR remote control. There are quite a few available IR options that are NOT tied to a video capture device at all -- the mceusb and imon drivers submitted in my patch series are actually two such beasts.

And particularly with the mceusb receivers, because they support damn near every IR protocol under the sun at any carrier frequency, using a remote other than the bundled one is quite common. Most people's set top boxes and/or televisions and/or AV receivers come with a remote capable of controlling multiple devices, and many bundled remotes are, quite frankly, utter garbage. I use a Logitech Harmony 880 universal remote myself.

>>> It should also be noticed that not all the already-existing IR drivers
>>> on kernel can provide a lirc interface, since several devices have
>>> their own IR decoding chips inside the hardware.
>>
>> Right. I think they shouldn't use lirc interface, so it doesn't matter.
>
> If you see patch 3/3, of the lirc submission series, you'll notice a driver
> that has hardware decoding, but, due to lirc interface, the driver generates
> pseudo pulse/space code for it to work via lirc interface.

Historically, this is true. But the version I submitted actually defaults to operating as a pure input layer device for all the imon devices that do onboard decoding. There are older imon devices that don't do onboard decoding, and I retained "legacy", if you will, lirc interface support in this pass of the driver for the onboard decode devices for those that want to keep things running as they always have (via a modparam).

More replyification later tonight...

--
Jarod Wilson
jarod [at] wilsonet

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

khc at pm

Nov 23, 2009, 12:09 PM

Post #13 of 163 (886 views)
Permalink

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

James Mastros <james [at] mastros> writes:

> (This is the
> difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
> to it at boottime, so it works out-of-box. This isn't really possible
> with an IR remote -- though perhaps rc5 is standarized enough, I don't
> think other protocols neccessarly are.)

Even with RC5 this isn't really possible. RC5 specifies several classes
of remotes, and with a typical HTPC scenario the sensor will pick up
more than one remote codeset - e.g. one for the display, one for TV
card, and maybe others (all those codes may be coming from a single
remote). We have no way to know in advance which one code set is for the
PC.

The only thing which we can "preconfigure" is the remote bundled with
the sensor (card etc). And even this can be incorrect. Several sensors
don't came with a remote controller.

I think the default sensor->remote assignment may only make sense in
userspace, while configuring the mapping.

Of course all the above changes when the sensors can't present the
"raw" data (IR on/off) but does all the decoding internally (and for
example can't decode all RC5 but only keys used on its remote). In such
unfortunate cases it has to go to the input layer directly.

> Userspace would have to load a keymap; those don't really belong in
> kernel code. Of course, userspace could look at the device
> identifiers to pick a reasonable default keymap if it's not configured
> to load another, solving the out-of-box experince.

Precisely.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khc at pm

Nov 23, 2009, 12:14 PM

Post #14 of 163 (887 views)
Permalink

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

Mauro Carvalho Chehab <mchehab [at] redhat> writes:

> True, but this means that everyone with an IR will need to use lirc.

I think that if the input layer (instead of raw code) is used, a utility
which only sets the mapping(s) would suffice. I.e. no daemon.

> /me thinks that, whatever decided with those lirc drivers, this should
> be applied also to the existing V4L/DVB drivers.

Certainly.

> IMO, it would be better to load the tables at the boot time (or at the
> corresponding hotplug event, for USB devices).

Sure (unless the "raw code" interface is in use).

Though maybe the raw code interface should be done in a simple library
instead of requiring the daemon.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khc at pm

Nov 23, 2009, 12:23 PM

Post #15 of 163 (876 views)
Permalink

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

Mauro Carvalho Chehab <mchehab [at] redhat> writes:

>> (This is no recommendation for lirc. I have no idea whether a
>> pulse/space -> scancode -> keycode translation would be practical
>> there.)

It would, but not exactly in the present shape.

> For example, there are several bttv and saa7134 devices that polls (or receive
> IRQ interrupts) to detect pulses (and the absense of them) in order to create
> a pulse/space code. The conversion from pulse/space to scancode is done inside
> the driver, with the help of some generic routines and based on the protocol
> specifications.

Right. There are currently several problems (I'm quite familiar with
saa713x RC5 code): the one that it barely works and is not implemented
for most such "GPIO/IRQ-driven" cards (as of 2.6.29 or so). This could
be fixed, I even have a working though quick&dirty patch. Another: the
RC5 allows for groups and codes within groups. The mapping can only use
one group, and there can only be one mapping. These design limitations
mean it's unusable in many cases.

> Those devices where the decoding is done by software can support any
> IR protocols.

Yes, and there can be multiple remote controllers, and multiple code
groups within a remote.

> This can be solved by adding a few ioctls to enumerate the supported
> protocols and to select the one(s) that will be handled by the kernel
> driver.

The driver may have to handle many protocols simultaneously. This is not
a problem from a technical POV.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khc at pm

Nov 23, 2009, 12:41 PM

Post #16 of 163 (876 views)
Permalink

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

Mauro Carvalho Chehab <mchehab [at] redhat> writes:

> If you see patch 3/3, of the lirc submission series, you'll notice a driver
> that has hardware decoding, but, due to lirc interface, the driver generates
> pseudo pulse/space code for it to work via lirc interface.

IOW the driver generates artificial pulse code for lircd?
I think - pure bloat. lircd can get events from input layer without
problems. Perhaps I misunderstood?

> It is very bad to have two interfaces for the same thing, because people
> may do things like that.

I think having a "raw" scan code interface + the key code "cooked" mode
is beneficial. For remotes lacking the raw interface only the latter
could be used.

> Also, there are some cases where the same V4L driver can receive IR scancodes
> directly for one board, while for others, it needs to get pulse/space
> decoding.

Sure.

> This is an interesting discussion. We currently have lots of such tables in
> kernel, but it can be a good idea to have it loaded by udev during
> boot time.

Sure.

> Are you meaning that we should do more than one RC per input event
> interface?

I think so. Why not?

For example, one of my remotes generates codes from at least two RC5
groups (in only one "mode"). Currently a remote is limited to only one
RC5 group.

I think the mapping should be: key = proto + group + raw code, while
key2 could be different_proto + different group (if any) + another code.

> If so, why do you think we need to handle more than one IR protocol at
> the same time?

Why not?
There are X-in-1 remotes on the market for years. They can "speak" many
protocols at once. One may want to have a protocol to handle DVD apps
while another for DVB etc.
And someone may want to use several different remotes, why not?
Personally I use two different remotes (both set to speak RC5 but what
if I couldn't set the protocol?). Sure, it requires a bit of hackery
(not with pulse code and lircd).

> I think this will just make the driver more complex without need.

Not much more, and there is a need.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khc at pm

Nov 23, 2009, 12:46 PM

Post #17 of 163 (877 views)
Permalink

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

Jarod Wilson <jarod [at] wilsonet> writes:

> There are quite a few available IR options that are NOT tied to a
> video capture device at all -- the mceusb and imon drivers submitted
> in my patch series are actually two such beasts.

Precisely. This also includes the parallel and serial port receivers,
I'm under impression that they are, or at least were, the most common,
due to their extreme simplicity.

> And particularly with the mceusb receivers, because they support damn
> near every IR protocol under the sun at any carrier frequency, using a
> remote other than the bundled one is quite common. Most people's set
> top boxes and/or televisions and/or AV receivers come with a remote
> capable of controlling multiple devices, and many bundled remotes are,
> quite frankly, utter garbage.

This is precisely also my experience.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khc at pm

Nov 23, 2009, 12:51 PM

Post #18 of 163 (876 views)
Permalink

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

Dmitry Torokhov <dmitry.torokhov [at] gmail> writes:

> Curreently the "scan" codes in the input layer serve just to help users
> to map whatever the device emits into a proper input event code so that
> the rest of userspace would not have to care and would work with all
> types of devices (USB, PS/2, etc).
>
> I would not want to get to the point where the raw codes are used as a
> primary data source.

The "key" interface is not flexible enough at present.

> Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for
> keys and buttons on all devices.

Primary, I think so.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

lirc at bartelmus

Nov 23, 2009, 1:10 PM

Post #19 of 163 (877 views)
Permalink

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

Hi Jarod,

on 23 Nov 09 at 14:17, Jarod Wilson wrote:
>> Krzysztof Halasa wrote:
[...]
>> If you see patch 3/3, of the lirc submission series, you'll notice a driver
>> that has hardware decoding, but, due to lirc interface, the driver
>> generates pseudo pulse/space code for it to work via lirc interface.

> Historically, this is true.

No, it's not.
I think you misunderstood the code. The comment may be a bit misleading,
too.
Early iMON devices did not decode in hardware and the part of the driver
that Krzystof is referring to is translating a bit-stream of the sampled
input data into pulse/space durations.

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

lirc at bartelmus

Nov 23, 2009, 1:11 PM

Post #20 of 163 (876 views)
Permalink

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

Czesc Krzysztof,

on 23 Nov 09 at 15:14, Krzysztof Halasa wrote:
[...]
> I think we shouldn't at this time worry about IR transmitters.

Sorry, but I have to disagree strongly.
Any interface without transmitter support would be absolutely unacceptable
for many LIRC users, including myself.

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

khc at pm

Nov 23, 2009, 1:46 PM

Post #21 of 163 (876 views)
Permalink

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

lirc [at] bartelmus (Christoph Bartelmus) writes:

>> I think we shouldn't at this time worry about IR transmitters.
>
> Sorry, but I have to disagree strongly.
> Any interface without transmitter support would be absolutely unacceptable
> for many LIRC users, including myself.

I don't say don't use a transmitter.
I say the transmitter is not an input device, they are completely
independent functions. I can't see any reason to try and fit both in the
same interface - can you?
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dheitmueller at kernellabs

Nov 23, 2009, 1:54 PM

Post #22 of 163 (876 views)
Permalink

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

On Mon, Nov 23, 2009 at 4:46 PM, Krzysztof Halasa <khc [at] pm> wrote:
> lirc [at] bartelmus (Christoph Bartelmus) writes:
>
>>> I think we shouldn't at this time worry about IR transmitters.
>>
>> Sorry, but I have to disagree strongly.
>> Any interface without transmitter support would be absolutely unacceptable
>> for many LIRC users, including myself.
>
> I don't say don't use a transmitter.
> I say the transmitter is not an input device, they are completely
> independent functions. I can't see any reason to try and fit both in the
> same interface - can you?

There is an argument to be made that since it may be desirable for
both IR receivers and transmitters to share the same table of remote
control definitions, it might make sense to at least *consider* how
the IR transmitter interface is going to work, even if it is decided
to not implement such a design in the first revision.

Personally, I would hate to see a situation where we find out that we
took a bad approach because nobody considered what would be required
for IR transmitters to reuse the same remote control definition data.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khc at pm

Nov 23, 2009, 2:25 PM

Post #23 of 163 (873 views)
Permalink

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

I though about it a bit - my idea:

1. Receivers that can only decode their own remote controllers.
The present code (saa713x etc) can stay mostly unchanged. I'd only
verify that 7 bits (or whatever the number is) is enough for all
cases. The ioctl() should stay unchanged. That means keyboard-like
input layer interface.

2. Receivers that can be programmed to receive different codes, and/or
which simply generate IRQ on space/mark changes. They would use a new
ioctl() instead:

int set_rc_mapping_ioctl(void *data ...)

data should be:
u32 protocol1;
u32 length1;
u32 protocol2;
u32 length2;
...
u32 protocol_last;
u32 length_last;
(u32) 0.

The protocol data would follow (after all proto/length fields to avoid
alignment issues, but that's a detail of course).

For example, RC5. It uses 1 start bit (formerly 2 bits), 1 "toggle" bit,
5 address bits (group code) and 7 command bits (formerly 6 bits).
Each key would be represented by u16, or maybe by a couple of u8.
A "discard repeated" (perhaps inverted) bit should be included. Of
course, the "symbolic" key code should be included for each "scan" code.

Maybe: u8 address_and_discard_repeated_bit;
u8 command_value;
u8 symbolic_key_code;
repeated as required.

Protocol2 would follow protocol1 etc. (alignment issues). The driver
could see this info (for example, to program hardware to receive a
specific protocol) and then it should pass it to the generic
lirc_set_mapping() routine.

I'd also add separate trivial space/mark protocol, for debugging etc.
Maybe: u8 key_code_for_space;
u8 key_code_for_mark;
Maybe specifying length = 0 (meaning constant "key" codes) would be
enough? I think the "key" code should also specify some time stamp (or
pulse length).

Interface to the sensor driver:
The driver should register an IRQ called on both (preferably) edges of
the input signal. Basically it should only register IRQ and do:

irqreturn_t xxx_irq()
{
ack_irq_as_usual_etc();
if (input_signal->changed_state) /* really for us */
lirc_signal_state_change(input_signal->current_state);
}

The sensor driver would not know about the protocols etc. unless it
needs to e.g. program the hardware.

The middle layer (some sort of a library, and module) would interface to
the userspace (ioctl passed by the driver, input interface) and to the
hw driver. It would have to enable and call the required protocol
decoders (based on the keymap loaded).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khc at pm

Nov 23, 2009, 2:31 PM

Post #24 of 163 (874 views)
Permalink

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

Devin Heitmueller <dheitmueller [at] kernellabs> writes:

> There is an argument to be made that since it may be desirable for
> both IR receivers and transmitters to share the same table of remote
> control definitions, it might make sense to at least *consider* how
> the IR transmitter interface is going to work, even if it is decided
> to not implement such a design in the first revision.
>
> Personally, I would hate to see a situation where we find out that we
> took a bad approach because nobody considered what would be required
> for IR transmitters to reuse the same remote control definition data.

I briefly though about such possibility, but dismissed it with
assumption that we won't transmit the same codes (including "key" codes)
that we receive.

Perhaps I'm wrong.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dheitmueller at kernellabs

Nov 23, 2009, 2:37 PM

Post #25 of 163 (874 views)
Permalink

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

On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa <khc [at] pm> wrote:
> Devin Heitmueller <dheitmueller [at] kernellabs> writes:
>
>> There is an argument to be made that since it may be desirable for
>> both IR receivers and transmitters to share the same table of remote
>> control definitions, it might make sense to at least *consider* how
>> the IR transmitter interface is going to work, even if it is decided
>> to not implement such a design in the first revision.
>>
>> Personally, I would hate to see a situation where we find out that we
>> took a bad approach because nobody considered what would be required
>> for IR transmitters to reuse the same remote control definition data.
>
> I briefly though about such possibility, but dismissed it with
> assumption that we won't transmit the same codes (including "key" codes)
> that we receive.

I'm not specifically suggesting that you would want to transmit the
same codes that you receive, but you probably want the database of
remote control definitions to be shared.

For example, you might want the IR receiver to be listening for codes
using the "Universal Remote Control XYZ" profile and the IR
transmitter pretending to be "Cable Company Remote Control ABC" when
blasting IR codes to the cable box. Ideally, there would be a single
shared database of the definitions of the remote controls, regardless
of whether you are IR receiving or transmitting.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3 4 5 6 7

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads