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

[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]

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

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> 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

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

[Emmanuel Fusté]

It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote control support ?

See http://marc.info/?l=linux-kernel&m=122591465821297&w=2 and all discussions around it.


Regards,
Emmanuel.
---

---------------------------------------------------------------------------- 
Laposte.net fête ses 10 ans ! 

Gratuite, garantie à vie et déjà utilisée par des millions d'internautes... 
vous aussi, pour votre adresse e-mail, choisissez laposte.net. 

Laposte.net, bien + qu'une messagerie 
----------------------------------------------------------------------------

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

[Devin Heitmueller]

On Mon, Nov 23, 2009 at 9:14 AM, Krzysztof Halasa <khc@pm.waw.pl> 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

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

[Stefan Richter]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> 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 is no recommendation for lirc.  I have no idea whether a
pulse/space -> scancode -> keycode translation would be practical there.)
-- 
Stefan Richter
-=====-==--= =-== =-===
http://arcgraph.de/sr/

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

[James Mastros]

2009/11/23 Devin Heitmueller <dheitmueller@kernellabs.com>:
> 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

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

[James Mastros]

2009/11/23 Devin Heitmueller <dheitmueller@kernellabs.com>:
> 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

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

[Devin Heitmueller]

On Mon, Nov 23, 2009 at 12:05 PM, James Mastros <james@mastros.biz> wrote:
> 2009/11/23 Devin Heitmueller <dheitmueller@kernellabs.com>:
>> 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

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> 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.

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

[Dmitry Torokhov]

On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> 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

Re: [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]

Stefan Richter wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab <mchehab@redhat.com> 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

Re: [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]

James Mastros wrote:
> 2009/11/23 Devin Heitmueller <dheitmueller@kernellabs.com>:
>> 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.

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

[Jarod Wilson]

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@redhat.com> 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@wilsonet.com

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

[Krzysztof Halasa]

James Mastros <james@mastros.biz> 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

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> 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

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> 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

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> 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

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

[Krzysztof Halasa]

Jarod Wilson <jarod@wilsonet.com> 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

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

[Krzysztof Halasa]

Dmitry Torokhov <dmitry.torokhov@gmail.com> 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

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

[Christoph Bartelmus]

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

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

[Christoph Bartelmus]

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

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

[Krzysztof Halasa]

lirc@bartelmus.de (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

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

[Devin Heitmueller]

On Mon, Nov 23, 2009 at 4:46 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> lirc@bartelmus.de (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

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

[Krzysztof Halasa]

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

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

[Krzysztof Halasa]

Devin Heitmueller <dheitmueller@kernellabs.com> 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

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

[Devin Heitmueller]

On Mon, Nov 23, 2009 at 5:31 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Devin Heitmueller <dheitmueller@kernellabs.com> 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

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

[Krzysztof Halasa]

Devin Heitmueller <dheitmueller@kernellabs.com> writes:

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

Well, with different receivers, the maps must certainly be different.
There can be single database in the userspace but the kernel must be
uploaded the relevant info only.
-- 
Krzysztof Halasa

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

[Andy Walls]

On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> 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.

I agree with Christoph.  

Is it that the input subsystem is better developed and seen as a
leverage point for development and thus an "easier" place to get results
earlier?  If so, then one should definitely deal with transmitters early
in the design, as that is where the most unknowns lie.

With the end of analog TV, people will have STBs feeding analog only
video cards.  Being able to change the channel on the STB with an IR
transmitter controlled by applications like MythTV is essential.


And on some different notes:

I generally don't understand the LIRC aversion I perceive in this thread
(maybe I just have a skewed perception).  Aside for a video card's
default remote setup, the suggestions so far don't strike me as any
simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
already works for both transmit and receive and has existing support in
applications such as MythTV and mplayer.

I believe Jarod's intent is to have the LIRC components, that need to be
in kernel modules, moved into kernel mainline to avoid the headaches of
out of kernel driver maintenance.  I'm not sure it is time well spent
for developers, or end users, to develop yet another IR receive
implementation in addition to the ones we suffer with now.


I would also note that RC-6 Mode 6A, used by most MCE remotes, was
developed by Philips, but Microsoft has some sort of licensing interest
in it and it is almost surely encumbered somwhow:

http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt

"Microsoft recommends the Microsoft-Philips IR protocol (based on RC6)
              * You can become a licensee at no charge to you
[...]
  * How to license RC6
      * Contact RemoteMC @ microsoft.com for license agreement"


I would much rather that RC-6 be handled as much as possible in user
space than in the kernel.  LIRC userspace components already handle it,
IIRC.


Regards,
Andy "LIRC Fan-Boy" Walls

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

[Andy Walls]

On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
> lirc@bartelmus.de (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?

The underlying hardware need not be completely independent.

For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
chips have IR hardware that shares a common timing source, interrupt
line, interrupt status register, etc, between IR Rx and Tx.  They can
also do things like loopback of Tx to Rx.

That said, an underlying hardware implementation can be split up to user
space with separate interfaces Tx and Rx.  The underlying driver module
would have to manage the dependencies.  I would guess that would be
easier for driver modules, if the userspace interfaces were designed
with such combined IR Tx/Rx hardware in mind.

Regards,
Andy

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

[Jarod Wilson]

On 11/23/2009 04:10 PM, Christoph Bartelmus wrote:
> 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.

Sorry, no, I know the newer devices don't actually send pulse/data info 
out to userspace, just hex codes that correspond to key presses. What I 
meant was "onboard decoding devices can operate as pure input devices or 
in classic lirc mode", leaving out the details on exactly what they were 
sending out to userspace. :)

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Jarod Wilson]

On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab<mchehab@redhat.com>  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)...

Its the cases like programmable universal remotes that really throw 
things for a loop. That, and people wanting to use random remote X that 
came with the amp or tv or set top box, with IR receiver Y.

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

Current lircd actually inter-operates with the input subsystem quite 
well for any and all supported remotes if their keys are mapped in their 
respective lircd.conf file using standard input subsystem key names, and 
the lirc daemon started with the --uinput param. lircd decodes the raw 
IR, finds the mapping in its config, and happily passes it along to uinput.

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Jarod Wilson]

On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:

> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
...
> I generally don't understand the LIRC aversion I perceive in this thread
> (maybe I just have a skewed perception).  Aside for a video card's
> default remote setup, the suggestions so far don't strike me as any
> simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
> already works for both transmit and receive and has existing support in
> applications such as MythTV and mplayer.

There's one gripe I agree with, and that is that its still not plug-n-play. Something where udev auto-loads a sane default remote config for say, mceusb transceivers, and the stock mce remote Just Works would be nice, but auto-config is mostly out the window the second you involve transmitters and universal remotes anyway. But outside of that, I think objections are largely philosophical -- in a nutshell, the kernel has an input layer, remotes are input devices, and lirc doesn't conform to input layer standards. I do understand that argument, I just don't currently agree that all IR must go through the input layer before the drivers are acceptable for upstream -- especially since lircd can reinject decoded key presses into the input layer via uinput.

> I believe Jarod's intent is to have the LIRC components, that need to be
> in kernel modules, moved into kernel mainline to avoid the headaches of
> out of kernel driver maintenance.  I'm not sure it is time well spent
> for developers, or end users, to develop yet another IR receive
> implementation in addition to the ones we suffer with now.

Yeah, a fairly relevant factor in all this is that, despite not being in the linux kernel source tree proper-like, the lirc drivers and lirc have been in use for many years by lots of users. The likes of Fedora, Debian, Ubuntu, SUSE, Mandriva, etc. have all been shipping lirc drivers for years now. While lirc certainly isn't perfect (its not always the easiest thing for users to set up), it has actually proven itself pretty robust and useful in the field, once set up. The bulk of breakage in lirc I've personally had to deal with has mostly come in the form of kernel interface changes, which would definitely be mitigated by not having to maintain the drivers out-of-tree any longer.

Now, I'm all for "improving" things and integrating better with the input subsystem, but what I don't really want to do is break compatibility with the existing setups on thousands (and thousands?) of MythTV boxes around the globe. The lirc userspace can be pretty nimble. If we can come up with a shiny new way that raw IR can be passed out through an input device, I'm pretty sure lirc userspace can be adapted to handle that. If a new input-layer-based transmit interface is developed, we can take advantage of that too. But there's already a very mature lirc interface for doing all of this. So why not start with adding things more or less as they exist right now and evolve the drivers into an idealized form? Getting *something* into the kernel in the first place is a huge step in that direction.

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Krzysztof Halasa]

Andy Walls <awalls@radix.net> writes:

> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> developed by Philips, but Microsoft has some sort of licensing interest
> in it and it is almost surely encumbered somwhow:

I don't know about legal problems in some countries but from the
technical POV handling the protocol in the kernel is more efficient
or (/and) simpler.
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Jarod Wilson <jarod@wilsonet.com> writes:

> The bulk of breakage in lirc I've personally had to deal with has
> mostly come in the form of kernel interface changes, which would
> definitely be mitigated by not having to maintain the drivers
> out-of-tree any longer.

Certainly.

> Now, I'm all for "improving" things and integrating better with the
> input subsystem, but what I don't really want to do is break
> compatibility with the existing setups on thousands (and thousands?)
> of MythTV boxes around the globe. The lirc userspace can be pretty
> nimble. If we can come up with a shiny new way that raw IR can be
> passed out through an input device, I'm pretty sure lirc userspace can
> be adapted to handle that.

Lirc can already handle input layer. Since both ways require userspace
changes, why not do it the right way the first time? Most of the code
is already written.

> If a new input-layer-based transmit interface is developed, we can
> take advantage of that too. But there's already a very mature lirc
> interface for doing all of this. So why not start with adding things
> more or less as they exist right now and evolve the drivers into an
> idealized form? Getting *something* into the kernel in the first place
> is a huge step in that direction.

What I see as potentially problematic is breaking compatibility multiple
times.
-- 
Krzysztof Halasa

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

[Christoph Bartelmus]

Hi,

on 25 Nov 09 at 17:53, Krzysztof Halasa wrote:
> Jarod Wilson <jarod@wilsonet.com> writes:
[...]
>> nimble. If we can come up with a shiny new way that raw IR can be
>> passed out through an input device, I'm pretty sure lirc userspace can
>> be adapted to handle that.

As Trent already pointed out, adding support for raw IR through an input  
device would require a new interface too. You just put the label "input  
device" on it. This does not make much sense for me.

> Lirc can already handle input layer. Since both ways require userspace
> changes,

I'm not sure what two ways you are talking about. With the patches posted  
by Jarod, nothing has to be changed in userspace.
Everything works, no code needs to be written and tested, everybody is  
happy.

We had exactly the same discussion around one year ago. I've seen no new  
arguements in the current discussion and nobody came up with this shiny  
new way of integrating LIRC into the input layer since last year. Maybe  
it's about time to just accept that the LIRC interface is the way to go.

Can we finally get the patch integrated, please?

Christoph

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

[Krzysztof Halasa]

lirc@bartelmus.de (Christoph Bartelmus) writes:

> I'm not sure what two ways you are talking about. With the patches posted  
> by Jarod, nothing has to be changed in userspace.
> Everything works, no code needs to be written and tested, everybody is  
> happy.

The existing drivers use input layer. Do you want part of the tree to
use existing lirc interface while the other part uses their own
in-kernel (badly broken for example) code to do precisely the same
thing?

We can have a good code for both, or we can end up with "badly broken"
media drivers and incompatible, suboptimal existing lirc interface
(though most probably much better in terms of quality, especially after
Jarod's work).
-- 
Krzysztof Halasa

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

[Jarod Wilson]

On Nov 25, 2009, at 11:53 AM, Krzysztof Halasa wrote:

> Jarod Wilson <jarod@wilsonet.com> writes:
...
>> Now, I'm all for "improving" things and integrating better with the
>> input subsystem, but what I don't really want to do is break
>> compatibility with the existing setups on thousands (and thousands?)
>> of MythTV boxes around the globe. The lirc userspace can be pretty
>> nimble. If we can come up with a shiny new way that raw IR can be
>> passed out through an input device, I'm pretty sure lirc userspace can
>> be adapted to handle that.
> 
> Lirc can already handle input layer. Since both ways require userspace
> changes, why not do it the right way the first time? Most of the code
> is already written.

There's obviously still some debate as to what "the right way" is. :)

And the matter of someone having the time to write the rest of the code that would be needed.

>> If a new input-layer-based transmit interface is developed, we can
>> take advantage of that too. But there's already a very mature lirc
>> interface for doing all of this. So why not start with adding things
>> more or less as they exist right now and evolve the drivers into an
>> idealized form? Getting *something* into the kernel in the first place
>> is a huge step in that direction.
> 
> What I see as potentially problematic is breaking compatibility multiple
> times.

Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this:

1) bring drivers in in their current state
   - users keep using lirc as they always have

2) add in-kernel decoding infra that feeds input layer

3) add option to use in-kernel decoding to existing lirc drivers
   - users can keep using lirc as they always have
   - users can optionally try out in-kernel decoding via a modparam

4) switch the default mode from lirc decode to kernel decode for each lirc driver
   - modparam can be used to continue using lirc interface instead

5) assuming users aren't coming at us with pitchforks, because things don't actually work reliably with in-kernel decoding, deprecate the lirc interface in driver

6) remove lirc interface from driver, its now a pure input device

This would all be on a per-lirc-driver basis, and if/when all decoding could be reliably done in-kernel, and/or there was a way other than the lirc interface to pass raw IR signals out to userspace, the lirc interface could be removed entirely.

And we still need to consider IR transmitters as well. Those are handled quite well through the lirc interface, and I've not seen any concrete code (or even fully fleshed out ideas) on how IR transmit could be handled in this in-kernel decoding world.


[*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight. ;)

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Jarod Wilson]

On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:

> lirc@bartelmus.de (Christoph Bartelmus) writes:
> 
>> I'm not sure what two ways you are talking about. With the patches posted  
>> by Jarod, nothing has to be changed in userspace.
>> Everything works, no code needs to be written and tested, everybody is  
>> happy.
> 
> The existing drivers use input layer. Do you want part of the tree to
> use existing lirc interface while the other part uses their own
> in-kernel (badly broken for example) code to do precisely the same
> thing?

Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct?

Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.

> We can have a good code for both, or we can end up with "badly broken"
> media drivers and incompatible, suboptimal existing lirc interface
> (though most probably much better in terms of quality, especially after
> Jarod's work).

Well, is there any reason most of those drivers with currently-in-kernel-but-badly-broken decoding can't be converted to use the lirc interface if its merged into the kernel? And/or, everything could converge on a new in-kernel decoding infra that wasn't badly broken. Sure, there may be two separate ways of doing essentially the same thing for a while, but meh. The lirc way works NOW for an incredibly wide variety of receivers, transmitters, IR protocols, etc.

I do concur that Just Works decoding for bundled remotes w/o having to configure anything would be nice, and one way to go about doing that certainly is via in-kernel IR decoding. But at the same time, the second you want to use something other than a bundled remote, things fall down, and having to do a bunch of setkeycode ops seems less optimal than simply dropping an appropriate lircd.conf in place.

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Devin Heitmueller]

On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
> Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct?
>
> Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.

This is one of the key use cases I would be very concerned with.  For
many users who have bought tuner products, the bundled remotes work
"out-of-the-box", regardless of whether lircd is installed.  I have no
objection so much as to saying "well, you have to install the lircd
service now", but there needs to be a way for the driver to
automatically tell lirc what the default remote control should be, to
avoid a regression in functionality.  We cannot go from a mode where
it worked automatically to a mode where now inexperienced users now
have to deal with the guts of getting lircd properly configured.

If such an interface were available, I would see to it that at least
all the devices I have added RC support for will continue to work
(converting the in-kernel RC profiles to lirc RC profiles as needed
and doing the associations with the driver).

The other key thing I don't think we have given much thought to is the
fact that in many tuners, the hardware does RC decoding and just
returns NEC/RC5/RC6 codes.  And in many of those cases, the hardware
has to be configured to know what format to receive.  We probably need
some kernel API such that the hardware can tell lirc what formats are
supported, and another API call to tell the hardware which mode to
operate in.

This is why I think we really should put together a list of use cases,
so that we can see how any given proposal addresses those use cases.
I offered to do such, but nobody seemed really interested in this.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

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

[Krzysztof Halasa]

Jarod Wilson <jarod@wilsonet.com> writes:

> Ah, but the approach I'd take to converting to in-kernel decoding[*]
> would be this:
>
> 1) bring drivers in in their current state
>    - users keep using lirc as they always have
>
> 2) add in-kernel decoding infra that feeds input layer

Well. I think the above is fine enough.

> 3) add option to use in-kernel decoding to existing lirc drivers
>    - users can keep using lirc as they always have
>    - users can optionally try out in-kernel decoding via a modparam
>
> 4) switch the default mode from lirc decode to kernel decode for each lirc driver
>    - modparam can be used to continue using lirc interface instead
>
> 5) assuming users aren't coming at us with pitchforks, because things don't actually work reliably with in-kernel decoding, deprecate the lirc interface in driver
>
> 6) remove lirc interface from driver, its now a pure input device

But 3-6 are IMHO not useful. We don't need lirc _or_ input. We need
both at the same time: input for the general, simple case and for
consistency with receivers decoding in firmware/hardware; input for
special cases such as mapping the keys, protocols not supported by the
kernel and so on (also for in-tree media drivers where applicable).

> [*] assuming, of course, that it was actually agreed upon that
> in-kernel decoding was the right way, the only way, all others will be
> shot on sight. ;)

I think: in-kernel decoding only as the general, primary means. Not the
only one.
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Jarod Wilson <jarod@wilsonet.com> writes:

> Took me a minute to figure out exactly what you were talking about.
> You're referring to the current in-kernel decoding done on an ad-hoc
> basis for assorted remotes bundled with capture devices, correct?

Yes.

> Well, is there any reason most of those drivers with
> currently-in-kernel-but-badly-broken decoding can't be converted to
> use the lirc interface if its merged into the kernel?

For many of them "lirc mode" can be easily _added_.
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Devin Heitmueller <dheitmueller@kernellabs.com> writes:

> The other key thing I don't think we have given much thought to is the
> fact that in many tuners, the hardware does RC decoding and just
> returns NEC/RC5/RC6 codes.  And in many of those cases, the hardware
> has to be configured to know what format to receive.  We probably need
> some kernel API such that the hardware can tell lirc what formats are
> supported, and another API call to tell the hardware which mode to
> operate in.

For such cases, I wouldn't bother with lirc mode. Input layer + key
mapping with ioctl (probably improved), and lircd can grab events from
input layer if needed.
-- 
Krzysztof Halasa

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

[Gerd Hoffmann]

On 11/25/09 19:20, Devin Heitmueller wrote:
> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<jarod@wilsonet.com>
> wrote:
>> Took me a minute to figure out exactly what you were talking
>> about. You're referring to the current in-kernel decoding done on
>> an ad-hoc basis for assorted remotes bundled with capture devices,
>> correct?
>>
>> Admittedly, unifying those and the lirc driven devices hasn't
>> really been on my radar.

I think at the end of the day we'll want to have all IR drivers use the
same interface.  The way the current in-kernel input layer drivers work
obviously isn't perfect too, so we *must* consider both worlds to get a
good solution for long-term ...

> This is one of the key use cases I would be very concerned with. For
> many users who have bought tuner products, the bundled remotes work
> "out-of-the-box", regardless of whether lircd is installed.

I bet this simply isn't going to change.

> I have no objection so much as to saying "well, you have to install
> the lircd service now", but there needs to be a way for the driver to
>  automatically tell lirc what the default remote control should be,
> to avoid a regression in functionality.

*Requiring* lircd for the current in-kernel drivers doesn't make sense
at all.  Allowing lircd being used so it can do some more advanced stuff 
makes sense though.

> This is why I think we really should put together a list of use
> cases, so that we can see how any given proposal addresses those use
> cases. I offered to do such, but nobody seemed really interested in
> this.

Lets have a look at the problems the current input layer bits have 
compared to lirc:


(1) ir code (say rc5) -> keycode conversion looses information.

I think this can easily be addressed by adding a IR event type to the 
input layer, which could look like this:

   input_event->type  = EV_IR
   input_event->code  = IR_RC5
   input_event->value = <rc5 value>

In case the 32bit value is too small we might want send two events 
instead, with ->code being set to IR_<code>_1 and IR_<code>_2

Advantages:
   * Applications (including lircd) can get access to the unmodified
     rc5/rc6/... codes.
   * All the ir-code -> keycode mapping magic can be handled by the
     core input layer then.  All the driver needs to do is to pass on
     the information which keymap should be loaded by default (for the
     bundled remote if any).  The configuration can happen in userspace
     (sysfs attribute + udev + small utility in tools/ir/).
   * lirc drivers which get ir codes from the hardware can be converted
     to pure input layer drivers without regressions.  lircd is not
     required any more.


(2) input layer doesn't give access to the raw samples.

Not sure how to deal with that best.  Passing them through the input 
layer would certainly be possible to hack up.  But what would be the 
point?  The input layer wouldn't do any processing on them.  It wouldn't 
buy us much.  So we might want to simply stick with todays lirc 
interface for the raw samples.

Drivers which support both ir codes (be it by hardware or by in-kernel 
decoding) and raw samples would register two devices then, one input 
device and one lirc device.  It would probably a good idea to stop 
sending events to the input layer as soon as someone (most likely lircd) 
opens the lirc device to avoid keystrokes showing up twice.

By default the in-kernel bits will be at work, but optionally you can 
have lircd grab the raw samples and do fancy advanced decoding.


(3) input layer doesn't allow transmitting IR codes.

If we keep the lirc interface for raw samples anyway, then we can keep 
it for sending too, problem solved ;)  How does sending hardware work 
btw?  Do they all accept just raw samples?  Or does some hardware also 
accept ir-codes?

cheers,
   Gerd

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

[Christoph Bartelmus]

Hi Gerd,

on 25 Nov 09 at 22:58, Gerd Hoffmann wrote:
[...]
> (1) ir code (say rc5) -> keycode conversion looses information.
>
> I think this can easily be addressed by adding a IR event type to the
> input layer, which could look like this:
>
>    input_event->type  = EV_IR
>    input_event->code  = IR_RC5
>    input_event->value = <rc5 value>
>
> In case the 32bit value is too small we might want send two events
> instead, with ->code being set to IR_<code>_1 and IR_<code>_2
>
> Advantages:
>    * Applications (including lircd) can get access to the unmodified
>      rc5/rc6/... codes.

Unfortunately with most hardware decoders the code that you get is only  
remotely related to the actual code sent. Most RC-5 decoders strip off  
start bits. Toggle-bits are thrown away. NEC decoders usually don't pass  
through the address part. Some even generate some pseudo-random code  
(Irman). There is no common standard which bit is sent first, LSB or MSB.  
Checksums are thrown away.
To sum it up: I don't think this information will be useful at all for  
lircd or anyone else. Actually lircd does not even know anything about  
actual protocols. We only distinguish between certain protocol types, like  
Manchester encoded, space encoded, pulse encoded etc. Everything else like  
the actual timing is fully configurable.

[...]
> If we keep the lirc interface for raw samples anyway, then we can keep
> it for sending too, problem solved ;)  How does sending hardware work
> btw?  Do they all accept just raw samples?  Or does some hardware also
> accept ir-codes?

Usually raw samples in some form. I've never seen any device that would  
accept just ir-codes. UIRT2 devices have some more advanced modes but also  
accept raw samples.

Christoph

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

[Gerd Hoffmann]

>> (1) ir code (say rc5) ->  keycode conversion looses information.
>>
>> I think this can easily be addressed by adding a IR event type to the
>> input layer, which could look like this:
>>
>>     input_event->type  = EV_IR
>>     input_event->code  = IR_RC5
>>     input_event->value =<rc5 value>
>>
>> In case the 32bit value is too small we might want send two events
>> instead, with ->code being set to IR_<code>_1 and IR_<code>_2
>>
>> Advantages:
>>     * Applications (including lircd) can get access to the unmodified
>>       rc5/rc6/... codes.
>
> Unfortunately with most hardware decoders the code that you get is only
> remotely related to the actual code sent. Most RC-5 decoders strip off
> start bits.

I would include only the actual data bits in the payload anyway.

> Toggle-bits are thrown away. NEC decoders usually don't pass
> through the address part.

Too bad.  But information which isn't provided by the hardware can't be 
passed up anyway, no matter what kernel/userspace interface is used. 
Gone is gone.

> There is no common standard which bit is sent first, LSB or MSB.

Input layer would have to define a bit order.  And drivers which get it 
the other way from the hardware have to convert.  Or maybe signal the 
order and the input core then will convert if needed.

> Checksums are thrown away.

Don't include them.

> To sum it up: I don't think this information will be useful at all for
> lircd or anyone else.

Why not?  With RC5 remotes applications can get the device address bits 
for example, which right now are simply get lost in the ir code -> 
keycode conversion step.

> Actually lircd does not even know anything about
> actual protocols. We only distinguish between certain protocol types, like
> Manchester encoded, space encoded, pulse encoded etc. Everything else like
> the actual timing is fully configurable.

I know that lircd does matching instead of decoding, which allows to 
handle unknown encodings.  Thats why I think there will always be cases 
which only lircd will be able to handle (using raw samples).

That doesn't make attempts to actually decode the IR samples a useless 
exercise though ;)

cheers,
   Gerd

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

[Andy Walls]

On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote:
> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
> 
> > lirc@bartelmus.de (Christoph Bartelmus) writes:
> > 
> >> I'm not sure what two ways you are talking about. With the patches posted  
> >> by Jarod, nothing has to be changed in userspace.
> >> Everything works, no code needs to be written and tested, everybody is  
> >> happy.
> > 
> > The existing drivers use input layer. Do you want part of the tree to
> > use existing lirc interface while the other part uses their own
> > in-kernel (badly broken for example) code to do precisely the same
> > thing?
> 
> Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct?
> 
> Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.

It has been on mine.  I have been somewhat against the input subsystem
route for unification because it neglects transmitters and appears to
trade the userspace complexity we already have (i.e. LIRC configuration)
for another new (and hence less documented) configuration complexity for
end users.

My strategy for unification goes something like this:

1. Get lirc_dev and the needed supporting headers in the kernel.  I will
concede LIRC is not perfect or beautiful, but I'll assert it is feature
complete for all the end user use cases that matter.

2. Encapsulate all the various IR controller hardware handling in
V4L-DVB into v4l_subdevice objects and provide a uniform interface to IR
hardware internally via v4l2_subdev_ir_ops.  The exact nature of the IR
hardware is then mostly abstracted away: I2C bus microcontroller,
register block, GPIO line control of discretes devices, etc. can all be
accessed in a somewhat unifrom manner.

3. In conjunction with 2, common IR handling routines that exist in
various drivers already can be broken out: RC-5 protocol handling, etc.

4. Develop an internal interface so the v4l2_subdev object instance for
the IR hardware is exposed through a bridge driver's v4l2_device object.

5. Develop the needed layer between lirc_dev and the v4l2_device object
to connect things up.


That unifies all the IR cats and dogs in V4L-DVB at the low levels and
glues them in a consistent manner to something up top (i.e. lirc_dev)
that already handles Rx, Tx, protocols, keymapping, etc.

My primary desire is to encapsulate or remove the complexity we
currently have in kernel with all the ad-hoc IR hardware handling and
get it unifrom and layered.  

The upper level glue to userspace doesn't have to be lirc_dev, but why
not?  It's there and the end users are familiair with it.  I have
set-top boxes, I need IR Tx.



> > We can have a good code for both, or we can end up with "badly broken"
> > media drivers and incompatible, suboptimal existing lirc interface
> > (though most probably much better in terms of quality, especially after
> > Jarod's work).
> 
> Well, is there any reason most of those drivers with
> currently-in-kernel-but-badly-broken decoding can't be converted to
> use the lirc interface if its merged into the kernel? 

I think all the V4L-DVB IR hardware can be.  I have not done sufficient
research on the Serial, USB and other devices to say personally.


> And/or, everything could converge on a new in-kernel decoding infra
> that wasn't badly broken. Sure, there may be two separate ways of
> doing essentially the same thing for a while, but meh. The lirc way
> works NOW for an incredibly wide variety of receivers, transmitters,
> IR protocols, etc.

Also LIRC has had years of requirements collection and refinement of use
cases.  Anything new implementation will likely end up converging to the
feature set LIRC already has implemented.



> I do concur that Just Works decoding for bundled remotes w/o having to
> configure anything would be nice, and one way to go about doing that
> certainly is via in-kernel IR decoding. But at the same time, the
> second you want to use something other than a bundled remote, things
> fall down, and having to do a bunch of setkeycode ops seems less
> optimal than simply dropping an appropriate lircd.conf in place.


>From a big picture perspective I would never see the OS kenrel as a good
place to address usability issues.  It seems more logical to fix
usability issues with a decent GUI application and good documentation.
(LIRC needs a configuration GUI!).  Expecting IR usability problems to
be eased by the kernel and command line utilties is - well -
optimistic. 

I'll add that there are too many factors that can be permuted by the end
user and OEM -- protocols, remote layouts, button codes, PC IR Rx/Tx
hardware, and Set top boxes feeding PC video capture devices -- that
generating defaults that "Just Work" is a generally unsolvable problem.


Regards,
Andy

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

[Andy Walls]

On Wed, 2009-11-25 at 13:20 -0500, Devin Heitmueller wrote:
> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
> > Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct?
> >
> > Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.
> 
> This is one of the key use cases I would be very concerned with.  For
> many users who have bought tuner products, the bundled remotes work
> "out-of-the-box", regardless of whether lircd is installed.  I have no
> objection so much as to saying "well, you have to install the lircd
> service now", but there needs to be a way for the driver to
> automatically tell lirc what the default remote control should be, to
> avoid a regression in functionality.  We cannot go from a mode where
> it worked automatically to a mode where now inexperienced users now
> have to deal with the guts of getting lircd properly configured.
> 
> If such an interface were available, I would see to it that at least
> all the devices I have added RC support for will continue to work
> (converting the in-kernel RC profiles to lirc RC profiles as needed
> and doing the associations with the driver).
> 
> The other key thing I don't think we have given much thought to is the
> fact that in many tuners, the hardware does RC decoding and just
> returns NEC/RC5/RC6 codes.  And in many of those cases, the hardware
> has to be configured to know what format to receive.  We probably need
> some kernel API such that the hardware can tell lirc what formats are
> supported, and another API call to tell the hardware which mode to
> operate in.

Please think about how we would need to augment the v4l_subdev_ir_ops:

http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l246
http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l305
http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/include/media/v4l2-subdev.h#l27

I think encapsulation of the various IR devices under V4L-DVB into
v4l_subdevices can facilitate your suggestions.


The CX23888 IR subdevice code configures itself to a single default
setup for Tx and Rx:

http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23888-ir.c#l1192
http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23888-ir.c#l1211

but there isn't a reason V4L2 IR subdevices couldn't configure to a per
"product" defaults based on information about the detected card from the
main bridge driver code.

Regards,
Andy

> This is why I think we really should put together a list of use cases,
> so that we can see how any given proposal addresses those use cases.
> I offered to do such, but nobody seemed really interested in this.
> 
> Devin

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

[hermann pitton]

Am Mittwoch, den 25.11.2009, 22:31 -0500 schrieb Andy Walls:
> On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote:
> > On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
> > 
> > > lirc@bartelmus.de (Christoph Bartelmus) writes:
> > > 
> > >> I'm not sure what two ways you are talking about. With the patches posted  
> > >> by Jarod, nothing has to be changed in userspace.
> > >> Everything works, no code needs to be written and tested, everybody is  
> > >> happy.
> > > 
> > > The existing drivers use input layer. Do you want part of the tree to
> > > use existing lirc interface while the other part uses their own
> > > in-kernel (badly broken for example) code to do precisely the same
> > > thing?
> > 
> > Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct?
> > 
> > Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.
> 
> It has been on mine.  I have been somewhat against the input subsystem
> route for unification because it neglects transmitters and appears to
> trade the userspace complexity we already have (i.e. LIRC configuration)
> for another new (and hence less documented) configuration complexity for
> end users.
> 
> My strategy for unification goes something like this:
> 
> 1. Get lirc_dev and the needed supporting headers in the kernel.  I will
> concede LIRC is not perfect or beautiful, but I'll assert it is feature
> complete for all the end user use cases that matter.
> 
> 2. Encapsulate all the various IR controller hardware handling in
> V4L-DVB into v4l_subdevice objects and provide a uniform interface to IR
> hardware internally via v4l2_subdev_ir_ops.  The exact nature of the IR
> hardware is then mostly abstracted away: I2C bus microcontroller,
> register block, GPIO line control of discretes devices, etc. can all be
> accessed in a somewhat unifrom manner.
> 
> 3. In conjunction with 2, common IR handling routines that exist in
> various drivers already can be broken out: RC-5 protocol handling, etc.
> 
> 4. Develop an internal interface so the v4l2_subdev object instance for
> the IR hardware is exposed through a bridge driver's v4l2_device object.
> 
> 5. Develop the needed layer between lirc_dev and the v4l2_device object
> to connect things up.
> 
> 
> That unifies all the IR cats and dogs in V4L-DVB at the low levels and
> glues them in a consistent manner to something up top (i.e. lirc_dev)
> that already handles Rx, Tx, protocols, keymapping, etc.
> 
> My primary desire is to encapsulate or remove the complexity we
> currently have in kernel with all the ad-hoc IR hardware handling and
> get it unifrom and layered.  
> 
> The upper level glue to userspace doesn't have to be lirc_dev, but why
> not?  It's there and the end users are familiair with it.  I have
> set-top boxes, I need IR Tx.
> 
> 
> 
> > > We can have a good code for both, or we can end up with "badly broken"
> > > media drivers and incompatible, suboptimal existing lirc interface
> > > (though most probably much better in terms of quality, especially after
> > > Jarod's work).
> > 
> > Well, is there any reason most of those drivers with
> > currently-in-kernel-but-badly-broken decoding can't be converted to
> > use the lirc interface if its merged into the kernel? 
> 
> I think all the V4L-DVB IR hardware can be.  I have not done sufficient
> research on the Serial, USB and other devices to say personally.
> 
> 
> > And/or, everything could converge on a new in-kernel decoding infra
> > that wasn't badly broken. Sure, there may be two separate ways of
> > doing essentially the same thing for a while, but meh. The lirc way
> > works NOW for an incredibly wide variety of receivers, transmitters,
> > IR protocols, etc.
> 
> Also LIRC has had years of requirements collection and refinement of use
> cases.  Anything new implementation will likely end up converging to the
> feature set LIRC already has implemented.
> 
> 
> 
> > I do concur that Just Works decoding for bundled remotes w/o having to
> > configure anything would be nice, and one way to go about doing that
> > certainly is via in-kernel IR decoding. But at the same time, the
> > second you want to use something other than a bundled remote, things
> > fall down, and having to do a bunch of setkeycode ops seems less
> > optimal than simply dropping an appropriate lircd.conf in place.
> 
> 
> >From a big picture perspective I would never see the OS kenrel as a good
> place to address usability issues.  It seems more logical to fix
> usability issues with a decent GUI application and good documentation.
> (LIRC needs a configuration GUI!).  Expecting IR usability problems to
> be eased by the kernel and command line utilties is - well -
> optimistic. 
> 
> I'll add that there are too many factors that can be permuted by the end
> user and OEM -- protocols, remote layouts, button codes, PC IR Rx/Tx
> hardware, and Set top boxes feeding PC video capture devices -- that
> generating defaults that "Just Work" is a generally unsolvable problem.
> 
> 
> Regards,
> Andy
> 

It has something that seemingly can be discussed endlessly.

By all good pros and cons, it takes much too long to see anything
forthcoming soon.

To remind, we had eleven 2.6.x test kernels, nothing on lirc came even
close to it, and on 2.6.6 some first sign of life again ... IIRC.

Including 2.5.x, how long is that?

By all sympathy, it was a big peace of crap for much too long, simply
ignoring the kernel development, and I don't have any tears for it
getting dropped that time.

We _need_ to live without it, that is the only reason for the IR input
layer in kernel, and not any other way round.

Gerd can of course tell better, but that is how I have it and there was
a lot of work because of such lamers not coming by in time then.

Cheers,
Hermann

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

[Andy Walls]

On Wed, 2009-11-25 at 22:58 +0100, Gerd Hoffmann wrote:
> On 11/25/09 19:20, Devin Heitmueller wrote:
> > On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<jarod@wilsonet.com>
> > wrote:
> >> Took me a minute to figure out exactly what you were talking
> >> about. You're referring to the current in-kernel decoding done on
> >> an ad-hoc basis for assorted remotes bundled with capture devices,
> >> correct?
> >>
> >> Admittedly, unifying those and the lirc driven devices hasn't
> >> really been on my radar.
> 
> I think at the end of the day we'll want to have all IR drivers use the
> same interface.  The way the current in-kernel input layer drivers work
> obviously isn't perfect too, so we *must* consider both worlds to get a
> good solution for long-term ...
> 
> > This is one of the key use cases I would be very concerned with. For
> > many users who have bought tuner products, the bundled remotes work
> > "out-of-the-box", regardless of whether lircd is installed.
> 
> I bet this simply isn't going to change.
> 
> > I have no objection so much as to saying "well, you have to install
> > the lircd service now", but there needs to be a way for the driver to
> >  automatically tell lirc what the default remote control should be,
> > to avoid a regression in functionality.
> 
> *Requiring* lircd for the current in-kernel drivers doesn't make sense
> at all.  Allowing lircd being used so it can do some more advanced stuff 
> makes sense though.
> 
> > This is why I think we really should put together a list of use
> > cases, so that we can see how any given proposal addresses those use
> > cases. I offered to do such, but nobody seemed really interested in
> > this.
> 
> Lets have a look at the problems the current input layer bits have 
> compared to lirc:
> 
> 
> (1) ir code (say rc5) -> keycode conversion looses information.
> 
> I think this can easily be addressed by adding a IR event type to the 
> input layer, which could look like this:
> 
>    input_event->type  = EV_IR
>    input_event->code  = IR_RC5
>    input_event->value = <rc5 value>
> 
> In case the 32bit value is too small we might want send two events 
> instead, with ->code being set to IR_<code>_1 and IR_<code>_2

RC-6 Mode 6A can be up to 67 bits:

http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm

(This page is slightly wrong, there is some data coded in the header
such as the RC-6 Mode, but I can't remeber if it's biphase or not.)

> Advantages:
>    * Applications (including lircd) can get access to the unmodified
>      rc5/rc6/... codes.
>    * All the ir-code -> keycode mapping magic can be handled by the
>      core input layer then.  All the driver needs to do is to pass on
>      the information which keymap should be loaded by default (for the
>      bundled remote if any).  The configuration can happen in userspace
>      (sysfs attribute + udev + small utility in tools/ir/).
>    * lirc drivers which get ir codes from the hardware can be converted
>      to pure input layer drivers without regressions.  lircd is not
>      required any more.
> 
> (2) input layer doesn't give access to the raw samples.
> 
> Not sure how to deal with that best.  Passing them through the input 
> layer would certainly be possible to hack up.  But what would be the 
> point?  The input layer wouldn't do any processing on them.  It wouldn't 
> buy us much.  So we might want to simply stick with todays lirc 
> interface for the raw samples.
> 
> Drivers which support both ir codes (be it by hardware or by in-kernel 
> decoding) and raw samples would register two devices then, one input 
> device and one lirc device.  It would probably a good idea to stop 
> sending events to the input layer as soon as someone (most likely lircd) 
> opens the lirc device to avoid keystrokes showing up twice.
> 
> By default the in-kernel bits will be at work, but optionally you can 
> have lircd grab the raw samples and do fancy advanced decoding.

(2a) Input layer doesn't help with raw samples:

So now what about devices that don't produce codes at all, but simply
pulse width measurements?  Where's the infrastrucutre to perform low
pass filtering to get rid of glitches and to perform oversampling to
deal with pulse jitter, so that adding a new IR device isn't a pain
incurred per driver?

I was quite dismayed at how much I had to reimplement here, just for
RC-5 for the sake of the input layer and having a remote "Just Work":

http://linuxtv.org/hg/v4l-dvb/file/74ad936bcca2/linux/drivers/media/video/cx23885/cx23885-input.c

lirc does all that stuff in spades.


> (3) input layer doesn't allow transmitting IR codes.
> 
> If we keep the lirc interface for raw samples anyway, then we can keep 
> it for sending too, problem solved ;)  How does sending hardware work 
> btw?  Do they all accept just raw samples?  Or does some hardware also 
> accept ir-codes?

The Conexant chips' integrated IR Tx hardware expects a series of pulse
widths and a flag for mark or space with each width.

I'd have to research other implementations.

Regards,
Andy

> cheers,
>    Gerd

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

[Jarod Wilson]

On Nov 25, 2009, at 2:27 PM, Krzysztof Halasa wrote:

> Jarod Wilson <jarod@wilsonet.com> writes:
> 
>> Ah, but the approach I'd take to converting to in-kernel decoding[*]
>> would be this:
>> 
>> 1) bring drivers in in their current state
>>   - users keep using lirc as they always have
>> 
>> 2) add in-kernel decoding infra that feeds input layer
> 
> Well. I think the above is fine enough.
> 
>> 3) add option to use in-kernel decoding to existing lirc drivers
>>   - users can keep using lirc as they always have
>>   - users can optionally try out in-kernel decoding via a modparam
>> 
>> 4) switch the default mode from lirc decode to kernel decode for each lirc driver
>>   - modparam can be used to continue using lirc interface instead
>> 
>> 5) assuming users aren't coming at us with pitchforks, because things don't actually work reliably with in-kernel decoding, deprecate the lirc interface in driver
>> 
>> 6) remove lirc interface from driver, its now a pure input device
> 
> But 3-6 are IMHO not useful. We don't need lirc _or_ input. We need
> both at the same time: input for the general, simple case and for
> consistency with receivers decoding in firmware/hardware; input for
> special cases such as mapping the keys, protocols not supported by the
> kernel and so on (also for in-tree media drivers where applicable).
> 
>> [*] assuming, of course, that it was actually agreed upon that
>> in-kernel decoding was the right way, the only way, all others will be
>> shot on sight. ;)
> 
> I think: in-kernel decoding only as the general, primary means. Not the
> only one.

Okay, I read ya now. I got my wires crossed, thought you were advocating for dropping the lirc interface entirely. I think we're on the same page then. :)

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Dmitry Torokhov]

On Mon, Nov 23, 2009 at 09:51:31PM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> 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.
> 

In what way the key interface is unsufficient for delivering button
events?

-- 
Dmitry

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

[Dmitry Torokhov]

On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
>>> Mauro Carvalho Chehab<mchehab@redhat.com>  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)...
>
> Its the cases like programmable universal remotes that really throw  
> things for a loop. That, and people wanting to use random remote X that  
> came with the amp or tv or set top box, with IR receiver Y.

Right, but still the keys usually do have the well-defined meaning, teh
issue is in mapping raw code to the appropriate keycode. This can be
done either by lirc config file (when lirc is used) or by some other
means.

> ...
>>> 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.
>
> Current lircd actually inter-operates with the input subsystem quite  
> well for any and all supported remotes if their keys are mapped in their  
> respective lircd.conf file using standard input subsystem key names, and  
> the lirc daemon started with the --uinput param. lircd decodes the raw  
> IR, finds the mapping in its config, and happily passes it along to 
> uinput.

Right.

I guess the question is what is the interface we want the regular
userspace (i.e. not lircd) to use. Right now programs has to use 2
intercfaces - one lirc for dealing with remotes that are not using
the standard event interface and evdev for remotes using it as well
as the rest of the input devices.

-- 
Dmitry

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

[Jarod Wilson]

On Nov 25, 2009, at 10:31 PM, Andy Walls wrote:

> On Wed, 2009-11-25 at 13:07 -0500, Jarod Wilson wrote:
>> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
>> 
>>> lirc@bartelmus.de (Christoph Bartelmus) writes:
>>> 
>>>> I'm not sure what two ways you are talking about. With the patches posted  
>>>> by Jarod, nothing has to be changed in userspace.
>>>> Everything works, no code needs to be written and tested, everybody is  
>>>> happy.
>>> 
>>> The existing drivers use input layer. Do you want part of the tree to
>>> use existing lirc interface while the other part uses their own
>>> in-kernel (badly broken for example) code to do precisely the same
>>> thing?
>> 
>> Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct?
>> 
>> Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.
> 
> It has been on mine.  I have been somewhat against the input subsystem
> route for unification because it neglects transmitters and appears to
> trade the userspace complexity we already have (i.e. LIRC configuration)
> for another new (and hence less documented) configuration complexity for
> end users.
> 
> My strategy for unification goes something like this:
> 
> 1. Get lirc_dev and the needed supporting headers in the kernel.  I will
> concede LIRC is not perfect or beautiful, but I'll assert it is feature
> complete for all the end user use cases that matter.

So... What I'd like to propose is that I address Mauro's review comments for my v2 patchset, and resubmit a v3 patchset. If there are no show-stoppers, lets get the thing merged. If people don't want to use it, they don't have to, I won't be offended. But it seems there are quite a few people that would be incredibly happy to see this finally get in. There are definitely worse things that could be merged. :)

And from what I've been able to surmise, the input layer would need so much new functionality to handle both raw IR output and IR transmit, that we'd simply be reinventing a hefty chunk of the lirc device interface under the guise of being an input device, to be used *only* by things that can already simply use the existing feature-complete lirc device interface, which seems... wasteful.


> 2. Encapsulate all the various IR controller hardware handling in
> V4L-DVB into v4l_subdevice objects and provide a uniform interface to IR
> hardware internally via v4l2_subdev_ir_ops.  The exact nature of the IR
> hardware is then mostly abstracted away: I2C bus microcontroller,
> register block, GPIO line control of discretes devices, etc. can all be
> accessed in a somewhat unifrom manner.
> 
> 3. In conjunction with 2, common IR handling routines that exist in
> various drivers already can be broken out: RC-5 protocol handling, etc.

Once 1 happens, I'd be happy to work on adding code to currently pure lirc device drivers (like lirc_mceusb) to do in-kernel decoding for their bundled remotes. The vague plan in my head (shamelessly heisted from someone else in this thread, can't remember who atm) involves each lirc device registering two devices, one input device and one lirc device. Out of the box, without lircd, they would operate as a pure input device with their bundled remote -- out-of-the-box bliss. Once lircd opened the device's lirc device, we'd stop sending input data, and feed data out via the lirc interface.

This hybrid approach gives those who want nothing to do with lircd and the lirc device interface what they want (hell, drivers might even be buildable w/o the lirc portion even enabled), and those that want more flexibility can use either/or.


> 4. Develop an internal interface so the v4l2_subdev object instance for
> the IR hardware is exposed through a bridge driver's v4l2_device object.
> 
> 5. Develop the needed layer between lirc_dev and the v4l2_device object
> to connect things up.
> 
> 
> That unifies all the IR cats and dogs in V4L-DVB at the low levels and
> glues them in a consistent manner to something up top (i.e. lirc_dev)
> that already handles Rx, Tx, protocols, keymapping, etc.
> 
> My primary desire is to encapsulate or remove the complexity we
> currently have in kernel with all the ad-hoc IR hardware handling and
> get it unifrom and layered.  
> 
> The upper level glue to userspace doesn't have to be lirc_dev, but why
> not?  It's there and the end users are familiair with it.  I have
> set-top boxes, I need IR Tx.

Yup, me too. :)


>>> We can have a good code for both, or we can end up with "badly broken"
>>> media drivers and incompatible, suboptimal existing lirc interface
>>> (though most probably much better in terms of quality, especially after
>>> Jarod's work).
>> 
>> Well, is there any reason most of those drivers with
>> currently-in-kernel-but-badly-broken decoding can't be converted to
>> use the lirc interface if its merged into the kernel? 
> 
> I think all the V4L-DVB IR hardware can be.  I have not done sufficient
> research on the Serial, USB and other devices to say personally.

Which serial and/or usb devices other than those already supported by lirc drivers did you have in mind? Damn near all the serial and usb IR devices I know of are already supported by either another lirc kernel driver I have laying in wait, or by a userspace driver (typically interfacing w/a usb receiver using libusb).


>> And/or, everything could converge on a new in-kernel decoding infra
>> that wasn't badly broken. Sure, there may be two separate ways of
>> doing essentially the same thing for a while, but meh. The lirc way
>> works NOW for an incredibly wide variety of receivers, transmitters,
>> IR protocols, etc.
> 
> Also LIRC has had years of requirements collection and refinement of use
> cases.  Anything new implementation will likely end up converging to the
> feature set LIRC already has implemented.

Yep, I suspect as much myself. The only major feature I'm aware of that lirc hasn't already implemented is zero-config, works-out-of-the-box, really.


>> I do concur that Just Works decoding for bundled remotes w/o having to
>> configure anything would be nice, and one way to go about doing that
>> certainly is via in-kernel IR decoding. But at the same time, the
>> second you want to use something other than a bundled remote, things
>> fall down, and having to do a bunch of setkeycode ops seems less
>> optimal than simply dropping an appropriate lircd.conf in place.
> 
> 
>> From a big picture perspective I would never see the OS kenrel as a good
> place to address usability issues.  It seems more logical to fix
> usability issues with a decent GUI application and good documentation.
> (LIRC needs a configuration GUI!).

gnome-lirc-properties attempts to be that, but needs a lot more love, and isn't actually part of the lirc userspace source, its maintained by some gnome folks on freedesktop.org, iirc...


> Expecting IR usability problems to
> be eased by the kernel and command line utilties is - well -
> optimistic. 
> 
> I'll add that there are too many factors that can be permuted by the end
> user and OEM -- protocols, remote layouts, button codes, PC IR Rx/Tx
> hardware, and Set top boxes feeding PC video capture devices -- that
> generating defaults that "Just Work" is a generally unsolvable problem.

Agreed. *Especially* with IR TX in the mix, which a LOT of DVR users rely heavily upon -- we have no way of divining what the hell IR codes a random set top box needs. And the bulk of bundled remotes we can make Just Work are flimsy, crappy, cheap plastic pieces of junk. No self-respecting HTPC user actually uses any of those things. ;)

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Dmitry Torokhov]

On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> > 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.
> 
> I agree with Christoph.  
> 
> Is it that the input subsystem is better developed and seen as a
> leverage point for development and thus an "easier" place to get results
> earlier?  If so, then one should definitely deal with transmitters early
> in the design, as that is where the most unknowns lie.
> 
> With the end of analog TV, people will have STBs feeding analog only
> video cards.  Being able to change the channel on the STB with an IR
> transmitter controlled by applications like MythTV is essential.
> 
> 
> And on some different notes:
> 
> I generally don't understand the LIRC aversion I perceive in this thread
> (maybe I just have a skewed perception).  Aside for a video card's
> default remote setup, the suggestions so far don't strike me as any
> simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
> already works for both transmit and receive and has existing support in
> applications such as MythTV and mplayer.

Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are
forced to support lirc because the remores are not available through
other means? I believe it is the latter and applications writers would
be happy to reduce number of ways they get button data.

I don't think there is LIRC aversion per se. We are just trying to
decide whether multiple interfaces for the same data is needed. And
I don't think that we will completely reject userspace components. Just
as input subsystem allows for userspace drivers I do not think why we
can't have the same for the LIRC. But I do think that the primary
interface for regular userspace consumers (read mplayer and MythTV and
the likes) should be input event interface (EV_KEY/KEY_*).

-- 
Dmitry

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

[Jarod Wilson]

On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:

> On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
>> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
>>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
>>>> Mauro Carvalho Chehab<mchehab@redhat.com>  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)...
>> 
>> Its the cases like programmable universal remotes that really throw  
>> things for a loop. That, and people wanting to use random remote X that  
>> came with the amp or tv or set top box, with IR receiver Y.
> 
> Right, but still the keys usually do have the well-defined meaning,

Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean.

> teh
> issue is in mapping raw code to the appropriate keycode. This can be
> done either by lirc config file (when lirc is used) or by some other
> means.

The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too.

>> ...
>>>> 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.
>> 
>> Current lircd actually inter-operates with the input subsystem quite  
>> well for any and all supported remotes if their keys are mapped in their  
>> respective lircd.conf file using standard input subsystem key names, and  
>> the lirc daemon started with the --uinput param. lircd decodes the raw  
>> IR, finds the mapping in its config, and happily passes it along to 
>> uinput.
> 
> Right.
> 
> I guess the question is what is the interface we want the regular
> userspace (i.e. not lircd) to use. Right now programs has to use 2
> intercfaces - one lirc for dealing with remotes that are not using
> the standard event interface and evdev for remotes using it as well
> as the rest of the input devices.

>From the mythtv perspective, using the input layer could yield a better out-of-the-box experience -- users don't have to set up an lircrc mapping that converts key names as specified in lircd.conf into commands (key strokes, actually) that mythtv understands. For example, a button labeled "Play" in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right thing with it. If everything came through the input layer, be that natively or via lircd's uinput reinjection, there would be no need to do that extra mapping step, mythtv would simply handle a KEY_PLAY event. So at worst, one manual mapping to do -- IR signal to standard button name in lircd.conf -- instead of two. But the lircrc approach does also allow more flexibility, in that you can only have a certain app respond to a certain key, if so desired, and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, KEY_YELLOW -- what should their default functionality be? I know some users map a pair of those to mythtv's "skip to next commflag point" and "skip to prior commflag point").

Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., etc. at all right now, it operates purely on keys commonly found on a standard keyboard. Remedying that is on my TODO list for the next release, if I can carve out the time.

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Jarod Wilson]

On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote:

> On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
>>> 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.
>> 
>> I agree with Christoph.  
>> 
>> Is it that the input subsystem is better developed and seen as a
>> leverage point for development and thus an "easier" place to get results
>> earlier?  If so, then one should definitely deal with transmitters early
>> in the design, as that is where the most unknowns lie.
>> 
>> With the end of analog TV, people will have STBs feeding analog only
>> video cards.  Being able to change the channel on the STB with an IR
>> transmitter controlled by applications like MythTV is essential.
>> 
>> 
>> And on some different notes:
>> 
>> I generally don't understand the LIRC aversion I perceive in this thread
>> (maybe I just have a skewed perception).  Aside for a video card's
>> default remote setup, the suggestions so far don't strike me as any
>> simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
>> already works for both transmit and receive and has existing support in
>> applications such as MythTV and mplayer.
> 
> Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are
> forced to support lirc because the remores are not available through
> other means? I believe it is the latter and applications writers would
> be happy to reduce number of ways they get button data.

Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. serial receivers and transmitters, both supported by lirc_serial, were the most frequently used devices outside of plain old keyboards. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that...

> I don't think there is LIRC aversion per se. We are just trying to
> decide whether multiple interfaces for the same data is needed. And
> I don't think that we will completely reject userspace components. Just
> as input subsystem allows for userspace drivers I do not think why we
> can't have the same for the LIRC. But I do think that the primary
> interface for regular userspace consumers (read mplayer and MythTV and
> the likes) should be input event interface (EV_KEY/KEY_*).

Works for me.


-- 
Jarod Wilson
jarod@wilsonet.com

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

[Christoph Bartelmus]

Hi Gerd,

on 26 Nov 09 at 00:22, Gerd Hoffmann wrote:
[...]
>> To sum it up: I don't think this information will be useful at all for
>> lircd or anyone else.
[...]
> I know that lircd does matching instead of decoding, which allows to
> handle unknown encodings.  Thats why I think there will always be cases
> which only lircd will be able to handle (using raw samples).
>
> That doesn't make attempts to actually decode the IR samples a useless
> exercise though ;)

Well, in my opinion it is kind of useless. I don't see any use case or any  
demand for passing this kind of information to userspace, at least in the  
LIRC context.
If there's no demand, why bother?

Christoph

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

[Christoph Bartelmus]

Hi,

on 25 Nov 09 at 12:44, Jarod Wilson wrote:
[...]
> Ah, but the approach I'd take to converting to in-kernel decoding[*] would
> be this:
[...]
> [*] assuming, of course, that it was actually agreed upon that in-kernel
> decoding was the right way, the only way, all others will be shot on sight.

I'm happy to see that the discussion is getting along.
But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just  
because I'm not familiar at all with input layer toolset.

1. For sure in-kernel decoding will require some assistance from userspace  
to load the mapping from IR codes to keys. So, if there needs to be a tool  
in userspace that does some kind of autodetection, why not have a tool  
that does some autodetection and autoconfigures lircd for the current  
device. Lots of code duplication in kernel saved. What's the actual  
benefit of in-kernel decoding?

2. What would be the format of the key map? lircd.conf files already exist  
for a lot of remote controls. Will we have a second incompatible format to  
map the keys in-kernel? Where are the tools that create the key maps for  
new remotes?

Maybe someone can shed some light on this.

Christoph

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

[Dmitry Torokhov]

On Thu, Nov 26, 2009 at 09:01:00AM +0100, Christoph Bartelmus wrote:
> Hi,
> 
> on 25 Nov 09 at 12:44, Jarod Wilson wrote:
> [...]
> > Ah, but the approach I'd take to converting to in-kernel decoding[*] would
> > be this:
> [...]
> > [*] assuming, of course, that it was actually agreed upon that in-kernel
> > decoding was the right way, the only way, all others will be shot on sight.
> 
> I'm happy to see that the discussion is getting along.
> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just  
> because I'm not familiar at all with input layer toolset.
> 
> 1. For sure in-kernel decoding will require some assistance from userspace  
> to load the mapping from IR codes to keys. So, if there needs to be a tool  
> in userspace that does some kind of autodetection, why not have a tool  
> that does some autodetection and autoconfigures lircd for the current  
> device. Lots of code duplication in kernel saved. What's the actual  
> benefit of in-kernel decoding?

Why are you mixing configuration and decoding? Configuration I expect
will be done with the help of userspace. Udev is probably the best
place.

> 
> 2. What would be the format of the key map? lircd.conf files already exist  
> for a lot of remote controls. Will we have a second incompatible format to  
> map the keys in-kernel? Where are the tools that create the key maps for  
> new remotes?
> 

Same as the keymaps for the other input devices I'd expect.

> Maybe someone can shed some light on this.
> 
> Christoph

-- 
Dmitry

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

[Gerd Hoffmann]

On 11/26/09 08:28, Christoph Bartelmus wrote:
> Hi Gerd,
>
> on 26 Nov 09 at 00:22, Gerd Hoffmann wrote:
> [...]
>>> To sum it up: I don't think this information will be useful at all for
>>> lircd or anyone else.
> [...]
>> I know that lircd does matching instead of decoding, which allows to
>> handle unknown encodings.  Thats why I think there will always be cases
>> which only lircd will be able to handle (using raw samples).
>>
>> That doesn't make attempts to actually decode the IR samples a useless
>> exercise though ;)
>
> Well, in my opinion it is kind of useless. I don't see any use case or any
> demand for passing this kind of information to userspace, at least in the
> LIRC context.
> If there's no demand, why bother?

There have been complains about this getting lost somewhere in this 
thread, so it looks like there are people which do care.

cheers,
   Gerd

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

[Gerd Hoffmann]

On 11/26/09 07:23, Jarod Wilson wrote:
> Well, when mythtv was started, I don't know that there were many
> input layer remotes around... lirc was definitely around though.

lirc predates the input layer IR drivers by years, maybe even the input 
layer itself.

The main reason for the input layer IR drivers appearing was lirc not 
being mainline.  A in-kernel driver (bttv in that case) which depends on 
a out-of-tree subsystem for IR support was simply a pain in the ass for 
both maintainer (/me back then) and users.

At least for IR hardware which allows access to the raw samples it 
certainly makes sense to support lirc, additional to the current (or 
improved) input layer support.

> The lirc support in mythtv actually relies on mapping remote button
> names as defined in lircd.conf to keyboard key strokes. As mentioned
> elsewhere in this beast of a thread, mythtv doesn't currently support
> things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but
> I intend on fixing that...

lircd can handle the input layer as input as well, so you actually can 
remap things via lircd even for pure input layer drivers.  mythtv 
handling KEY_VOLUMEUP directly would be more elegant though.

cheers,
   Gerd

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> 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.

This is a current limitation, since the saa713x code converts the RC5 code into a 7bits
scancode, by applying a mask. One of the reasons for that conversion is that the two 
ioctls that allows reading/changing the keycode table (EVIOCSKEYCODE and EVIOCGKEYCODE)
were implemented via a table with a fixed size of 128 entries.

We already have an implementation at the dvb-usb driver that uses a table without
such limits, where the IR scancode is completely stored there. So, you can create
any arbitrary scancode <--> keycode table there.

Technically, it is not hard to port this solution to the other drivers, but the issue
is that we don't have all those IR's to know what is the complete scancode that
each key produces. So, the hardest part is to find a way for doing it without
causing regressions, and to find a group of people that will help testing the new way.

Maybe one alternative would be to add a modprobe parameter at the converted drivers
to allow them to work with the old behavior, after their migration.

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

There are 3 different situations:
	1) hardware where you can support multiple protocols at the same time;
	2) hardware that supports one programmable protocol;
	3) hardware that support just one (or a limited set) of protocols.

In general, (1) applies only to those devices that outputs a raw pulse/space code,
where they just connect the IR sensor to a generic I/O pin and let the software
to decode the code. This is the case of most of cheapest devices. Yet, you can
find some cheap devices with low-cost micro-controllers with a dedicated firmware
on its ROM, doing (2).

The most commonly found hardware, in general have a chip to decode IR pulse/space
sequences, converting it on a scancode and implementing (3).

That's said, a raw input interface, only fits on case (1). On the other hand, the
existing input API works for all types of IR. However, we need to add the ioctls
to allow protocol selection, to better handle (1) and (3).

Cheers,
Mauro.

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

[Andy Walls]

On Thu, 2009-11-26 at 01:23 -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote:
> 
> > On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote:
> >> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> >>> 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.
> >> 
> >> I agree with Christoph.  
> >> 
> >> Is it that the input subsystem is better developed and seen as a
> >> leverage point for development and thus an "easier" place to get results
> >> earlier?  If so, then one should definitely deal with transmitters early
> >> in the design, as that is where the most unknowns lie.
> >> 
> >> With the end of analog TV, people will have STBs feeding analog only
> >> video cards.  Being able to change the channel on the STB with an IR
> >> transmitter controlled by applications like MythTV is essential.
> >> 
> >> 
> >> And on some different notes:
> >> 
> >> I generally don't understand the LIRC aversion I perceive in this thread
> >> (maybe I just have a skewed perception).  Aside for a video card's
> >> default remote setup, the suggestions so far don't strike me as any
> >> simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
> >> already works for both transmit and receive and has existing support in
> >> applications such as MythTV and mplayer.
> > 
> > Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are
> > forced to support lirc because the remores are not available through
> > other means? I believe it is the latter and applications writers would
> > be happy to reduce number of ways they get button data.
> 
> Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. serial receivers and transmitters, both supported by lirc_serial, were the most frequently used devices outside of plain old keyboards. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that...
> 
> > I don't think there is LIRC aversion per se. We are just trying to
> > decide whether multiple interfaces for the same data is needed. And
> > I don't think that we will completely reject userspace components. Just
> > as input subsystem allows for userspace drivers I do not think why we
> > can't have the same for the LIRC. But I do think that the primary
> > interface for regular userspace consumers (read mplayer and MythTV and
> > the likes) should be input event interface (EV_KEY/KEY_*).
> 
> Works for me.

Even though two interfaces is a bit of "extra" work, I'm not averse to
Gerd's suggestions of a dual implementation: input layer for the simple,
common use case, and lirc type interface for more sophisticated usage.

One thing I would like to be provided by the input layer is automatic
key-up after a specified time.  Remote protocols send an initial button
press and then after a certain amount of time (~115 ms for RC-5) send a
repeated code or repeat sequence, if the button is still pressed.
Currently, most of the V4L-DVB drivers have some code to perform a
timeout just to send the key-up event.  That's a good bit of redundant
code for key-up timeouts that I suspect makes sense for the input layer
to handle.

Regards,
Andy

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> 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?

lircd supports input layer interface. Yet, patch 3/3 exports both devices
that support only pulse/space raw mode and devices that generate scan
codes via the raw mode interface. It does it by generating artificial
pulse codes.
> 
>> 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.

It sounds an interesting idea.

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

Yet, both are RC5. This can already be handled by the input layer.
See dvb-usb implementation.

The issue I see is to support at the same time NEC and RC5 protocols. While
this may work with some devices, for others, the hardware won't allow.

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

This may work for protocols up to RC5, that uses either 8 or 16 bits.
However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits
for a scancode. So, we don't have spare bits to represent a protocol, 
if we consider RC6 mode 6 codes as well.

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

See above. Also, several protocols have a way to check if a keystroke were
properly received. When handling just one protocol, we can use this to double
check the key. However, on a multiprotocol mode, we'll need to disable this
feature.

PS.: For those following those discussions that want to know more about
IR protocols, a good reference is at:
	http://www.sbprojects.com/knowledge/ir/ir.htm

Unfortunately, it doesn't describe RC6 mode 6.

Cheers,
Mauro.

Re: [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]

Andy Walls wrote:

> I generally don't understand the LIRC aversion I perceive in this thread
> (maybe I just have a skewed perception). 

> Regards,
> Andy "LIRC Fan-Boy" Walls

This is not a lirc love or hate thread. We're simply discussing the better
API's for IR, from the technical standpoint, considering that some users 
may want to use lirc and some users may want to have their IR working 
out-of-the-box.

By not using lirc, users will loose the advantages of having lircd, like clicking
on a button and calling automatically the DVD player application, but this means
that their device with the shipped IR will work without needing to do any setup.

Whatever we do, both kind of usages should be possible, since there are demand
for both.

Also, the decision should consider that the existing drivers will need to
support the new way without causing regressions.

Cheers,
Mauro.

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

[Andy Walls]

On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Mauro Carvalho Chehab <mchehab@redhat.com> writes:


> PS.: For those following those discussions that want to know more about
> IR protocols, a good reference is at:
> 	http://www.sbprojects.com/knowledge/ir/ir.htm
> 
> Unfortunately, it doesn't describe RC6 mode 6.

RC-6 Mode 0 and Mode 6A is briefly describe here:

http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm

That page is slightly wrong, as there is some data coded in the header
such as the RC-6 Mode.

This page is an older version of the sbprojects.com RC-6 page, before
the information on RC-6 Mode 6A was removed:

http://slycontrol.ru/scr/kb/rc6.htm


My personal opinion is that, for non-technical reasons, RC-6 Mode 6A
decoding should not be included in the kernel.  That's why I didn't do
it for the HVR-1850/CX23888.


Regards,
Andy

Re: [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]

Andy Walls wrote:
> On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
>> lirc@bartelmus.de (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?
> 
> The underlying hardware need not be completely independent.
> 
> For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
> chips have IR hardware that shares a common timing source, interrupt
> line, interrupt status register, etc, between IR Rx and Tx.  They can
> also do things like loopback of Tx to Rx.
> 
> That said, an underlying hardware implementation can be split up to user
> space with separate interfaces Tx and Rx.  The underlying driver module
> would have to manage the dependencies.  I would guess that would be
> easier for driver modules, if the userspace interfaces were designed
> with such combined IR Tx/Rx hardware in mind.

True, but, in the case of Rx, there are already API's for it. Tx case is
simpler, as we don't have any API for it yet.

I'm not sure if all the existing hardware for TX currently supports only
raw pulse/code sequencies, but I still think that, even on the Tx case, 
it is better to send scancodes to the driver, and let it do the conversion
to raw pulse/code, if the hardware requires pulse/code instead of scancodes. 

However, as we have green field,
I would add the protocol explicitly for each scancode to be transmitted, like:

struct ir_tx {
	enum ir_protocol proto;
	u32 scancode;
};

Eventually, we might have a protocol "raw" and some extra field to allow passing
a raw pulse/code sequence instead of a scancode.

Cheers,
Mauro.

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

[Andy Walls]

On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
> >> lirc@bartelmus.de (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?
> > 
> > The underlying hardware need not be completely independent.
> > 
> > For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
> > chips have IR hardware that shares a common timing source, interrupt
> > line, interrupt status register, etc, between IR Rx and Tx.  They can
> > also do things like loopback of Tx to Rx.
> > 
> > That said, an underlying hardware implementation can be split up to user
> > space with separate interfaces Tx and Rx.  The underlying driver module
> > would have to manage the dependencies.  I would guess that would be
> > easier for driver modules, if the userspace interfaces were designed
> > with such combined IR Tx/Rx hardware in mind.
> 
> True, but, in the case of Rx, there are already API's for it. Tx case is
> simpler, as we don't have any API for it yet.
> 
> I'm not sure if all the existing hardware for TX currently supports only
> raw pulse/code sequencies, but I still think that, even on the Tx case, 
> it is better to send scancodes to the driver, and let it do the conversion
> to raw pulse/code, if the hardware requires pulse/code instead of scancodes. 

That seems like a decision which will create a lots of duplicative code
in the kernel.  Add it's just busy-work to write such code when a
userspace application in common use already handles the protocols and
sends raw pulses to hardware that expects raw pulses.

> However, as we have green field,
> I would add the protocol explicitly for each scancode to be transmitted, like:
> 
> struct ir_tx {
> 	enum ir_protocol proto;
> 	u32 scancode;
> };
> 
> Eventually, we might have a protocol "raw" and some extra field to allow passing
> a raw pulse/code sequence instead of a scancode.

I think you would have to.  32 bits is really not enough for all
protocols, and it is already partial encoding of information anyway.

If the Tx driver has to break them down into pulses anyway, why not have
fields with more meaningful names

	mode
	toggle
	customer code (or system code or address),
	information (or command)

According to

	http://slycontrol.ru/scr/kb/rc6.htm

the "information" field could be up to 128 bits.

(Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
kernel.)		

Regards,
Andy

> Cheers,
> Mauro.

Re: [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]

Jarod Wilson wrote:
> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
> 
>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> ...
>> I generally don't understand the LIRC aversion I perceive in this thread
>> (maybe I just have a skewed perception).  Aside for a video card's
>> default remote setup, the suggestions so far don't strike me as any
>> simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
>> already works for both transmit and receive and has existing support in
>> applications such as MythTV and mplayer.
> 
> There's one gripe I agree with, and that is that its still not plug-n-play. 
> Something where udev auto-loads a sane default remote config for say, 
> mceusb transceivers, and the stock mce remote Just Works would be nice, 
> but auto-config is mostly out the window the second you involve transmitters 
> and universal remotes anyway. 

For several devices, an udev rule that auto-loads a sane default keymap does work.
Of course, this won't cover 100% of the usages, and I lirc is a very good way
of covering the holes.

> But outside of that, I think objections are largely philosophical -- 
> in a nutshell, the kernel has an input layer, remotes are input devices, 
> and lirc doesn't conform to input layer standards. 

Yes. I think this is mainly the issue. 

The other issue is how to migrate the existing drivers to a new API without 
causing regressions. If we decide that IR's that receive raw pulse/code
should use the raw input interface, this means that a large task force will be
needed to convert the existing drivers to use it.

> I do understand that argument, I just don't currently agree that all IR must
> go through the input layer before the drivers are acceptable for upstream -- 
> especially since lircd can reinject decoded key presses into the input layer via uinput.

IMHO, there are some scenarios for an upcoming kernel IR raw input interface:

1) as a temporary solution for merging lirc drivers, knowing in advance that it will
be later converted to the standard input API;

2) as a raw interface for some weird usages, with its usage limited to just a
few device drivers;

3) as the solution for all IR's that produces pulse/code raw sequences;

For (1), while it may make sense, we'll be creating an userspace API that is
meant to be stable, knowing in advance that it will be removed in a close
future.

IMHO, we should avoid (2), since it will be hard to define what is the "limited
usage", and I bet that it will evolute to (3) in a long term.

For (3), we need to consider the migration of the existing drivers.

By discarding scenario (2), this means that, in the long term, we'll need to either
migrate all existing out-of-tree lirc drivers to the standard input API interface 
(scenario 1) or to migrate the existing drivers to the raw input interface (scenario 3).

For me, scenario (1) is fine if we add the lirc drivers at drivers/staging.

>> I believe Jarod's intent is to have the LIRC components, that need to be
>> in kernel modules, moved into kernel mainline to avoid the headaches of
>> out of kernel driver maintenance.  I'm not sure it is time well spent
>> for developers, or end users, to develop yet another IR receive
>> implementation in addition to the ones we suffer with now.
> 
> Yeah, a fairly relevant factor in all this is that, despite not being in the linux 
> kernel source tree proper-like, the lirc drivers and lirc have been in use for many
> years by lots of users. The likes of Fedora, Debian, Ubuntu, SUSE, Mandriva, etc. 
> have all been shipping lirc drivers for years now. While lirc certainly isn't 
> perfect (its not always the easiest thing for users to set up), it has actually 
> proven itself pretty robust and useful in the field, once set up. The bulk of 
> breakage in lirc I've personally had to deal with has mostly come in the 
> form of kernel interface changes, which would definitely be mitigated by 
> not having to maintain the drivers out-of-tree any longer.
> 
> Now, I'm all for "improving" things and integrating better with the input 
> subsystem, but what I don't really want to do is break compatibility with the 
> existing setups on thousands (and thousands?) of MythTV boxes around the globe. 
> The lirc userspace can be pretty nimble. If we can come up with a shiny new way 
> that raw IR can be passed out through an input device, I'm pretty sure lirc 
> userspace can be adapted to handle that. If a new input-layer-based transmit 
> interface is developed, we can take advantage of that too. But there's already 
> a very mature lirc interface for doing all of this. So why not start with adding 
> things more or less as they exist right now and evolve the drivers into an 
> idealized form? Getting *something* into the kernel in the first place is a 
> huge step in that direction.

I agree. We should really move forward and add it to kernel as soon as possible,
and start to work on improving the IR support at the upstream kernel.

Jarold,

What do you think of adding lirc at staging while we discuss/improve the API's and lircd
support for the input event interface? Do you think this would work?

Cheers,
Mauro.

Re: [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]

Krzysztof Halasa wrote:
> Andy Walls <awalls@radix.net> writes:
> 
>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>> developed by Philips, but Microsoft has some sort of licensing interest
>> in it and it is almost surely encumbered somwhow:
> 
> I don't know about legal problems in some countries but from the
> technical POV handling the protocol in the kernel is more efficient
> or (/and) simpler.

A software licensing from Microsoft won't apply to Linux kernel, so I'm
assuming that you're referring to some patent that they could be filled
about RC6 mode 6A.

I don't know if is there any US patent pending about it (AFAIK, only US
accepts software patents), but there are some prior-art for IR key
decoding. So, I don't see what "innovation" RC6 would be adding. 
If it is some new way to transmit waves, the patent issues
aren't related to software, and the device manufacturer had already handled
it when they made their devices. If it is just a new keytable, this issue 
could be easily solved by loading the keytable via userspace.

Also, assuming that you can use the driver only with a hardware that comes
with a licensed software, the user has already the license for using it.

Do you have any details on what patents they are claiming?

Cheers,
Mauro.

Re: [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]

Jarod Wilson wrote:
> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
> 
>> lirc@bartelmus.de (Christoph Bartelmus) writes:
>>
>>> I'm not sure what two ways you are talking about. With the patches posted  
>>> by Jarod, nothing has to be changed in userspace.
>>> Everything works, no code needs to be written and tested, everybody is  
>>> happy.
>> The existing drivers use input layer. Do you want part of the tree to
>> use existing lirc interface while the other part uses their own
>> in-kernel (badly broken for example) code to do precisely the same
>> thing?
> 
> Took me a minute to figure out exactly what you were talking about. You're referring to the
> current in-kernel decoding done on an ad-hoc basis for assorted remotes 
> bundled with capture devices, correct?

They are not limited to the currently bundled IR's, since almost all drivers allow
replacing the existing scancode/keycode table to a new onw.

> Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.

It should be done. Having two ways for doing the same thing is not an option. We'll
need to unify them sooner or later. The sooner, the better.

>> We can have a good code for both, or we can end up with "badly broken"
>> media drivers and incompatible, suboptimal existing lirc interface
>> (though most probably much better in terms of quality, especially after
>> Jarod's work).
> 
> Well, is there any reason most of those drivers with 
> currently-in-kernel-but-badly-broken decoding can't be converted to
> use the lirc interface if its merged into the kernel?

> And/or, everything
> could converge on a new in-kernel decoding infra that wasn't badly broken.
> Sure, there may be two separate ways of doing essentially the same thing
> for a while, but meh. The lirc way works NOW for an incredibly wide
> variety of receivers, transmitters, IR protocols, etc.

Yes: the same drivers support both pulse/space and in-hardware scancode conversion.
In order to use the raw pulse/space API, they'll need to generate pseudo pulse/space's.
This would be a dirty solution, IMHO.

Also, changing the drivers would not be that easy, since it will require lots of
tests with IR's and devices that the developers won't have. This is a weaker argument,
since no matter what decided, we'll need to change the drivers code (on lirc drivers
or on the in-kernel drivers) even without having all hardware available.

> I do concur that Just Works decoding for bundled remotes w/o having to 
> configure anything would be nice, and one way to go about doing that 
> certainly is via in-kernel IR decoding. But at the same time, the second
> you want to use something other than a bundled remote, things fall down, 
> and having to do a bunch of setkeycode ops seems less optimal than simply 
> dropping an appropriate lircd.conf in place.

I don't see this as an issue. We have by far too much work to be done in kernelspace
than the changes that are needed on userspace.

Replace the entire scancode table with setkeycode ops is very fast, and needs to be
done only once, at lirc startup. Once you load the new IR code at the driver,
the kernel will send the new keycodes to lirc.

It doesn't seem hard to modify lirc to do read the lircd.conf table and replace the
IR scancodes at the in-kernel driver. It took me half an hour to write my own keycode
loader code, and you can use it as the basis for such feature:
	http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c


Cheers,
Mauro.

Re: [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]

Gerd Hoffmann wrote:
> On 11/25/09 19:20, Devin Heitmueller wrote:
>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<jarod@wilsonet.com>
>> wrote:
>>> Took me a minute to figure out exactly what you were talking
>>> about. You're referring to the current in-kernel decoding done on
>>> an ad-hoc basis for assorted remotes bundled with capture devices,
>>> correct?
>>>
>>> Admittedly, unifying those and the lirc driven devices hasn't
>>> really been on my radar.
> 
> I think at the end of the day we'll want to have all IR drivers use the
> same interface.  The way the current in-kernel input layer drivers work
> obviously isn't perfect too, so we *must* consider both worlds to get a
> good solution for long-term ...
> 
>> This is one of the key use cases I would be very concerned with. For
>> many users who have bought tuner products, the bundled remotes work
>> "out-of-the-box", regardless of whether lircd is installed.
> 
> I bet this simply isn't going to change.
> 
>> I have no objection so much as to saying "well, you have to install
>> the lircd service now", but there needs to be a way for the driver to
>>  automatically tell lirc what the default remote control should be,
>> to avoid a regression in functionality.
> 
> *Requiring* lircd for the current in-kernel drivers doesn't make sense
> at all.  Allowing lircd being used so it can do some more advanced stuff
> makes sense though.
> 
>> This is why I think we really should put together a list of use
>> cases, so that we can see how any given proposal addresses those use
>> cases. I offered to do such, but nobody seemed really interested in
>> this.
> 
> Lets have a look at the problems the current input layer bits have
> compared to lirc:
> 
> 
> (1) ir code (say rc5) -> keycode conversion looses information.
> 
> I think this can easily be addressed by adding a IR event type to the
> input layer, which could look like this:
> 
>   input_event->type  = EV_IR
>   input_event->code  = IR_RC5
>   input_event->value = <rc5 value>

Agreed. We're doing this already with some drivers (dvb-usb ones). I've
started working on a patchset to extend this to the remaining drivers.
I'm not sure whare were already merged from this tree, but my intention
is to extend this to all drivers.

> In case the 32bit value is too small we might want send two events
> instead, with ->code being set to IR_<code>_1 and IR_<code>_2

Well, RC6 mode 6 uses 32 bits. I don't know if is there any case for
more than 32 bits. However, on some I2C IR chips, we see some cases
where the IR scancode key is encapsulated into some protocol with more
bytes. It seems that those extra bytes are used to handle key repetition
sort of events. I'm not sure if it would make sense to pass the raw 
data to userspace. Probably not.

> Advantages:
>   * Applications (including lircd) can get access to the unmodified
>     rc5/rc6/... codes.
>   * All the ir-code -> keycode mapping magic can be handled by the
>     core input layer then.  All the driver needs to do is to pass on
>     the information which keymap should be loaded by default (for the
>     bundled remote if any).  The configuration can happen in userspace
>     (sysfs attribute + udev + small utility in tools/ir/).

I like the idea of such small utility to load the keymap table.

>   * lirc drivers which get ir codes from the hardware can be converted
>     to pure input layer drivers without regressions.  lircd is not
>     required any more.
> 
> 
> (2) input layer doesn't give access to the raw samples.
> 
> Not sure how to deal with that best.  Passing them through the input
> layer would certainly be possible to hack up.  But what would be the
> point?  The input layer wouldn't do any processing on them.  It wouldn't
> buy us much.  So we might want to simply stick with todays lirc
> interface for the raw samples.

If we need such interface, the better is to keep using the lirc interface.
Yet, I'm not sure if we should really keep outputing raw samples, since
several devices won't support it.

> Drivers which support both ir codes (be it by hardware or by in-kernel
> decoding) and raw samples would register two devices then, one input
> device and one lirc device.  It would probably a good idea to stop
> sending events to the input layer as soon as someone (most likely lircd)
> opens the lirc device to avoid keystrokes showing up twice.
> 
> By default the in-kernel bits will be at work, but optionally you can
> have lircd grab the raw samples and do fancy advanced decoding.
> 
> 
> (3) input layer doesn't allow transmitting IR codes.
> 
> If we keep the lirc interface for raw samples anyway, then we can keep
> it for sending too, problem solved ;)  How does sending hardware work
> btw?  Do they all accept just raw samples?  Or does some hardware also
> accept ir-codes?

I would do it in a way that it will accept scancodes and raw samples, 
since, even if we currently have only devices that accept raw samples, 
it would be more future-proof to allow sending scancodes also.

Cheers,
Mauro

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

[Jon Smirl]

On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Gerd Hoffmann wrote:
>> On 11/25/09 19:20, Devin Heitmueller wrote:
>>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<jarod@wilsonet.com>
>>> wrote:
>>>> Took me a minute to figure out exactly what you were talking
>>>> about. You're referring to the current in-kernel decoding done on
>>>> an ad-hoc basis for assorted remotes bundled with capture devices,
>>>> correct?
>>>>
>>>> Admittedly, unifying those and the lirc driven devices hasn't
>>>> really been on my radar.
>>
>> I think at the end of the day we'll want to have all IR drivers use the
>> same interface.  The way the current in-kernel input layer drivers work
>> obviously isn't perfect too, so we *must* consider both worlds to get a
>> good solution for long-term ...

I made an attempt at implementing all of this a year ago.
http://lkml.org/lkml/2008/11/5/233

All of this kernel code is tiny, about 20K including a driver.

Basic flow works like this:

Add a new IR data type to the input framework
http://lkml.org/lkml/2008/11/5/234

Example mceusb IR input driver
http://lkml.org/lkml/2008/11/5/238

In-kernel decoding of core IR protocols - RC5, RC6, etc
http://lkml.org/lkml/2008/11/5/234

Decoded core protocols pass through a translation map based on configfs
When core protocol matches an entry in configfs it is turned into a
keycode event.
http://lkml.org/lkml/2008/11/5/235

You make a directory in /configfs/remotes for each remote you have.
Making the directory creates a new evdev device.  Under the directory
make an entry for each command generated by the device. These entries
cause the decoded IR data to be mapped into keycodes on the new evdev
device. udev would load these configfs mappings at boot time...

mkdir /config/remotes/sony
 -- this creates a new evdev device
mkdir remotes/sony/one
echo 7 >remotes/sony/one/protocol
echo 264 >remotes/sony/one/command
echo 2 >remotes/sony/one/keycode

This transforms a button push of 1 on my remote into a key stroke for KEY_1

 *   configfs root
 *   --remotes
 *   ----specific remote
 *   ------keymap
 *   --------protocol
 *   --------device
 *   --------command
 *   --------keycode
 *   ------repeat keymaps
 *   --------....
 *   ----another remote
 *   ------more keymaps

You can map the 1 button from multiple remotes to KEY_1 if you want. Or
you can use a single remote to create multiple virtual keyboards.

-------------------------

Raw IR pulse data is available in a FIFO via sysfs. You can use this
to figure out new remote protocols.

Two input events are generated
1) an event for the decoded raw IR protocol
2) a keycode event if thedecoded raw IR protocol matches an entry in
the configfs

You can also send pulses.

------

If you want to script this, you would have a user space task that
watches for either the decoded IR codes or the mapped keycodes.

This system also works with user space device drivers. They can inject
input events into the early event flow and they will get processed as
if the event originated in the kernel.

---------------------

Sure you could push the protocol decoding code (RC5, etc) into user
space. Seems like a lot of hassle to move about 3KB of code out of the
kernel.


-- 
Jon Smirl
jonsmirl@gmail.com

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

[Jon Smirl]

BTW, we used to have device specific user space interfaces for mouse
and keyboard. These caused all sort of problems. A lot of work went
into unifying them under evdev.  It will be years until the old,
messed up interfaces can be totally removed.

I'm not in favor of repeating the problems with a device specific user
space interface for IR. I believe all new input devices should
implement the evdev framework.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [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]

Jarod Wilson wrote:

>> I guess the question is what is the interface we want the regular
>> userspace (i.e. not lircd) to use. Right now programs has to use 2
>> intercfaces - one lirc for dealing with remotes that are not using
>> the standard event interface and evdev for remotes using it as well
>> as the rest of the input devices.
> 
> From the mythtv perspective, using the input layer could yield a better
> out-of-the-box experience -- users don't have to set up an lircrc mapping
> that converts key names as specified in lircd.conf into commands 
> (key strokes, actually) that mythtv understands. For example, a button labeled "Play"
> in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right 
> thing with it. If everything came through the input layer, be that natively
> or via lircd's uinput reinjection, there would be no need to do that extra 
> mapping step, mythtv would simply handle a KEY_PLAY event. So at worst, 
> one manual mapping to do -- IR signal to standard button name in lircd.conf -- 
> instead of two. But the lircrc approach does also allow more flexibility, 
> in that you can only have a certain app respond to a certain key, if so desired, 
> and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, KEY_YELLOW
>  -- what should their default functionality be? I know some users map a pair
> of those to mythtv's "skip to next commflag point" and "skip to prior commflag point").
> 
> Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., etc. at 
> all right now, it operates purely on keys commonly found on a standard keyboard.
> Remedying that is on my TODO list for the next release, if I can carve out the time.

This discussion is a little OT from the API discussions, since it affects both out-of-the
box IR reception via input layer and lirc.

All media applications should be capable of handling the corresponding KEY_PLAY, KEY_VOLUMEUP ...
keys without needing to do anything else than just handling the corresponding keycode.
You shouldn't need to start a daemon or doing anything else for this to work out-of-the-box.

They currently don't do it due to historic reasons (it is easier to let something else
remap KEY_PLAY into 'p' than to add the proper code there).

When using non-hot-pluggable devices where you're building a dedicated MCE hardware (this 
is the common case of MythTV setups), things are not that bad, since, once you set your
hardware, it is done.

However, by looking on the number of different new devices, it seems that the most common 
type of devices are the TV USB sticks. As they are hot pluggable, eventually users may 
have more than one hardware and they expect that the IR layer will work equally on
all your devices.

The proper way for supporting it is to have a common application-agnostic keycode to indicate
the received events. For example, all IR's should produce KEY_CHANNELUP/KEY_CHANNELDOWN events
for changing the channels. Also, on a perfect world, lirc should send this event to the
multimedia application that handles TV when such key is pressed, instead of converting into
some other keycode. This prevents future problems if, for some reason, the application needs to
do something else with that key, or if the key has a different meaning on some different contexts.

For example, on some applications, KEY_UP/KEY_DOWN can mean to change a channel, but those keys
are also used for menu navigation. However, KEY_CHANNELUP has a clear unique meaning: to change a channel. 
The expected behavior, from users perspective, is to mimic a TV box, where if you press channel UP
any open menu will be closed and the channel will be changed, but pressing UP key will
navigate at the menu. Well, if you map KEY_CHANNELUP as KEY_UP, you'll produce a different behavior.

Cheers,
Mauro.

Re: [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]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

Christoph Bartelmus wrote:
> Hi,
> 
> on 25 Nov 09 at 12:44, Jarod Wilson wrote:
> [...]
>> Ah, but the approach I'd take to converting to in-kernel decoding[*] would
>> be this:
> [...]
>> [*] assuming, of course, that it was actually agreed upon that in-kernel
>> decoding was the right way, the only way, all others will be shot on sight.
> 
> I'm happy to see that the discussion is getting along.
> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just  
> because I'm not familiar at all with input layer toolset.
> 
> 1. For sure in-kernel decoding will require some assistance from userspace  
> to load the mapping from IR codes to keys.

Current drivers have the IR keycode tables in-kernel also, directly associated
with the board ID.

> So, if there needs to be a tool  
> in userspace that does some kind of autodetection, why not have a tool  
> that does some autodetection and autoconfigures lircd for the current  
> device.

There are userspace tools to change the IR keycode maps. It shouldn't be hard to
change it to autodetect the hardware and to autoconfigure lircd.

> Lots of code duplication in kernel saved. 

Huh? The code is already there.

> What's the actual benefit of in-kernel decoding?

There are two benefits:

1) the developer that adds the hardware also adds the IR code. He has the hardware
and the IR for testing, so it means a faster development cycle than waiting for someone
else with the same hardware and IR to recode it on some other place. You should
remember that not all developers use lirc;

2) the IR works out of the box.

> 2. What would be the format of the key map? lircd.conf files already exist  
> for a lot of remote controls. Will we have a second incompatible format to  
> map the keys in-kernel? Where are the tools that create the key maps for  
> new remotes?

No matter what tool you use, the format should be very close: scancode -> key_code.

If you wan to take a look on a real example, I'm enclosing the keycode table used by
dib0700 driver, as generated/readed by a simple keycode application I made to test
the dynamic keycode loading:
	http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c

Most of the keycodes there are RC5 keys. There are also some NEC keys,
as those devices can work with either RC5 or NEC keycodes, by using a different
parameter during module load.

In the case of this driver, the pulse/space is done in hardware by the DibCom chip. The
scancode is sent to PC via the USB interface.

I hope it helps for you to better understand how this works.

Cheers,
Mauro.

[-- Attachment #2: dib0700_rc_keys --]
[-- Type: text/plain, Size: 3541 bytes --]

0x0700 KEY_MUTE
0x0701 KEY_MENU
0x0739 KEY_POWER
0x0703 KEY_VOLUMEUP
0x0709 KEY_VOLUMEDOWN
0x0706 KEY_CHANNELUP
0x070c KEY_CHANNELDOWN
0x070f KEY_1
0x0715 KEY_2
0x0710 KEY_3
0x0718 KEY_4
0x071b KEY_5
0x071e KEY_6
0x0711 KEY_7
0x0721 KEY_8
0x0712 KEY_9
0x0727 KEY_0
0x0724 KEY_SCREEN
0x072a KEY_TEXT
0x072d KEY_REWIND
0x0730 KEY_PLAY
0x0733 KEY_FASTFORWARD
0x0736 KEY_RECORD
0x073c KEY_STOP
0x073f KEY_CANCEL
0xeb01 KEY_POWER
0xeb02 KEY_1
0xeb03 KEY_2
0xeb04 KEY_3
0xeb05 KEY_4
0xeb06 KEY_5
0xeb07 KEY_6
0xeb08 KEY_7
0xeb09 KEY_8
0xeb0a KEY_9
0xeb0b KEY_VIDEO
0xeb0c KEY_0
0xeb0d KEY_REFRESH
0xeb0f KEY_EPG
0xeb10 KEY_UP
0xeb11 KEY_LEFT
0xeb12 KEY_OK
0xeb13 KEY_RIGHT
0xeb14 KEY_DOWN
0xeb16 KEY_INFO
0xeb17 KEY_RED
0xeb18 KEY_GREEN
0xeb19 KEY_YELLOW
0xeb1a KEY_BLUE
0xeb1b KEY_CHANNELUP
0xeb1c KEY_VOLUMEUP
0xeb1d KEY_MUTE
0xeb1e KEY_VOLUMEDOWN
0xeb1f KEY_CHANNELDOWN
0xeb40 KEY_PAUSE
0xeb41 KEY_HOME
0xeb42 KEY_MENU
0xeb43 KEY_SUBTITLE
0xeb44 KEY_TEXT
0xeb45 KEY_DELETE
0xeb46 KEY_TV
0xeb47 KEY_DVD
0xeb48 KEY_STOP
0xeb49 KEY_VIDEO
0xeb4a KEY_AUDIO
0xeb4b KEY_SCREEN
0xeb4c KEY_PLAY
0xeb4d KEY_BACK
0xeb4e KEY_REWIND
0xeb4f KEY_FASTFORWARD
0xeb54 KEY_PREVIOUS
0xeb58 KEY_RECORD
0xeb5c KEY_NEXT
0x1e00 KEY_0
0x1e01 KEY_1
0x1e02 KEY_2
0x1e03 KEY_3
0x1e04 KEY_4
0x1e05 KEY_5
0x1e06 KEY_6
0x1e07 KEY_7
0x1e08 KEY_8
0x1e09 KEY_9
0x1e0a KEY_KPASTERISK
0x1e0b KEY_RED
0x1e0c KEY_RADIO
0x1e0d KEY_MENU
0x1e0e KEY_GRAVE
0x1e0f KEY_MUTE
0x1e10 KEY_VOLUMEUP
0x1e11 KEY_VOLUMEDOWN
0x1e12 KEY_CHANNEL
0x1e14 KEY_UP
0x1e15 KEY_DOWN
0x1e16 KEY_LEFT
0x1e17 KEY_RIGHT
0x1e18 KEY_VIDEO
0x1e19 KEY_AUDIO
0x1e1a KEY_MEDIA
0x1e1b KEY_EPG
0x1e1c KEY_TV
0x1e1e KEY_NEXT
0x1e1f KEY_BACK
0x1e20 KEY_CHANNELUP
0x1e21 KEY_CHANNELDOWN
0x1e24 KEY_LAST
0x1e25 KEY_OK
0x1e29 KEY_BLUE
0x1e2e KEY_GREEN
0x1e30 KEY_PAUSE
0x1e32 KEY_REWIND
0x1e34 KEY_FASTFORWARD
0x1e35 KEY_PLAY
0x1e36 KEY_STOP
0x1e37 KEY_RECORD
0x1e38 KEY_YELLOW
0x1e3b KEY_GOTO
0x1e3d KEY_POWER
0x0042 KEY_POWER
0x077c KEY_TUNER
0x0f4e KEY_PRINT
0x0840 KEY_SCREEN
0x0f71 KEY_DOT
0x0743 KEY_0
0x0c41 KEY_1
0x0443 KEY_2
0x0b7f KEY_3
0x0e41 KEY_4
0x0643 KEY_5
0x097f KEY_6
0x0d7e KEY_7
0x057c KEY_8
0x0a40 KEY_9
0x0e4e KEY_CLEAR
0x047c KEY_CHANNEL
0x0f41 KEY_LAST
0x0342 KEY_MUTE
0x064c KEY_RESERVED
0x0172 KEY_SHUFFLE
0x0c4e KEY_PLAYPAUSE
0x0b70 KEY_RECORD
0x037d KEY_VOLUMEUP
0x017d KEY_VOLUMEDOWN
0x0242 KEY_CHANNELUP
0x007d KEY_CHANNELDOWN
0x1d00 KEY_0
0x1d01 KEY_1
0x1d02 KEY_2
0x1d03 KEY_3
0x1d04 KEY_4
0x1d05 KEY_5
0x1d06 KEY_6
0x1d07 KEY_7
0x1d08 KEY_8
0x1d09 KEY_9
0x1d0a KEY_TEXT
0x1d0d KEY_MENU
0x1d0f KEY_MUTE
0x1d10 KEY_VOLUMEUP
0x1d11 KEY_VOLUMEDOWN
0x1d12 KEY_CHANNEL
0x1d14 KEY_UP
0x1d15 KEY_DOWN
0x1d16 KEY_LEFT
0x1d17 KEY_RIGHT
0x1d1c KEY_TV
0x1d1e KEY_NEXT
0x1d1f KEY_BACK
0x1d20 KEY_CHANNELUP
0x1d21 KEY_CHANNELDOWN
0x1d24 KEY_LAST
0x1d25 KEY_OK
0x1d30 KEY_PAUSE
0x1d32 KEY_REWIND
0x1d34 KEY_FASTFORWARD
0x1d35 KEY_PLAY
0x1d36 KEY_STOP
0x1d37 KEY_RECORD
0x1d3b KEY_GOTO
0x1d3d KEY_POWER
0x8613 KEY_MUTE
0x8612 KEY_POWER
0x8601 KEY_1
0x8602 KEY_2
0x8603 KEY_3
0x8604 KEY_4
0x8605 KEY_5
0x8606 KEY_6
0x8607 KEY_7
0x8608 KEY_8
0x8609 KEY_9
0x8600 KEY_0
0x860d KEY_CHANNELUP
0x8619 KEY_CHANNELDOWN
0x8610 KEY_VOLUMEUP
0x860c KEY_VOLUMEDOWN
0x860a KEY_CAMERA
0x860b KEY_ZOOM
0x861b KEY_BACKSPACE
0x8615 KEY_ENTER
0x861d KEY_UP
0x861e KEY_DOWN
0x860e KEY_LEFT
0x860f KEY_RIGHT
0x8618 KEY_RECORD
0x861a KEY_STOP
0x7a00 KEY_MENU
0x7a01 KEY_RECORD
0x7a02 KEY_PLAY
0x7a03 KEY_STOP
0x7a10 KEY_CHANNELUP
0x7a11 KEY_CHANNELDOWN
0x7a12 KEY_VOLUMEUP
0x7a13 KEY_VOLUMEDOWN
0x7a40 KEY_POWER
0x7a41 KEY_MUTE

Re: [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]

Andy Walls wrote:
> On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:

>> I'm not sure if all the existing hardware for TX currently supports only
>> raw pulse/code sequencies, but I still think that, even on the Tx case, 
>> it is better to send scancodes to the driver, and let it do the conversion
>> to raw pulse/code, if the hardware requires pulse/code instead of scancodes. 
> 
> That seems like a decision which will create a lots of duplicative code
> in the kernel.  Add it's just busy-work to write such code when a
> userspace application in common use already handles the protocols and
> sends raw pulses to hardware that expects raw pulses.

I don't see how this would create lots of duplicative code.

>> However, as we have green field,
>> I would add the protocol explicitly for each scancode to be transmitted, like:
>>
>> struct ir_tx {
>> 	enum ir_protocol proto;
>> 	u32 scancode;
>> };
>>
>> Eventually, we might have a protocol "raw" and some extra field to allow passing
>> a raw pulse/code sequence instead of a scancode.
> 
> I think you would have to.  32 bits is really not enough for all
> protocols, and it is already partial encoding of information anyway.
> 
> If the Tx driver has to break them down into pulses anyway, 

Do all Tx drivers need handle pulse by pulse, or there are some that works
only with scancodes?

> why not have fields with more meaningful names
> 
> 	mode
> 	toggle
> 	customer code (or system code or address),
> 	information (or command)
> 
> According to
> 
> 	http://slycontrol.ru/scr/kb/rc6.htm
> 
> the "information" field could be up to 128 bits.

Seems fine to me.

> (Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
> kernel.)		
> 
> Regards,
> Andy
> 
>> Cheers,
>> Mauro.
> 
> 

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

[Krzysztof Halasa]

Gerd Hoffmann <kraxel@redhat.com> writes:

> Why not?  With RC5 remotes applications can get the device address
> bits for example, which right now are simply get lost in the ir code
> -> 
> keycode conversion step.

Right, this in fact makes the input layer interface unusable for many
remotes at this time.
I think the address (aka group) should be just a part of the key
("command") code, IIRC this is what lirc RC5 does (I'm presently using
a custom "media" version of RC5).

> I know that lircd does matching instead of decoding, which allows to
> handle unknown encodings.  Thats why I think there will always be
> cases which only lircd will be able to handle (using raw samples).
>
> That doesn't make attempts to actually decode the IR samples a useless
> exercise though ;)

Sure. Especially RC5-like protos are simple to decode, and it's very
reliable, even with a very unstable remote clock source (such as
RC-based = resistor + capacitor).
-- 
Krzysztof Halasa

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

[Jarod Wilson]

On 11/26/2009 04:14 AM, Gerd Hoffmann wrote:
> On 11/26/09 07:23, Jarod Wilson wrote:
>> Well, when mythtv was started, I don't know that there were many
>> input layer remotes around... lirc was definitely around though.
>
> lirc predates the input layer IR drivers by years, maybe even the input
> layer itself.

That was my guess, but I didn't have a timeline in front of me. :)

> The main reason for the input layer IR drivers appearing was lirc not
> being mainline. A in-kernel driver (bttv in that case) which depends on
> a out-of-tree subsystem for IR support was simply a pain in the ass for
> both maintainer (/me back then) and users.
>
> At least for IR hardware which allows access to the raw samples it
> certainly makes sense to support lirc, additional to the current (or
> improved) input layer support.

I'm liking the idea of a hybrid approach, where IR devices can support 
both lirc and input device interfaces. I think its the most 
regression-proof for end-users, if done correctly, which is one of my 
biggest concerns.

>> The lirc support in mythtv actually relies on mapping remote button
>> names as defined in lircd.conf to keyboard key strokes. As mentioned
>> elsewhere in this beast of a thread, mythtv doesn't currently support
>> things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but
>> I intend on fixing that...
>
> lircd can handle the input layer as input as well, so you actually can
> remap things via lircd even for pure input layer drivers. mythtv
> handling KEY_VOLUMEUP directly would be more elegant though.

Yeah, no, I know lircd can attach to an input device. But even if you do 
that, you have to have a mapping that converts KEY_VOLUMEUP as captured 
by lircd into (iirc) right-bracket (]) for mythtv to actually consume 
it. Directly handling definitely needs to be added to mythtv.

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Jarod Wilson]

On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
> Jarod Wilson wrote:
>> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>>
>>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
>> ...
>>> I generally don't understand the LIRC aversion I perceive in this thread
>>> (maybe I just have a skewed perception).  Aside for a video card's
>>> default remote setup, the suggestions so far don't strike me as any
>>> simpler for the end user than LIRC -- maybe I'm just used to LIRC.  LIRC
>>> already works for both transmit and receive and has existing support in
>>> applications such as MythTV and mplayer.
>>
>> There's one gripe I agree with, and that is that its still not plug-n-play.
>> Something where udev auto-loads a sane default remote config for say,
>> mceusb transceivers, and the stock mce remote Just Works would be nice,
>> but auto-config is mostly out the window the second you involve transmitters
>> and universal remotes anyway.
>
> For several devices, an udev rule that auto-loads a sane default keymap does work.
> Of course, this won't cover 100% of the usages, and I lirc is a very good way
> of covering the holes.
>
>> But outside of that, I think objections are largely philosophical --
>> in a nutshell, the kernel has an input layer, remotes are input devices,
>> and lirc doesn't conform to input layer standards.
>
> Yes. I think this is mainly the issue.
>
> The other issue is how to migrate the existing drivers to a new API without
> causing regressions. If we decide that IR's that receive raw pulse/code
> should use the raw input interface, this means that a large task force will be
> needed to convert the existing drivers to use it.

Aversion to regression is definitely a major concern. And why I'm liking 
the idea of a hybrid approach, at least initially.

> What do you think of adding lirc at staging while we discuss/improve the API's and lircd
> support for the input event interface? Do you think this would work?

Sure, I don't see why not. And I've got another dozen or so drivers to 
follow those first three... :)

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Krzysztof Halasa]

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

> In what way the key interface is unsufficient for delivering button
> events?

At present: 128 different keys only (RC5: one group). One remote per
device only.

The protocol itself doesn't have the above limitations, but has others,
with are acceptable for key input.
-- 
Krzysztof Halasa

Re: [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]

Jarod Wilson wrote:
> On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
>> Jarod Wilson wrote:
>>> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>>>
>>>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
>>> ...
>>>> I generally don't understand the LIRC aversion I perceive in this
>>>> thread
>>>> (maybe I just have a skewed perception).  Aside for a video card's
>>>> default remote setup, the suggestions so far don't strike me as any
>>>> simpler for the end user than LIRC -- maybe I'm just used to LIRC. 
>>>> LIRC
>>>> already works for both transmit and receive and has existing support in
>>>> applications such as MythTV and mplayer.
>>>
>>> There's one gripe I agree with, and that is that its still not
>>> plug-n-play.
>>> Something where udev auto-loads a sane default remote config for say,
>>> mceusb transceivers, and the stock mce remote Just Works would be nice,
>>> but auto-config is mostly out the window the second you involve
>>> transmitters
>>> and universal remotes anyway.
>>
>> For several devices, an udev rule that auto-loads a sane default
>> keymap does work.
>> Of course, this won't cover 100% of the usages, and I lirc is a very
>> good way
>> of covering the holes.
>>
>>> But outside of that, I think objections are largely philosophical --
>>> in a nutshell, the kernel has an input layer, remotes are input devices,
>>> and lirc doesn't conform to input layer standards.
>>
>> Yes. I think this is mainly the issue.
>>
>> The other issue is how to migrate the existing drivers to a new API
>> without
>> causing regressions. If we decide that IR's that receive raw pulse/code
>> should use the raw input interface, this means that a large task force
>> will be
>> needed to convert the existing drivers to use it.
> 
> Aversion to regression is definitely a major concern. And why I'm liking
> the idea of a hybrid approach, at least initially.

Yes. This indeed seems to be a very good idea.
> 
>> What do you think of adding lirc at staging while we discuss/improve
>> the API's and lircd
>> support for the input event interface? Do you think this would work?
> 
> Sure, I don't see why not. And I've got another dozen or so drivers to
> follow those first three... :)

Ok. As you said you'll do some work at the patches, could you please send us v3
in order to add it into drivers/staging? 

In the case of the API header file, I would tag at the header file that the API
is experimental, so can be changed without prior announcements, etc (in order to
avoid people to use and rely on it it outside lirc). IMO, the better is to keep
such announcement there while we're still working at the hybrid approach, as we
may need to change something during the development phase.

Dmitry,

While lirc is basically a series of input drivers, considering that they have lots
in common with the input drivers at V4L/DVB and that we'll need to work on
some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from
my trees? 

Cheers,
Mauro.

Re: [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]

Krzysztof Halasa wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> 
>> In what way the key interface is unsufficient for delivering button
>> events?
> 
> At present: 128 different keys only (RC5: one group). One remote per
> device only.
> 
> The protocol itself doesn't have the above limitations, but has others,
> with are acceptable for key input.

This is not a limit at the input subsystem. It were a design decision for
some drivers at the V4L subsystem that we need to change.

Cheers,
Mauro.

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> 1) the developer that adds the hardware also adds the IR code. He has
> the hardware and the IR for testing, so it means a faster development
> cycle than waiting for someone else with the same hardware and IR to
> recode it on some other place. You should remember that not all
> developers use lirc;

It's fine, but please - no keymaps in the kernel (except for fixed
receivers, i.e. the ones which can only work with their own dedicated
remote, and which don't pass RC5/etc. code).

The existing keymaps (those which can be used with lirc) have to be
moved to userspace as well.
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> Technically, it is not hard to port this solution to the other
> drivers, but the issue is that we don't have all those IR's to know
> what is the complete scancode that each key produces. So, the hardest
> part is to find a way for doing it without causing regressions, and to
> find a group of people that will help testing the new way.

We don't want to "port it" to other drivers. We need to have a common
module which does all RCx decoding. The individual drivers should be as
simple as possible, something that I outlined in a previous mail.
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> The issue I see is to support at the same time NEC and RC5 protocols. While
> this may work with some devices, for others, the hardware won't allow.

Sure. We can handle it for the "simple" devices at least.

>> I think the mapping should be: key = proto + group + raw code, while
>> key2 could be different_proto + different group (if any) + another code.
>
> This may work for protocols up to RC5, that uses either 8 or 16 bits.
> However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits
> for a scancode. So, we don't have spare bits to represent a protocol, 
> if we consider RC6 mode 6 codes as well.

I don't see this limitation. The number of bits should depend on the
protocol.

> See above. Also, several protocols have a way to check if a keystroke were
> properly received. When handling just one protocol, we can use this to double
> check the key. However, on a multiprotocol mode, we'll need to disable this
> feature.

I don't think so. We can pass the space/mark data to all (configured,
i.e. with active mapping) protocol handlers at once. Should a check
fail, we ignore the data. Perhaps another protocol will make some sense
out of it.
-- 
Krzysztof Halasa

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> 1) the developer that adds the hardware also adds the IR code. He has
>> the hardware and the IR for testing, so it means a faster development
>> cycle than waiting for someone else with the same hardware and IR to
>> recode it on some other place. You should remember that not all
>> developers use lirc;
> 
> It's fine, but please - no keymaps in the kernel (except for fixed
> receivers, i.e. the ones which can only work with their own dedicated
> remote, and which don't pass RC5/etc. code).
> 
> The existing keymaps (those which can be used with lirc) have to be
> moved to userspace as well.

The removal of the existing keymaps from kernel depends on having an application
to be called from udev to load the proper keymaps when a device is probed.

After having it for a while, we should deprecate the in-kernel keymaps
and move them to userspace.

I also think that it is important to remove the 7 bits limitation from all drivers
and re-generate the keymaps, since they'll change after it.

cheers,
Mauro.

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> Technically, it is not hard to port this solution to the other
>> drivers, but the issue is that we don't have all those IR's to know
>> what is the complete scancode that each key produces. So, the hardest
>> part is to find a way for doing it without causing regressions, and to
>> find a group of people that will help testing the new way.
> 
> We don't want to "port it" to other drivers. We need to have a common
> module which does all RCx decoding. The individual drivers should be as
> simple as possible, something that I outlined in a previous mail.

With the current 7bits mask applied to almost all devices, it is probably not very
useful for those who want to use generic IRs. We really need to port the solution
we've done on dvb-usb to the other drivers, allowing them to have the entire
scancode at the tables while keep supporting table replacement. 

The issue is that we currently have only 7bits of the scan codes produced by the IR's.
So, we need to re-generate the keycode tables for each IR after the changes got applied.

With respect to a common module, unfortunately most of the work should be done on
each driver, since the code that communicates with the hardware is specific to each
device. There is a common code (at ir-common.ko) with helper decoding routines.

Please feel free to send us contributions to improve the current code.

Cheers,
Mauro.

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> The issue I see is to support at the same time NEC and RC5 protocols. While
>> this may work with some devices, for others, the hardware won't allow.
> 
> Sure. We can handle it for the "simple" devices at least.
> 
>>> I think the mapping should be: key = proto + group + raw code, while
>>> key2 could be different_proto + different group (if any) + another code.
>> This may work for protocols up to RC5, that uses either 8 or 16 bits.
>> However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits
>> for a scancode. So, we don't have spare bits to represent a protocol, 
>> if we consider RC6 mode 6 codes as well.
> 
> I don't see this limitation. The number of bits should depend on the
> protocol.

see include/linux/input.h:

struct input_event {
        struct timeval time;
        __u16 type;
        __u16 code;
        __s32 value;
};

extending the value to more than 32 bits require some changes at the input layer,
probably breaking kernel API.

> 
>> See above. Also, several protocols have a way to check if a keystroke were
>> properly received. When handling just one protocol, we can use this to double
>> check the key. However, on a multiprotocol mode, we'll need to disable this
>> feature.
> 
> I don't think so. We can pass the space/mark data to all (configured,
> i.e. with active mapping) protocol handlers at once. Should a check
> fail, we ignore the data. Perhaps another protocol will make some sense
> out of it.

What happens if it succeeds on two protocol handlers?

Cheers,
Mauro.

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

[Andy Walls]

On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> Krzysztof Halasa wrote:
> > Andy Walls <awalls@radix.net> writes:
> > 
> >> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> >> developed by Philips, but Microsoft has some sort of licensing interest
> >> in it and it is almost surely encumbered somwhow:
> > 
> > I don't know about legal problems in some countries but from the
> > technical POV handling the protocol in the kernel is more efficient
> > or (/and) simpler.
> 
> A software licensing from Microsoft won't apply to Linux kernel, so I'm
> assuming that you're referring to some patent that they could be filled
> about RC6 mode 6A.
> 
> I don't know if is there any US patent pending about it (AFAIK, only US
> accepts software patents), but there are some prior-art for IR key
> decoding. So, I don't see what "innovation" RC6 would be adding. 
> If it is some new way to transmit waves, the patent issues
> aren't related to software, and the device manufacturer had already handled
> it when they made their devices.
>
>  If it is just a new keytable, this issue 
> could be easily solved by loading the keytable via userspace.
> 
> Also, assuming that you can use the driver only with a hardware that comes
> with a licensed software, the user has already the license for using it.
> 
> Do you have any details on what patents they are claiming?

The US Philips RC-6 patent is US Patent 5,877,702

http://www.google.com/patents?vid=USPAT5877702

Click on download PDF to get a copy of the whole patent.

I am not a lawyer.  Philips claims' all appear to tie to a transmitter
or receiver as part of a system, but most of the claims are about
information and bit positions and lengths.


I don't know for sure what Microsoft claims to be licensing.  I think it
is the protocol itself:

http://www.microsoft.com/presspass/Press/2002/Apr02/04-16FreestylePhilipsPR.mspx

"Under the terms of the agreement, Microsoft and Philips will license to
OEMs an IR protocol based on Philips proprietary RC6 IR technology. The
patented and globally adopted solution minimizes interference from other
remote-control devices in the household. Use of this established
protocol will help ensure uniform development of Windows infrared
remote-control products, which include infrared remote-control units and
remote-control receivers..."

http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt

See Slide 5, which has the bullet: "How to License RC6"

Since the content of the information field in RC-6 Mode 6A is left up to
OEMs, I would not be surprised by bogus "innovations" in OEM patents
about RC-6 Mode 6A contents.  I would not be at all surprised by
something like "a bit to indicate a toggled remote key press in the
information field" since RC-6's T bits for mode 6 indicate Mode 6A or
Mode 6B and not toggles.


IMO, given

a. the dearth of public information about RC-6, indicating someone
thinks it's their trade secret or intellectual property

b. Microsoft claiming to license something related to the MCE remote
protocols (which are obviously RC-6 Mode 6A),

c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
encoding and decoding, as needed by MCE remotes, implemented in software
doesn't violate anyone's government granted rights to exclusivity.

I think it's much better to implement software RC-6 Mode 6A encoding and
decoding in user space, doing only the minimum needed to get the
hardware setup and going in the kernel.  

Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
worry me. 


Maybe I'm being too conservative here, but I have a personal interest in
keeping Linux free and unencumbered even in the US which, I cannot deny,
has a patent system that is screwed up.

Regards,
Andy

> Cheers,
> Mauro.

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> The removal of the existing keymaps from kernel depends on having an
> application
> to be called from udev to load the proper keymaps when a device is probed.
>
> After having it for a while, we should deprecate the in-kernel keymaps
> and move them to userspace.

Sounds like a plan.

> I also think that it is important to remove the 7 bits limitation from
> all drivers
> and re-generate the keymaps, since they'll change after it.

I think the existing space/mark media drivers need to be reworked
completely.
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> see include/linux/input.h:
>
> struct input_event {
>         struct timeval time;
>         __u16 type;
>         __u16 code;
>         __s32 value;
> };
>
> extending the value to more than 32 bits require some changes at the
> input layer, probably breaking kernel API.

Yeah, but that's a "key" space, not "raw code" space.
Keys via input and raw codes via lirc and there is no problem.

The mapping tables for input layer need to have variable code widths,
depending on the protocol, sure.

>> I don't think so. We can pass the space/mark data to all (configured,
>> i.e. with active mapping) protocol handlers at once. Should a check
>> fail, we ignore the data. Perhaps another protocol will make some sense
>> out of it.
>
> What happens if it succeeds on two protocol handlers?

We signal both and hope it isn't self-destruct button.
We can't fix it no matter how hard we try.
-- 
Krzysztof Halasa

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

[Christoph Bartelmus]

Hi Mauro,

on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
[...]
> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> that support only pulse/space raw mode and devices that generate scan
> codes via the raw mode interface. It does it by generating artificial
> pulse codes.

Nonsense! There's no generation of artificial pulse codes in the drivers.
The LIRC interface includes ways to pass decoded IR codes of arbitrary  
length to userspace.

Christoph

Re: [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]

Christoph Bartelmus wrote:
> Hi Mauro,
> 
> on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote:
> [...]
>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>> that support only pulse/space raw mode and devices that generate scan
>> codes via the raw mode interface. It does it by generating artificial
>> pulse codes.
> 
> Nonsense! There's no generation of artificial pulse codes in the drivers.
> The LIRC interface includes ways to pass decoded IR codes of arbitrary  
> length to userspace.

I might have got wrong then a comment in the middle of the 
imon_incoming_packet() of the SoundGraph iMON IR patch:

+	/*
+	 * Translate received data to pulse and space lengths.
+	 * Received data is active low, i.e. pulses are 0 and
+	 * spaces are 1.
+	 *
+	 * My original algorithm was essentially similar to
+	 * Changwoo Ryu's with the exception that he switched
+	 * the incoming bits to active high and also fed an
+	 * initial space to LIRC at the start of a new sequence
+	 * if the previous bit was a pulse.
+	 *
+	 * I've decided to adopt his algorithm.
+	 */

Cheers,
Mauro.

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> see include/linux/input.h:
>>
>> struct input_event {
>>         struct timeval time;
>>         __u16 type;
>>         __u16 code;
>>         __s32 value;
>> };
>>
>> extending the value to more than 32 bits require some changes at the
>> input layer, probably breaking kernel API.
> 
> Yeah, but that's a "key" space, not "raw code" space.
> Keys via input and raw codes via lirc and there is no problem.

No. All the other API functions there work with 32 bits for scancodes.

For example, the two ioctls to replace a scancode x key code are defined as:

#define EVIOCGKEYCODE           _IOR('E', 0x04, int[2])                 /* get keycode */
#define EVIOCSKEYCODE           _IOW('E', 0x04, int[2])                 /* set keycode */

We need to better analyze the API to see how this can be extended to
allow bigger widths.

(what's worse is that it is defined as "int" instead of "u32" - so the number
of bits is different on 32 and on 64 systems)

> The mapping tables for input layer need to have variable code widths,
> depending on the protocol, sure.
> 
>>> I don't think so. We can pass the space/mark data to all (configured,
>>> i.e. with active mapping) protocol handlers at once. Should a check
>>> fail, we ignore the data. Perhaps another protocol will make some sense
>>> out of it.
>> What happens if it succeeds on two protocol handlers?
> 
> We signal both and hope it isn't self-destruct button.
> We can't fix it no matter how hard we try.

We can fix. Just let the userspace select what protocol(s) is(are) enabled.

Cheers,
Mauro.

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> No. All the other API functions there work with 32 bits for scancodes.

We don't need them, do we? We need a new ioctl for changing key mappings
anyway (a single ioctl for setting the whole table I think), and we can
have arbitrary length of scan codes there.

> (what's worse is that it is defined as "int" instead of "u32" - so the number
> of bits is different on 32 and on 64 systems)

Most (all?) 64-bit systems use 32-bit ints (and 64-bit longs).
u32 and similar are for sure better.

>> We signal both and hope it isn't self-destruct button.
>> We can't fix it no matter how hard we try.
>
> We can fix. Just let the userspace select what protocol(s) is(are) enabled.

Sure, I meant the situation when both protocols (and scan codes) where
enabled and configured. If we don't use RCx in the mapping table, we
don't pass anything to RCx routine. If we have RCx but don't have the
scan code in question, we don't find the key in the table and thus we
ignore it again.
-- 
Krzysztof Halasa

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> The removal of the existing keymaps from kernel depends on having an
>> application
>> to be called from udev to load the proper keymaps when a device is probed.
>>
>> After having it for a while, we should deprecate the in-kernel keymaps
>> and move them to userspace.
> 
> Sounds like a plan.
> 
>> I also think that it is important to remove the 7 bits limitation from
>> all drivers
>> and re-generate the keymaps, since they'll change after it.
> 
> I think the existing space/mark media drivers need to be reworked
> completely.

Nah. the changes aren't big. The first part of the change were already done
for 2.6.32: instead of having a vector of 128 elements, where the element order
used to be the masked scancode, we now have a table of scancode x keycode, defined
as:

struct ir_scancode {
        u16     scancode;
        u32     keycode;
};

Changing scancode to u32 is as easy as edit a file - it is currently 16 just because
all currently supported IR's and protocols have 16 bits only - there's no in-kernel
implementation for RC6 mode 6 yet. However, increasing it above to 64 bits will break on
32 bits kernels (and above 64 bits, on all architectures), due to the current API limits.

this change is currently limited to the ir keytables, but I have a patch already done
extending this change for the drivers to work directly with the new table.

The next step is to replace the ir->mask_keycode at the drivers to a value that
gets the entire scancode. We may still need a mask there, since not all drivers output
a 32 bits scancode.

Also, there's no single "space/mark" media driver. All drivers that support 
pulse/space also support in-hardware IR decoding, in order to support the 
different types of devices. They generally support several ways to get keys:
	- serial pulse/space decoding on one GPIO pin (most pci hardware have);
	- serial pulse/space decoding via a IRQ enabled GPIO pin (several saa7134 IR's use this way);
	- i2c IR's (common on several popular devices);
	- parallel scancode output via gpio pins several cx88 IR's use this way);
	- direct IR hardware decoding done by the video chipset 
		(DibCom and newer em28xx hardware, for example).

So, the driver input complexity is needed to support all those different ways. 

So, rewriting it would likely cause regressions.

I agree that there are some cleanups that should be done for the serial pulse/space raw
decoding. By adding a lirc interface, we'll need to have a common code for handling
those events anyway.

Cheers,
Mauro.

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

[Dmitry Torokhov]

On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa <khc@pm.waw.pl> wrote:

> Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
>
>> In what way the key interface is unsufficient for delivering button
>> events?
>
> At present: 128 different keys only (RC5: one group).

Where did this limitation come from? We have more than 256 keycodes  
already _defined_ in the input core and we can add more if needed.


> One remote per
> device only.

Why would you want more? One physical device usually corresponds to a  
logical device. If you have 2 remotes create 2 devices.

> The protocol itself doesn't have the above limitations, but has  
> others,
> with are acceptable for key input.
> -- 
> Krzysztof Halasa

-- 
Dmitry

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

[Christoph Bartelmus]

Hi Mauro,

on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
[...]
>>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>>> that support only pulse/space raw mode and devices that generate scan
>>> codes via the raw mode interface. It does it by generating artificial
>>> pulse codes.
>>
>> Nonsense! There's no generation of artificial pulse codes in the drivers.
>> The LIRC interface includes ways to pass decoded IR codes of arbitrary
>> length to userspace.

> I might have got wrong then a comment in the middle of the
> imon_incoming_packet() of the SoundGraph iMON IR patch:

Indeed, you got it wrong.
As I already explained before, this device samples the signal at a  
constant rate and delivers the current level in a bit-array. This data is  
then condensed to pulse/space data.

Christoph

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> No. All the other API functions there work with 32 bits for scancodes.
> 
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the whole table I think), and we can
> have arbitrary length of scan codes there.

Why do you want to replace everything into a single shot? Had you ever tried
to replace a scancode table with the current API?

$ wc ./keycodes/dib0700_rc_keys
 216  432 3541 ./keycodes/dib0700_rc_keys

This is the biggest table we have: 216 scancodes. It has codes for several 
different IR's bound together into the same table.

Let's replace the entire table (tested on a dib8076 reference design device):

$ time ./keytable ./keycodes/dib0700_rc_keys

real    0m0.029s
user    0m0.000s
sys     0m0.027s

Don't you think that 29ms to replace 216 codes to be fast enough, especially since
you only need to do it once after plugging a device?

Also, if you want to control your device with two different IR controllers, the better
is to allow adding new keycodes there, instead of just allowing the replacement
of the entire table.

Maybe we'll need some extensions there, for example to extend the size of the dynamic
table, but I don't see any timing issue here.

Cheers,
Mauro

Re: [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]

Christoph Bartelmus wrote:
> Hi Mauro,
> 
> on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
>> Christoph Bartelmus wrote:
> [...]
>>>> lircd supports input layer interface. Yet, patch 3/3 exports both devices
>>>> that support only pulse/space raw mode and devices that generate scan
>>>> codes via the raw mode interface. It does it by generating artificial
>>>> pulse codes.
>>> Nonsense! There's no generation of artificial pulse codes in the drivers.
>>> The LIRC interface includes ways to pass decoded IR codes of arbitrary
>>> length to userspace.
> 
>> I might have got wrong then a comment in the middle of the
>> imon_incoming_packet() of the SoundGraph iMON IR patch:
> 
> Indeed, you got it wrong.
> As I already explained before, this device samples the signal at a  
> constant rate and delivers the current level in a bit-array. This data is  
> then condensed to pulse/space data.

Ah, ok. It is now clear to me. 

IMHO, it would be better to explain this at the source code, since the 
imon_incoming_packet() is a little complex. 

It would help the review process if those big routines could be broken into
 a few functions. While this improves code readability, it shouldn't 
affect performance, as gcc will handle the static functions used only once
as inline.

> Christoph

Cheers,
Mauro.

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

[Trent Piepho]

On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> See above. Also, several protocols have a way to check if a keystroke were
> >> properly received. When handling just one protocol, we can use this to double
> >> check the key. However, on a multiprotocol mode, we'll need to disable this
> >> feature.
> >
> > I don't think so. We can pass the space/mark data to all (configured,
> > i.e. with active mapping) protocol handlers at once. Should a check
> > fail, we ignore the data. Perhaps another protocol will make some sense
> > out of it.
>
> What happens if it succeeds on two protocol handlers?

Then you use the protocol that fits best.  For instance decoding with one
protocol might produce a scancode that isn't assigned to any key, while
another protocol produces an assigned scancode.  Clearly then the latter is
most likely to be correct.  It also possible to have a space/mark length
that is within the allowable tolerances for one remote, but is even closer
another remote.  You don't want to just find *a* match, you want to find
the *best* match.

The in kernel code in v4l is very simple in that it is only designed to
work with one procotol and one remote.  Once you have multiple remotes of
any type things become much more complicted.  Keep in mind that remotes
that aren't even intended to be used with the computer but are used in the
same room will still be received by the receiver.  It's not enough to
decode the signals you expect to receive, you must also not get confused by
random signals destined for somewhere else.

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

[Trent Piepho]

On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> >> lircd supports input layer interface. Yet, patch 3/3 exports both devices
> >> that support only pulse/space raw mode and devices that generate scan
> >> codes via the raw mode interface. It does it by generating artificial
> >> pulse codes.
> >
> > Nonsense! There's no generation of artificial pulse codes in the drivers.
> > The LIRC interface includes ways to pass decoded IR codes of arbitrary
> > length to userspace.
>
> I might have got wrong then a comment in the middle of the
> imon_incoming_packet() of the SoundGraph iMON IR patch:
>
> +	/*
> +	 * Translate received data to pulse and space lengths.
> +	 * Received data is active low, i.e. pulses are 0 and
> +	 * spaces are 1.

I'm not sure about this specific code, but what is likely
going on here is the waveform is being RLE encoding.

For example, a cx88 receiver has two ways of being connected (without
using an external decoder chip).  One generates an IRQ on each
edge of the signal.  The time between IRQs gives mark/space lengths
which is what lirc expects.  This is how a simple serial port receiver
works too.

Another connections effectivly samples the waveform one bit deep at IIRC
4kHz.  I think that's what the code you are looking at gets.  The code
extracts the edges from the waveform and returns the time between them.  In
effect one is run length encoding a sequence of bits.

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

[Dmitry Torokhov]

On Thu, Nov 26, 2009 at 07:05:01PM -0200, Mauro Carvalho Chehab wrote:
> 
> For example, the two ioctls to replace a scancode x key code are defined as:
> 
> #define EVIOCGKEYCODE           _IOR('E', 0x04, int[2])                 /* get keycode */
> #define EVIOCSKEYCODE           _IOW('E', 0x04, int[2])                 /* set keycode */
> 
> We need to better analyze the API to see how this can be extended to
> allow bigger widths.
> 
> (what's worse is that it is defined as "int" instead of "u32" - so the number
> of bits is different on 32 and on 64 systems)
> 

Not really, int is 32 bits on both, longs the ones that differ.

-- 
Dmitry

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

[Dmitry Torokhov]

On Thu, Nov 26, 2009 at 10:27:08PM +0100, Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
> > No. All the other API functions there work with 32 bits for scancodes.
> 
> We don't need them, do we? We need a new ioctl for changing key mappings
> anyway (a single ioctl for setting the whole table I think), and we can
> have arbitrary length of scan codes there.

Unless we determine that we 100% need bigger size of scancode then the
current ioctls are just fine. Why do we _need_ an ioctl to load the whole
tabe? Are you concerned about speed with which the keymap is populated?
I don't think it would be an issue.

-- 
Dmitry

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

[Dmitry Torokhov]

On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
> 
> > On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
> >> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
> >>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
> >>>> Mauro Carvalho Chehab<mchehab@redhat.com>  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)...
> >> 
> >> Its the cases like programmable universal remotes that really throw  
> >> things for a loop. That, and people wanting to use random remote X that  
> >> came with the amp or tv or set top box, with IR receiver Y.
> > 
> > Right, but still the keys usually do have the well-defined meaning,
> 
> Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean.

I guess we are talking about different things. While the 2 remotes may
use different protocols to communicate and may use the same codes to
mean different things they buttons have well-defined meaning and we
could map that to input keycodes. Then what is left is to load the
proper mapping for particular device into the kernel. This can be done
either automatically (when we know the mapping) or with the help of the
user (owner of the system).

> 
> > teh
> > issue is in mapping raw code to the appropriate keycode. This can be
> > done either by lirc config file (when lirc is used) or by some other
> > means.
> 
> The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too.

No, at present we expect 1:1 button->event mapping leaving macro
expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to
userspace).

-- 
Dmitry

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

[Dmitry Torokhov]

On Wed, Nov 25, 2009 at 10:58:29PM +0100, Gerd Hoffmann wrote:
>
> (1) ir code (say rc5) -> keycode conversion looses information.
>
> I think this can easily be addressed by adding a IR event type to the  
> input layer, which could look like this:
>
>   input_event->type  = EV_IR
>   input_event->code  = IR_RC5
>   input_event->value = <rc5 value>
>
> In case the 32bit value is too small we might want send two events  
> instead, with ->code being set to IR_<code>_1 and IR_<code>_2
>
> Advantages:
>   * Applications (including lircd) can get access to the unmodified
>     rc5/rc6/... codes.
>   * All the ir-code -> keycode mapping magic can be handled by the
>     core input layer then.  All the driver needs to do is to pass on
>     the information which keymap should be loaded by default (for the
>     bundled remote if any).  The configuration can happen in userspace
>     (sysfs attribute + udev + small utility in tools/ir/).
>   * lirc drivers which get ir codes from the hardware can be converted
>     to pure input layer drivers without regressions.  lircd is not
>     required any more.
>

I think we need to separate 2 kinds of applications since they have
different requirements as far as interface goes:

1. "Reguilar" user-space applications interested in receiving keystrokes
from user and reacting to them. Movie players, CD players, MythTV-like
applications and so on. Those, to my understanding, are not concerned
with the fine details of RC5, RC6, NEC and so forth protocol decoding
and just want to know when to start playing, when to stop and when to
revind. That class of applications is best served by current input layer
since it unifies data coming from IR, keyboards, button devices and so
forth.

2. "System" applications that are interested in protocol decoding. Those
need interface best suited for IR and nothing else. This protocol is
appears is better kept separate from the evdev input protocol. In case
where we rely solely on such userspace application(s) to perform protocol
decoding we should route input events back to kernel through uinput for
consumption by "class 1" applications.


We use this approach for PS/2 (serio allows binding either psmouse/atkbd
or serio_raw to provide alternate interfaces depending on the users
need), USB hid allows raw access as well, maybe we should follow the
suit here.

-- 
Dmitry

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

[Dmitry Torokhov]

On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
> 
> Dmitry,
> 
> While lirc is basically a series of input drivers, considering that they have lots
> in common with the input drivers at V4L/DVB and that we'll need to work on
> some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from
> my trees? 
> 

Mauro,

I would not mind if you will be pushing it to staging, however I am not
sure we have an agreement on what exactly the interface that we will be
using. I would hate to get something in that will need to be reworked
again.

Thanks.

-- 
Dmitry

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

[Krzysztof Halasa]

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

>> One remote per
>> device only.
>
> Why would you want more? One physical device usually corresponds to a
> logical device. If you have 2 remotes create 2 devices.

I meant "per receiver device".
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> Why do you want to replace everything into a single shot?

Why not? It seems simpler to me. We need to change this anyway.

If we change the whole table in a single ioctl, we can easily enumerate
protocols requested and enable then selectively.
But I think it's a minor implementation decision and we don't need to
look at it at this time.
-- 
Krzysztof Halasa

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

[Dmitry Torokhov]

On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> 
> >> One remote per
> >> device only.
> >
> > Why would you want more? One physical device usually corresponds to a
> > logical device. If you have 2 remotes create 2 devices.
> 
> I meant "per receiver device".

There is nothing in input layer that precludes you from creating
multiple input devices per *whatever*. Please, when you are talking
about limitations, specify whether those limitations are applicable to
the input layer, the current implementation of IR in DVB or something
else.

Thanks.

-- 
Dmitry

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

[Arnd Bergmann]

On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
> > Why do you want to replace everything into a single shot?
> 
> Why not? It seems simpler to me. We need to change this anyway.

ioctls with a variable argument length are a pain for 32 bit
emulation and stuff like strace. You either need to encode
the variable length into the ioctl cmd, making it variable
as well, or use a pointer in the data structure, which requires
conversion.

Ideally, ioctl arguments have a constant layout, no pointers
and are at most 64 bits long.

	Arnd <><

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

[Krzysztof Halasa]

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

> There is nothing in input layer that precludes you from creating
> multiple input devices per *whatever*.

Of course. I though it was obvious I mean present situation with the
media drivers but I can see now it was far from being obvious.
-- 
Krzysztof Halasa

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

[Krzysztof Halasa]

Trent Piepho <xyzzy@speakeasy.org> writes:

> Then you use the protocol that fits best.  For instance decoding with one
> protocol might produce a scancode that isn't assigned to any key, while
> another protocol produces an assigned scancode.  Clearly then the latter is
> most likely to be correct.

Right.

> It also possible to have a space/mark length
> that is within the allowable tolerances for one remote, but is even closer
> another remote.  You don't want to just find *a* match, you want to find
> the *best* match.

That won't work, the decoders don't calculate quality. And even if they
did, if you have two remotes generating the same e.g. RC5 code, you
won't be able to differentiate between them. Your TV etc. won't do that
either.

> The in kernel code in v4l is very simple in that it is only designed to
> work with one procotol and one remote.  Once you have multiple remotes of
> any type things become much more complicted.

If you're using them at once, sure :-)

> Keep in mind that remotes
> that aren't even intended to be used with the computer but are used in the
> same room will still be received by the receiver.  It's not enough to
> decode the signals you expect to receive, you must also not get confused by
> random signals destined for somewhere else.

This is usually not a problem. My experience is the decoding is very
reliable.
-- 
Krzysztof Halasa

Re: [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]

Dmitry Torokhov wrote:
> On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry,
>>
>> While lirc is basically a series of input drivers, considering that they have lots
>> in common with the input drivers at V4L/DVB and that we'll need to work on
>> some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from
>> my trees? 
>>
> 
> Mauro,
> 
> I would not mind if you will be pushing it to staging, however I am not
> sure we have an agreement on what exactly the interface that we will be
> using. I would hate to get something in that will need to be reworked
> again.

I understand your concerns.

IMHO, we should be really careful with API's when migrating from staging to the
right place, but I'm not that much concerned with staging. We already have several 
drivers there with bad behaviors and even with some API's there that will go to /dev/null.

For example there's a V4L2 driver there (staging/go7007) that has their own private
API to handle compressed streams. I won't ack moving it from staging while
it has their own private extensions for something that are part of V4L2 API.

Also, staging drivers without progress for a few kernel cycles will be moved to /dev/null,
so I don't see much sense of denying a driver to go there.

Anyway, I'll add it there only when you feel comfortable about that and send us your ack.

-

>From what I heard on the comments, I think we have already a consensus of some points:
	1) all IR's should implement the standard evdev interface;
	2) IR's with raw interfaces will implement a raw pulse/space IR interface. 
The proposal is to use lirc API interface for raw pulse/code TX and RX.

Do you think we'll need to better detail the IR raw interface API before accepting 
the patches for staging? If so, what level of details do you want?

Cheers,
Mauro.

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

[Jarod Wilson]

On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
> On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
>> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
>>
>>> On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
>>>> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
>>>>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
>>>>>> Mauro Carvalho Chehab<mchehab@redhat.com>   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)...
>>>>
>>>> Its the cases like programmable universal remotes that really throw
>>>> things for a loop. That, and people wanting to use random remote X that
>>>> came with the amp or tv or set top box, with IR receiver Y.
>>>
>>> Right, but still the keys usually do have the well-defined meaning,
>>
>> Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean.
>
> I guess we are talking about different things. While the 2 remotes may
> use different protocols to communicate

The remotes use the exact same protocol. Their respective bundled 
receivers however, do translate key presses differently. Perhaps this is 
a bad example though, because both of these remotes came with receivers 
that do onboard decoding. But there's nothing stopping me from wanting 
to use either of these remotes with an mceusb IR transceiver.

> and may use the same codes to
> mean different things they buttons have well-defined meaning and we
> could map that to input keycodes. Then what is left is to load the
> proper mapping for particular device into the kernel.

In this case, its not the device, but the remote, that we need a 
different mapping for.

> This can be done
> either automatically (when we know the mapping) or with the help of the
> user (owner of the system).

Yep, that'd work. Just trying to illustrate that the same code doesn't 
always mean anywhere near the same thing from one remote to another.

>>> teh
>>> issue is in mapping raw code to the appropriate keycode. This can be
>>> done either by lirc config file (when lirc is used) or by some other
>>> means.
>>
>> The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too.
>
> No, at present we expect 1:1 button->event mapping leaving macro
> expansion (i.e. KEY_PROG1 ->  "do some multi-step sequence" to
> userspace).

Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace 
somehow. Bummer.

-- 
Jarod Wilson
jarod@wilsonet.com

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

[hermann pitton]

Am Donnerstag, den 26.11.2009, 14:59 -0800 schrieb Trent Piepho:
> On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> > >> See above. Also, several protocols have a way to check if a keystroke were
> > >> properly received. When handling just one protocol, we can use this to double
> > >> check the key. However, on a multiprotocol mode, we'll need to disable this
> > >> feature.
> > >
> > > I don't think so. We can pass the space/mark data to all (configured,
> > > i.e. with active mapping) protocol handlers at once. Should a check
> > > fail, we ignore the data. Perhaps another protocol will make some sense
> > > out of it.
> >
> > What happens if it succeeds on two protocol handlers?
> 
> Then you use the protocol that fits best.  For instance decoding with one
> protocol might produce a scancode that isn't assigned to any key, while
> another protocol produces an assigned scancode.  Clearly then the latter is
> most likely to be correct.  It also possible to have a space/mark length
> that is within the allowable tolerances for one remote, but is even closer
> another remote.  You don't want to just find *a* match, you want to find
> the *best* match.
> 
> The in kernel code in v4l is very simple in that it is only designed to
> work with one procotol and one remote.  Once you have multiple remotes of
> any type things become much more complicted.  Keep in mind that remotes
> that aren't even intended to be used with the computer but are used in the
> same room will still be received by the receiver.  It's not enough to
> decode the signals you expect to receive, you must also not get confused by
> random signals destined for somewhere else.

Giving some random living room these days, likely open to the kids
rooms, you have to take that into account.

Another point, if decoding from IRQs generated by the remote, there is
flawed hardware around, needing to poll IRQs in some timely manner to
get it to something at all.

This will break such remotes. Never seen?

For me the first priority is, that existing remotes are not broken.

Don't tell you have done a nice job just now, but are unfortunately in
need of testers ... 

Cheers,
Hermann

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

[Jon Smirl]

On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
>> No, at present we expect 1:1 button->event mapping leaving macro
>> expansion (i.e. KEY_PROG1 ->  "do some multi-step sequence" to
>> userspace).
>
> Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow.
> Bummer.

That is scripting. Scripting always needs to be done in user space.

In the code I posted there is one evdev device for each configured
remote. Mapped single keycodes are presented on these devices for each
IR burst. There is no device for the IR receiver.  A LIRC type process
could watch these devices and then execute scripts based on the
keycodes reported.

The configfs model is very flexible. You could make a "remote" that
translates the UP/DOWN buttons of several different remotes into
KEY_UP/DOWN.  That lets several different remotes control the same
app.

Sure it is clunky to play with IR hex codes and keycodes in the
configfs mapping dir. If you don't like it write a GUI app for
manipulating the codes. GUI would then generate a script for udev to
run which builds the configfs entries.

Maybe I should rename those directory entries to "app" instead of
"remote". They contain the mappings from IR hex codes to keycodes that
an app is interested in. Usually there is a 1:1 correspondence between
remote and app but there doesn't have to be.

-- 
Jon Smirl
jonsmirl@gmail.com

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

[Dmitry Torokhov]

On Thu, Nov 26, 2009 at 09:28:51PM -0500, Jarod Wilson wrote:
> On 11/26/2009 06:23 PM, Dmitry Torokhov wrote:
>> On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote:
>>> On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote:
>>>
>>>> On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote:
>>>>> On 11/23/2009 12:37 PM, Dmitry Torokhov wrote:
>>>>>> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:
>>>>>>> Mauro Carvalho Chehab<mchehab@redhat.com>   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)...
>>>>>
>>>>> Its the cases like programmable universal remotes that really throw
>>>>> things for a loop. That, and people wanting to use random remote X that
>>>>> came with the amp or tv or set top box, with IR receiver Y.
>>>>
>>>> Right, but still the keys usually do have the well-defined meaning,
>>>
>>> Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean.
>>
>> I guess we are talking about different things. While the 2 remotes may
>> use different protocols to communicate
>
> The remotes use the exact same protocol. Their respective bundled  
> receivers however, do translate key presses differently. Perhaps this is  
> a bad example though, because both of these remotes came with receivers  
> that do onboard decoding. But there's nothing stopping me from wanting  
> to use either of these remotes with an mceusb IR transceiver.
>
>> and may use the same codes to
>> mean different things they buttons have well-defined meaning and we
>> could map that to input keycodes. Then what is left is to load the
>> proper mapping for particular device into the kernel.
>
> In this case, its not the device, but the remote, that we need a  
> different mapping for.

I would say that the remote is the device, not the receiver...

>
>> This can be done
>> either automatically (when we know the mapping) or with the help of the
>> user (owner of the system).
>
> Yep, that'd work. Just trying to illustrate that the same code doesn't  
> always mean anywhere near the same thing from one remote to another.

We have the same scenatio with atkbd and various laptops - the
"extended" keys may use the same scancodes for different keys and we use
DMI data to load the proper keymap. Obviously in case if IRC we won't be
using DMI but something else.

>
>>>> teh
>>>> issue is in mapping raw code to the appropriate keycode. This can be
>>>> done either by lirc config file (when lirc is used) or by some other
>>>> means.
>>>
>>> The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too.
>>
>> No, at present we expect 1:1 button->event mapping leaving macro
>> expansion (i.e. KEY_PROG1 ->  "do some multi-step sequence" to
>> userspace).
>
> Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace  
> somehow. Bummer.
>

What is Ctrl-x? Alt-tab? This are application-specific binding and of
course kernel does not emit these. If there is a distinct action that
needs to be signalled then there [normally] is a keycode for it.

-- 
Dmitry

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

[Dmitry Torokhov]

On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
> >> No, at present we expect 1:1 button->event mapping leaving macro
> >> expansion (i.e. KEY_PROG1 ->  "do some multi-step sequence" to
> >> userspace).
> >
> > Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow.
> > Bummer.
> 
> That is scripting. Scripting always needs to be done in user space.
> 
> In the code I posted there is one evdev device for each configured
> remote. Mapped single keycodes are presented on these devices for each
> IR burst. There is no device for the IR receiver.  A LIRC type process
> could watch these devices and then execute scripts based on the
> keycodes reported.
> 
> The configfs model is very flexible. You could make a "remote" that
> translates the UP/DOWN buttons of several different remotes into
> KEY_UP/DOWN.  That lets several different remotes control the same
> app.
> 
> Sure it is clunky to play with IR hex codes and keycodes in the
> configfs mapping dir. If you don't like it write a GUI app for
> manipulating the codes. GUI would then generate a script for udev to
> run which builds the configfs entries.
> 
> Maybe I should rename those directory entries to "app" instead of
> "remote". They contain the mappings from IR hex codes to keycodes that
> an app is interested in. Usually there is a 1:1 correspondence between
> remote and app but there doesn't have to be.
> 

Maybe we should revisit Jon's patchset as well. Regretfully I did not
have time to do that when it was submitted the last time.

-- 
Dmitry

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

[Jon Smirl]

On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>> In the code I posted there is one evdev device for each configured
>> remote. Mapped single keycodes are presented on these devices for each
>> IR burst. There is no device for the IR receiver.  A LIRC type process
>> could watch these devices and then execute scripts based on the
>> keycodes reported.
>>
...
>
> Maybe we should revisit Jon's patchset as well. Regretfully I did not
> have time to do that when it was submitted the last time.

Consider my patch set a technology demo starting point. It shows a
modern architecture for integrating IR into evdev.  Use the input from
everyone else to turn these concepts into a real design. I wrote the
code for the fun of it, I have no commercial interest in IR. I was
annoyed with how LIRC handled Sony remotes on my home system.

The design is a clean slate implementation of IR for the kernel. No
attempt was made at legacy compatibility. I was familiar with evdev vs
/dev/mouse problems from my work on the X server. Because of working
on X I've also always hated keymaps (that's what drove the configfs
design).

I wish one of the set top box or TV manufacturers would step up and
own this.  They are the ones that would benefit the most. Jarod would
probably be open to some consulting, right?

-- 
Jon Smirl
jonsmirl@gmail.com

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

[Christoph Bartelmus]

Hi Jon,

on 27 Nov 09 at 00:06, Jon Smirl wrote:
[...]
> code for the fun of it, I have no commercial interest in IR. I was
> annoyed with how LIRC handled Sony remotes on my home system.

Can you elaborate on this?
I'm not aware of any issue with Sony remotes.

Christoph

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

[Christoph Bartelmus]

Hi Mauro,

on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
> Christoph Bartelmus wrote:
[...]
>> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just
>> because I'm not familiar at all with input layer toolset.
[...]
> I hope it helps for you to better understand how this works.

So the plan is to have two ways of using IR in the future which are  
incompatible to each other, the feature-set of one being a subset of the  
other?

When designing the key mapping in the kernel you should be aware that  
there are remotes out there that send a sequence of scan codes for some  
buttons, e.g.
http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159

Christoph

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

[Jon Smirl]

On Fri, Nov 27, 2009 at 2:33 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi Jon,
>
> on 27 Nov 09 at 00:06, Jon Smirl wrote:
> [...]
>> code for the fun of it, I have no commercial interest in IR. I was
>> annoyed with how LIRC handled Sony remotes on my home system.
>
> Can you elaborate on this?
> I'm not aware of any issue with Sony remotes.

irrecord can't figure out that Sony remotes transmit multiple
protocols so it reverts to raw mode. When trying to figure that out I
started working on the concept of running simultaneous state machines
to decode the pulse timings.  I also had an embedded system with an IR
receiver hooked to a timer input pin.  I started off with a
implementation that ran multiple Sony protocol decoders and used the
input from the timer pin. I know now that I could use irrecord
individually for each group of keys on the Sony remote and then glue
the flies together. But that's the path that caused me to write the
code.

Also throw into pot that I had previously had some very bad
experiences trying to deal with the old mouse and kbd device inside of
the X server. I was aware that evdev was designed to fix all of those
problems. That made me want a fully evdev based design.

>
> Christoph
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [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]

Em Thu, 26 Nov 2009 17:06:03 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Krzysztof Halasa wrote:
> > Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> > 
> >> Technically, it is not hard to port this solution to the other
> >> drivers, but the issue is that we don't have all those IR's to know
> >> what is the complete scancode that each key produces. So, the hardest
> >> part is to find a way for doing it without causing regressions, and to
> >> find a group of people that will help testing the new way.
> > 
> > We don't want to "port it" to other drivers. We need to have a common
> > module which does all RCx decoding. The individual drivers should be as
> > simple as possible, something that I outlined in a previous mail.
> 
> With the current 7bits mask applied to almost all devices, it is probably not very
> useful for those who want to use generic IRs. We really need to port the solution
> we've done on dvb-usb to the other drivers, allowing them to have the entire
> scancode at the tables while keep supporting table replacement. 
> 
> The issue is that we currently have only 7bits of the scan codes produced by the IR's.
> So, we need to re-generate the keycode tables for each IR after the changes got applied.

Ok, I got some time to add support for tables with the full scan codes at the V4L drivers.
In order to not break all tables, I've confined the changes to just one device (HVR-950,
at the em28xx driver). The patches were already committed at the -hg development tree.

In order to support tables with the full scan codes, all that is needed is to add the 
RC5 address + RC5 data when calling ir_input_keydown. So, the change is as simple as:

-			ir_input_keydown(ir->input, &ir->ir,
-					 poll_result.rc_data[0]);
+			ir_input_keydown(ir->input, &ir->ir,
+					 poll_result.rc_address << 8 |
+					 poll_result.rc_data[0]);
+		else

An example of such patch can be seen at:
	http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56

There are still some work to do, since, currently, the drivers will use a table with a fixed
size. So, you can replace the current values, but it is not possible to add new keys.

The fix for it is simple, but we need to think what would be the better way for it. There are
two alternatives:
	- A table with a fixed size (like 128 or 256 entries - maybe a modprobe parameter
could be used to change its size);
	- some way to increase/reduce the table size. In this case, we'll likely need some
ioctl for it.

-- 

Cheers,
Mauro

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

[Dmitry Torokhov]

On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Nov 2009 17:06:03 -0200
> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> 
> > Krzysztof Halasa wrote:
> > > Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> > > 
> > >> Technically, it is not hard to port this solution to the other
> > >> drivers, but the issue is that we don't have all those IR's to know
> > >> what is the complete scancode that each key produces. So, the hardest
> > >> part is to find a way for doing it without causing regressions, and to
> > >> find a group of people that will help testing the new way.
> > > 
> > > We don't want to "port it" to other drivers. We need to have a common
> > > module which does all RCx decoding. The individual drivers should be as
> > > simple as possible, something that I outlined in a previous mail.
> > 
> > With the current 7bits mask applied to almost all devices, it is probably not very
> > useful for those who want to use generic IRs. We really need to port the solution
> > we've done on dvb-usb to the other drivers, allowing them to have the entire
> > scancode at the tables while keep supporting table replacement. 
> > 
> > The issue is that we currently have only 7bits of the scan codes produced by the IR's.
> > So, we need to re-generate the keycode tables for each IR after the changes got applied.
> 
> Ok, I got some time to add support for tables with the full scan codes at the V4L drivers.
> In order to not break all tables, I've confined the changes to just one device (HVR-950,
> at the em28xx driver). The patches were already committed at the -hg development tree.
> 
> In order to support tables with the full scan codes, all that is needed is to add the 
> RC5 address + RC5 data when calling ir_input_keydown. So, the change is as simple as:
> 
> -			ir_input_keydown(ir->input, &ir->ir,
> -					 poll_result.rc_data[0]);
> +			ir_input_keydown(ir->input, &ir->ir,
> +					 poll_result.rc_address << 8 |
> +					 poll_result.rc_data[0]);
> +		else
> 
> An example of such patch can be seen at:
> 	http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56
> 
> There are still some work to do, since, currently, the drivers will use a table with a fixed
> size. So, you can replace the current values, but it is not possible to add new keys.
> 
> The fix for it is simple, but we need to think what would be the better way for it. There are
> two alternatives:
> 	- A table with a fixed size (like 128 or 256 entries - maybe a modprobe parameter
> could be used to change its size);
> 	- some way to increase/reduce the table size. In this case, we'll likely need some
> ioctl for it.
> 

Hmm, why can't you just resize it when you get EVIOCSKEYCODE for
scancode that would be out of bounds for the current table (if using
table approach)?

-- 
Dmitry

Re: [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]

Dmitry Torokhov wrote:
> On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote:
>> Em Thu, 26 Nov 2009 17:06:03 -0200
>> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>>
>>> Krzysztof Halasa wrote:
>>>> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
>>>>
>>>>> Technically, it is not hard to port this solution to the other
>>>>> drivers, but the issue is that we don't have all those IR's to know
>>>>> what is the complete scancode that each key produces. So, the hardest
>>>>> part is to find a way for doing it without causing regressions, and to
>>>>> find a group of people that will help testing the new way.
>>>> We don't want to "port it" to other drivers. We need to have a common
>>>> module which does all RCx decoding. The individual drivers should be as
>>>> simple as possible, something that I outlined in a previous mail.
>>> With the current 7bits mask applied to almost all devices, it is probably not very
>>> useful for those who want to use generic IRs. We really need to port the solution
>>> we've done on dvb-usb to the other drivers, allowing them to have the entire
>>> scancode at the tables while keep supporting table replacement. 
>>>
>>> The issue is that we currently have only 7bits of the scan codes produced by the IR's.
>>> So, we need to re-generate the keycode tables for each IR after the changes got applied.
>> Ok, I got some time to add support for tables with the full scan codes at the V4L drivers.
>> In order to not break all tables, I've confined the changes to just one device (HVR-950,
>> at the em28xx driver). The patches were already committed at the -hg development tree.
>>
>> In order to support tables with the full scan codes, all that is needed is to add the 
>> RC5 address + RC5 data when calling ir_input_keydown. So, the change is as simple as:
>>
>> -			ir_input_keydown(ir->input, &ir->ir,
>> -					 poll_result.rc_data[0]);
>> +			ir_input_keydown(ir->input, &ir->ir,
>> +					 poll_result.rc_address << 8 |
>> +					 poll_result.rc_data[0]);
>> +		else
>>
>> An example of such patch can be seen at:
>> 	http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56
>>
>> There are still some work to do, since, currently, the drivers will use a table with a fixed
>> size. So, you can replace the current values, but it is not possible to add new keys.
>>
>> The fix for it is simple, but we need to think what would be the better way for it. There are
>> two alternatives:
>> 	- A table with a fixed size (like 128 or 256 entries - maybe a modprobe parameter
>> could be used to change its size);
>> 	- some way to increase/reduce the table size. In this case, we'll likely need some
>> ioctl for it.
>>
> 
> Hmm, why can't you just resize it when you get EVIOCSKEYCODE for
> scancode that would be out of bounds for the current table (if using
> table approach)?

For your reference, the code where EVIOGKEYCODE/EVIOSKEYCODE handling is done is at
this changeset:
	http://linuxtv.org/hg/v4l-dvb/rev/21e71d58cd2a

Dynamic resizing can be done, but there are a few different use cases for 
someone to touch on the keymaps:

1. People want to change the key assignment for a key at the shipped IR. In this case, 
the table won't need to change its size;

2. People want to use the shipped IR, plus a different one. In this case, table size needs
to be extended to store the newer codes;

3. People want to discard the shipped IR and use something else. 

Case 3 is the worse scenario. Let's suppose, for example that instead of using a 49 keys
IR, they want to use some programable IR with 55 keys, with different
scancodes. This means that they'll need to delete all 49 scancodes from the old IR 
and add 55 new scancodes. As there's no explicit call to delete a scan code, the solution
I found with the current API is to read the current scancode table and replace them with
KEY_UNKNOWN, allowing its re-use (this is what the driver currently does) or deleting
that scancode from the table. After deleting 49 keys, you'll need to add the 55 new keys.
If we do dynamic table resize for each operation, we'll do 104 sequences of kmalloc/kfree
for replacing one table. 

IMO, it would be better to have an ioctl to do the keycode table resize. An optional flag
at the ioctl (or a separate one) can be used to ask the driver to clean the current
keymap table and allocate a new one with the specified size. 
This will avoid playing with memory allocation for every new key and will provide a simple
way to say to the driver to discard the current keybable, since a new one will be used.

Cheers,
Mauro.

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

[Stefan Richter]

Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
[scancode-to-keycode map size]
>> Hmm, why can't you just resize it when you get EVIOCSKEYCODE for
>> scancode that would be out of bounds for the current table (if using
>> table approach)?
[...]
> Let's suppose, for example that instead of using a 49 keys
> IR, they want to use some programable IR with 55 keys, with different
> scancodes. This means that they'll need to delete all 49 scancodes from the old IR 
> and add 55 new scancodes. As there's no explicit call to delete a scan code, the solution
> I found with the current API is to read the current scancode table and replace them with
> KEY_UNKNOWN, allowing its re-use (this is what the driver currently does) or deleting
> that scancode from the table. After deleting 49 keys, you'll need to add the 55 new keys.
> If we do dynamic table resize for each operation, we'll do 104 sequences of kmalloc/kfree
> for replacing one table.

It is not a performance sensitive task, is it?  If you can trade ABI
simplicity for performance (which shouldn't actually matter), that'd be
a better deal.

Besides, some of the necessary kernel-internal house-keeping can also be
deferred until close().

> IMO, it would be better to have an ioctl to do the keycode table resize. An optional flag
> at the ioctl (or a separate one) can be used to ask the driver to clean the current
> keymap table and allocate a new one with the specified size. 
> This will avoid playing with memory allocation for every new key and will provide a simple
> way to say to the driver to discard the current keybable, since a new one will be used.

OTOH, an additional "forget all current mappings" ioctl sounds like an
ABI simplification.
-- 
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/

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

[Arnd Bergmann]

On Saturday 28 November 2009, Mauro Carvalho Chehab wrote:
> After deleting 49 keys, you'll need to add the 55 new keys.
> If we do dynamic table resize for each operation, we'll do 104 
> sequences of kmalloc/kfree for replacing one table. 

Given that kmalloc only does power-of-two allocations, you can limit
the resize operations to when you go beyond the current allocation
limit. You can also choose a reasonable minimum table size (e.g. 32
or 64 entries) and avoid resizes for many of the common cases entirely.

	Arnd <><

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

[Jarod Wilson]

On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote:

> On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>>> In the code I posted there is one evdev device for each configured
>>> remote. Mapped single keycodes are presented on these devices for each
>>> IR burst. There is no device for the IR receiver.  A LIRC type process
>>> could watch these devices and then execute scripts based on the
>>> keycodes reported.
>>> 
> ...
>> 
>> Maybe we should revisit Jon's patchset as well. Regretfully I did not
>> have time to do that when it was submitted the last time.
> 
> Consider my patch set a technology demo starting point. It shows a
> modern architecture for integrating IR into evdev.  Use the input from
> everyone else to turn these concepts into a real design. I wrote the
> code for the fun of it, I have no commercial interest in IR. I was
> annoyed with how LIRC handled Sony remotes on my home system.
> 
> The design is a clean slate implementation of IR for the kernel. No
> attempt was made at legacy compatibility. I was familiar with evdev vs
> /dev/mouse problems from my work on the X server. Because of working
> on X I've also always hated keymaps (that's what drove the configfs
> design).
> 
> I wish one of the set top box or TV manufacturers would step up and
> own this.  They are the ones that would benefit the most. Jarod would
> probably be open to some consulting, right?

Mauro may actually have better connections on that front than I do... Thus far, I've only talked to a few vendors of IR devices, with mixed results getting any sort of support out of them. But its on my todo list to put out some feelers on the work front to see if we have any connections that we might be able to utilize.

-- 
Jarod Wilson
jarod@wilsonet.com

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

[Jarod Wilson]

On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:

> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
>> Krzysztof Halasa wrote:
>>> Andy Walls <awalls@radix.net> writes:
>>> 
>>>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>>>> developed by Philips, but Microsoft has some sort of licensing interest
>>>> in it and it is almost surely encumbered somwhow:
>>> 
>>> I don't know about legal problems in some countries but from the
>>> technical POV handling the protocol in the kernel is more efficient
>>> or (/and) simpler.
>> 
>> A software licensing from Microsoft won't apply to Linux kernel, so I'm
>> assuming that you're referring to some patent that they could be filled
>> about RC6 mode 6A.
>> 
>> I don't know if is there any US patent pending about it (AFAIK, only US
>> accepts software patents), but there are some prior-art for IR key
>> decoding. So, I don't see what "innovation" RC6 would be adding. 
>> If it is some new way to transmit waves, the patent issues
>> aren't related to software, and the device manufacturer had already handled
>> it when they made their devices.
>> 
>> If it is just a new keytable, this issue 
>> could be easily solved by loading the keytable via userspace.
>> 
>> Also, assuming that you can use the driver only with a hardware that comes
>> with a licensed software, the user has already the license for using it.
>> 
>> Do you have any details on what patents they are claiming?
> 
> The US Philips RC-6 patent is US Patent 5,877,702
> 
> http://www.google.com/patents?vid=USPAT5877702
> 
> Click on download PDF to get a copy of the whole patent.
> 
> I am not a lawyer.  Philips claims' all appear to tie to a transmitter
> or receiver as part of a system, but most of the claims are about
> information and bit positions and lengths.
...
> IMO, given
> 
> a. the dearth of public information about RC-6, indicating someone
> thinks it's their trade secret or intellectual property
> 
> b. Microsoft claiming to license something related to the MCE remote
> protocols (which are obviously RC-6 Mode 6A),
> 
> c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
> encoding and decoding, as needed by MCE remotes, implemented in software
> doesn't violate anyone's government granted rights to exclusivity.
> 
> I think it's much better to implement software RC-6 Mode 6A encoding and
> decoding in user space, doing only the minimum needed to get the
> hardware setup and going in the kernel.  
> 
> Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
> worry me. 
> 
> 
> Maybe I'm being too conservative here, but I have a personal interest in
> keeping Linux free and unencumbered even in the US which, I cannot deny,
> has a patent system that is screwed up.

So I had one of the people who does all the license and patent audits for Fedora packages look at the Philips patent on RC-6. He's 100% positive that the patent *only* covers hardware, there should be no problem whatsoever writing a software decoder for RC-6.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [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]

Jarod Wilson wrote:
> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> 
>> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:

>> Maybe I'm being too conservative here, but I have a personal interest in
>> keeping Linux free and unencumbered even in the US which, I cannot deny,
>> has a patent system that is screwed up.
> 
> So I had one of the people who does all the license and patent audits for 
> Fedora packages look at the Philips patent on RC-6. He's 100% positive 
> that the patent *only* covers hardware, there should be no problem whatsoever
> writing a software decoder for RC-6.

That's good!

Cheers,
Mauro.

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

[Andy Walls]

On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> 
> > On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> >> Krzysztof Halasa wrote:
> >>> Andy Walls <awalls@radix.net> writes:
> >>> 
> >>>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> >>>> developed by Philips, but Microsoft has some sort of licensing interest
> >>>> in it and it is almost surely encumbered somwhow:
> >>> 
> >>> I don't know about legal problems in some countries but from the
> >>> technical POV handling the protocol in the kernel is more efficient
> >>> or (/and) simpler.
> >> 
> >> A software licensing from Microsoft won't apply to Linux kernel, so I'm
> >> assuming that you're referring to some patent that they could be filled
> >> about RC6 mode 6A.
> >> 
> >> I don't know if is there any US patent pending about it (AFAIK, only US
> >> accepts software patents), but there are some prior-art for IR key
> >> decoding. So, I don't see what "innovation" RC6 would be adding. 
> >> If it is some new way to transmit waves, the patent issues
> >> aren't related to software, and the device manufacturer had already handled
> >> it when they made their devices.
> >> 
> >> If it is just a new keytable, this issue 
> >> could be easily solved by loading the keytable via userspace.
> >> 
> >> Also, assuming that you can use the driver only with a hardware that comes
> >> with a licensed software, the user has already the license for using it.
> >> 
> >> Do you have any details on what patents they are claiming?
> > 
> > The US Philips RC-6 patent is US Patent 5,877,702
> > 
> > http://www.google.com/patents?vid=USPAT5877702
> > 
> > Click on download PDF to get a copy of the whole patent.
> > 
> > I am not a lawyer.  Philips claims' all appear to tie to a transmitter
> > or receiver as part of a system, but most of the claims are about
> > information and bit positions and lengths.
> ...
> > IMO, given
> > 
> > a. the dearth of public information about RC-6, indicating someone
> > thinks it's their trade secret or intellectual property
> > 
> > b. Microsoft claiming to license something related to the MCE remote
> > protocols (which are obviously RC-6 Mode 6A),
> > 
> > c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
> > encoding and decoding, as needed by MCE remotes, implemented in software
> > doesn't violate anyone's government granted rights to exclusivity.
> > 
> > I think it's much better to implement software RC-6 Mode 6A encoding and
> > decoding in user space, doing only the minimum needed to get the
> > hardware setup and going in the kernel.  
> > 
> > Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
> > worry me. 
> > 
> > 
> > Maybe I'm being too conservative here, but I have a personal interest in
> > keeping Linux free and unencumbered even in the US which, I cannot deny,
> > has a patent system that is screwed up.
> 
> So I had one of the people who does all the license and patent audits
> for Fedora packages look at the Philips patent on RC-6. He's 100%
> positive that the patent *only* covers hardware, there should be no
> problem whatsoever writing a software decoder for RC-6.

OK.  Thanks for having some professionals take a look.  (I'm assuming
that's the only patent.)

So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.

I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
a common set of parameters, so I may be able to set up the decoders to
handle decoding from two different remote types at once.  The HVR boards
can ship with either type of remote AFAIK.

I wonder if I can flip the keytables on the fly or if I have to create
two different input devices?

Regards,
Andy

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

[Dmitry Torokhov]

On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> > On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> > 
> > > On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> > >> Krzysztof Halasa wrote:
> > >>> Andy Walls <awalls@radix.net> writes:
> > >>> 
> > >>>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> > >>>> developed by Philips, but Microsoft has some sort of licensing interest
> > >>>> in it and it is almost surely encumbered somwhow:
> > >>> 
> > >>> I don't know about legal problems in some countries but from the
> > >>> technical POV handling the protocol in the kernel is more efficient
> > >>> or (/and) simpler.
> > >> 
> > >> A software licensing from Microsoft won't apply to Linux kernel, so I'm
> > >> assuming that you're referring to some patent that they could be filled
> > >> about RC6 mode 6A.
> > >> 
> > >> I don't know if is there any US patent pending about it (AFAIK, only US
> > >> accepts software patents), but there are some prior-art for IR key
> > >> decoding. So, I don't see what "innovation" RC6 would be adding. 
> > >> If it is some new way to transmit waves, the patent issues
> > >> aren't related to software, and the device manufacturer had already handled
> > >> it when they made their devices.
> > >> 
> > >> If it is just a new keytable, this issue 
> > >> could be easily solved by loading the keytable via userspace.
> > >> 
> > >> Also, assuming that you can use the driver only with a hardware that comes
> > >> with a licensed software, the user has already the license for using it.
> > >> 
> > >> Do you have any details on what patents they are claiming?
> > > 
> > > The US Philips RC-6 patent is US Patent 5,877,702
> > > 
> > > http://www.google.com/patents?vid=USPAT5877702
> > > 
> > > Click on download PDF to get a copy of the whole patent.
> > > 
> > > I am not a lawyer.  Philips claims' all appear to tie to a transmitter
> > > or receiver as part of a system, but most of the claims are about
> > > information and bit positions and lengths.
> > ...
> > > IMO, given
> > > 
> > > a. the dearth of public information about RC-6, indicating someone
> > > thinks it's their trade secret or intellectual property
> > > 
> > > b. Microsoft claiming to license something related to the MCE remote
> > > protocols (which are obviously RC-6 Mode 6A),
> > > 
> > > c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
> > > encoding and decoding, as needed by MCE remotes, implemented in software
> > > doesn't violate anyone's government granted rights to exclusivity.
> > > 
> > > I think it's much better to implement software RC-6 Mode 6A encoding and
> > > decoding in user space, doing only the minimum needed to get the
> > > hardware setup and going in the kernel.  
> > > 
> > > Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
> > > worry me. 
> > > 
> > > 
> > > Maybe I'm being too conservative here, but I have a personal interest in
> > > keeping Linux free and unencumbered even in the US which, I cannot deny,
> > > has a patent system that is screwed up.
> > 
> > So I had one of the people who does all the license and patent audits
> > for Fedora packages look at the Philips patent on RC-6. He's 100%
> > positive that the patent *only* covers hardware, there should be no
> > problem whatsoever writing a software decoder for RC-6.
> 
> OK.  Thanks for having some professionals take a look.  (I'm assuming
> that's the only patent.)
> 
> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> end of the month.
> 
> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> a common set of parameters, so I may be able to set up the decoders to
> handle decoding from two different remote types at once.  The HVR boards
> can ship with either type of remote AFAIK.
> 
> I wonder if I can flip the keytables on the fly or if I have to create
> two different input devices?
> 

Can you distinguish between the 2 remotes (not receivers)? Like I said,
I think the preferred way is to represent every remote that can be
distinguished from each other as a separate input device. Applications
expect to query device capabilities and expect them to stay somewhat
stable (we do support keymap change but I don't think anyone expectes
flip-flopping).

-- 
Dmitry

Re: [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]

Andy Walls wrote:
> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
>> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
>>
>>> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
>>>> Krzysztof Halasa wrote:
>>>>> Andy Walls <awalls@radix.net> writes:
>>>>>
>>>>>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>>>>>> developed by Philips, but Microsoft has some sort of licensing interest
>>>>>> in it and it is almost surely encumbered somwhow:
>>>>> I don't know about legal problems in some countries but from the
>>>>> technical POV handling the protocol in the kernel is more efficient
>>>>> or (/and) simpler.
>>>> A software licensing from Microsoft won't apply to Linux kernel, so I'm
>>>> assuming that you're referring to some patent that they could be filled
>>>> about RC6 mode 6A.
>>>>
>>>> I don't know if is there any US patent pending about it (AFAIK, only US
>>>> accepts software patents), but there are some prior-art for IR key
>>>> decoding. So, I don't see what "innovation" RC6 would be adding. 
>>>> If it is some new way to transmit waves, the patent issues
>>>> aren't related to software, and the device manufacturer had already handled
>>>> it when they made their devices.
>>>>
>>>> If it is just a new keytable, this issue 
>>>> could be easily solved by loading the keytable via userspace.
>>>>
>>>> Also, assuming that you can use the driver only with a hardware that comes
>>>> with a licensed software, the user has already the license for using it.
>>>>
>>>> Do you have any details on what patents they are claiming?
>>> The US Philips RC-6 patent is US Patent 5,877,702
>>>
>>> http://www.google.com/patents?vid=USPAT5877702
>>>
>>> Click on download PDF to get a copy of the whole patent.
>>>
>>> I am not a lawyer.  Philips claims' all appear to tie to a transmitter
>>> or receiver as part of a system, but most of the claims are about
>>> information and bit positions and lengths.
>> ...
>>> IMO, given
>>>
>>> a. the dearth of public information about RC-6, indicating someone
>>> thinks it's their trade secret or intellectual property
>>>
>>> b. Microsoft claiming to license something related to the MCE remote
>>> protocols (which are obviously RC-6 Mode 6A),
>>>
>>> c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
>>> encoding and decoding, as needed by MCE remotes, implemented in software
>>> doesn't violate anyone's government granted rights to exclusivity.
>>>
>>> I think it's much better to implement software RC-6 Mode 6A encoding and
>>> decoding in user space, doing only the minimum needed to get the
>>> hardware setup and going in the kernel.  
>>>
>>> Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
>>> worry me. 
>>>
>>>
>>> Maybe I'm being too conservative here, but I have a personal interest in
>>> keeping Linux free and unencumbered even in the US which, I cannot deny,
>>> has a patent system that is screwed up.
>> So I had one of the people who does all the license and patent audits
>> for Fedora packages look at the Philips patent on RC-6. He's 100%
>> positive that the patent *only* covers hardware, there should be no
>> problem whatsoever writing a software decoder for RC-6.
> 
> OK.  Thanks for having some professionals take a look.  (I'm assuming
> that's the only patent.)
> 
> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> end of the month.

Good! Please, try to design the decoder as an independent module that gets
data from a kfifo and generate scancodes for the input API.
 
> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> a common set of parameters, so I may be able to set up the decoders to
> handle decoding from two different remote types at once.  The HVR boards
> can ship with either type of remote AFAIK.
> 
> I wonder if I can flip the keytables on the fly or if I have to create
> two different input devices?

IMO, the better is, by default, to open just one input device per IR receiver.
>From what I understand from our discussions, if the user wants to filter IR
commands into several input interfaces, some userspace interface will be 
provided to allow the creation of other input interfaces for that purpose.

Cheers,
Mauro.

Re: [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]

Dmitry Torokhov wrote:
> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
>>> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
>>>
>>>> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
>>>>> Krzysztof Halasa wrote:
>>>>>> Andy Walls <awalls@radix.net> writes:
>>>>>>
>>>>>>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>>>>>>> developed by Philips, but Microsoft has some sort of licensing interest
>>>>>>> in it and it is almost surely encumbered somwhow:
>>>>>> I don't know about legal problems in some countries but from the
>>>>>> technical POV handling the protocol in the kernel is more efficient
>>>>>> or (/and) simpler.
>>>>> A software licensing from Microsoft won't apply to Linux kernel, so I'm
>>>>> assuming that you're referring to some patent that they could be filled
>>>>> about RC6 mode 6A.
>>>>>
>>>>> I don't know if is there any US patent pending about it (AFAIK, only US
>>>>> accepts software patents), but there are some prior-art for IR key
>>>>> decoding. So, I don't see what "innovation" RC6 would be adding. 
>>>>> If it is some new way to transmit waves, the patent issues
>>>>> aren't related to software, and the device manufacturer had already handled
>>>>> it when they made their devices.
>>>>>
>>>>> If it is just a new keytable, this issue 
>>>>> could be easily solved by loading the keytable via userspace.
>>>>>
>>>>> Also, assuming that you can use the driver only with a hardware that comes
>>>>> with a licensed software, the user has already the license for using it.
>>>>>
>>>>> Do you have any details on what patents they are claiming?
>>>> The US Philips RC-6 patent is US Patent 5,877,702
>>>>
>>>> http://www.google.com/patents?vid=USPAT5877702
>>>>
>>>> Click on download PDF to get a copy of the whole patent.
>>>>
>>>> I am not a lawyer.  Philips claims' all appear to tie to a transmitter
>>>> or receiver as part of a system, but most of the claims are about
>>>> information and bit positions and lengths.
>>> ...
>>>> IMO, given
>>>>
>>>> a. the dearth of public information about RC-6, indicating someone
>>>> thinks it's their trade secret or intellectual property
>>>>
>>>> b. Microsoft claiming to license something related to the MCE remote
>>>> protocols (which are obviously RC-6 Mode 6A),
>>>>
>>>> c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
>>>> encoding and decoding, as needed by MCE remotes, implemented in software
>>>> doesn't violate anyone's government granted rights to exclusivity.
>>>>
>>>> I think it's much better to implement software RC-6 Mode 6A encoding and
>>>> decoding in user space, doing only the minimum needed to get the
>>>> hardware setup and going in the kernel.  
>>>>
>>>> Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
>>>> worry me. 
>>>>
>>>>
>>>> Maybe I'm being too conservative here, but I have a personal interest in
>>>> keeping Linux free and unencumbered even in the US which, I cannot deny,
>>>> has a patent system that is screwed up.
>>> So I had one of the people who does all the license and patent audits
>>> for Fedora packages look at the Philips patent on RC-6. He's 100%
>>> positive that the patent *only* covers hardware, there should be no
>>> problem whatsoever writing a software decoder for RC-6.
>> OK.  Thanks for having some professionals take a look.  (I'm assuming
>> that's the only patent.)
>>
>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>> end of the month.
>>
>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>> a common set of parameters, so I may be able to set up the decoders to
>> handle decoding from two different remote types at once.  The HVR boards
>> can ship with either type of remote AFAIK.
>>
>> I wonder if I can flip the keytables on the fly or if I have to create
>> two different input devices?
>>
> 
> Can you distinguish between the 2 remotes (not receivers)? Like I said,
> I think the preferred way is to represent every remote that can be
> distinguished from each other as a separate input device. Applications
> expect to query device capabilities and expect them to stay somewhat
> stable (we do support keymap change but I don't think anyone expectes
> flip-flopping).
> 
With RC-5, you have no fields describing the remote. So, all the driver could
do is an educated guess.

>From a quick look I did at the RC-6 Mode 6A docs I found, I suspect that
you can distinguish two different remotes when someone press a key there.

However, I don't think it is a good idea to automatically create a new interface
every time a different vendor is detected. Maybe the user simply have a
RC-6 IR to control his TV and doesn't have any intention on using that
device on his computer.

IMO, the better is to have an API to allow creation of multiple interfaces
per IR receiver, based on some scancode matching table and/or on some
matching mask.

It should be possible to use the filter API to match different IR's by
vendor/product on protocols that supports it, or to match address/command
tuples on protocols where you just have those fields.

Cheers,
Mauro.

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

[Andy Walls]

On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:

> > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> > end of the month.
> > 
> > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> > a common set of parameters, so I may be able to set up the decoders to
> > handle decoding from two different remote types at once.  The HVR boards
> > can ship with either type of remote AFAIK.
> > 
> > I wonder if I can flip the keytables on the fly or if I have to create
> > two different input devices?
> > 
> 
> Can you distinguish between the 2 remotes (not receivers)?

Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
(Honestly I could pile on more protocols that have similar pulse time
periods, but that's complexity for no good reason and I don't know of a
vendor that bundles 3 types of remotes per TV card.)


>  Like I said,
> I think the preferred way is to represent every remote that can be
> distinguished from each other as a separate input device.

OK.  With RC-5, NEC, and RC-6 at least there is also an address or
system byte or word to distingish different remotes.  However creating
multiple input devices on the fly for detected remotes would be madness
- especially with a decoding error in the address bits.  

Any one vendor usually picks one address for their bundled remote.
Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.



>  Applications
> expect to query device capabilities and expect them to stay somewhat
> stable (we do support keymap change but I don't think anyone expectes
> flip-flopping).

OK.

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

[Andy Walls]

On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:

> > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> > end of the month.
> 
> Good! Please, try to design the decoder as an independent module that gets
> data from a kfifo and generate scancodes for the input API.

Hmmm.  Let me see how the protoype turns out keeping that design
objective in mind.  I've already got the current RC-5 and NEC decoding
state machines in cx23885-input a bit layered, but they are taking
advantage of specific events signaled by my v4l2_subdev implementation.

Strictly speaking the state machines don't have to.  All of the remote
protocols I have played with make framing pretty easy.



> > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> > a common set of parameters, so I may be able to set up the decoders to
> > handle decoding from two different remote types at once.  The HVR boards
> > can ship with either type of remote AFAIK.
> > 
> > I wonder if I can flip the keytables on the fly or if I have to create
> > two different input devices?
> 
> IMO, the better is, by default, to open just one input device per IR receiver.
> >From what I understand from our discussions, if the user wants to filter IR
> commands into several input interfaces, some userspace interface will be 
> provided to allow the creation of other input interfaces for that purpose.

Hmm. That's not what I just thought I read from Dmitry....

Oh well.  If I don'y get it done by 24 Dec, it'll be in the new year.


Regards,
Andy

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>
>> > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>> > end of the month.
>> >
>> > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>> > a common set of parameters, so I may be able to set up the decoders to
>> > handle decoding from two different remote types at once.  The HVR boards
>> > can ship with either type of remote AFAIK.
>> >
>> > I wonder if I can flip the keytables on the fly or if I have to create
>> > two different input devices?
>> >
>>
>> Can you distinguish between the 2 remotes (not receivers)?
>
> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
> (Honestly I could pile on more protocols that have similar pulse time
> periods, but that's complexity for no good reason and I don't know of a
> vendor that bundles 3 types of remotes per TV card.)
>
>
>>  Like I said,
>> I think the preferred way is to represent every remote that can be
>> distinguished from each other as a separate input device.
>
> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
> system byte or word to distingish different remotes.  However creating
> multiple input devices on the fly for detected remotes would be madness
> - especially with a decoding error in the address bits.

I agree that creating devices on the fly has problems. Another
solution is to create one device for each map that is loaded. There
would be a couple built-in maps for bundled remotes - each would
create a device. Then the user could load more maps with each map
creating a device.

Incoming scancodes are matched against all of the loaded maps and a
keycode event is generated if a match occurs.

This illustrates why there should an EV_IR event which communicates
scancodes, without this event you can't see the scancodes that don't
match a map entry. A scancode would be first matched against the map,
then if there as no match an EV_IR event would be reported.


>
> Any one vendor usually picks one address for their bundled remote.
> Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.
>
>
>
>>  Applications
>> expect to query device capabilities and expect them to stay somewhat
>> stable (we do support keymap change but I don't think anyone expectes
>> flip-flopping).
>
> OK.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [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]

Andy Walls wrote:
> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> 
>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>> end of the month.
>>>
>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>> a common set of parameters, so I may be able to set up the decoders to
>>> handle decoding from two different remote types at once.  The HVR boards
>>> can ship with either type of remote AFAIK.
>>>
>>> I wonder if I can flip the keytables on the fly or if I have to create
>>> two different input devices?
>>>
>> Can you distinguish between the 2 remotes (not receivers)?
> 
> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
> (Honestly I could pile on more protocols that have similar pulse time
> periods, but that's complexity for no good reason and I don't know of a
> vendor that bundles 3 types of remotes per TV card.)

You'll be distinguishing the protocol, not the remote. If I understood
Dmitry's question, he is asking if you can distinguish between two different
remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
and another RC-6.

>>  Like I said,
>> I think the preferred way is to represent every remote that can be
>> distinguished from each other as a separate input device.
> 
> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
> system byte or word to distingish different remotes.  However creating
> multiple input devices on the fly for detected remotes would be madness
> - especially with a decoding error in the address bits.  
> 
> Any one vendor usually picks one address for their bundled remote.
> Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.

The address field on RC-5 protocol is not meant to distinguish different
vendors, but different "applications". It identifies that a code should
be sent to a TV or a VCR, or a DVD or a SAT.

In the case of bundled IR's, some vendors like Hauppauge opted to use a
reserved address to avoid conflicts with other equipments. It happens that
vendor's "reserved address" can be different between two different vendors,
but is just an educated guess to say that an address equal to 0x1e is Hauppauge.

Cheers,
Mauro.

Re: [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]

Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>> end of the month.
>>>>
>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>> a common set of parameters, so I may be able to set up the decoders to
>>>> handle decoding from two different remote types at once.  The HVR boards
>>>> can ship with either type of remote AFAIK.
>>>>
>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>> two different input devices?
>>>>
>>> Can you distinguish between the 2 remotes (not receivers)?
>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>> (Honestly I could pile on more protocols that have similar pulse time
>> periods, but that's complexity for no good reason and I don't know of a
>> vendor that bundles 3 types of remotes per TV card.)
>>
>>
>>>  Like I said,
>>> I think the preferred way is to represent every remote that can be
>>> distinguished from each other as a separate input device.
>> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
>> system byte or word to distingish different remotes.  However creating
>> multiple input devices on the fly for detected remotes would be madness
>> - especially with a decoding error in the address bits.
> 
> I agree that creating devices on the fly has problems. Another
> solution is to create one device for each map that is loaded. There
> would be a couple built-in maps for bundled remotes - each would
> create a device. Then the user could load more maps with each map
> creating a device.

No, please. We currently have already 89 different keymaps in-kernel. Creating
89 different interfaces per IR receiver is not useful at all.

IMO, the interfaces should be created as the keymaps are associated
to an specific IR receiver.

> Incoming scancodes are matched against all of the loaded maps and a
> keycode event is generated if a match occurs.

s/all of the loaded maps/all of the loaded maps per device/

You may have more than one IR receiver on a given machine.

IMO, we may have a mask filter matching also, associated with each keycode
table, to minimize the keycode seek time. Something like:

	if (scancode & scancode_mask)
		check_scancode()

> This illustrates why there should an EV_IR event which communicates
> scancodes, without this event you can't see the scancodes that don't
> match a map entry. A scancode would be first matched against the map,
> then if there as no match an EV_IR event would be reported.

There's nothing wrong on receiving a scancode that won't map. This can
simply be an event that you don't want to handle (for example, an IR
code sent to user's TV set).

IMO, the better is to provide this scancode at KERN_DEBUG (if debug is
enabled), and via an "observer" program.

Cheers,
Mauro.

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Andy Walls wrote:
>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>
>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>> end of the month.
>>>>
>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>> a common set of parameters, so I may be able to set up the decoders to
>>>> handle decoding from two different remote types at once.  The HVR boards
>>>> can ship with either type of remote AFAIK.
>>>>
>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>> two different input devices?
>>>>
>>> Can you distinguish between the 2 remotes (not receivers)?
>>
>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>> (Honestly I could pile on more protocols that have similar pulse time
>> periods, but that's complexity for no good reason and I don't know of a
>> vendor that bundles 3 types of remotes per TV card.)
>
> You'll be distinguishing the protocol, not the remote. If I understood
> Dmitry's question, he is asking if you can distinguish between two different
> remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
> and another RC-6.

RC-5 and RC-6 both contain an address field.  My opinion is that
different addresses represent different devices and in general they
should appear on an input devices per address.

However, I prefer a different scheme for splitting the signals apart.
Load separate maps containing scancodes for each address. When the IR
signals come in they are matched against the maps and a keycode is
generated when a match is found. Now there is no need to distinguish
between the remotes. It doesn't matter which remote generated the
signal.

scancode RC5/12/1 - protocol, address, command tuplet. Map this to
KP_1 on interface 1.
scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1
on interface 2.

Using the maps to split the commands out also fixes the problem with
Sony remotes which use multiple protocols to control a single device.
scancode Sony12/12/1 - protocol, address, command tuplet. Map this to
power_on on interface 1.
scancode Sony15/12/1 - protocol, address, command tuplet. Map this to
KP_1 on interface 1.


>
>>>  Like I said,
>>> I think the preferred way is to represent every remote that can be
>>> distinguished from each other as a separate input device.
>>
>> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
>> system byte or word to distingish different remotes.  However creating
>> multiple input devices on the fly for detected remotes would be madness
>> - especially with a decoding error in the address bits.
>>
>> Any one vendor usually picks one address for their bundled remote.
>> Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT.
>
> The address field on RC-5 protocol is not meant to distinguish different
> vendors, but different "applications". It identifies that a code should
> be sent to a TV or a VCR, or a DVD or a SAT.
>
> In the case of bundled IR's, some vendors like Hauppauge opted to use a
> reserved address to avoid conflicts with other equipments. It happens that
> vendor's "reserved address" can be different between two different vendors,
> but is just an educated guess to say that an address equal to 0x1e is Hauppauge.
>
> Cheers,
> Mauro.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [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]

Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Andy Walls wrote:
>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>> end of the month.
>>>>>
>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>> can ship with either type of remote AFAIK.
>>>>>
>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>> two different input devices?
>>>>>
>>>> Can you distinguish between the 2 remotes (not receivers)?
>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>> (Honestly I could pile on more protocols that have similar pulse time
>>> periods, but that's complexity for no good reason and I don't know of a
>>> vendor that bundles 3 types of remotes per TV card.)
>> You'll be distinguishing the protocol, not the remote. If I understood
>> Dmitry's question, he is asking if you can distinguish between two different
>> remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
>> and another RC-6.
> 
> RC-5 and RC-6 both contain an address field.  My opinion is that
> different addresses represent different devices and in general they
> should appear on an input devices per address.

The same IR can produce two different addresses. The IR bundled with my satellite
STB produces two different codes, depending if you previously pressed <TV> or <SAT>
key (in fact, I think it can even produce different protocols for TV, as it can
be configured to work with different TV sets).

> However, I prefer a different scheme for splitting the signals apart.
> Load separate maps containing scancodes for each address. When the IR
> signals come in they are matched against the maps and a keycode is
> generated when a match is found. Now there is no need to distinguish
> between the remotes. It doesn't matter which remote generated the
> signal.
> 
> scancode RC5/12/1 - protocol, address, command tuplet. Map this to
> KP_1 on interface 1.
> scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1
> on interface 2.
> 
> Using the maps to split the commands out also fixes the problem with
> Sony remotes which use multiple protocols to control a single device.
> scancode Sony12/12/1 - protocol, address, command tuplet. Map this to
> power_on on interface 1.
> scancode Sony15/12/1 - protocol, address, command tuplet. Map this to
> KP_1 on interface 1.
> 

I agree.

Cheers,
Mauro.

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>> end of the month.
>>>>>
>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>> can ship with either type of remote AFAIK.
>>>>>
>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>> two different input devices?
>>>>>
>>>> Can you distinguish between the 2 remotes (not receivers)?
>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>> (Honestly I could pile on more protocols that have similar pulse time
>>> periods, but that's complexity for no good reason and I don't know of a
>>> vendor that bundles 3 types of remotes per TV card.)
>>>
>>>
>>>>  Like I said,
>>>> I think the preferred way is to represent every remote that can be
>>>> distinguished from each other as a separate input device.
>>> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
>>> system byte or word to distingish different remotes.  However creating
>>> multiple input devices on the fly for detected remotes would be madness
>>> - especially with a decoding error in the address bits.
>>
>> I agree that creating devices on the fly has problems. Another
>> solution is to create one device for each map that is loaded. There
>> would be a couple built-in maps for bundled remotes - each would
>> create a device. Then the user could load more maps with each map
>> creating a device.
>
> No, please. We currently have already 89 different keymaps in-kernel. Creating
> 89 different interfaces per IR receiver is not useful at all.
>
> IMO, the interfaces should be created as the keymaps are associated
> to an specific IR receiver.

Each IR receiver device driver would have a built-in keymap for the
remote bundled with it. When you load the driver it will poke the
input system and install the map. Any additional keymaps would get
loaded from user space. You would load one keymap per input device.

You might have 89 maps in the kernel with each map being built into
the device driver for those 89 IR receivers. But you'll only own one
or two of those devices so only one or two of the 89 maps will load.
Building the map for the bundled receiver into the device driver is an
important part of achieving "just works".

I suspect we'll have a 1,000 maps defined after ten years, most of
these maps will be loaded from user space. But you'll only have two or
three loaded at any one time into your kernel. You need one map per
input device created. These maps are tiny, less than 1KB.

Having all of these maps is the price of allowing everyone to use any
more that they please. If you force the use of universal remotes most
of the maps can be eliminated.



>
>> Incoming scancodes are matched against all of the loaded maps and a
>> keycode event is generated if a match occurs.
>
> s/all of the loaded maps/all of the loaded maps per device/
>
> You may have more than one IR receiver on a given machine.
>
> IMO, we may have a mask filter matching also, associated with each keycode
> table, to minimize the keycode seek time. Something like:
>
>        if (scancode & scancode_mask)
>                check_scancode()
>
>> This illustrates why there should an EV_IR event which communicates
>> scancodes, without this event you can't see the scancodes that don't
>> match a map entry. A scancode would be first matched against the map,
>> then if there as no match an EV_IR event would be reported.
>
> There's nothing wrong on receiving a scancode that won't map. This can
> simply be an event that you don't want to handle (for example, an IR
> code sent to user's TV set).
>
> IMO, the better is to provide this scancode at KERN_DEBUG (if debug is
> enabled), and via an "observer" program.
>
> Cheers,
> Mauro.
>



-- 
Jon Smirl
jonsmirl@gmail.com

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

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> With RC-5, you have no fields describing the remote. So, all the driver could
> do is an educated guess.

It can't even do that, e.g. single remotes (even the dumb ones) can send
different code groups (addresses) for different keys.

> IMO, the better is to have an API to allow creation of multiple interfaces
> per IR receiver, based on some scancode matching table and/or on some
> matching mask.

I think setting the keytables for each logical device would do.

I.e. just have a way to create additional logical devices. Each can have
its own keytable. The decoders would send their output to all logical
remotes, trying to match the tables etc.

> It should be possible to use the filter API to match different IR's by
> vendor/product on protocols that supports it,

That would mean unnecessary limiting.

> or to match address/command
> tuples on protocols where you just have those fields.

Precisely.
-- 
Krzysztof Halasa

Re: [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]

Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>> end of the month.
>>>>>>
>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>> can ship with either type of remote AFAIK.
>>>>>>
>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>> two different input devices?
>>>>>>
>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>> periods, but that's complexity for no good reason and I don't know of a
>>>> vendor that bundles 3 types of remotes per TV card.)
>>>>
>>>>
>>>>>  Like I said,
>>>>> I think the preferred way is to represent every remote that can be
>>>>> distinguished from each other as a separate input device.
>>>> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
>>>> system byte or word to distingish different remotes.  However creating
>>>> multiple input devices on the fly for detected remotes would be madness
>>>> - especially with a decoding error in the address bits.
>>> I agree that creating devices on the fly has problems. Another
>>> solution is to create one device for each map that is loaded. There
>>> would be a couple built-in maps for bundled remotes - each would
>>> create a device. Then the user could load more maps with each map
>>> creating a device.
>> No, please. We currently have already 89 different keymaps in-kernel. Creating
>> 89 different interfaces per IR receiver is not useful at all.
>>
>> IMO, the interfaces should be created as the keymaps are associated
>> to an specific IR receiver.
> 
> Each IR receiver device driver would have a built-in keymap for the
> remote bundled with it. When you load the driver it will poke the
> input system and install the map. Any additional keymaps would get
> loaded from user space. You would load one keymap per input device.
> 
> You might have 89 maps in the kernel with each map being built into
> the device driver for those 89 IR receivers. But you'll only own one
> or two of those devices so only one or two of the 89 maps will load.
> Building the map for the bundled receiver into the device driver is an
> important part of achieving "just works".
> 
> I suspect we'll have a 1,000 maps defined after ten years, most of
> these maps will be loaded from user space. But you'll only have two or
> three loaded at any one time into your kernel. You need one map per
> input device created. These maps are tiny, less than 1KB.
> 
> Having all of these maps is the price of allowing everyone to use any
> more that they please. If you force the use of universal remotes most
> of the maps can be eliminated.

Makes sense. Yet, I would add an option at Kbuild to create a module or not
with the bundled IR keymaps.

So, it should be possible to have all of them completely on userspace or
having them at kernelspace.

Cheers,
Mauro.

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Andy Walls wrote:
>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>> end of the month.
>>>>>>
>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>> can ship with either type of remote AFAIK.
>>>>>>
>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>> two different input devices?
>>>>>>
>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>> periods, but that's complexity for no good reason and I don't know of a
>>>> vendor that bundles 3 types of remotes per TV card.)
>>> You'll be distinguishing the protocol, not the remote. If I understood
>>> Dmitry's question, he is asking if you can distinguish between two different
>>> remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
>>> and another RC-6.
>>
>> RC-5 and RC-6 both contain an address field.  My opinion is that
>> different addresses represent different devices and in general they
>> should appear on an input devices per address.
>
> The same IR can produce two different addresses. The IR bundled with my satellite
> STB produces two different codes, depending if you previously pressed <TV> or <SAT>
> key (in fact, I think it can even produce different protocols for TV, as it can
> be configured to work with different TV sets).

You have a multi-function remote. Multi-function remotes combine
multiple single function remotes into a single device. All universal
remotes I have seen are multi-function. They usually combine three to
five single function remotes.

Yours is a two function remote <TV> and <SAT>. When you push <TV> and
<SAT> you are changing which single function remote is being emulated.
That's why those keys don't send codes. When writing code you should
think of this remote as being two indpendent virtual remotes, not a
single one.

Note that it is common for multfunction remotes to completely change
IR protocol families when you switch which single function remote you
are emulating. I have my universal set for a Sony TV , JVC DVD player
and a Comcast STB. All three of those use different IR protocols.

By using maps containing the two different addresses for <TV> and
<SAT> you can split these commands onto two different evdev devices.

This model is complicated by the fact that some remotes that look like
multi-function remotes aren't really multifunction. The remote bundled
with the MS MCE receiver is one. That remote is a single function
device even though it has function buttons for TV, Music, Pictures,
etc.


>
>> However, I prefer a different scheme for splitting the signals apart.
>> Load separate maps containing scancodes for each address. When the IR
>> signals come in they are matched against the maps and a keycode is
>> generated when a match is found. Now there is no need to distinguish
>> between the remotes. It doesn't matter which remote generated the
>> signal.
>>
>> scancode RC5/12/1 - protocol, address, command tuplet. Map this to
>> KP_1 on interface 1.
>> scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1
>> on interface 2.
>>
>> Using the maps to split the commands out also fixes the problem with
>> Sony remotes which use multiple protocols to control a single device.
>> scancode Sony12/12/1 - protocol, address, command tuplet. Map this to
>> power_on on interface 1.
>> scancode Sony15/12/1 - protocol, address, command tuplet. Map this to
>> KP_1 on interface 1.
>>
>
> I agree.
>
> Cheers,
> Mauro.
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [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]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
>> IMO, the better is to have an API to allow creation of multiple interfaces
>> per IR receiver, based on some scancode matching table and/or on some
>> matching mask.
> 
> I think setting the keytables for each logical device would do.

Yes.
> 
> I.e. just have a way to create additional logical devices. Each can have
> its own keytable. The decoders would send their output to all logical
> remotes, trying to match the tables etc.
> 
>> It should be possible to use the filter API to match different IR's by
>> vendor/product on protocols that supports it,
> 
> That would mean unnecessary limiting.

If the mask is (unsigned)-1, it will not add any limit. This should be the default.

The advantage of the mask is that you can speedup the keycode decoding by not calling
a seek routine in the cases where it doesn't make sense.

Also, the cost of scancode & scancode_mask is cheap enough, comparing with the 
potential optimization gain of not seeking a data in a table that wouldn't match anyway.

Also, the IR core may automatically generate such mask, by doing an "and" operation of all
the scancodes at the table during table initialization/changes. If the mask is zero, it
defaults to use a (unsigned) -1 mask.

Cheers,
Mauro.

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Jon Smirl wrote:
>>>> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
>>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>>> end of the month.
>>>>>>>
>>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>>> can ship with either type of remote AFAIK.
>>>>>>>
>>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>>> two different input devices?
>>>>>>>
>>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>>> periods, but that's complexity for no good reason and I don't know of a
>>>>> vendor that bundles 3 types of remotes per TV card.)
>>>>>
>>>>>
>>>>>>  Like I said,
>>>>>> I think the preferred way is to represent every remote that can be
>>>>>> distinguished from each other as a separate input device.
>>>>> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
>>>>> system byte or word to distingish different remotes.  However creating
>>>>> multiple input devices on the fly for detected remotes would be madness
>>>>> - especially with a decoding error in the address bits.
>>>> I agree that creating devices on the fly has problems. Another
>>>> solution is to create one device for each map that is loaded. There
>>>> would be a couple built-in maps for bundled remotes - each would
>>>> create a device. Then the user could load more maps with each map
>>>> creating a device.
>>> No, please. We currently have already 89 different keymaps in-kernel. Creating
>>> 89 different interfaces per IR receiver is not useful at all.
>>>
>>> IMO, the interfaces should be created as the keymaps are associated
>>> to an specific IR receiver.
>>
>> Each IR receiver device driver would have a built-in keymap for the
>> remote bundled with it. When you load the driver it will poke the
>> input system and install the map. Any additional keymaps would get
>> loaded from user space. You would load one keymap per input device.
>>
>> You might have 89 maps in the kernel with each map being built into
>> the device driver for those 89 IR receivers. But you'll only own one
>> or two of those devices so only one or two of the 89 maps will load.
>> Building the map for the bundled receiver into the device driver is an
>> important part of achieving "just works".
>>
>> I suspect we'll have a 1,000 maps defined after ten years, most of
>> these maps will be loaded from user space. But you'll only have two or
>> three loaded at any one time into your kernel. You need one map per
>> input device created. These maps are tiny, less than 1KB.
>>
>> Having all of these maps is the price of allowing everyone to use any
>> more that they please. If you force the use of universal remotes most
>> of the maps can be eliminated.
>
> Makes sense. Yet, I would add an option at Kbuild to create a module or not
> with the bundled IR keymaps.
>
> So, it should be possible to have all of them completely on userspace or
> having them at kernelspace.

Removing the maps for the bundled remotes from the receiver device
drivers will break "just works". The map will be in an __init section
of the IR device driver. When it is fed into the input system a RAM
based structure will be created. If you really want the 1KB memory
back, use sysfs to remove the default map.  An embedded system will
have a bundled remote so it is going to want the map. If you want to
change the default map loading a new map will release the memory from
the previous map.

>
> Cheers,
> Mauro.
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [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]

Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Andy Walls wrote:
>>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>>> end of the month.
>>>>>>>
>>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>>> can ship with either type of remote AFAIK.
>>>>>>>
>>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>>> two different input devices?
>>>>>>>
>>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>>> periods, but that's complexity for no good reason and I don't know of a
>>>>> vendor that bundles 3 types of remotes per TV card.)
>>>> You'll be distinguishing the protocol, not the remote. If I understood
>>>> Dmitry's question, he is asking if you can distinguish between two different
>>>> remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
>>>> and another RC-6.
>>> RC-5 and RC-6 both contain an address field.  My opinion is that
>>> different addresses represent different devices and in general they
>>> should appear on an input devices per address.
>> The same IR can produce two different addresses. The IR bundled with my satellite
>> STB produces two different codes, depending if you previously pressed <TV> or <SAT>
>> key (in fact, I think it can even produce different protocols for TV, as it can
>> be configured to work with different TV sets).
> 
> You have a multi-function remote.

Yes.

> That's why those keys don't send codes. When writing code you should
> think of this remote as being two indpendent virtual remotes, not a
> single one.

Not really. I may think on it as a single device and use the two groups
of functions to control two aspects at the same application.

For example, I may map the <TV> group on kaffeine for DVB reception and the
<SAT> group for DVD (well, probably, in this case, I'll use an IR with
<TV> and <DVD> keys, instead ;) ).

> By using maps containing the two different addresses for <TV> and
> <SAT> you can split these commands onto two different evdev devices.

True. I can do it, but I can opt to have both mapped as one evdev device as well.
This will basically depend on how I want to mount my environment.
 
> This model is complicated by the fact that some remotes that look like
> multi-function remotes aren't really multifunction. The remote bundled
> with the MS MCE receiver is one. That remote is a single function
> device even though it has function buttons for TV, Music, Pictures,
> etc.

It is very common to have such remotes bundled with multimedia devices.

An unsolved question on my mind is how should we map such IR's? Should we
provide a way for them to emulate a multifunction IR (for example, after pressing
TV key, subsequent keystrokes would be directed to the TV evdev device?), or
should we let this up to some userspace app to handle this case?
 
Cheers,
Mauro.

Re: [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]

Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Jon Smirl wrote:
>>>>> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
>>>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>>>> end of the month.
>>>>>>>>
>>>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>>>> can ship with either type of remote AFAIK.
>>>>>>>>
>>>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>>>> two different input devices?
>>>>>>>>
>>>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>>>> periods, but that's complexity for no good reason and I don't know of a
>>>>>> vendor that bundles 3 types of remotes per TV card.)
>>>>>>
>>>>>>
>>>>>>>  Like I said,
>>>>>>> I think the preferred way is to represent every remote that can be
>>>>>>> distinguished from each other as a separate input device.
>>>>>> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
>>>>>> system byte or word to distingish different remotes.  However creating
>>>>>> multiple input devices on the fly for detected remotes would be madness
>>>>>> - especially with a decoding error in the address bits.
>>>>> I agree that creating devices on the fly has problems. Another
>>>>> solution is to create one device for each map that is loaded. There
>>>>> would be a couple built-in maps for bundled remotes - each would
>>>>> create a device. Then the user could load more maps with each map
>>>>> creating a device.
>>>> No, please. We currently have already 89 different keymaps in-kernel. Creating
>>>> 89 different interfaces per IR receiver is not useful at all.
>>>>
>>>> IMO, the interfaces should be created as the keymaps are associated
>>>> to an specific IR receiver.
>>> Each IR receiver device driver would have a built-in keymap for the
>>> remote bundled with it. When you load the driver it will poke the
>>> input system and install the map. Any additional keymaps would get
>>> loaded from user space. You would load one keymap per input device.
>>>
>>> You might have 89 maps in the kernel with each map being built into
>>> the device driver for those 89 IR receivers. But you'll only own one
>>> or two of those devices so only one or two of the 89 maps will load.
>>> Building the map for the bundled receiver into the device driver is an
>>> important part of achieving "just works".
>>>
>>> I suspect we'll have a 1,000 maps defined after ten years, most of
>>> these maps will be loaded from user space. But you'll only have two or
>>> three loaded at any one time into your kernel. You need one map per
>>> input device created. These maps are tiny, less than 1KB.
>>>
>>> Having all of these maps is the price of allowing everyone to use any
>>> more that they please. If you force the use of universal remotes most
>>> of the maps can be eliminated.
>> Makes sense. Yet, I would add an option at Kbuild to create a module or not
>> with the bundled IR keymaps.
>>
>> So, it should be possible to have all of them completely on userspace or
>> having them at kernelspace.
> 
> Removing the maps for the bundled remotes from the receiver device
> drivers will break "just works". 

No. This can be provided by an udev application that will load the keytable
when the device is connected.

Of course before adding it into a module, we'll need to write such app.

This will only affects the need of IR during boot time.

> The map will be in an __init section
> of the IR device driver. When it is fed into the input system a RAM
> based structure will be created. 

We can't use __init, since another device needing the keymap may be hot-plugged.

> If you really want the 1KB memory
> back, use sysfs to remove the default map.  An embedded system will
> have a bundled remote so it is going to want the map. 

Yes, but it needs just one map, not all of them. The maps shouldn't be linked
into the drivers, as the same map is used by several different devices on
different drivers. So, the option is to allow customizing the available keymaps,
if CONFIG_EMBEDDED.

Cheers,
Mauro.

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Jon Smirl wrote:
>>>> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
>>>> <mchehab@redhat.com> wrote:
>>>>> Andy Walls wrote:
>>>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>>>> end of the month.
>>>>>>>>
>>>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>>>> can ship with either type of remote AFAIK.
>>>>>>>>
>>>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>>>> two different input devices?
>>>>>>>>
>>>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>>>> periods, but that's complexity for no good reason and I don't know of a
>>>>>> vendor that bundles 3 types of remotes per TV card.)
>>>>> You'll be distinguishing the protocol, not the remote. If I understood
>>>>> Dmitry's question, he is asking if you can distinguish between two different
>>>>> remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
>>>>> and another RC-6.
>>>> RC-5 and RC-6 both contain an address field.  My opinion is that
>>>> different addresses represent different devices and in general they
>>>> should appear on an input devices per address.
>>> The same IR can produce two different addresses. The IR bundled with my satellite
>>> STB produces two different codes, depending if you previously pressed <TV> or <SAT>
>>> key (in fact, I think it can even produce different protocols for TV, as it can
>>> be configured to work with different TV sets).
>>
>> You have a multi-function remote.
>
> Yes.
>
>> That's why those keys don't send codes. When writing code you should
>> think of this remote as being two indpendent virtual remotes, not a
>> single one.
>
> Not really. I may think on it as a single device and use the two groups
> of functions to control two aspects at the same application.
>
> For example, I may map the <TV> group on kaffeine for DVB reception and the
> <SAT> group for DVD (well, probably, in this case, I'll use an IR with
> <TV> and <DVD> keys, instead ;) ).
>
>> By using maps containing the two different addresses for <TV> and
>> <SAT> you can split these commands onto two different evdev devices.
>
> True. I can do it, but I can opt to have both mapped as one evdev device as well.
> This will basically depend on how I want to mount my environment.
>
>> This model is complicated by the fact that some remotes that look like
>> multi-function remotes aren't really multifunction. The remote bundled
>> with the MS MCE receiver is one. That remote is a single function
>> device even though it has function buttons for TV, Music, Pictures,
>> etc.
>
> It is very common to have such remotes bundled with multimedia devices.
>
> An unsolved question on my mind is how should we map such IR's? Should we
> provide a way for them to emulate a multifunction IR (for example, after pressing
> TV key, subsequent keystrokes would be directed to the TV evdev device?), or
> should we let this up to some userspace app to handle this case?

Splitting them into multiple devices requires remembering state and
scripting so it needs to be done in user space. If the user wants to
control a radio app and a home automation app they need to choose.
Keep the bundled remote and do some non-trivial scripting or buy a
universal remote.

Universal remotes make it much easier to achieve "just works".

The IR core can contain default universal profiles for various classes
of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check
if the receiver is cable of receiving these profiles before loading
them. There would be ten of these default universal profiles at most
and you can unload them from RAM if they aren't needed.

Now Myth can have a menu with three remote choices:
 Universal Morotola_DVR
 Universal SciAtlanta_DVR
 Bundled

The Bundled choice came from the map built into the IR receiver's device driver.
The other two choices were loaded by the IR core after ensuring that
the hardware could receive from a universal remote.

The core would also load a couple of default radio profiles
 Univeral SonyDR112_RADIO
 Univeral OnkyoTX8255_RADIO
Same for automation and mouse/keyboard emulation.

Myth looks in sysfs and builds a menu containing DVR devices and all
bundled entries. First app to open the "Bundled" device gets to keep
it.

These apps could take "just works" even farther. When they start up
they could listen on all three evdev devices:  Morotola_DVR,
SciAtlanta_DVR,   Bundled. And then if you find Myth responding to
unwanted commands you could disable the unwanted profiles by
deselecting them in the Myth UI.

All of this may seem complicated to build, but the purpose is to
create an environment where a non-technical user can get an IR remote
working without needing detailed knowledge about how IR protocols
work.







-- 
Jon Smirl
jonsmirl@gmail.com

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 9:40 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Jon Smirl wrote:
>>>> On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab
>>>> <mchehab@redhat.com> wrote:
>>>>> Jon Smirl wrote:
>>>>>> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
>>>>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>>>>> end of the month.
>>>>>>>>>
>>>>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>>>>> can ship with either type of remote AFAIK.
>>>>>>>>>
>>>>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>>>>> two different input devices?
>>>>>>>>>
>>>>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>>>>> periods, but that's complexity for no good reason and I don't know of a
>>>>>>> vendor that bundles 3 types of remotes per TV card.)
>>>>>>>
>>>>>>>
>>>>>>>>  Like I said,
>>>>>>>> I think the preferred way is to represent every remote that can be
>>>>>>>> distinguished from each other as a separate input device.
>>>>>>> OK.  With RC-5, NEC, and RC-6 at least there is also an address or
>>>>>>> system byte or word to distingish different remotes.  However creating
>>>>>>> multiple input devices on the fly for detected remotes would be madness
>>>>>>> - especially with a decoding error in the address bits.
>>>>>> I agree that creating devices on the fly has problems. Another
>>>>>> solution is to create one device for each map that is loaded. There
>>>>>> would be a couple built-in maps for bundled remotes - each would
>>>>>> create a device. Then the user could load more maps with each map
>>>>>> creating a device.
>>>>> No, please. We currently have already 89 different keymaps in-kernel. Creating
>>>>> 89 different interfaces per IR receiver is not useful at all.
>>>>>
>>>>> IMO, the interfaces should be created as the keymaps are associated
>>>>> to an specific IR receiver.
>>>> Each IR receiver device driver would have a built-in keymap for the
>>>> remote bundled with it. When you load the driver it will poke the
>>>> input system and install the map. Any additional keymaps would get
>>>> loaded from user space. You would load one keymap per input device.
>>>>
>>>> You might have 89 maps in the kernel with each map being built into
>>>> the device driver for those 89 IR receivers. But you'll only own one
>>>> or two of those devices so only one or two of the 89 maps will load.
>>>> Building the map for the bundled receiver into the device driver is an
>>>> important part of achieving "just works".
>>>>
>>>> I suspect we'll have a 1,000 maps defined after ten years, most of
>>>> these maps will be loaded from user space. But you'll only have two or
>>>> three loaded at any one time into your kernel. You need one map per
>>>> input device created. These maps are tiny, less than 1KB.
>>>>
>>>> Having all of these maps is the price of allowing everyone to use any
>>>> more that they please. If you force the use of universal remotes most
>>>> of the maps can be eliminated.
>>> Makes sense. Yet, I would add an option at Kbuild to create a module or not
>>> with the bundled IR keymaps.
>>>
>>> So, it should be possible to have all of them completely on userspace or
>>> having them at kernelspace.
>>
>> Removing the maps for the bundled remotes from the receiver device
>> drivers will break "just works".
>
> No. This can be provided by an udev application that will load the keytable
> when the device is connected.

Why do you want to pull the 1KB default mapping table out of the
device driver __init section and more it to a udev script? Now we will
have to maintain a parallel udev script for ever receiver's device
driver.

The purpose of putting this table into __init is to get rid of all
these udev scripts in the default case.

>
> Of course before adding it into a module, we'll need to write such app.
>
> This will only affects the need of IR during boot time.
>
>> The map will be in an __init section
>> of the IR device driver. When it is fed into the input system a RAM
>> based structure will be created.
>
> We can't use __init, since another device needing the keymap may be hot-plugged.

You can handle that with __devinit


>> If you really want the 1KB memory
>> back, use sysfs to remove the default map.  An embedded system will
>> have a bundled remote so it is going to want the map.
>
> Yes, but it needs just one map, not all of them. The maps shouldn't be linked
> into the drivers, as the same map is used by several different devices on

Link them or #include them, it doesn't make any difference.

> different drivers. So, the option is to allow customizing the available keymaps,
> if CONFIG_EMBEDDED.
>
> Cheers,
> Mauro.
>



-- 
Jon Smirl
jonsmirl@gmail.com

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

[Ferenc Wagner]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> Jon Smirl wrote:
>
>> This model is complicated by the fact that some remotes that look
>> like multi-function remotes aren't really multifunction. The remote
>> bundled with the MS MCE receiver is one. That remote is a single
>> function device even though it has function buttons for TV, Music,
>> Pictures, etc.
>
> An unsolved question on my mind is how should we map such IR's? Should
> we provide a way for them to emulate a multifunction IR (for example,
> after pressing TV key, subsequent keystrokes would be directed to the
> TV evdev device?), or should we let this up to some userspace app to
> handle this case?

This case feels similar to that of Caps Lock, Num Lock and Scrool Lock,
but I don't know if that scheme could be applied here.
-- 
Regards,
Feri.

Re: [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]

Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Jon Smirl wrote:
>>> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Jon Smirl wrote:
>>>>> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
>>>>> <mchehab@redhat.com> wrote:
>>>>>> Andy Walls wrote:
>>>>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>>>>> end of the month.
>>>>>>>>>
>>>>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>>>>> can ship with either type of remote AFAIK.
>>>>>>>>>
>>>>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>>>>> two different input devices?
>>>>>>>>>
>>>>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>>>>> periods, but that's complexity for no good reason and I don't know of a
>>>>>>> vendor that bundles 3 types of remotes per TV card.)
>>>>>> You'll be distinguishing the protocol, not the remote. If I understood
>>>>>> Dmitry's question, he is asking if you can distinguish between two different
>>>>>> remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
>>>>>> and another RC-6.
>>>>> RC-5 and RC-6 both contain an address field.  My opinion is that
>>>>> different addresses represent different devices and in general they
>>>>> should appear on an input devices per address.
>>>> The same IR can produce two different addresses. The IR bundled with my satellite
>>>> STB produces two different codes, depending if you previously pressed <TV> or <SAT>
>>>> key (in fact, I think it can even produce different protocols for TV, as it can
>>>> be configured to work with different TV sets).
>>> You have a multi-function remote.
>> Yes.
>>
>>> That's why those keys don't send codes. When writing code you should
>>> think of this remote as being two indpendent virtual remotes, not a
>>> single one.
>> Not really. I may think on it as a single device and use the two groups
>> of functions to control two aspects at the same application.
>>
>> For example, I may map the <TV> group on kaffeine for DVB reception and the
>> <SAT> group for DVD (well, probably, in this case, I'll use an IR with
>> <TV> and <DVD> keys, instead ;) ).
>>
>>> By using maps containing the two different addresses for <TV> and
>>> <SAT> you can split these commands onto two different evdev devices.
>> True. I can do it, but I can opt to have both mapped as one evdev device as well.
>> This will basically depend on how I want to mount my environment.
>>
>>> This model is complicated by the fact that some remotes that look like
>>> multi-function remotes aren't really multifunction. The remote bundled
>>> with the MS MCE receiver is one. That remote is a single function
>>> device even though it has function buttons for TV, Music, Pictures,
>>> etc.
>> It is very common to have such remotes bundled with multimedia devices.
>>
>> An unsolved question on my mind is how should we map such IR's? Should we
>> provide a way for them to emulate a multifunction IR (for example, after pressing
>> TV key, subsequent keystrokes would be directed to the TV evdev device?), or
>> should we let this up to some userspace app to handle this case?
> 
> Splitting them into multiple devices requires remembering state and
> scripting so it needs to be done in user space.

It shouldn't be hard to do it in kernelspace, since you'll need to have
one evdev interface associated with the IR anyway, but this will add
some extra complexity at the scancode->keycode conversion, but I'm wandering
if we should do it or not.

Maybe the better is to not do it in kernelspace, to avoid adding there an
extra complexity that can easily be done in userspace.

> If the user wants to
> control a radio app and a home automation app they need to choose.
> Keep the bundled remote and do some non-trivial scripting or buy a
> universal remote.

Ok, but using the shipped IR even without a separate address group for
different applications, and having it controlling radio app and tv app
(not simultaneously) should not be hard, but I LIRC already covers such
usecase, so maybe we don't need to worry about it.

> Universal remotes make it much easier to achieve "just works".

True.

> The IR core can contain default universal profiles for various classes
> of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check
> if the receiver is cable of receiving these profiles before loading
> them. There would be ten of these default universal profiles at most
> and you can unload them from RAM if they aren't needed.
> 
> Now Myth can have a menu with three remote choices:
>  Universal Morotola_DVR
>  Universal SciAtlanta_DVR
>  Bundled
> 
> The Bundled choice came from the map built into the IR receiver's device driver.
> The other two choices were loaded by the IR core after ensuring that
> the hardware could receive from a universal remote.
> 
> The core would also load a couple of default radio profiles
>  Univeral SonyDR112_RADIO
>  Univeral OnkyoTX8255_RADIO
> Same for automation and mouse/keyboard emulation.

Agreed.

> Myth looks in sysfs and builds a menu containing DVR devices and all
> bundled entries. First app to open the "Bundled" device gets to keep
> it.

Myth (or other userspace apps) don't need to to that, since we've standardized
the keycode actions (see the IR chapter of the media DocBook). It just
needs to support the keycodes already defined, for the common case.

> These apps could take "just works" even farther. When they start up
> they could listen on all three evdev devices:  Morotola_DVR,
> SciAtlanta_DVR,   Bundled. And then if you find Myth responding to
> unwanted commands you could disable the unwanted profiles by
> deselecting them in the Myth UI.

I don't like the idea of automatically loading 3 different keycodes at the
same time. You may have overlaps between different keycode tables. The
better is to have some userspace GUI that will allow the user to select
what keycode table(s) he want to be available, if he decides to not use the
bundled IR.

The same applies to applications: if you have 3 keymaps loaded, is because you
want do do different things with the 3 keymaps (like using keymap 1 for kaffeine,
keymap 2 for mplayer, keymap 3 for mythtv).

So, IR-aware applications should have a setup interface to specify what IR keycodes
are relevant to that particular application, and how to associate an evdev interface
to an specific group of functions (for applications that supports several different
types of media, like MythTV and Kaffeine, where you'll end by having a "TV" keymap/evdev,
a "Radio" keymap/evdev, a "CD/DVD" Keymap/evdev, etc).

Btw, if we're doing that, IMO, we should have an string sysfs alias attribute,
to allow associating the userspace application to an specific keymap alias 
(like "radio", "tv", etc.).

> All of this may seem complicated to build, but the purpose is to
> create an environment where a non-technical user can get an IR remote
> working without needing detailed knowledge about how IR protocols
> work.

IMO, this is an important requisite to fulfill.

Cheers,
Mauro.

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

[Dmitry Torokhov]

On Tue, Dec 08, 2009 at 09:44:29AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> >> On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> >>> On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
> >>>
> >>>> On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
> >>>>> Krzysztof Halasa wrote:
> >>>>>> Andy Walls <awalls@radix.net> writes:
> >>>>>>
> >>>>>>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
> >>>>>>> developed by Philips, but Microsoft has some sort of licensing interest
> >>>>>>> in it and it is almost surely encumbered somwhow:
> >>>>>> I don't know about legal problems in some countries but from the
> >>>>>> technical POV handling the protocol in the kernel is more efficient
> >>>>>> or (/and) simpler.
> >>>>> A software licensing from Microsoft won't apply to Linux kernel, so I'm
> >>>>> assuming that you're referring to some patent that they could be filled
> >>>>> about RC6 mode 6A.
> >>>>>
> >>>>> I don't know if is there any US patent pending about it (AFAIK, only US
> >>>>> accepts software patents), but there are some prior-art for IR key
> >>>>> decoding. So, I don't see what "innovation" RC6 would be adding. 
> >>>>> If it is some new way to transmit waves, the patent issues
> >>>>> aren't related to software, and the device manufacturer had already handled
> >>>>> it when they made their devices.
> >>>>>
> >>>>> If it is just a new keytable, this issue 
> >>>>> could be easily solved by loading the keytable via userspace.
> >>>>>
> >>>>> Also, assuming that you can use the driver only with a hardware that comes
> >>>>> with a licensed software, the user has already the license for using it.
> >>>>>
> >>>>> Do you have any details on what patents they are claiming?
> >>>> The US Philips RC-6 patent is US Patent 5,877,702
> >>>>
> >>>> http://www.google.com/patents?vid=USPAT5877702
> >>>>
> >>>> Click on download PDF to get a copy of the whole patent.
> >>>>
> >>>> I am not a lawyer.  Philips claims' all appear to tie to a transmitter
> >>>> or receiver as part of a system, but most of the claims are about
> >>>> information and bit positions and lengths.
> >>> ...
> >>>> IMO, given
> >>>>
> >>>> a. the dearth of public information about RC-6, indicating someone
> >>>> thinks it's their trade secret or intellectual property
> >>>>
> >>>> b. Microsoft claiming to license something related to the MCE remote
> >>>> protocols (which are obviously RC-6 Mode 6A),
> >>>>
> >>>> c. my inability to draw a "clear, bright line" that RC-6 Mode 6A
> >>>> encoding and decoding, as needed by MCE remotes, implemented in software
> >>>> doesn't violate anyone's government granted rights to exclusivity.
> >>>>
> >>>> I think it's much better to implement software RC-6 Mode 6A encoding and
> >>>> decoding in user space, doing only the minimum needed to get the
> >>>> hardware setup and going in the kernel.  
> >>>>
> >>>> Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
> >>>> worry me. 
> >>>>
> >>>>
> >>>> Maybe I'm being too conservative here, but I have a personal interest in
> >>>> keeping Linux free and unencumbered even in the US which, I cannot deny,
> >>>> has a patent system that is screwed up.
> >>> So I had one of the people who does all the license and patent audits
> >>> for Fedora packages look at the Philips patent on RC-6. He's 100%
> >>> positive that the patent *only* covers hardware, there should be no
> >>> problem whatsoever writing a software decoder for RC-6.
> >> OK.  Thanks for having some professionals take a look.  (I'm assuming
> >> that's the only patent.)
> >>
> >> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> >> end of the month.
> >>
> >> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> >> a common set of parameters, so I may be able to set up the decoders to
> >> handle decoding from two different remote types at once.  The HVR boards
> >> can ship with either type of remote AFAIK.
> >>
> >> I wonder if I can flip the keytables on the fly or if I have to create
> >> two different input devices?
> >>
> > 
> > Can you distinguish between the 2 remotes (not receivers)? Like I said,
> > I think the preferred way is to represent every remote that can be
> > distinguished from each other as a separate input device. Applications
> > expect to query device capabilities and expect them to stay somewhat
> > stable (we do support keymap change but I don't think anyone expectes
> > flip-flopping).
> > 
> With RC-5, you have no fields describing the remote. So, all the driver could
> do is an educated guess.
> 
> From a quick look I did at the RC-6 Mode 6A docs I found, I suspect that
> you can distinguish two different remotes when someone press a key there.
> 
> However, I don't think it is a good idea to automatically create a new interface
> every time a different vendor is detected. Maybe the user simply have a
> RC-6 IR to control his TV and doesn't have any intention on using that
> device on his computer.
> 
> IMO, the better is to have an API to allow creation of multiple interfaces
> per IR receiver, based on some scancode matching table and/or on some
> matching mask.
> 
> It should be possible to use the filter API to match different IR's by
> vendor/product on protocols that supports it, or to match address/command
> tuples on protocols where you just have those fields.
> 

OK, fair enough.

-- 
Dmitry

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

[Dmitry Torokhov]

On Tue, Dec 08, 2009 at 07:52:02AM -0500, Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls <awalls@radix.net> wrote:
> > On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> >> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
> >
> >> > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> >> > end of the month.
> >> >
> >> > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> >> > a common set of parameters, so I may be able to set up the decoders to
> >> > handle decoding from two different remote types at once.  The HVR boards
> >> > can ship with either type of remote AFAIK.
> >> >
> >> > I wonder if I can flip the keytables on the fly or if I have to create
> >> > two different input devices?
> >> >
> >>
> >> Can you distinguish between the 2 remotes (not receivers)?
> >
> > Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
> > (Honestly I could pile on more protocols that have similar pulse time
> > periods, but that's complexity for no good reason and I don't know of a
> > vendor that bundles 3 types of remotes per TV card.)
> >
> >
> >>  Like I said,
> >> I think the preferred way is to represent every remote that can be
> >> distinguished from each other as a separate input device.
> >
> > OK.  With RC-5, NEC, and RC-6 at least there is also an address or
> > system byte or word to distingish different remotes.  However creating
> > multiple input devices on the fly for detected remotes would be madness
> > - especially with a decoding error in the address bits.
> 
> I agree that creating devices on the fly has problems. Another
> solution is to create one device for each map that is loaded. There
> would be a couple built-in maps for bundled remotes - each would
> create a device. Then the user could load more maps with each map
> creating a device.
> 
> Incoming scancodes are matched against all of the loaded maps and a
> keycode event is generated if a match occurs.
> 

How many sancodes do we need to reliably recognize the device though? I
am not sure users would want to press 5 random buttons in order to start
using the remote, unless it happens exactly once and then we manage to
store the data somewhere.

> This illustrates why there should an EV_IR event which communicates
> scancodes, without this event you can't see the scancodes that don't
> match a map entry. A scancode would be first matched against the map,
> then if there as no match an EV_IR event would be reported.

Just report MSC_SCAN always. As I said elsewhere we can extend it to be
multi-dword if needed (just need to agree on endianness).

-- 
Dmitry

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

[Dmitry Torokhov]

On Tue, Dec 08, 2009 at 07:46:52AM -0500, Andy Walls wrote:
> On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote:
> > Andy Walls wrote:
> > > On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
> 
> > > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
> > > end of the month.
> > 
> > Good! Please, try to design the decoder as an independent module that gets
> > data from a kfifo and generate scancodes for the input API.
> 
> Hmmm.  Let me see how the protoype turns out keeping that design
> objective in mind.  I've already got the current RC-5 and NEC decoding
> state machines in cx23885-input a bit layered, but they are taking
> advantage of specific events signaled by my v4l2_subdev implementation.
> 
> Strictly speaking the state machines don't have to.  All of the remote
> protocols I have played with make framing pretty easy.
> 
> 
> 
> > > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
> > > a common set of parameters, so I may be able to set up the decoders to
> > > handle decoding from two different remote types at once.  The HVR boards
> > > can ship with either type of remote AFAIK.
> > > 
> > > I wonder if I can flip the keytables on the fly or if I have to create
> > > two different input devices?
> > 
> > IMO, the better is, by default, to open just one input device per IR receiver.
> > >From what I understand from our discussions, if the user wants to filter IR
> > commands into several input interfaces, some userspace interface will be 
> > provided to allow the creation of other input interfaces for that purpose.
> 
> Hmm. That's not what I just thought I read from Dmitry....
> 

I am a resonable guy ;) In cases when we can certainly say that there
are 2 separate remotes (and we know characteristics somehow) we need to
create 2 input devices. Otherwise we can't ;)

-- 
Dmitry

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

[Jon Smirl]

On Tue, Dec 8, 2009 at 11:27 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Jon Smirl wrote:
>> On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Jon Smirl wrote:
>>>> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
>>>> <mchehab@redhat.com> wrote:
>>>>> Jon Smirl wrote:
>>>>>> On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab
>>>>>> <mchehab@redhat.com> wrote:
>>>>>>> Andy Walls wrote:
>>>>>>>> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
>>>>>>>>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
>>>>>>>>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
>>>>>>>>>> end of the month.
>>>>>>>>>>
>>>>>>>>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
>>>>>>>>>> a common set of parameters, so I may be able to set up the decoders to
>>>>>>>>>> handle decoding from two different remote types at once.  The HVR boards
>>>>>>>>>> can ship with either type of remote AFAIK.
>>>>>>>>>>
>>>>>>>>>> I wonder if I can flip the keytables on the fly or if I have to create
>>>>>>>>>> two different input devices?
>>>>>>>>>>
>>>>>>>>> Can you distinguish between the 2 remotes (not receivers)?
>>>>>>>> Yes.  RC-6 and RC-5 are different enough to distinguish between the two.
>>>>>>>> (Honestly I could pile on more protocols that have similar pulse time
>>>>>>>> periods, but that's complexity for no good reason and I don't know of a
>>>>>>>> vendor that bundles 3 types of remotes per TV card.)
>>>>>>> You'll be distinguishing the protocol, not the remote. If I understood
>>>>>>> Dmitry's question, he is asking if you can distinguish between two different
>>>>>>> remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5
>>>>>>> and another RC-6.
>>>>>> RC-5 and RC-6 both contain an address field.  My opinion is that
>>>>>> different addresses represent different devices and in general they
>>>>>> should appear on an input devices per address.
>>>>> The same IR can produce two different addresses. The IR bundled with my satellite
>>>>> STB produces two different codes, depending if you previously pressed <TV> or <SAT>
>>>>> key (in fact, I think it can even produce different protocols for TV, as it can
>>>>> be configured to work with different TV sets).
>>>> You have a multi-function remote.
>>> Yes.
>>>
>>>> That's why those keys don't send codes. When writing code you should
>>>> think of this remote as being two indpendent virtual remotes, not a
>>>> single one.
>>> Not really. I may think on it as a single device and use the two groups
>>> of functions to control two aspects at the same application.
>>>
>>> For example, I may map the <TV> group on kaffeine for DVB reception and the
>>> <SAT> group for DVD (well, probably, in this case, I'll use an IR with
>>> <TV> and <DVD> keys, instead ;) ).
>>>
>>>> By using maps containing the two different addresses for <TV> and
>>>> <SAT> you can split these commands onto two different evdev devices.
>>> True. I can do it, but I can opt to have both mapped as one evdev device as well.
>>> This will basically depend on how I want to mount my environment.
>>>
>>>> This model is complicated by the fact that some remotes that look like
>>>> multi-function remotes aren't really multifunction. The remote bundled
>>>> with the MS MCE receiver is one. That remote is a single function
>>>> device even though it has function buttons for TV, Music, Pictures,
>>>> etc.
>>> It is very common to have such remotes bundled with multimedia devices.
>>>
>>> An unsolved question on my mind is how should we map such IR's? Should we
>>> provide a way for them to emulate a multifunction IR (for example, after pressing
>>> TV key, subsequent keystrokes would be directed to the TV evdev device?), or
>>> should we let this up to some userspace app to handle this case?
>>
>> Splitting them into multiple devices requires remembering state and
>> scripting so it needs to be done in user space.
>
> It shouldn't be hard to do it in kernelspace, since you'll need to have
> one evdev interface associated with the IR anyway, but this will add
> some extra complexity at the scancode->keycode conversion, but I'm wandering
> if we should do it or not.
>
> Maybe the better is to not do it in kernelspace, to avoid adding there an
> extra complexity that can easily be done in userspace.
>
>> If the user wants to
>> control a radio app and a home automation app they need to choose.
>> Keep the bundled remote and do some non-trivial scripting or buy a
>> universal remote.
>
> Ok, but using the shipped IR even without a separate address group for
> different applications, and having it controlling radio app and tv app
> (not simultaneously) should not be hard, but I LIRC already covers such
> usecase, so maybe we don't need to worry about it.
>
>> Universal remotes make it much easier to achieve "just works".
>
> True.
>
>> The IR core can contain default universal profiles for various classes
>> of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check
>> if the receiver is cable of receiving these profiles before loading
>> them. There would be ten of these default universal profiles at most
>> and you can unload them from RAM if they aren't needed.
>>
>> Now Myth can have a menu with three remote choices:
>>  Universal Morotola_DVR
>>  Universal SciAtlanta_DVR
>>  Bundled
>>
>> The Bundled choice came from the map built into the IR receiver's device driver.
>> The other two choices were loaded by the IR core after ensuring that
>> the hardware could receive from a universal remote.
>>
>> The core would also load a couple of default radio profiles
>>  Univeral SonyDR112_RADIO
>>  Univeral OnkyoTX8255_RADIO
>> Same for automation and mouse/keyboard emulation.
>
> Agreed.
>
>> Myth looks in sysfs and builds a menu containing DVR devices and all
>> bundled entries. First app to open the "Bundled" device gets to keep
>> it.
>
> Myth (or other userspace apps) don't need to to that, since we've standardized
> the keycode actions (see the IR chapter of the media DocBook). It just
> needs to support the keycodes already defined, for the common case.
>
>> These apps could take "just works" even farther. When they start up
>> they could listen on all three evdev devices:  Morotola_DVR,
>> SciAtlanta_DVR,   Bundled. And then if you find Myth responding to
>> unwanted commands you could disable the unwanted profiles by
>> deselecting them in the Myth UI.
>
> I don't like the idea of automatically loading 3 different keycodes at the
> same time. You may have overlaps between different keycode tables. The
> better is to have some userspace GUI that will allow the user to select
> what keycode table(s) he want to be available, if he decides to not use the
> bundled IR.

Of course there is going to be overlap of the keycodes, but not the
scancodes. There should be almost 100% overlap.

The three maps are there to support a non-technical user, a
sophisticated user will disable two of them. This works because the
non-technical user is only going to use one of the three IR device
profiles. The other two may be loaded, but the user isn't sending any
IR signals that match their maps.

Where this breaks down is if they are using SciAtlanta_DVR to control
MythTV and they also happen to have a physical Motorola DVR in the
same room. The Linux box is going to pick up the commands meant for
the Motorola DVR and both boxes will respond.. In that cause they will
need to figure figure out how to disable the Motorola DVR profile.
But is a non-technical person likely to have two DVRs in the same
room?

>
> The same applies to applications: if you have 3 keymaps loaded, is because you
> want do do different things with the 3 keymaps (like using keymap 1 for kaffeine,
> keymap 2 for mplayer, keymap 3 for mythtv).
>
> So, IR-aware applications should have a setup interface to specify what IR keycodes
> are relevant to that particular application, and how to associate an evdev interface
> to an specific group of functions (for applications that supports several different
> types of media, like MythTV and Kaffeine, where you'll end by having a "TV" keymap/evdev,
> a "Radio" keymap/evdev, a "CD/DVD" Keymap/evdev, etc).
>
> Btw, if we're doing that, IMO, we should have an string sysfs alias attribute,
> to allow associating the userspace application to an specific keymap alias
> (like "radio", "tv", etc.).
>
>> All of this may seem complicated to build, but the purpose is to
>> create an environment where a non-technical user can get an IR remote
>> working without needing detailed knowledge about how IR protocols
>> work.
>
> IMO, this is an important requisite to fulfill.
>
> Cheers,
> Mauro.
>



-- 
Jon Smirl
jonsmirl@gmail.com

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

[Krzysztof Halasa]

Jon Smirl <jonsmirl@gmail.com> writes:

> Why do you want to pull the 1KB default mapping table out of the
> device driver __init section and more it to a udev script? Now we will
> have to maintain a parallel udev script for ever receiver's device
> driver.

Of course no. We will need a single program (script etc.) for all
devices. And we will need a database of the known remotes (scan and key
codes).

> You can handle that with __devinit

__devinit is NOP with hot-plug.

Fortunately we don't need the keymaps in the kernel.
For certain uses we may (and may not) need to have one keymap built-in,
perhaps something similar to the embedded initrd.
-- 
Krzysztof Halasa

Re: [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]

Krzysztof Halasa wrote:
> Jon Smirl <jonsmirl@gmail.com> writes:
> 
>> Why do you want to pull the 1KB default mapping table out of the
>> device driver __init section and more it to a udev script? Now we will
>> have to maintain a parallel udev script for ever receiver's device
>> driver.
> 
> Of course no. We will need a single program (script etc.) for all
> devices. And we will need a database of the known remotes (scan and key
> codes).

The keycode database can be easily extracted from kernel drivers by script.
I have it already at V4L/DVB development tree.

>> You can handle that with __devinit
> 
> __devinit is NOP with hot-plug.
> 
> Fortunately we don't need the keymaps in the kernel.
> For certain uses we may (and may not) need to have one keymap built-in,
> perhaps something similar to the embedded initrd.

I still think the better is to have them in kernel, but compiled only
if selected at Kbuild.

Cheers,
Mauro.

Re: [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]

Dmitry Torokhov wrote:

> I am a resonable guy ;) In cases when we can certainly say that there
> are 2 separate remotes (and we know characteristics somehow) we need to
> create 2 input devices. Otherwise we can't ;)
 
Only on very few specific cases (a few protocols), you can be (almost) sure.
Even on this case, universal remotes can fake another IR.

Cheers,
Mauro.

Re: [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]

Jon Smirl wrote:

>> I don't like the idea of automatically loading 3 different keycodes at the
>> same time. You may have overlaps between different keycode tables. The
>> better is to have some userspace GUI that will allow the user to select
>> what keycode table(s) he want to be available, if he decides to not use the
>> bundled IR.
> 
> Of course there is going to be overlap of the keycodes, but not the
> scancodes. There should be almost 100% overlap.

What prevents users to create overlaps at scancodes? We might add some
protection, but, providing that different keycode tables can be used by
different applications, why do we need to prevent it?

> The three maps are there to support a non-technical user, a
> sophisticated user will disable two of them. This works because the
> non-technical user is only going to use one of the three IR device
> profiles. The other two may be loaded, but the user isn't sending any
> IR signals that match their maps.

I doubt you can map all cases with just three profiles.

> 
> Where this breaks down is if they are using SciAtlanta_DVR to control
> MythTV and they also happen to have a physical Motorola DVR in the
> same room. 
> The Linux box is going to pick up the commands meant for
> the Motorola DVR and both boxes will respond.. In that cause they will
> need to figure figure out how to disable the Motorola DVR profile.

I used to have a Set Top Box that has some broken code to decode IR. So,
sometimes, when I used to press a key on my TV IR, the STB were getting
the code, producing a really bad result. That's really bad.

A normal user is able to click on some graphical application and
select his IR model. The app may even have some photos or pictures
representing the most used IR's. This is better than letting him to to
to some forum, asking his friends, etc, trying to figure out why his
PC is doing something wrong when he changes a channel on his TV.

> But is a non-technical person likely to have two DVRs in the same
> room?

Well, I know someone that has an 8 year old children with a setup like this: 
a PC monitor that has an IR, and a PC with a TV board also with IR.
Of course, both the monitor and the PC are at the same room.

Cheers,
Mauro.

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

[david]

On Mon, 23 Nov 2009, Krzysztof Halasa wrote:

> Devin Heitmueller <dheitmueller@kernellabs.com> 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.

I could definantly see this happening. the computer receives the 'play' 
button from a dvd remote, issues commands to control the audio system, dim 
lights, and then sends the 'play' button to the DVD player inside a 
cabinet where it can't see the remote directly.

but in any case, it shouldn't be hard to share a table of mappings.

David Lang