[RFC v2] Another approach to IR

[RFC v2] Another approach to IR

[Jon Smirl]

While reading all of these IR threads another way of handling IR
occurred to me that pretty much eliminates the need for LIRC and
configuration files in default cases. The best way to make everything
"just work" is to eliminate it.

The first observation is that the IR profile of various devices are
well known. Most devices profiles are in the published One-for-All
database. These device profiles consist of vendor/device/command
triplets. There is one triplet for each command like play, pause, 1,
2, 3, power, etc.

The second observation is that universal remotes know how to generate
commands for all of the common devices.

Let's define evdev messages for IR than contain vendor/device/command
triplets. I already posted code for doing that in my original patch
set. These messages are generated from in-kernel code.

Now add a small amount of code to MythTV, etc to act on these evdev
messages. Default MythTV, etc to respond to the IR commands for a
common DVR device. Program your universal remote to send the commands
for this device. You're done. Everything will "just work" - no LIRC,
no irrecord, no config files, no command mapping, etc.

Of course there are details involved in making this work. MythTV will
have to have a config option to allow it to emulate several different
DVR devices so that you can pick one that you don't own. It should
also have choices for emulating the common devices defined for the
remotes included with various Linux video board like the Hauppauge
remote.

For apps that haven't been modified you will have to run a daemon
which will capture vendor/device/command evdev events and convert them
into keystroke commands than work the menus. You'll need a config file
for this and have to write scripts. Instead I'd just go modify the app
the respond to the IR events, it is easy to do.

Long run, we define a MythTV IR profile, mplayer profile, etc and get
these into the IR database for universal remotes. Now MythTV can stop
emulating another vendor's device.

For the default MythTV case no external support will need to be
installed if the protocol decode engines are in the kernel. The raw
data will come in, run through the engines, and pop out as evdev
messages with a vendor/device/command triplet. Devices that decode in
hardware will just send vendor/device/command triplets.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Maxim Levitsky]

On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: 
> While reading all of these IR threads another way of handling IR
> occurred to me that pretty much eliminates the need for LIRC and
> configuration files in default cases. The best way to make everything
> "just work" is to eliminate it.
> 
> The first observation is that the IR profile of various devices are
> well known. Most devices profiles are in the published One-for-All
> database. These device profiles consist of vendor/device/command
> triplets. There is one triplet for each command like play, pause, 1,
> 2, 3, power, etc.
> 
> The second observation is that universal remotes know how to generate
> commands for all of the common devices.
> 
> Let's define evdev messages for IR than contain vendor/device/command
> triplets. I already posted code for doing that in my original patch
> set. These messages are generated from in-kernel code.
> 
> Now add a small amount of code to MythTV, etc to act on these evdev
> messages. Default MythTV, etc to respond to the IR commands for a
> common DVR device. Program your universal remote to send the commands
> for this device. You're done. Everything will "just work" - no LIRC,
> no irrecord, no config files, no command mapping, etc.
You are making one  big wrong assumption that everyone that has a remote
uses mythtv, and only it.

Many users including me, use the remote just like a keyboard, or even
like a mouse.


> 
> Of course there are details involved in making this work. MythTV will
> have to have a config option to allow it to emulate several different
> DVR devices so that you can pick one that you don't own. It should
> also have choices for emulating the common devices defined for the
> remotes included with various Linux video board like the Hauppauge
> remote.
> 
> For apps that haven't been modified you will have to run a daemon
> which will capture vendor/device/command evdev events and convert them
> into keystroke commands than work the menus. You'll need a config file
> for this and have to write scripts. Instead I'd just go modify the app
> the respond to the IR events, it is easy to do.
> 
> Long run, we define a MythTV IR profile, mplayer profile, etc and get
> these into the IR database for universal remotes. Now MythTV can stop
> emulating another vendor's device.
> 
> For the default MythTV case no external support will need to be
> installed if the protocol decode engines are in the kernel. The raw
> data will come in, run through the engines, and pop out as evdev
> messages with a vendor/device/command triplet. Devices that decode in
> hardware will just send vendor/device/command triplets.
> 

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
>> While reading all of these IR threads another way of handling IR
>> occurred to me that pretty much eliminates the need for LIRC and
>> configuration files in default cases. The best way to make everything
>> "just work" is to eliminate it.
>>
>> The first observation is that the IR profile of various devices are
>> well known. Most devices profiles are in the published One-for-All
>> database. These device profiles consist of vendor/device/command
>> triplets. There is one triplet for each command like play, pause, 1,
>> 2, 3, power, etc.
>>
>> The second observation is that universal remotes know how to generate
>> commands for all of the common devices.
>>
>> Let's define evdev messages for IR than contain vendor/device/command
>> triplets. I already posted code for doing that in my original patch
>> set. These messages are generated from in-kernel code.
>>
>> Now add a small amount of code to MythTV, etc to act on these evdev
>> messages. Default MythTV, etc to respond to the IR commands for a
>> common DVR device. Program your universal remote to send the commands
>> for this device. You're done. Everything will "just work" - no LIRC,
>> no irrecord, no config files, no command mapping, etc.
> You are making one  big wrong assumption that everyone that has a remote
> uses mythtv, and only it.
>
> Many users including me, use the remote just like a keyboard, or even
> like a mouse.

So let's try and figure out a "just works" scheme for doing this. What
I'm trying to do is to get everyone to step back and think about this
problem instead of rushing head long into merging LIRC as is. irrecord
is not something a non-technical user can easily handle.

A basic scheme that can be used to eliminate configuration is to take
well known IR device profiles and emulate them in Linux.  So pick
another well known device to emulate (call it A) and map it to
mouse/keyboard events.  Mapping vendor/device/command codes for a
couple devices to mouse/keyboard events is a tiny amount of data and
can be done in-kernel.

This case could also be made to "just work". Set your universal remote
to device A. Commands from for device A will arrive and be mapped into
generic keyboard/mouse commands.

There are probably other solutions to making IR work without needing
irrecord and configuration. What would be some other possibilities?

Also consider the long term strategy of defining standard device
profiles and getting them into the IR database. Make an IR profile for
mouse/keyboard. After this gets into the database a universal remote
can be set to this profile which will be a better match than emulating
another device.


>
>
>>
>> Of course there are details involved in making this work. MythTV will
>> have to have a config option to allow it to emulate several different
>> DVR devices so that you can pick one that you don't own. It should
>> also have choices for emulating the common devices defined for the
>> remotes included with various Linux video board like the Hauppauge
>> remote.
>>
>> For apps that haven't been modified you will have to run a daemon
>> which will capture vendor/device/command evdev events and convert them
>> into keystroke commands than work the menus. You'll need a config file
>> for this and have to write scripts. Instead I'd just go modify the app
>> the respond to the IR events, it is easy to do.
>>
>> Long run, we define a MythTV IR profile, mplayer profile, etc and get
>> these into the IR database for universal remotes. Now MythTV can stop
>> emulating another vendor's device.
>>
>> For the default MythTV case no external support will need to be
>> installed if the protocol decode engines are in the kernel. The raw
>> data will come in, run through the engines, and pop out as evdev
>> messages with a vendor/device/command triplet. Devices that decode in
>> hardware will just send vendor/device/command triplets.
>>
>
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Hi Jon,

Jon Smirl wrote:
> On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
>>> While reading all of these IR threads another way of handling IR
>>> occurred to me that pretty much eliminates the need for LIRC and
>>> configuration files in default cases. The best way to make everything
>>> "just work" is to eliminate it.
>>>
>>> The first observation is that the IR profile of various devices are
>>> well known. Most devices profiles are in the published One-for-All
>>> database. These device profiles consist of vendor/device/command
>>> triplets. There is one triplet for each command like play, pause, 1,
>>> 2, 3, power, etc.
>>>
>>> The second observation is that universal remotes know how to generate
>>> commands for all of the common devices.
>>>
>>> Let's define evdev messages for IR than contain vendor/device/command
>>> triplets. I already posted code for doing that in my original patch
>>> set. These messages are generated from in-kernel code.
>>>
>>> Now add a small amount of code to MythTV, etc to act on these evdev
>>> messages. Default MythTV, etc to respond to the IR commands for a
>>> common DVR device. Program your universal remote to send the commands
>>> for this device. You're done. Everything will "just work" - no LIRC,
>>> no irrecord, no config files, no command mapping, etc.
>> You are making one  big wrong assumption that everyone that has a remote
>> uses mythtv, and only it.
>>
>> Many users including me, use the remote just like a keyboard, or even
>> like a mouse.
> 
> So let's try and figure out a "just works" scheme for doing this. What
> I'm trying to do is to get everyone to step back and think about this
> problem instead of rushing head long into merging LIRC as is. irrecord
> is not something a non-technical user can easily handle.
> 
> A basic scheme that can be used to eliminate configuration is to take
> well known IR device profiles and emulate them in Linux.  So pick
> another well known device to emulate (call it A) and map it to
> mouse/keyboard events.  Mapping vendor/device/command codes for a
> couple devices to mouse/keyboard events is a tiny amount of data and
> can be done in-kernel.
> 
> This case could also be made to "just work". Set your universal remote
> to device A. Commands from for device A will arrive and be mapped into
> generic keyboard/mouse commands.
> 
> There are probably other solutions to making IR work without needing
> irrecord and configuration. What would be some other possibilities?
> 
> Also consider the long term strategy of defining standard device
> profiles and getting them into the IR database. Make an IR profile for
> mouse/keyboard. After this gets into the database a universal remote
> can be set to this profile which will be a better match than emulating
> another device.

This is basically the way the current in-kernel IR drivers work. The
driver converts scancodes (device address/command sequence) into
an evdev standard code.

Just taking an example from the dibcom0700 driver (as the same driver 
supports several different RC5 and NEC codes at the same time), 
the kernel table has several keycodes added there, all working
at the same time. Providing that the scancodes won't overlap, you can
map two different scancodes (from different IR's) to return the same
keycode (table is not complete - I just got a few common keycodes):

# SCAN Key_code
#
0xeb13 KEY_RIGHT
0x1e17 KEY_RIGHT
0x1d17 KEY_RIGHT
0x860f KEY_RIGHT

0xeb11 KEY_LEFT
0x1e16 KEY_LEFT
0x1d16 KEY_LEFT
0x860e KEY_LEFT

0x0703 KEY_VOLUMEUP
0xeb1c KEY_VOLUMEUP
0x1e10 KEY_VOLUMEUP
0x037d KEY_VOLUMEUP
0x1d10 KEY_VOLUMEUP
0x8610 KEY_VOLUMEUP
0x7a12 KEY_VOLUMEUP

0x0709 KEY_VOLUMEDOWN
0xeb1e KEY_VOLUMEDOWN
0x1e11 KEY_VOLUMEDOWN
0x017d KEY_VOLUMEDOWN
0x1d11 KEY_VOLUMEDOWN
0x860c KEY_VOLUMEDOWN
0x7a13 KEY_VOLUMEDOWN

0x0706 KEY_CHANNELUP
0xeb1b KEY_CHANNELUP
0x1e20 KEY_CHANNELUP
0x0242 KEY_CHANNELUP
0x1d20 KEY_CHANNELUP
0x860d KEY_CHANNELUP
0x7a10 KEY_CHANNELUP

0x070c KEY_CHANNELDOWN
0xeb1f KEY_CHANNELDOWN
0x1e21 KEY_CHANNELDOWN
0x007d KEY_CHANNELDOWN
0x1d21 KEY_CHANNELDOWN
0x8619 KEY_CHANNELDOWN
0x7a11 KEY_CHANNELDOWN

It should be noticed, however, that some devices may be provided with a shipped
IR with a different keytable where the keycodes may overlap with this table.

So, what we can do is to have a "default" keycode table mapping several
different IR's there to be used by drivers that are shipped with an IR
that can be fully mapped by the default table. However, for devices
with scancodes that overlaps with the default table, we'll need a separate
table.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Devin Heitmueller]

On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Just taking an example from the dibcom0700 driver (as the same driver
> supports several different RC5 and NEC codes at the same time),
> the kernel table has several keycodes added there, all working
> at the same time. Providing that the scancodes won't overlap, you can
> map two different scancodes (from different IR's) to return the same
> keycode (table is not complete - I just got a few common keycodes):

Mauro,

Just to be clear, the dib0700 does not actually support receiving RC5
or NEC codes at the same time.  You have to tell the chip which mode
to operate in, via a REQUEST_SET_RC to the firmware (see
dib0700_core.c:405).  The em28xx works the same way (you have to tell
it what type of IR format to receive).

The fact that the driver currently uses the same lookup table for both
types of remote controls however, was perhaps not the best design
choice.  It really should be separated out, and merged with the
regular ir-functions.c.  I just never got around to it.

Devin

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

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Devin Heitmueller wrote:
> On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Just taking an example from the dibcom0700 driver (as the same driver
>> supports several different RC5 and NEC codes at the same time),
>> the kernel table has several keycodes added there, all working
>> at the same time. Providing that the scancodes won't overlap, you can
>> map two different scancodes (from different IR's) to return the same
>> keycode (table is not complete - I just got a few common keycodes):
> 
> Mauro,
> 
> Just to be clear, the dib0700 does not actually support receiving RC5
> or NEC codes at the same time.  You have to tell the chip which mode
> to operate in, via a REQUEST_SET_RC to the firmware (see
> dib0700_core.c:405).  The em28xx works the same way (you have to tell
> it what type of IR format to receive).

Yes, I know. I have a dib0700-based device that came with a NEC table, and
I had to fix the driver to work with NEC on newer (1.20) firmwares and add the
corresponding table for my NEC IR. Still I prefer to use this device with a
RC5 IR from another manufacturer ;)

Yet, the same table works on my device with the shipped IR and with some
other RC5 IR's I have. Due to the lack of an API to select the IR standard,
I need to reload the module, passing a different modprobe parameter, to
set it to either mode.

> The fact that the driver currently uses the same lookup table for both
> types of remote controls however, was perhaps not the best design
> choice.  It really should be separated out, and merged with the
> regular ir-functions.c.  I just never got around to it.

I'm not sure if splitting the table on two would be the better way.

For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
to change the protocol in runtime.

If we'll keep using the same table, all an userspace app need is to say what's
the desired IR mode. On the other hand, it should be easy for the application
to also replace the table when a different protocol is selected.

The point that I want to bold is that it is possible to use one big table to
support several different IR's at the same time. This may be a good solution for
devices that were shipped with more than one different IR models. It may also
be a good solution to avoid having a large number of keymaps, as we may consolidate
commonly used IR's on an unique table (or on a few groups of tables).

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> 
> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
> to change the protocol in runtime.
> 

Mauro,

I think this kind of confuguration belongs to lirc device space,
not input/evdev. This is the same as protocol selection for psmouse
module: while it is normally auto-detected we have sysfs attribute to
force one or another and it is tied to serio device, not input
device.

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
>> to change the protocol in runtime.
>>
> 
> Mauro,
> 
> I think this kind of confuguration belongs to lirc device space,
> not input/evdev. This is the same as protocol selection for psmouse
> module: while it is normally auto-detected we have sysfs attribute to
> force one or another and it is tied to serio device, not input
> device.

Dmitry,

This has nothing to do with the raw interface nor with lirc. This problem 
happens with the evdev interface and already affects the in-kernel drivers.

In this case, psmouse is not a good example. With a mouse, when a movement
occurs, you'll receive some data from its port. So, a software can autodetect
the protocol. The same principle can be used also with a raw pulse/space
interface, where software can autodetect the protocol.

However, with hardware decoded IR's, when the hardware detects a code
from the wrong protocol, it simply discards the unknown protocol code 
without any advice. So, there's no way to autodetect. 

You need to set the right protocol before enabling the hardware decoder,
or no scan code will be produced at all.

Also, the same hardware can work with more than one protocol, on several cases,
but the list is generally limited to a few different protocols. So, a way
to enumerate what protocols are supported by the hardware is needed.

Let me give you a practical example: I have here a a Pixelview SBTVD USB stick,
for ISDB-T digital TV standard.

Pixelview provides a very inexpensive and limited NEC protocol-based IR, with a dozen
of keys. 

However, the hardware of the stick has the same components that are also present
on similar devices made by other manufacturers, with are shipped with different IR's,
running different protocols.

The same hardware design is also used with other models that work with DVB or ATSC
video standards.

For example, the same dib0700 driver supports this ISDB-T device and, for example,
a Hauppauge Nova-T DVB stick, that used a Hauppauge Grey IR, based on RC5 protocol.

Due to the lack of an evdev API call to select the IR protocol, an ugly modprobe 
parameter is provided to select the protocol at module boot time.

So, if people want to use the original NEC protocol-based IR, they need to do:
	modprobe dvb_usb_dib0700 dvb_usb_dib0700_ir_proto=0

But, if they want to use a decent IR, even having the keycodes for the RC5
remotes there, the driver needs to be reloaded with a different parameter, to
change the hardware to use a different decoder.

This is not an isolated case of this driver. The same problem happens will all other
in-kernel drivers at drivers/media.

Due to the lack of an API for it, each driver has their own way to handle the
protocols, but basically, on almost all drivers, even supporting different protocols,
the driver limits the usage of just the protocol provided by the shipped remote.

To solve this, we really need to extend evdev API to do 3 things: enumberate the
supported protocols, get the current protocol(s), and select the protocol(s) that
will be used by a newer table.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Due to the lack of an API for it, each driver has their own way to handle the
> protocols, but basically, on almost all drivers, even supporting different protocols,
> the driver limits the usage of just the protocol provided by the shipped remote.
>
> To solve this, we really need to extend evdev API to do 3 things: enumberate the
> supported protocols, get the current protocol(s), and select the protocol(s) that
> will be used by a newer table.

evdev capabilities bits can support enumerating the supported
protocols. I'm not sure if you can write those bits back into evdev to
turn a feature off/on. If not its something that could be added to
evdev.

I agree that there is no consistency in the existing driver implementations.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
> >> to change the protocol in runtime.
> >>
> > 
> > Mauro,
> > 
> > I think this kind of confuguration belongs to lirc device space,
> > not input/evdev. This is the same as protocol selection for psmouse
> > module: while it is normally auto-detected we have sysfs attribute to
> > force one or another and it is tied to serio device, not input
> > device.
> 
> Dmitry,
> 
> This has nothing to do with the raw interface nor with lirc. This problem 
> happens with the evdev interface and already affects the in-kernel drivers.
> 
> In this case, psmouse is not a good example. With a mouse, when a movement
> occurs, you'll receive some data from its port. So, a software can autodetect
> the protocol. The same principle can be used also with a raw pulse/space
> interface, where software can autodetect the protocol.

Or, in certain cases, it can not.

> 
[... skipped rationale for adding a way to control protocol (with which
I agree) ...]

> 
> To solve this, we really need to extend evdev API to do 3 things: enumberate the
> supported protocols, get the current protocol(s), and select the protocol(s) that
> will be used by a newer table.
> 

And here we start disagreeing. My preference would be for adding this
API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
since it only applicable to IR, not to input devices in general.

Once you selected proper protocol(s) and maybe instantiated several
input devices then udev (by examining input device capabilities and
optionally looking up at the parent device properties) would use
input evdev API to load proper keymap. Because translation of
driver-specific codes into standard key definitions is in the input
realm. Reading these driver-specific codes from hardware is outside of
input layer domain.

Just as psmouse ability to specify protocol is not shoved into evdev;
just as atkbd quirks (force release key list and other driver-specific
options) are not in evdev either; we should not overload evdev interface
with IR-specific items.

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
>>>> to change the protocol in runtime.
>>>>
>>> Mauro,
>>>
>>> I think this kind of confuguration belongs to lirc device space,
>>> not input/evdev. This is the same as protocol selection for psmouse
>>> module: while it is normally auto-detected we have sysfs attribute to
>>> force one or another and it is tied to serio device, not input
>>> device.
>> Dmitry,
>>
>> This has nothing to do with the raw interface nor with lirc. This problem 
>> happens with the evdev interface and already affects the in-kernel drivers.
>>
>> In this case, psmouse is not a good example. With a mouse, when a movement
>> occurs, you'll receive some data from its port. So, a software can autodetect
>> the protocol. The same principle can be used also with a raw pulse/space
>> interface, where software can autodetect the protocol.
> 
> Or, in certain cases, it can not.
> 
> [... skipped rationale for adding a way to control protocol (with which
> I agree) ...]
> 
>> To solve this, we really need to extend evdev API to do 3 things: enumberate the
>> supported protocols, get the current protocol(s), and select the protocol(s) that
>> will be used by a newer table.
>>
> 
> And here we start disagreeing. My preference would be for adding this
> API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
> since it only applicable to IR, not to input devices in general.
> 
> Once you selected proper protocol(s) and maybe instantiated several
> input devices then udev (by examining input device capabilities and
> optionally looking up at the parent device properties) would use
> input evdev API to load proper keymap. Because translation of
> driver-specific codes into standard key definitions is in the input
> realm. Reading these driver-specific codes from hardware is outside of
> input layer domain.
> 
> Just as psmouse ability to specify protocol is not shoved into evdev;
> just as atkbd quirks (force release key list and other driver-specific
> options) are not in evdev either; we should not overload evdev interface
> with IR-specific items.

I'm not against mapping those features as sysfs atributes, but they don't belong
to lirc, as far as I understand. From all we've discussed, we'll create a lirc
interface to allow the direct usage of raw IO. However, IR protocol is a property
that is not related to raw IO mode but, instead, to evdev mode.

We might add a /sys/class/IR and add IR specific stuff there, but it seems
overkill to me and will hide the fact that those parameters are part of the evdev
interface.

So, I would just add the IR sysfs parameters at the /sys/class/input, if
the device is an IR (or create it is /sys/class/input/IR).

I agree that the code to implement the IR specific sysfs parameter should be kept
oustide input core, as they're specific to IR implementations.

Would this work for you?

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
> >>>> to change the protocol in runtime.
> >>>>
> >>> Mauro,
> >>>
> >>> I think this kind of confuguration belongs to lirc device space,
> >>> not input/evdev. This is the same as protocol selection for psmouse
> >>> module: while it is normally auto-detected we have sysfs attribute to
> >>> force one or another and it is tied to serio device, not input
> >>> device.
> >> Dmitry,
> >>
> >> This has nothing to do with the raw interface nor with lirc. This problem 
> >> happens with the evdev interface and already affects the in-kernel drivers.
> >>
> >> In this case, psmouse is not a good example. With a mouse, when a movement
> >> occurs, you'll receive some data from its port. So, a software can autodetect
> >> the protocol. The same principle can be used also with a raw pulse/space
> >> interface, where software can autodetect the protocol.
> > 
> > Or, in certain cases, it can not.
> > 
> > [... skipped rationale for adding a way to control protocol (with which
> > I agree) ...]
> > 
> >> To solve this, we really need to extend evdev API to do 3 things: enumberate the
> >> supported protocols, get the current protocol(s), and select the protocol(s) that
> >> will be used by a newer table.
> >>
> > 
> > And here we start disagreeing. My preference would be for adding this
> > API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
> > since it only applicable to IR, not to input devices in general.
> > 
> > Once you selected proper protocol(s) and maybe instantiated several
> > input devices then udev (by examining input device capabilities and
> > optionally looking up at the parent device properties) would use
> > input evdev API to load proper keymap. Because translation of
> > driver-specific codes into standard key definitions is in the input
> > realm. Reading these driver-specific codes from hardware is outside of
> > input layer domain.
> > 
> > Just as psmouse ability to specify protocol is not shoved into evdev;
> > just as atkbd quirks (force release key list and other driver-specific
> > options) are not in evdev either; we should not overload evdev interface
> > with IR-specific items.
> 
> I'm not against mapping those features as sysfs atributes, but they don't belong
> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
> interface to allow the direct usage of raw IO. However, IR protocol is a property
> that is not related to raw IO mode but, instead, to evdev mode.
>

Why would protocol relate to evdev node? Evdev does not really care what
how the fact that a certain button was pressed was communicated to it.
It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
some custom IR protocol. It makes no difference _whatsoever_ to evdev
nor any users of evdev care about protocol used by underlying hardware
device to transmit the data.
 
> We might add a /sys/class/IR and add IR specific stuff there, but it seems
> overkill to me and will hide the fact that those parameters are part of the evdev
> interface.
> 
> So, I would just add the IR sysfs parameters at the /sys/class/input, if
> the device is an IR (or create it is /sys/class/input/IR).
> 
> I agree that the code to implement the IR specific sysfs parameter should be kept
> oustide input core, as they're specific to IR implementations.
> 
> Would this work for you?

I am seeing a little bit differently structured subsystem for IR at the
moment. I think we should do something like this:

- receivers create /sys/class/lirc devices. These devices provide API
  with a ring buffer (fifo) for the raw data stream coming from (and to)
  them.
- we allow registering several data interfaces/decoders that can be bound
  (manually or maybe automatically) to lirc devices. lirc devices may
  provide hints as to which interface(s) better suited for handling the
  data coming form particular receiver. Several interfaces may be bound
  to one device at a time.
- one of the interfaces is interface implementing current lirc_dev
- other interfaces may be in-kernel RC-5 decoder or other decoders.
  decoders will create instances of input devices (for each
  remote/substream that they can recognize).

This way there is clear layering, protocol selection is kept at lirc
level.

Would this work?

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
> On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
>>>> Dmitry Torokhov wrote:
>>>>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>>>>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
>>>>>> to change the protocol in runtime.
>>>>>>
>>>>> Mauro,
>>>>>
>>>>> I think this kind of confuguration belongs to lirc device space,
>>>>> not input/evdev. This is the same as protocol selection for psmouse
>>>>> module: while it is normally auto-detected we have sysfs attribute to
>>>>> force one or another and it is tied to serio device, not input
>>>>> device.
>>>> Dmitry,
>>>>
>>>> This has nothing to do with the raw interface nor with lirc. This problem 
>>>> happens with the evdev interface and already affects the in-kernel drivers.
>>>>
>>>> In this case, psmouse is not a good example. With a mouse, when a movement
>>>> occurs, you'll receive some data from its port. So, a software can autodetect
>>>> the protocol. The same principle can be used also with a raw pulse/space
>>>> interface, where software can autodetect the protocol.
>>> Or, in certain cases, it can not.
>>>
>>> [... skipped rationale for adding a way to control protocol (with which
>>> I agree) ...]
>>>
>>>> To solve this, we really need to extend evdev API to do 3 things: enumberate the
>>>> supported protocols, get the current protocol(s), and select the protocol(s) that
>>>> will be used by a newer table.
>>>>
>>> And here we start disagreeing. My preference would be for adding this
>>> API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
>>> since it only applicable to IR, not to input devices in general.
>>>
>>> Once you selected proper protocol(s) and maybe instantiated several
>>> input devices then udev (by examining input device capabilities and
>>> optionally looking up at the parent device properties) would use
>>> input evdev API to load proper keymap. Because translation of
>>> driver-specific codes into standard key definitions is in the input
>>> realm. Reading these driver-specific codes from hardware is outside of
>>> input layer domain.
>>>
>>> Just as psmouse ability to specify protocol is not shoved into evdev;
>>> just as atkbd quirks (force release key list and other driver-specific
>>> options) are not in evdev either; we should not overload evdev interface
>>> with IR-specific items.
>> I'm not against mapping those features as sysfs atributes, but they don't belong
>> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
>> interface to allow the direct usage of raw IO. However, IR protocol is a property
>> that is not related to raw IO mode but, instead, to evdev mode.
>>
> 
> Why would protocol relate to evdev node? Evdev does not really care what
> how the fact that a certain button was pressed was communicated to it.
> It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
> or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
> some custom IR protocol. It makes no difference _whatsoever_ to evdev
> nor any users of evdev care about protocol used by underlying hardware
> device to transmit the data.
>  
>> We might add a /sys/class/IR and add IR specific stuff there, but it seems
>> overkill to me and will hide the fact that those parameters are part of the evdev
>> interface.
>>
>> So, I would just add the IR sysfs parameters at the /sys/class/input, if
>> the device is an IR (or create it is /sys/class/input/IR).
>>
>> I agree that the code to implement the IR specific sysfs parameter should be kept
>> oustide input core, as they're specific to IR implementations.
>>
>> Would this work for you?
> 
> I am seeing a little bit differently structured subsystem for IR at the
> moment. I think we should do something like this:
> 
> - receivers create /sys/class/lirc devices. These devices provide API
>   with a ring buffer (fifo) for the raw data stream coming from (and to)
>   them.

The raw interface applies only to the devices that doesn't have a hardware decoder
(something between 40%-60% of the currently supported devices).

> - we allow registering several data interfaces/decoders that can be bound
>   (manually or maybe automatically) to lirc devices. lirc devices may
>   provide hints as to which interface(s) better suited for handling the
>   data coming form particular receiver. Several interfaces may be bound
>   to one device at a time.
> - one of the interfaces is interface implementing current lirc_dev
> - other interfaces may be in-kernel RC-5 decoder or other decoders.
>   decoders will create instances of input devices

I don't see why having more than one interface, especially for devices with
hardware decoders.

On IR remote receivers, internally, there's just one interface per hardware.

Considering the hardware decoding case, why to artificially create other
interfaces that can't be used simultaneously? No current hardware
decoders can do that (or, at least, no current implementation allows).
We're foreseen some cases where we'll have that (like Patrick's dib0700 driver),
but for now, it is not possible to offer more than one interface to userspace.
Creating an arbitrary number of artificial interfaces just to pass a parameter
to the driver (the protocol), really seems overkill to me.

In the case of the cheap devices with just raw interfaces, running in-kernel
decoders, while it will work if you create one interface per protocol
per IR receiver, this also seems overkill. Why to do that? It sounds that it will
just create additional complexity at the kernelspace and at the userspace, since
now userspace programs will need to open more than one device to receive the
keycodes.

> (for each remote/substream that they can recognize).

I'm assuming that, by remote, you're referring to a remote receiver (and not to 
the remote itself), right?

> 
> This way there is clear layering, protocol selection is kept at lirc
> level.
> 
> Would this work?
> 

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> >>>> Dmitry Torokhov wrote:
> >>>>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >>>>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
> >>>>>> to change the protocol in runtime.
> >>>>>>
> >>>>> Mauro,
> >>>>>
> >>>>> I think this kind of confuguration belongs to lirc device space,
> >>>>> not input/evdev. This is the same as protocol selection for psmouse
> >>>>> module: while it is normally auto-detected we have sysfs attribute to
> >>>>> force one or another and it is tied to serio device, not input
> >>>>> device.
> >>>> Dmitry,
> >>>>
> >>>> This has nothing to do with the raw interface nor with lirc. This problem 
> >>>> happens with the evdev interface and already affects the in-kernel drivers.
> >>>>
> >>>> In this case, psmouse is not a good example. With a mouse, when a movement
> >>>> occurs, you'll receive some data from its port. So, a software can autodetect
> >>>> the protocol. The same principle can be used also with a raw pulse/space
> >>>> interface, where software can autodetect the protocol.
> >>> Or, in certain cases, it can not.
> >>>
> >>> [... skipped rationale for adding a way to control protocol (with which
> >>> I agree) ...]
> >>>
> >>>> To solve this, we really need to extend evdev API to do 3 things: enumberate the
> >>>> supported protocols, get the current protocol(s), and select the protocol(s) that
> >>>> will be used by a newer table.
> >>>>
> >>> And here we start disagreeing. My preference would be for adding this
> >>> API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
> >>> since it only applicable to IR, not to input devices in general.
> >>>
> >>> Once you selected proper protocol(s) and maybe instantiated several
> >>> input devices then udev (by examining input device capabilities and
> >>> optionally looking up at the parent device properties) would use
> >>> input evdev API to load proper keymap. Because translation of
> >>> driver-specific codes into standard key definitions is in the input
> >>> realm. Reading these driver-specific codes from hardware is outside of
> >>> input layer domain.
> >>>
> >>> Just as psmouse ability to specify protocol is not shoved into evdev;
> >>> just as atkbd quirks (force release key list and other driver-specific
> >>> options) are not in evdev either; we should not overload evdev interface
> >>> with IR-specific items.
> >> I'm not against mapping those features as sysfs atributes, but they don't belong
> >> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
> >> interface to allow the direct usage of raw IO. However, IR protocol is a property
> >> that is not related to raw IO mode but, instead, to evdev mode.
> >>
> > 
> > Why would protocol relate to evdev node? Evdev does not really care what
> > how the fact that a certain button was pressed was communicated to it.
> > It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
> > or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
> > some custom IR protocol. It makes no difference _whatsoever_ to evdev
> > nor any users of evdev care about protocol used by underlying hardware
> > device to transmit the data.
> >  
> >> We might add a /sys/class/IR and add IR specific stuff there, but it seems
> >> overkill to me and will hide the fact that those parameters are part of the evdev
> >> interface.
> >>
> >> So, I would just add the IR sysfs parameters at the /sys/class/input, if
> >> the device is an IR (or create it is /sys/class/input/IR).
> >>
> >> I agree that the code to implement the IR specific sysfs parameter should be kept
> >> oustide input core, as they're specific to IR implementations.
> >>
> >> Would this work for you?
> > 
> > I am seeing a little bit differently structured subsystem for IR at the
> > moment. I think we should do something like this:
> > 
> > - receivers create /sys/class/lirc devices. These devices provide API
> >   with a ring buffer (fifo) for the raw data stream coming from (and to)
> >   them.
> 
> The raw interface applies only to the devices that doesn't have a hardware decoder
> (something between 40%-60% of the currently supported devices).

50% is quite a number I think. But if driver does not allow access to
the raw stream - it will refuse binding to lirc_dev interface.

> 
> > - we allow registering several data interfaces/decoders that can be bound
> >   (manually or maybe automatically) to lirc devices. lirc devices may
> >   provide hints as to which interface(s) better suited for handling the
> >   data coming form particular receiver. Several interfaces may be bound
> >   to one device at a time.
> > - one of the interfaces is interface implementing current lirc_dev
> > - other interfaces may be in-kernel RC-5 decoder or other decoders.
> >   decoders will create instances of input devices
> 
> I don't see why having more than one interface, especially for devices with
> hardware decoders.
> 
> On IR remote receivers, internally, there's just one interface per hardware.
> 
> Considering the hardware decoding case, why to artificially create other
> interfaces that can't be used simultaneously? No current hardware
> decoders can do that (or, at least, no current implementation allows).
> We're foreseen some cases where we'll have that (like Patrick's dib0700 driver),
> but for now, it is not possible to offer more than one interface to userspace.
> Creating an arbitrary number of artificial interfaces just to pass a parameter
> to the driver (the protocol), really seems overkill to me.

We need to cater to the future cases as well. I don't want to redesign
it in 2 years. But for devices that have only hardware decoders I
suppose we can short-curcuit "interfaces" and have a library-like module
creating input devices directly.

> 
> In the case of the cheap devices with just raw interfaces, running in-kernel
> decoders, while it will work if you create one interface per protocol
> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
> just create additional complexity at the kernelspace and at the userspace, since
> now userspace programs will need to open more than one device to receive the
> keycodes.

_Yes_!!! You open as many event devices as there are devices you are
interested in receiving data from. Multiplexing devices are bad, bad,
bad. Witness /dev/input/mouse and all the attempts at working around the
fact that if you have a special driver for one of your devices you
receive events from the same device through 2 interfaces and all kind of
"grab", "super-grab", "smart-grab" schemes are born.

> 
> > (for each remote/substream that they can recognize).
> 
> I'm assuming that, by remote, you're referring to a remote receiver (and not to 
> the remote itself), right?

If we could separate by remote transmitter that would be the best I
think, but I understand that it is rarely possible?

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
>> >> Dmitry Torokhov wrote:
>> >>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
>> >>>> Dmitry Torokhov wrote:
>> >>>>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>> >>>>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
>> >>>>>> to change the protocol in runtime.
>> >>>>>>
>> >>>>> Mauro,
>> >>>>>
>> >>>>> I think this kind of confuguration belongs to lirc device space,
>> >>>>> not input/evdev. This is the same as protocol selection for psmouse
>> >>>>> module: while it is normally auto-detected we have sysfs attribute to
>> >>>>> force one or another and it is tied to serio device, not input
>> >>>>> device.
>> >>>> Dmitry,
>> >>>>
>> >>>> This has nothing to do with the raw interface nor with lirc. This problem
>> >>>> happens with the evdev interface and already affects the in-kernel drivers.
>> >>>>
>> >>>> In this case, psmouse is not a good example. With a mouse, when a movement
>> >>>> occurs, you'll receive some data from its port. So, a software can autodetect
>> >>>> the protocol. The same principle can be used also with a raw pulse/space
>> >>>> interface, where software can autodetect the protocol.
>> >>> Or, in certain cases, it can not.
>> >>>
>> >>> [... skipped rationale for adding a way to control protocol (with which
>> >>> I agree) ...]
>> >>>
>> >>>> To solve this, we really need to extend evdev API to do 3 things: enumberate the
>> >>>> supported protocols, get the current protocol(s), and select the protocol(s) that
>> >>>> will be used by a newer table.
>> >>>>
>> >>> And here we start disagreeing. My preference would be for adding this
>> >>> API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
>> >>> since it only applicable to IR, not to input devices in general.
>> >>>
>> >>> Once you selected proper protocol(s) and maybe instantiated several
>> >>> input devices then udev (by examining input device capabilities and
>> >>> optionally looking up at the parent device properties) would use
>> >>> input evdev API to load proper keymap. Because translation of
>> >>> driver-specific codes into standard key definitions is in the input
>> >>> realm. Reading these driver-specific codes from hardware is outside of
>> >>> input layer domain.
>> >>>
>> >>> Just as psmouse ability to specify protocol is not shoved into evdev;
>> >>> just as atkbd quirks (force release key list and other driver-specific
>> >>> options) are not in evdev either; we should not overload evdev interface
>> >>> with IR-specific items.
>> >> I'm not against mapping those features as sysfs atributes, but they don't belong
>> >> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
>> >> interface to allow the direct usage of raw IO. However, IR protocol is a property
>> >> that is not related to raw IO mode but, instead, to evdev mode.
>> >>
>> >
>> > Why would protocol relate to evdev node? Evdev does not really care what
>> > how the fact that a certain button was pressed was communicated to it.
>> > It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
>> > or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
>> > some custom IR protocol. It makes no difference _whatsoever_ to evdev
>> > nor any users of evdev care about protocol used by underlying hardware
>> > device to transmit the data.
>> >
>> >> We might add a /sys/class/IR and add IR specific stuff there, but it seems
>> >> overkill to me and will hide the fact that those parameters are part of the evdev
>> >> interface.
>> >>
>> >> So, I would just add the IR sysfs parameters at the /sys/class/input, if
>> >> the device is an IR (or create it is /sys/class/input/IR).
>> >>
>> >> I agree that the code to implement the IR specific sysfs parameter should be kept
>> >> oustide input core, as they're specific to IR implementations.
>> >>
>> >> Would this work for you?
>> >
>> > I am seeing a little bit differently structured subsystem for IR at the
>> > moment. I think we should do something like this:
>> >
>> > - receivers create /sys/class/lirc devices. These devices provide API
>> >   with a ring buffer (fifo) for the raw data stream coming from (and to)
>> >   them.
>>
>> The raw interface applies only to the devices that doesn't have a hardware decoder
>> (something between 40%-60% of the currently supported devices).
>
> 50% is quite a number I think. But if driver does not allow access to
> the raw stream - it will refuse binding to lirc_dev interface.
>
>>
>> > - we allow registering several data interfaces/decoders that can be bound
>> >   (manually or maybe automatically) to lirc devices. lirc devices may
>> >   provide hints as to which interface(s) better suited for handling the
>> >   data coming form particular receiver. Several interfaces may be bound
>> >   to one device at a time.
>> > - one of the interfaces is interface implementing current lirc_dev
>> > - other interfaces may be in-kernel RC-5 decoder or other decoders.
>> >   decoders will create instances of input devices
>>
>> I don't see why having more than one interface, especially for devices with
>> hardware decoders.
>>
>> On IR remote receivers, internally, there's just one interface per hardware.
>>
>> Considering the hardware decoding case, why to artificially create other
>> interfaces that can't be used simultaneously? No current hardware
>> decoders can do that (or, at least, no current implementation allows).
>> We're foreseen some cases where we'll have that (like Patrick's dib0700 driver),
>> but for now, it is not possible to offer more than one interface to userspace.
>> Creating an arbitrary number of artificial interfaces just to pass a parameter
>> to the driver (the protocol), really seems overkill to me.
>
> We need to cater to the future cases as well. I don't want to redesign
> it in 2 years. But for devices that have only hardware decoders I
> suppose we can short-curcuit "interfaces" and have a library-like module
> creating input devices directly.
>
>>
>> In the case of the cheap devices with just raw interfaces, running in-kernel
>> decoders, while it will work if you create one interface per protocol
>> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
>> just create additional complexity at the kernelspace and at the userspace, since
>> now userspace programs will need to open more than one device to receive the
>> keycodes.
>
> _Yes_!!! You open as many event devices as there are devices you are
> interested in receiving data from. Multiplexing devices are bad, bad,
> bad. Witness /dev/input/mouse and all the attempts at working around the
> fact that if you have a special driver for one of your devices you
> receive events from the same device through 2 interfaces and all kind of
> "grab", "super-grab", "smart-grab" schemes are born.
>
>>
>> > (for each remote/substream that they can recognize).
>>
>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>> the remote itself), right?
>
> If we could separate by remote transmitter that would be the best I
> think, but I understand that it is rarely possible?

The code I posted using configfs did that. Instead of making apps IR
aware it mapped the vendor/device/command triplets into standard Linux
keycodes.  Each remote was its own evdev device.

That scheme could be made to "just work" by building in a couple of
mapping tables. The driver would pre-populate configfs entries for a
some standard IR devices. Set the remote for Motorala DVR. Default
Myth to look for the evdev device associated with Motorola DVR. The
built-in mapping table would then map from pulse timing to Linux
keycodes.

If everyone hates configfs the same mapping can be done via the set
keys IOCTL and making changes to the user space apps like loadkeys.

For IR to "just work" the irrecord training process needs be
eliminated for 90% of users.




>
> --
> Dmitry
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> >> >> Dmitry Torokhov wrote:
> >> >>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> >> >>>> Dmitry Torokhov wrote:
> >> >>>>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >> >>>>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
> >> >>>>>> to change the protocol in runtime.
> >> >>>>>>
> >> >>>>> Mauro,
> >> >>>>>
> >> >>>>> I think this kind of confuguration belongs to lirc device space,
> >> >>>>> not input/evdev. This is the same as protocol selection for psmouse
> >> >>>>> module: while it is normally auto-detected we have sysfs attribute to
> >> >>>>> force one or another and it is tied to serio device, not input
> >> >>>>> device.
> >> >>>> Dmitry,
> >> >>>>
> >> >>>> This has nothing to do with the raw interface nor with lirc. This problem
> >> >>>> happens with the evdev interface and already affects the in-kernel drivers.
> >> >>>>
> >> >>>> In this case, psmouse is not a good example. With a mouse, when a movement
> >> >>>> occurs, you'll receive some data from its port. So, a software can autodetect
> >> >>>> the protocol. The same principle can be used also with a raw pulse/space
> >> >>>> interface, where software can autodetect the protocol.
> >> >>> Or, in certain cases, it can not.
> >> >>>
> >> >>> [... skipped rationale for adding a way to control protocol (with which
> >> >>> I agree) ...]
> >> >>>
> >> >>>> To solve this, we really need to extend evdev API to do 3 things: enumberate the
> >> >>>> supported protocols, get the current protocol(s), and select the protocol(s) that
> >> >>>> will be used by a newer table.
> >> >>>>
> >> >>> And here we start disagreeing. My preference would be for adding this
> >> >>> API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
> >> >>> since it only applicable to IR, not to input devices in general.
> >> >>>
> >> >>> Once you selected proper protocol(s) and maybe instantiated several
> >> >>> input devices then udev (by examining input device capabilities and
> >> >>> optionally looking up at the parent device properties) would use
> >> >>> input evdev API to load proper keymap. Because translation of
> >> >>> driver-specific codes into standard key definitions is in the input
> >> >>> realm. Reading these driver-specific codes from hardware is outside of
> >> >>> input layer domain.
> >> >>>
> >> >>> Just as psmouse ability to specify protocol is not shoved into evdev;
> >> >>> just as atkbd quirks (force release key list and other driver-specific
> >> >>> options) are not in evdev either; we should not overload evdev interface
> >> >>> with IR-specific items.
> >> >> I'm not against mapping those features as sysfs atributes, but they don't belong
> >> >> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
> >> >> interface to allow the direct usage of raw IO. However, IR protocol is a property
> >> >> that is not related to raw IO mode but, instead, to evdev mode.
> >> >>
> >> >
> >> > Why would protocol relate to evdev node? Evdev does not really care what
> >> > how the fact that a certain button was pressed was communicated to it.
> >> > It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
> >> > or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
> >> > some custom IR protocol. It makes no difference _whatsoever_ to evdev
> >> > nor any users of evdev care about protocol used by underlying hardware
> >> > device to transmit the data.
> >> >
> >> >> We might add a /sys/class/IR and add IR specific stuff there, but it seems
> >> >> overkill to me and will hide the fact that those parameters are part of the evdev
> >> >> interface.
> >> >>
> >> >> So, I would just add the IR sysfs parameters at the /sys/class/input, if
> >> >> the device is an IR (or create it is /sys/class/input/IR).
> >> >>
> >> >> I agree that the code to implement the IR specific sysfs parameter should be kept
> >> >> oustide input core, as they're specific to IR implementations.
> >> >>
> >> >> Would this work for you?
> >> >
> >> > I am seeing a little bit differently structured subsystem for IR at the
> >> > moment. I think we should do something like this:
> >> >
> >> > - receivers create /sys/class/lirc devices. These devices provide API
> >> >   with a ring buffer (fifo) for the raw data stream coming from (and to)
> >> >   them.
> >>
> >> The raw interface applies only to the devices that doesn't have a hardware decoder
> >> (something between 40%-60% of the currently supported devices).
> >
> > 50% is quite a number I think. But if driver does not allow access to
> > the raw stream - it will refuse binding to lirc_dev interface.
> >
> >>
> >> > - we allow registering several data interfaces/decoders that can be bound
> >> >   (manually or maybe automatically) to lirc devices. lirc devices may
> >> >   provide hints as to which interface(s) better suited for handling the
> >> >   data coming form particular receiver. Several interfaces may be bound
> >> >   to one device at a time.
> >> > - one of the interfaces is interface implementing current lirc_dev
> >> > - other interfaces may be in-kernel RC-5 decoder or other decoders.
> >> >   decoders will create instances of input devices
> >>
> >> I don't see why having more than one interface, especially for devices with
> >> hardware decoders.
> >>
> >> On IR remote receivers, internally, there's just one interface per hardware.
> >>
> >> Considering the hardware decoding case, why to artificially create other
> >> interfaces that can't be used simultaneously? No current hardware
> >> decoders can do that (or, at least, no current implementation allows).
> >> We're foreseen some cases where we'll have that (like Patrick's dib0700 driver),
> >> but for now, it is not possible to offer more than one interface to userspace.
> >> Creating an arbitrary number of artificial interfaces just to pass a parameter
> >> to the driver (the protocol), really seems overkill to me.
> >
> > We need to cater to the future cases as well. I don't want to redesign
> > it in 2 years. But for devices that have only hardware decoders I
> > suppose we can short-curcuit "interfaces" and have a library-like module
> > creating input devices directly.
> >
> >>
> >> In the case of the cheap devices with just raw interfaces, running in-kernel
> >> decoders, while it will work if you create one interface per protocol
> >> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
> >> just create additional complexity at the kernelspace and at the userspace, since
> >> now userspace programs will need to open more than one device to receive the
> >> keycodes.
> >
> > _Yes_!!! You open as many event devices as there are devices you are
> > interested in receiving data from. Multiplexing devices are bad, bad,
> > bad. Witness /dev/input/mouse and all the attempts at working around the
> > fact that if you have a special driver for one of your devices you
> > receive events from the same device through 2 interfaces and all kind of
> > "grab", "super-grab", "smart-grab" schemes are born.
> >
> >>
> >> > (for each remote/substream that they can recognize).
> >>
> >> I'm assuming that, by remote, you're referring to a remote receiver (and not to
> >> the remote itself), right?
> >
> > If we could separate by remote transmitter that would be the best I
> > think, but I understand that it is rarely possible?
> 
> The code I posted using configfs did that. Instead of making apps IR
> aware it mapped the vendor/device/command triplets into standard Linux
> keycodes.  Each remote was its own evdev device.
>

That is what I liked about the patchset.
 
> That scheme could be made to "just work" by building in a couple of
> mapping tables. The driver would pre-populate configfs entries for a
> some standard IR devices. Set the remote for Motorala DVR. Default
> Myth to look for the evdev device associated with Motorola DVR. The
> built-in mapping table would then map from pulse timing to Linux
> keycodes.
> 
> If everyone hates configfs the same mapping can be done via the set
> keys IOCTL and making changes to the user space apps like loadkeys.
> 

It is not the hate of configfs per se, but rather concern that configfs
takes too much resources and is not normally enabled.

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 1:23 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote:
>> On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote:
>> >> Dmitry Torokhov wrote:
>> >> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
>> >> >> Dmitry Torokhov wrote:
>> >> >>> On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
>> >> >>>> Dmitry Torokhov wrote:
>> >> >>>>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>> >> >>>>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
>> >> >>>>>> to change the protocol in runtime.
>> >> >>>>>>
>> >> >>>>> Mauro,
>> >> >>>>>
>> >> >>>>> I think this kind of confuguration belongs to lirc device space,
>> >> >>>>> not input/evdev. This is the same as protocol selection for psmouse
>> >> >>>>> module: while it is normally auto-detected we have sysfs attribute to
>> >> >>>>> force one or another and it is tied to serio device, not input
>> >> >>>>> device.
>> >> >>>> Dmitry,
>> >> >>>>
>> >> >>>> This has nothing to do with the raw interface nor with lirc. This problem
>> >> >>>> happens with the evdev interface and already affects the in-kernel drivers.
>> >> >>>>
>> >> >>>> In this case, psmouse is not a good example. With a mouse, when a movement
>> >> >>>> occurs, you'll receive some data from its port. So, a software can autodetect
>> >> >>>> the protocol. The same principle can be used also with a raw pulse/space
>> >> >>>> interface, where software can autodetect the protocol.
>> >> >>> Or, in certain cases, it can not.
>> >> >>>
>> >> >>> [... skipped rationale for adding a way to control protocol (with which
>> >> >>> I agree) ...]
>> >> >>>
>> >> >>>> To solve this, we really need to extend evdev API to do 3 things: enumberate the
>> >> >>>> supported protocols, get the current protocol(s), and select the protocol(s) that
>> >> >>>> will be used by a newer table.
>> >> >>>>
>> >> >>> And here we start disagreeing. My preference would be for adding this
>> >> >>> API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
>> >> >>> since it only applicable to IR, not to input devices in general.
>> >> >>>
>> >> >>> Once you selected proper protocol(s) and maybe instantiated several
>> >> >>> input devices then udev (by examining input device capabilities and
>> >> >>> optionally looking up at the parent device properties) would use
>> >> >>> input evdev API to load proper keymap. Because translation of
>> >> >>> driver-specific codes into standard key definitions is in the input
>> >> >>> realm. Reading these driver-specific codes from hardware is outside of
>> >> >>> input layer domain.
>> >> >>>
>> >> >>> Just as psmouse ability to specify protocol is not shoved into evdev;
>> >> >>> just as atkbd quirks (force release key list and other driver-specific
>> >> >>> options) are not in evdev either; we should not overload evdev interface
>> >> >>> with IR-specific items.
>> >> >> I'm not against mapping those features as sysfs atributes, but they don't belong
>> >> >> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
>> >> >> interface to allow the direct usage of raw IO. However, IR protocol is a property
>> >> >> that is not related to raw IO mode but, instead, to evdev mode.
>> >> >>
>> >> >
>> >> > Why would protocol relate to evdev node? Evdev does not really care what
>> >> > how the fact that a certain button was pressed was communicated to it.
>> >> > It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
>> >> > or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
>> >> > some custom IR protocol. It makes no difference _whatsoever_ to evdev
>> >> > nor any users of evdev care about protocol used by underlying hardware
>> >> > device to transmit the data.
>> >> >
>> >> >> We might add a /sys/class/IR and add IR specific stuff there, but it seems
>> >> >> overkill to me and will hide the fact that those parameters are part of the evdev
>> >> >> interface.
>> >> >>
>> >> >> So, I would just add the IR sysfs parameters at the /sys/class/input, if
>> >> >> the device is an IR (or create it is /sys/class/input/IR).
>> >> >>
>> >> >> I agree that the code to implement the IR specific sysfs parameter should be kept
>> >> >> oustide input core, as they're specific to IR implementations.
>> >> >>
>> >> >> Would this work for you?
>> >> >
>> >> > I am seeing a little bit differently structured subsystem for IR at the
>> >> > moment. I think we should do something like this:
>> >> >
>> >> > - receivers create /sys/class/lirc devices. These devices provide API
>> >> >   with a ring buffer (fifo) for the raw data stream coming from (and to)
>> >> >   them.
>> >>
>> >> The raw interface applies only to the devices that doesn't have a hardware decoder
>> >> (something between 40%-60% of the currently supported devices).
>> >
>> > 50% is quite a number I think. But if driver does not allow access to
>> > the raw stream - it will refuse binding to lirc_dev interface.
>> >
>> >>
>> >> > - we allow registering several data interfaces/decoders that can be bound
>> >> >   (manually or maybe automatically) to lirc devices. lirc devices may
>> >> >   provide hints as to which interface(s) better suited for handling the
>> >> >   data coming form particular receiver. Several interfaces may be bound
>> >> >   to one device at a time.
>> >> > - one of the interfaces is interface implementing current lirc_dev
>> >> > - other interfaces may be in-kernel RC-5 decoder or other decoders.
>> >> >   decoders will create instances of input devices
>> >>
>> >> I don't see why having more than one interface, especially for devices with
>> >> hardware decoders.
>> >>
>> >> On IR remote receivers, internally, there's just one interface per hardware.
>> >>
>> >> Considering the hardware decoding case, why to artificially create other
>> >> interfaces that can't be used simultaneously? No current hardware
>> >> decoders can do that (or, at least, no current implementation allows).
>> >> We're foreseen some cases where we'll have that (like Patrick's dib0700 driver),
>> >> but for now, it is not possible to offer more than one interface to userspace.
>> >> Creating an arbitrary number of artificial interfaces just to pass a parameter
>> >> to the driver (the protocol), really seems overkill to me.
>> >
>> > We need to cater to the future cases as well. I don't want to redesign
>> > it in 2 years. But for devices that have only hardware decoders I
>> > suppose we can short-curcuit "interfaces" and have a library-like module
>> > creating input devices directly.
>> >
>> >>
>> >> In the case of the cheap devices with just raw interfaces, running in-kernel
>> >> decoders, while it will work if you create one interface per protocol
>> >> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
>> >> just create additional complexity at the kernelspace and at the userspace, since
>> >> now userspace programs will need to open more than one device to receive the
>> >> keycodes.
>> >
>> > _Yes_!!! You open as many event devices as there are devices you are
>> > interested in receiving data from. Multiplexing devices are bad, bad,
>> > bad. Witness /dev/input/mouse and all the attempts at working around the
>> > fact that if you have a special driver for one of your devices you
>> > receive events from the same device through 2 interfaces and all kind of
>> > "grab", "super-grab", "smart-grab" schemes are born.
>> >
>> >>
>> >> > (for each remote/substream that they can recognize).
>> >>
>> >> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>> >> the remote itself), right?
>> >
>> > If we could separate by remote transmitter that would be the best I
>> > think, but I understand that it is rarely possible?
>>
>> The code I posted using configfs did that. Instead of making apps IR
>> aware it mapped the vendor/device/command triplets into standard Linux
>> keycodes.  Each remote was its own evdev device.
>>
>
> That is what I liked about the patchset.

Some major use cases:
using IR as a keyboard replacement, controlling X and apps with it in
via mouse and keyboard emulation.
using IR to control a headless embedded device possibly running
multiple apps - like audio and home automation (my app)
IR during boot when it is the only input device the box has.
multifunction remote controlling several apps
using several different remotes to control a single app

Using irrecord to train a headless embedded system is impossible.
irrecord is also beyond the capabilities of non-technical users. So
I'd like to see a scheme that eliminates it in 90% of cases. So far
the only solution I've come up with is having a few predefined maps
built in.

>
>> That scheme could be made to "just work" by building in a couple of
>> mapping tables. The driver would pre-populate configfs entries for a
>> some standard IR devices. Set the remote for Motorala DVR. Default
>> Myth to look for the evdev device associated with Motorola DVR. The
>> built-in mapping table would then map from pulse timing to Linux
>> keycodes.
>>
>> If everyone hates configfs the same mapping can be done via the set
>> keys IOCTL and making changes to the user space apps like loadkeys.
>>
>
> It is not the hate of configfs per se, but rather concern that configfs
> takes too much resources and is not normally enabled.

It adds about 35K on 64b x86. 30K on 32b powerpc. If it gets turned on
by default other subsystems might start using it too. I work on an
embedded system. These arguments about non-swapable vs swapable are
pointless. Embedded systems don't have swap devices.

Of course config can be eliminated by modifying the setkeys IOCTL and
user space tools. It will require some more mods to input to allow
multiple maps monitoring the input stream and splitting them onto
multiple evdev devices. This is an equally valid way of building the
maps.

The code I posted is just demo code. It is clearly not in shape to be
merged. Its purpose was to spark a design discussion around creating a
good long-term architecture for IR.

One feature I never got around to was making unknown IR button presses
create entries in the configfs tree. A GUI program could use inotify
on the directory to monitor these new entries.  Now Myth could have a
display of commands it supported, push the IR button to create an
icon, then drop the icon onto the command. Export a script that udev
will use to populate the configfs.

-- 
Jon Smirl
jonsmirl@gmail.com
--
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

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Jon Smirl wrote:
> Some major use cases:
> using IR as a keyboard replacement, controlling X and apps with it in
> via mouse and keyboard emulation.
> using IR to control a headless embedded device possibly running
> multiple apps - like audio and home automation (my app)
> IR during boot when it is the only input device the box has.
> multifunction remote controlling several apps
> using several different remotes to control a single app

I think you reasonably described the major usecases.

>>> If everyone hates configfs the same mapping can be done via the set
>>> keys IOCTL and making changes to the user space apps like loadkeys.
>>>
>> It is not the hate of configfs per se, but rather concern that configfs
>> takes too much resources and is not normally enabled.
> 
> It adds about 35K on 64b x86. 30K on 32b powerpc. If it gets turned on
> by default other subsystems might start using it too. I work on an
> embedded system. These arguments about non-swapable vs swapable are
> pointless. Embedded systems don't have swap devices.

> Of course config can be eliminated by modifying the setkeys IOCTL and
> user space tools. It will require some more mods to input to allow
> multiple maps monitoring the input stream and splitting them onto
> multiple evdev devices. This is an equally valid way of building the
> maps.
> 
> The code I posted is just demo code. It is clearly not in shape to be
> merged. Its purpose was to spark a design discussion around creating a
> good long-term architecture for IR.

Unfortunately, afaik, most distros don't enable configfs yet. I have to
manually compile my kernel when I need some useful stuff there.

I agree with Dmitry: IR is probably not enough to have this enabled by
default on distros. I prefer a more traditional approach like ioctls 
(and/or sysfs) instead of configfs.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>> (for each remote/substream that they can recognize).
>>> >>
>>> >>  I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>> >>  the remote itself), right?
>> >
>> >  If we could separate by remote transmitter that would be the best I
>> >  think, but I understand that it is rarely possible?
 >
> The code I posted using configfs did that. Instead of making apps IR
> aware it mapped the vendor/device/command triplets into standard Linux
> keycodes.  Each remote was its own evdev device.

Note, of course, that you can only do that iff each remote uses distinct 
triplets. A good portion of mythtv users use a universal of some sort, 
programmed to emulate another remote, such as the mce remote bundled 
with mceusb transceivers, or the imon remote bundled with most imon 
receivers. I do just that myself.

Personally, I've always considered the driver/interface to be the 
receiver, not the remote. The lirc drivers operate at the receiver 
level, anyway, and the distinction between different remotes is made by 
the lirc daemon.

> For IR to "just work" the irrecord training process needs be
> eliminated for 90% of users.

Pretty sure that's already the case. I have upwards of 20 remotes and 15 
receivers. I've had to run irrecord maybe two times in five years to get 
any of them working. The existing lirc remote database is fairly extensive.

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>> (for each remote/substream that they can recognize).
>>>> >>
>>>> >>  I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>> >>  the remote itself), right?
>>> >
>>> >  If we could separate by remote transmitter that would be the best I
>>> >  think, but I understand that it is rarely possible?
> >
>> The code I posted using configfs did that. Instead of making apps IR
>> aware it mapped the vendor/device/command triplets into standard Linux
>> keycodes.  Each remote was its own evdev device.
>
> Note, of course, that you can only do that iff each remote uses distinct  
> triplets. A good portion of mythtv users use a universal of some sort,  
> programmed to emulate another remote, such as the mce remote bundled  
> with mceusb transceivers, or the imon remote bundled with most imon  
> receivers. I do just that myself.
>
> Personally, I've always considered the driver/interface to be the  
> receiver, not the remote. The lirc drivers operate at the receiver  
> level, anyway, and the distinction between different remotes is made by  
> the lirc daemon.

The fact that lirc does it this way does not necessarily mean it is the
most corerct way. Do you expect all bluetooth input devices be presented
as a single blob just because they happen to talk to the sane receiver
in yoru laptop? Do you expect your USB mouse and keyboard be merged
together just because they end up being serviced by the same host
controller? If not why remotes should be any different?

Now I understand that if 2 remotes send completely identical signals we
won't be able to separete them, but in cases when we can I think we
should.

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:

> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>> (for each remote/substream that they can recognize).
>>>>>>> 
>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>>>>> the remote itself), right?
>>>>> 
>>>>> If we could separate by remote transmitter that would be the best I
>>>>> think, but I understand that it is rarely possible?
>>> 
>>> The code I posted using configfs did that. Instead of making apps IR
>>> aware it mapped the vendor/device/command triplets into standard Linux
>>> keycodes.  Each remote was its own evdev device.
>> 
>> Note, of course, that you can only do that iff each remote uses distinct  
>> triplets. A good portion of mythtv users use a universal of some sort,  
>> programmed to emulate another remote, such as the mce remote bundled  
>> with mceusb transceivers, or the imon remote bundled with most imon  
>> receivers. I do just that myself.
>> 
>> Personally, I've always considered the driver/interface to be the  
>> receiver, not the remote. The lirc drivers operate at the receiver  
>> level, anyway, and the distinction between different remotes is made by  
>> the lirc daemon.
> 
> The fact that lirc does it this way does not necessarily mean it is the
> most corerct way.

No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.

> Do you expect all bluetooth input devices be presented
> as a single blob just because they happen to talk to the sane receiver
> in yoru laptop? Do you expect your USB mouse and keyboard be merged
> together just because they end up being serviced by the same host
> controller? If not why remotes should be any different?

A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples.

> Now I understand that if 2 remotes send completely identical signals we
> won't be able to separete them, but in cases when we can I think we
> should.

I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where "device" is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :)

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> 
> > On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> >> On 12/2/09 12:30 PM, Jon Smirl wrote:
> >>>>>> (for each remote/substream that they can recognize).
> >>>>>>> 
> >>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
> >>>>>>> the remote itself), right?
> >>>>> 
> >>>>> If we could separate by remote transmitter that would be the best I
> >>>>> think, but I understand that it is rarely possible?
> >>> 
> >>> The code I posted using configfs did that. Instead of making apps IR
> >>> aware it mapped the vendor/device/command triplets into standard Linux
> >>> keycodes.  Each remote was its own evdev device.
> >> 
> >> Note, of course, that you can only do that iff each remote uses distinct  
> >> triplets. A good portion of mythtv users use a universal of some sort,  
> >> programmed to emulate another remote, such as the mce remote bundled  
> >> with mceusb transceivers, or the imon remote bundled with most imon  
> >> receivers. I do just that myself.
> >> 
> >> Personally, I've always considered the driver/interface to be the  
> >> receiver, not the remote. The lirc drivers operate at the receiver  
> >> level, anyway, and the distinction between different remotes is made by  
> >> the lirc daemon.
> > 
> > The fact that lirc does it this way does not necessarily mean it is the
> > most corerct way.
> 
> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
> 
> > Do you expect all bluetooth input devices be presented
> > as a single blob just because they happen to talk to the sane receiver
> > in yoru laptop? Do you expect your USB mouse and keyboard be merged
> > together just because they end up being serviced by the same host
> > controller? If not why remotes should be any different?
> 
> A bluetooth remote has a specific device ID that the receiver has to
> pair with. Your usb mouse and keyboard each have specific device IDs.
> A usb IR *receiver* has a specific device ID, the remotes do not. So
> there's the major difference from your examples.
> 

Not exactly... I can have 2 identical USB keyboadrs form the same
manufacturer and they will still be treated separately. BT has session
ID to help distinguish between devices.

> > Now I understand that if 2 remotes send completely identical signals we
> > won't be able to separete them, but in cases when we can I think we
> > should.
> 
> I don't have a problem with that, if its a truly desired feature. But
> for the most part, I don't see the point. Generally, you go from
> having multiple remotes, one per device (where "device" is your TV,
> amplifier, set top box, htpc, etc), to having a single universal
> remote that controls all of those devices. But for each device (IR
> receiver), *one* IR command set. The desire to use multiple distinct
> remotes with a single IR receiver doesn't make sense to me. Perhaps
> I'm just not creative enough in my use of IR. :)

Didn't Jon posted his example whith programmable remote pretending to be
several separate remotes (depending on the mode of operation) so that
several devices/applications can be controlled without interfering with
each other?

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>
>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>>>> (for each remote/substream that they can recognize).
>>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>>>>>>> the remote itself), right?
>>>>>>> If we could separate by remote transmitter that would be the best I
>>>>>>> think, but I understand that it is rarely possible?
>>>>> The code I posted using configfs did that. Instead of making apps IR
>>>>> aware it mapped the vendor/device/command triplets into standard Linux
>>>>> keycodes.  Each remote was its own evdev device.
>>>> Note, of course, that you can only do that iff each remote uses distinct  
>>>> triplets. A good portion of mythtv users use a universal of some sort,  
>>>> programmed to emulate another remote, such as the mce remote bundled  
>>>> with mceusb transceivers, or the imon remote bundled with most imon  
>>>> receivers. I do just that myself.
>>>>
>>>> Personally, I've always considered the driver/interface to be the  
>>>> receiver, not the remote. The lirc drivers operate at the receiver  
>>>> level, anyway, and the distinction between different remotes is made by  
>>>> the lirc daemon.
>>> The fact that lirc does it this way does not necessarily mean it is the
>>> most corerct way.
>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>>
>>> Do you expect all bluetooth input devices be presented
>>> as a single blob just because they happen to talk to the sane receiver
>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>>> together just because they end up being serviced by the same host
>>> controller? If not why remotes should be any different?
>> A bluetooth remote has a specific device ID that the receiver has to
>> pair with. Your usb mouse and keyboard each have specific device IDs.
>> A usb IR *receiver* has a specific device ID, the remotes do not. So
>> there's the major difference from your examples.
>>
> 
> Not exactly... I can have 2 identical USB keyboadrs form the same
> manufacturer and they will still be treated separately. BT has session
> ID to help distinguish between devices.
> 
>>> Now I understand that if 2 remotes send completely identical signals we
>>> won't be able to separete them, but in cases when we can I think we
>>> should.
>> I don't have a problem with that, if its a truly desired feature. But
>> for the most part, I don't see the point. Generally, you go from
>> having multiple remotes, one per device (where "device" is your TV,
>> amplifier, set top box, htpc, etc), to having a single universal
>> remote that controls all of those devices. But for each device (IR
>> receiver), *one* IR command set. The desire to use multiple distinct
>> remotes with a single IR receiver doesn't make sense to me. Perhaps
>> I'm just not creative enough in my use of IR. :)
> 
> Didn't Jon posted his example whith programmable remote pretending to be
> several separate remotes (depending on the mode of operation) so that
> several devices/applications can be controlled without interfering with
> each other?
> 
>From what I understood, he is using the same physical remote, but creating different
IR groups of keys on it, each group meant to be used by a different application.

For such usage, some software will need to filter the scancode group and send
them only for a certain application. This can be done easily by using lirc,
purely in userspace.

Another alternative (that will also work for multimedia keys on a keyboard) is
to add a filtering subsystem at evdev that will send certain events for just certain
PID's.

Of course, it is feasible to do it in kernel, but, IMHO, it would be better to let
userspace to take care of this.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> >>> Now I understand that if 2 remotes send completely identical signals we
> >>> won't be able to separete them, but in cases when we can I think we
> >>> should.
> >> I don't have a problem with that, if its a truly desired feature. But
> >> for the most part, I don't see the point. Generally, you go from
> >> having multiple remotes, one per device (where "device" is your TV,
> >> amplifier, set top box, htpc, etc), to having a single universal
> >> remote that controls all of those devices. But for each device (IR
> >> receiver), *one* IR command set. The desire to use multiple distinct
> >> remotes with a single IR receiver doesn't make sense to me. Perhaps
> >> I'm just not creative enough in my use of IR. :)
> > 
> > Didn't Jon posted his example whith programmable remote pretending to be
> > several separate remotes (depending on the mode of operation) so that
> > several devices/applications can be controlled without interfering with
> > each other?
> > 
> From what I understood, he is using the same physical remote, but creating different
> IR groups of keys on it, each group meant to be used by a different application.
> 
> For such usage, some software will need to filter the scancode group and send
> them only for a certain application. This can be done easily by using lirc,
> purely in userspace.
> 
> Another alternative (that will also work for multimedia keys on a keyboard) is
> to add a filtering subsystem at evdev that will send certain events for just certain
> PID's.

They are the same key events (Lets's say KEY_PLAY) but one is supposed
to affect CD player while another DVD player application. Evdev will not
be able to distinguish them but if we had 2 separate devices then
applications could read from the one thet user assigned to them.

However even subscription is something that is desirable to have ouside
of IRC handling topic (so that supporting applications need not be woken
up by events they are not interested in - example mixer application is
interested in KEY_VOLUMEUP, KEY_VOLUMEDOWN and KEY_MUTE but not any
other key that may be emitted by a keyboard).

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>>> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
>>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>>> Now I understand that if 2 remotes send completely identical signals we
>>>>> won't be able to separete them, but in cases when we can I think we
>>>>> should.
>>>> I don't have a problem with that, if its a truly desired feature. But
>>>> for the most part, I don't see the point. Generally, you go from
>>>> having multiple remotes, one per device (where "device" is your TV,
>>>> amplifier, set top box, htpc, etc), to having a single universal
>>>> remote that controls all of those devices. But for each device (IR
>>>> receiver), *one* IR command set. The desire to use multiple distinct
>>>> remotes with a single IR receiver doesn't make sense to me. Perhaps
>>>> I'm just not creative enough in my use of IR. :)
>>> Didn't Jon posted his example whith programmable remote pretending to be
>>> several separate remotes (depending on the mode of operation) so that
>>> several devices/applications can be controlled without interfering with
>>> each other?
>>>
>> From what I understood, he is using the same physical remote, but creating different
>> IR groups of keys on it, each group meant to be used by a different application.
>>
>> For such usage, some software will need to filter the scancode group and send
>> them only for a certain application. This can be done easily by using lirc,
>> purely in userspace.
>>
>> Another alternative (that will also work for multimedia keys on a keyboard) is
>> to add a filtering subsystem at evdev that will send certain events for just certain
>> PID's.
> 
> They are the same key events (Lets's say KEY_PLAY) but one is supposed
> to affect CD player while another DVD player application. Evdev will not
> be able to distinguish them but if we had 2 separate devices then
> applications could read from the one thet user assigned to them.

This is clear, but the point is that the two distinguish scancodes can 
(and, in practice, will) be generated by the same IR. For example, my Satellite IR
produces two different sets of codes. if you press <SAT>, all keys you press after
that will have the "sat" address. If you press <TV>, they'll get a different address.

So, the needed feature is not to really distinguish two different IR's, but to allow
to create groups of scancodes that will be directed to a distinct interface.

I won't object about such interface, but the default should be to have just one interface
and having all conversion applied to that interface.

Maybe we can have a separate module for IR evdev filtering to fulfill this need.

Basically, such module will get the events from one input interface and create an
arbitrary number of evdev devices, and will apply different scancode->keycode tables
for each different interfaces. I don't see why to limit the input interface to be IR. It
can eventually be any input interface (bluetooth, keyboard, PS/3 control, Wii control, ...). 

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Ferenc Wagner]

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

> Dmitry Torokhov wrote:
>
>>>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>>>
>>>>>> Now I understand that if 2 remotes send completely identical
>>>>>> signals we won't be able to separete them, but in cases when we
>>>>>> can I think we should.
>>
>> They are the same key events (Lets's say KEY_PLAY) but one is
>> supposed to affect CD player while another DVD player
>> application. Evdev will not be able to distinguish them but if we had
>> 2 separate devices then applications could read from the one thet
>> user assigned to them.
>
> This is clear, but the point is that the two distinguish scancodes can
> (and, in practice, will) be generated by the same IR. For example, my
> Satellite IR produces two different sets of codes. if you press <SAT>,
> all keys you press after that will have the "sat" address. If you
> press <TV>, they'll get a different address.

The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
by any remote (ok, I'm stretching it a bit).  Instead, a multifunction
remote (or two distinct remotes) would send different scan codes[1],
which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
Btw. the former is already defined, besides the generic KEY_PLAY.

Even if all this worked, user space would need integration with
hal/devicekit to open the new input devices appearing on the fly (if
it's initiated by the arrival of a scan code belonging to some new
protocol), and also be able to decide whether the new event source is
for it or not.

Given that commodity home appliances manage not to be confused by
multiple or multifunction remotes, decent software should be able to do
so as well.

[1] scan codes in the broadest possible sense, containing vendor,
address and whatever, and only treating the case which is possible to
handle in principle.
-- 
Regards,
Feri.

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Ferenc Wagner wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> Dmitry Torokhov wrote:
>>

> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
> by any remote (ok, I'm stretching it a bit). 

Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc.

On those remotes, if you press TV and then press for example Channel UP
and press Radio, then press Channel UP, the channel UP code will be the same.

For example, on Hauppauge Grey IR, we have:

<TV>
[13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179
[13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1
[13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0

<CHANNEL UP>
[13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
[13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
[13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0

<Radio>
[13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181
[13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1
[13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0

<CHANNEL UP>
[13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
[13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
[13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0

In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the
shipped IR's.

> Instead, a multifunction
> remote (or two distinct remotes) would send different scan codes[1],
> which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
> Btw. the former is already defined, besides the generic KEY_PLAY.
> 
> Even if all this worked, user space would need integration with
> hal/devicekit to open the new input devices appearing on the fly (if
> it's initiated by the arrival of a scan code belonging to some new
> protocol), and also be able to decide whether the new event source is
> for it or not.
> 
> Given that commodity home appliances manage not to be confused by
> multiple or multifunction remotes, decent software should be able to do
> so as well.
> 
> [1] scan codes in the broadest possible sense, containing vendor,
> address and whatever, and only treating the case which is possible to
> handle in principle.

I see two alternatives for it:
	1) to map a multifunction scancode Address=TV/command=channel up as two
separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
handle it (lirc or other programs that knows IR keycodes);

	2) to implement Jon's filter idea of splitting one evdev interface into
several evdevs interface, one for each address.

We should not forget that simple IR's don't have any key to select the address,
so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Ferenc Wagner wrote:
>> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
>>
>>> Dmitry Torokhov wrote:
>>>
>
>> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
>> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
>> by any remote (ok, I'm stretching it a bit).
>
> Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc.
>
> On those remotes, if you press TV and then press for example Channel UP
> and press Radio, then press Channel UP, the channel UP code will be the same.
>
> For example, on Hauppauge Grey IR, we have:
>
> <TV>
> [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179
> [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1
> [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0
>
> <CHANNEL UP>
> [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
>
> <Radio>
> [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181
> [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1
> [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0
>
> <CHANNEL UP>
> [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
>
> In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the
> shipped IR's.

The remote is treating everything as a single integrated device which
is not inconsistent with what has been said. In this case there really
is only one multi-function device not two independent ones.

If you want to control two independent devices you need to buy a
different remote. Remotes are cheap so that's not a big deal.

If you really want to use this remote to control two independent
devices you need user space scripting to split the single device into
two devices and then inject new events into the input layer. This is a
complex case and not in the goal of getting 90% of users to "just
work".

>
>> Instead, a multifunction
>> remote (or two distinct remotes) would send different scan codes[1],
>> which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
>> Btw. the former is already defined, besides the generic KEY_PLAY.
>>
>> Even if all this worked, user space would need integration with
>> hal/devicekit to open the new input devices appearing on the fly (if
>> it's initiated by the arrival of a scan code belonging to some new
>> protocol), and also be able to decide whether the new event source is
>> for it or not.
>>
>> Given that commodity home appliances manage not to be confused by
>> multiple or multifunction remotes, decent software should be able to do
>> so as well.
>>
>> [1] scan codes in the broadest possible sense, containing vendor,
>> address and whatever, and only treating the case which is possible to
>> handle in principle.
>
> I see two alternatives for it:
>        1) to map a multifunction scancode Address=TV/command=channel up as two
> separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
> handle it (lirc or other programs that knows IR keycodes);
>
>        2) to implement Jon's filter idea of splitting one evdev interface into
> several evdevs interface, one for each address.
>
> We should not forget that simple IR's don't have any key to select the address,
> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
>
> Cheers,
> Mauro.
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
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

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl <jonsmirl@gmail.com> escreveu:

> On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> > Ferenc Wagner wrote:
> >> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> >>
> >>> Dmitry Torokhov wrote:
> >>>
> >
> >> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
> >> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
> >> by any remote (ok, I'm stretching it a bit).
> >
> > Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc.
> >
> > On those remotes, if you press TV and then press for example Channel UP
> > and press Radio, then press Channel UP, the channel UP code will be the same.
> >
> > For example, on Hauppauge Grey IR, we have:
> >
> > <TV>
> > [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179
> > [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1
> > [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0
> >
> > <CHANNEL UP>
> > [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> > [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> > [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
> >
> > <Radio>
> > [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181
> > [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1
> > [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0
> >
> > <CHANNEL UP>
> > [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192
> > [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1
> > [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0
> >
> > In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the
> > shipped IR's.
> 
> The remote is treating everything as a single integrated device which
> is not inconsistent with what has been said. In this case there really
> is only one multi-function device not two independent ones.
> 
> If you want to control two independent devices you need to buy a
> different remote. Remotes are cheap so that's not a big deal.
> 
> If you really want to use this remote to control two independent
> devices you need user space scripting to split the single device into
> two devices and then inject new events into the input layer. This is a
> complex case and not in the goal of getting 90% of users to "just
> work".

This remote is a typical example of the IR's that are provided together with media boards.
On all such IR's I know, it does generate one key event for TV, SAT, DVB, DVD... keys and
this event doesn't change the status of subsequent keys.

100% of the users of such boards will have the shipped IR. Some amount will be happy of
just using the provided IR to control different applications at their computer or embedded
hardware, and some amount will prefer to buy a multi-purpose IR that will allow him
to control not only his computer, but also, his TV, his Air conditioning, etc.

Both usages should be supported.

All I'm saying is that, in the case where people have only the shipped IR, if he wants to
see TV, the produced keycode will be KEY_TV, and then to change a channel, it will
receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, 
he will press KEY_DVB and then KEY_PLAY to play his movie.

So, an application like MythTV should be able to work with those keys.

I don't see the need to create a separate code for KEY_PLAYDVB, as this can be simply mapped
as KEY_DVB and KEY_PLAY.


-- 

Cheers,
Mauro

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
> Ferenc Wagner wrote:
> > Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
> We should not forget that simple IR's don't have any key to select the address,
> so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Ferenc Wagner]

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

> On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
>> Ferenc Wagner wrote:
>>> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
>> 
>> We should not forget that simple IR's don't have any key to select the address,
>> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
>
> Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
> media inputs in a device/application. My receiver accepts codes like
> that.

Sorry, my point wasn't the event names, I picked them for their
superficial correspondence to the TV, DVD, SAT etc. buttons found on
multifunction remotes.  Obviously I picked wrong.

I was also wrong to assume that remotes with such buttons are always
multifunction remotes in the sense that they are meant to control
separate devices.  As Mauro pointed out, (some) bundled remotes with
such buttons aren't; thus I wouldn't consider them multifunction at all.
They simply have some extra buttons labelled TV, DVD etc, which probably
shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry
different semantics) but should be mapped to something else.  Or not, if
these buttons change some internal decoder state instead, modifying the
mapping or destination input device of the other keys.

It's just a different scenario, where the kernel could reasonably give
rather different representations to simple applications aiming at
plug&play: letting through the function change events untouched, or
masking and using them internally.

True multifunction devices don't send such events, the TV, DVD etc
buttons on them change their internal state and the scan codes sent by
the other keys, if I understand this correctly.

I'd prefer if these two behaviours could be abstacted from, and the
input layer interface would provide destination selection events +
generic events, or (to be defined) device specific events only in either
case.  Is that possible or even reasonable?
-- 
Thanks,
Feri.

Ps: I'm writing this in the hope to clean up the landscape and possibly
help in choosing the best design.  I'm not at all familiar with IR, and
the above distinction was pretty surprising for me.  Also, I'm just
lurking here, so don't take me too seriously. :)

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote:

> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>> 
>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>>>> (for each remote/substream that they can recognize).
>>>>>>>>> 
>>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>>>>>>> the remote itself), right?
>>>>>>> 
>>>>>>> If we could separate by remote transmitter that would be the best I
>>>>>>> think, but I understand that it is rarely possible?
>>>>> 
>>>>> The code I posted using configfs did that. Instead of making apps IR
>>>>> aware it mapped the vendor/device/command triplets into standard Linux
>>>>> keycodes.  Each remote was its own evdev device.
>>>> 
>>>> Note, of course, that you can only do that iff each remote uses distinct  
>>>> triplets. A good portion of mythtv users use a universal of some sort,  
>>>> programmed to emulate another remote, such as the mce remote bundled  
>>>> with mceusb transceivers, or the imon remote bundled with most imon  
>>>> receivers. I do just that myself.
>>>> 
>>>> Personally, I've always considered the driver/interface to be the  
>>>> receiver, not the remote. The lirc drivers operate at the receiver  
>>>> level, anyway, and the distinction between different remotes is made by  
>>>> the lirc daemon.
>>> 
>>> The fact that lirc does it this way does not necessarily mean it is the
>>> most corerct way.
>> 
>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>> 
>>> Do you expect all bluetooth input devices be presented
>>> as a single blob just because they happen to talk to the sane receiver
>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>>> together just because they end up being serviced by the same host
>>> controller? If not why remotes should be any different?
>> 
>> A bluetooth remote has a specific device ID that the receiver has to
>> pair with. Your usb mouse and keyboard each have specific device IDs.
>> A usb IR *receiver* has a specific device ID, the remotes do not. So
>> there's the major difference from your examples.
>> 
> 
> Not exactly... I can have 2 identical USB keyboadrs form the same
> manufacturer and they will still be treated separately. BT has session
> ID to help distinguish between devices.

Semantics. :)

My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from.

>>> Now I understand that if 2 remotes send completely identical signals we
>>> won't be able to separete them, but in cases when we can I think we
>>> should.
>> 
>> I don't have a problem with that, if its a truly desired feature. But
>> for the most part, I don't see the point. Generally, you go from
>> having multiple remotes, one per device (where "device" is your TV,
>> amplifier, set top box, htpc, etc), to having a single universal
>> remote that controls all of those devices. But for each device (IR
>> receiver), *one* IR command set. The desire to use multiple distinct
>> remotes with a single IR receiver doesn't make sense to me. Perhaps
>> I'm just not creative enough in my use of IR. :)
> 
> Didn't Jon posted his example whith programmable remote pretending to be
> several separate remotes (depending on the mode of operation) so that
> several devices/applications can be controlled without interfering with
> each other?

Yes. But that's an atypical usage, in my experience, and as Mauro said, something that can be done trivially in userspace (lirc can do this today, even for the same remote and mode of operation, on a per-key basis if you want). If it doesn't add too much complexity and people will actually use it, I don't have a problem with implementing one input device per distinct remote, but I doubt many people would use that functionality.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 03:42:13PM -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote:
> 
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
> >> 
> >>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> >>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
> >>>>>>>> (for each remote/substream that they can recognize).
> >>>>>>>>> 
> >>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
> >>>>>>>>> the remote itself), right?
> >>>>>>> 
> >>>>>>> If we could separate by remote transmitter that would be the best I
> >>>>>>> think, but I understand that it is rarely possible?
> >>>>> 
> >>>>> The code I posted using configfs did that. Instead of making apps IR
> >>>>> aware it mapped the vendor/device/command triplets into standard Linux
> >>>>> keycodes.  Each remote was its own evdev device.
> >>>> 
> >>>> Note, of course, that you can only do that iff each remote uses distinct  
> >>>> triplets. A good portion of mythtv users use a universal of some sort,  
> >>>> programmed to emulate another remote, such as the mce remote bundled  
> >>>> with mceusb transceivers, or the imon remote bundled with most imon  
> >>>> receivers. I do just that myself.
> >>>> 
> >>>> Personally, I've always considered the driver/interface to be the  
> >>>> receiver, not the remote. The lirc drivers operate at the receiver  
> >>>> level, anyway, and the distinction between different remotes is made by  
> >>>> the lirc daemon.
> >>> 
> >>> The fact that lirc does it this way does not necessarily mean it is the
> >>> most corerct way.
> >> 
> >> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
> >> 
> >>> Do you expect all bluetooth input devices be presented
> >>> as a single blob just because they happen to talk to the sane receiver
> >>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
> >>> together just because they end up being serviced by the same host
> >>> controller? If not why remotes should be any different?
> >> 
> >> A bluetooth remote has a specific device ID that the receiver has to
> >> pair with. Your usb mouse and keyboard each have specific device IDs.
> >> A usb IR *receiver* has a specific device ID, the remotes do not. So
> >> there's the major difference from your examples.
> >> 
> > 
> > Not exactly... I can have 2 identical USB keyboadrs form the same
> > manufacturer and they will still be treated separately. BT has session
> > ID to help distinguish between devices.
> 
> Semantics. :)
> 
> My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from.
> 

Heh, right back at ya ;) The fact that you need to do some more work
to separate 2 physical devices does not mean it should not be done.

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On Dec 2, 2009, at 3:48 PM, Dmitry Torokhov wrote:
...
>>>>>> Personally, I've always considered the driver/interface to be the  
>>>>>> receiver, not the remote. The lirc drivers operate at the receiver  
>>>>>> level, anyway, and the distinction between different remotes is made by  
>>>>>> the lirc daemon.
>>>>> 
>>>>> The fact that lirc does it this way does not necessarily mean it is the
>>>>> most corerct way.
>>>> 
>>>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>>>> 
>>>>> Do you expect all bluetooth input devices be presented
>>>>> as a single blob just because they happen to talk to the sane receiver
>>>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>>>>> together just because they end up being serviced by the same host
>>>>> controller? If not why remotes should be any different?
>>>> 
>>>> A bluetooth remote has a specific device ID that the receiver has to
>>>> pair with. Your usb mouse and keyboard each have specific device IDs.
>>>> A usb IR *receiver* has a specific device ID, the remotes do not. So
>>>> there's the major difference from your examples.
>>>> 
>>> 
>>> Not exactly... I can have 2 identical USB keyboadrs form the same
>>> manufacturer and they will still be treated separately. BT has session
>>> ID to help distinguish between devices.
>> 
>> Semantics. :)
>> 
>> My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from.
>> 
> 
> Heh, right back at ya ;) The fact that you need to do some more work
> to separate 2 physical devices does not mean it should not be done.

No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [RFC v2] Another approach to IR

[Trent Piepho]

On Wed, 2 Dec 2009, Jarod Wilson wrote:
> >>
> >> My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from.
> >>
> >
> > Heh, right back at ya ;) The fact that you need to do some more work
> > to separate 2 physical devices does not mean it should not be done.
>
> No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work.

You just need to send a tuple that contrains the keycode plus some kind of
id for the remote it came from.  That's what I did for lirc, it decodes the
sparc/mark into a remote id and key code tuple.  It's certainly a common
thing to want.  Anyone who has existing remotes and components that use
them would want it.  You don't want your computer turning off when you push
the power button on the DVD player's remote, do you?

Each host connected to a network interface doesn't get its own device.

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote:

> On Wed, 2 Dec 2009, Jarod Wilson wrote:
>>>> 
>>>> My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from.
>>>> 
>>> 
>>> Heh, right back at ya ;) The fact that you need to do some more work
>>> to separate 2 physical devices does not mean it should not be done.
>> 
>> No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work.
> 
> You just need to send a tuple that contrains the keycode plus some kind of
> id for the remote it came from.  That's what I did for lirc, it decodes the
> sparc/mark into a remote id and key code tuple.  It's certainly a common
> thing to want.  Anyone who has existing remotes and components that use
> them would want it.

What for, exactly?

> You don't want your computer turning off when you push
> the power button on the DVD player's remote, do you?

No, I don't.

Perhaps we should clarify something here. Are we intending to auto-create a new input device for every IR command set we see arrive at the IR receiver? I've been assuming we're not going to willy-nilly just auto-create a new device for every IR signal we happen to catch passing by. The receiver should only be passing along input events for the codeset/remote I've told it to listen for (which by default, is the codes for the receiver's bundled remote). Otherwise, yeah, I'm going to wind up with my htpc powering off when I hit the button on my harmony remote that is supposed to turn off my tv and amp.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Jarod Wilson wrote:
> On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote:
> 
>> On Wed, 2 Dec 2009, Jarod Wilson wrote:
>>>>> My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from.
>>>>>
>>>> Heh, right back at ya ;) The fact that you need to do some more work
>>>> to separate 2 physical devices does not mean it should not be done.
>>> No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work.
>> You just need to send a tuple that contrains the keycode plus some kind of
>> id for the remote it came from.  That's what I did for lirc, it decodes the
>> sparc/mark into a remote id and key code tuple.  It's certainly a common
>> thing to want.  Anyone who has existing remotes and components that use
>> them would want it.
> 
> What for, exactly?
> 
>> You don't want your computer turning off when you push
>> the power button on the DVD player's remote, do you?
> 
> No, I don't.

In this specific case, IMO, the default keytables should map the power button to KEY_POWER2.
> 
> Perhaps we should clarify something here. Are we intending to auto-create 
> a new input device for every IR command set we see arrive at the IR receiver? 
> I've been assuming we're not going to willy-nilly just auto-create a new device
> for every IR signal we happen to catch passing by. The receiver should only 
> be passing along input events for the codeset/remote I've told it to listen
> for (which by default, is the codes for the receiver's bundled remote).

Yes, but several bundled IR's have a power button. By default, it doesn't make sense
to use it to turn the machine off, so KEY_POWER2 is a good option.

> Otherwise, yeah, I'm going to wind up with my htpc powering off when
> I hit the button on my harmony remote that is supposed to turn off my tv and amp.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Krzysztof Halasa]

Jarod Wilson <jarod@wilsonet.com> writes:

> Perhaps we should clarify something here. Are we intending to
> auto-create a new input device for every IR command set we see arrive
> at the IR receiver?

We don't want this, and we aren't really able to do this, because we
never know if two different scan codes are part of the same or different
command set.

Sharing the protocol and e.g. group code doesn't mean it's the same
remote.

Different protocol doesn't mean it's a different remote and what's more
important, doesn't mean the user wants it to be a different logical
remote.
-- 
Krzysztof Halasa

Re: [RFC v2] Another approach to IR

[Andy Walls]

On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote:
> On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:


> Didn't Jon posted his example whith programmable remote pretending to be
> several separate remotes (depending on the mode of operation) so that
> several devices/applications can be controlled without interfering with
> each other?


There are a few features that can be used to distinguish remotes:

1. Carrier freq
2. Protocol (NEC, Sony, JVC, RC-5...)
3. Protocol variant (NEC original, NEC with extended addresses,
		     RC-5, RC-5 with exteneded commands,
		     RC-6 Mode 0, RC-6 Mode 6B, ...)
4. System # or Address sent by the remote (16 bits max, I think)
5. Set of possible Commands or Information words sent from the remote.
6. Pulse width deviation from standard (mean, variance)


1, 5, and 6 are really a sort of "fingerprint" and likely not worth the
effort, even if you have hardware that can measure things with some
accuracy.

Regards,
Andy

Re: [RFC v2] Another approach to IR

[hermann pitton]

Am Mittwoch, den 02.12.2009, 20:19 -0500 schrieb Andy Walls:
> On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> 
> 
> > Didn't Jon posted his example whith programmable remote pretending to be
> > several separate remotes (depending on the mode of operation) so that
> > several devices/applications can be controlled without interfering with
> > each other?
> 
> 
> There are a few features that can be used to distinguish remotes:
> 
> 1. Carrier freq
> 2. Protocol (NEC, Sony, JVC, RC-5...)
> 3. Protocol variant (NEC original, NEC with extended addresses,
> 		     RC-5, RC-5 with exteneded commands,
> 		     RC-6 Mode 0, RC-6 Mode 6B, ...)
> 4. System # or Address sent by the remote (16 bits max, I think)
> 5. Set of possible Commands or Information words sent from the remote.
> 6. Pulse width deviation from standard (mean, variance)
> 
> 
> 1, 5, and 6 are really a sort of "fingerprint" and likely not worth the
> effort, even if you have hardware that can measure things with some
> accuracy.

I don't follow closely enough, but eventually we have (different)
remotes a receiver chip can distinguish in hardware, firmware might be
involved too.

If I don't get it wrong, Dmitry is asking in the first place, how such
sender receiver combinations switch to different emulated digital
information for a bunch of different types of hardware in living rooms.

Starting with RC5, IIRC, there is of course such switch over to another
device around. We are only one more.

To repeat, on such bundled cheapest remotes with some TV/DVB cards
around, there are only some minimal implementations of RC5, likely they
use that protocol even illegally, at least they make chips in use
unidentifiable and this seems to be by will.

So, if some try to implement now the highest level, they are far away
from to know what hardware goes how far with them.

At least fun to see they have some starting point ;)

Cheers,
Hermann

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>
>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>>> (for each remote/substream that they can recognize).
>>>>>>>>
>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>>>>>> the remote itself), right?
>>>>>>
>>>>>> If we could separate by remote transmitter that would be the best I
>>>>>> think, but I understand that it is rarely possible?
>>>>
>>>> The code I posted using configfs did that. Instead of making apps IR
>>>> aware it mapped the vendor/device/command triplets into standard Linux
>>>> keycodes.  Each remote was its own evdev device.
>>>
>>> Note, of course, that you can only do that iff each remote uses distinct
>>> triplets. A good portion of mythtv users use a universal of some sort,
>>> programmed to emulate another remote, such as the mce remote bundled
>>> with mceusb transceivers, or the imon remote bundled with most imon
>>> receivers. I do just that myself.
>>>
>>> Personally, I've always considered the driver/interface to be the
>>> receiver, not the remote. The lirc drivers operate at the receiver
>>> level, anyway, and the distinction between different remotes is made by
>>> the lirc daemon.
>>
>> The fact that lirc does it this way does not necessarily mean it is the
>> most corerct way.
>
> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>
>> Do you expect all bluetooth input devices be presented
>> as a single blob just because they happen to talk to the sane receiver
>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>> together just because they end up being serviced by the same host
>> controller? If not why remotes should be any different?
>
> A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples.

Actually remotes do have an ID. They all transmit vendor/device pairs
which is exactly how USB works.

>
>> Now I understand that if 2 remotes send completely identical signals we
>> won't be able to separate them, but in cases when we can I think we
>> should.
>
> I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where "device" is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :)
>
> --
> Jarod Wilson
> jarod@wilsonet.com
>
>
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>
>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>>>> (for each remote/substream that they can recognize).
>>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>>>>>>> the remote itself), right?
>>>>>>> If we could separate by remote transmitter that would be the best I
>>>>>>> think, but I understand that it is rarely possible?
>>>>> The code I posted using configfs did that. Instead of making apps IR
>>>>> aware it mapped the vendor/device/command triplets into standard Linux
>>>>> keycodes.  Each remote was its own evdev device.
>>>> Note, of course, that you can only do that iff each remote uses distinct
>>>> triplets. A good portion of mythtv users use a universal of some sort,
>>>> programmed to emulate another remote, such as the mce remote bundled
>>>> with mceusb transceivers, or the imon remote bundled with most imon
>>>> receivers. I do just that myself.
>>>>
>>>> Personally, I've always considered the driver/interface to be the
>>>> receiver, not the remote. The lirc drivers operate at the receiver
>>>> level, anyway, and the distinction between different remotes is made by
>>>> the lirc daemon.
>>> The fact that lirc does it this way does not necessarily mean it is the
>>> most corerct way.
>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>>
>>> Do you expect all bluetooth input devices be presented
>>> as a single blob just because they happen to talk to the sane receiver
>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>>> together just because they end up being serviced by the same host
>>> controller? If not why remotes should be any different?
>> A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples.
> 
> Actually remotes do have an ID. They all transmit vendor/device pairs
> which is exactly how USB works.
> 

Well, the description of NEC and RC5 protocol at http://www.sbprojects.com/knowledge/ir/rc5.htm
doesn't mention any vendor/device pair, nor I'm able to get them with the IR hardware decoders
I have.

Do you have any info on how they're encoded?

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Jon Smirl wrote:
>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>
>>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>>>>> (for each remote/substream that they can recognize).
>>>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>>>>>>>> the remote itself), right?
>>>>>>>> If we could separate by remote transmitter that would be the best I
>>>>>>>> think, but I understand that it is rarely possible?
>>>>>> The code I posted using configfs did that. Instead of making apps IR
>>>>>> aware it mapped the vendor/device/command triplets into standard Linux
>>>>>> keycodes.  Each remote was its own evdev device.
>>>>> Note, of course, that you can only do that iff each remote uses distinct
>>>>> triplets. A good portion of mythtv users use a universal of some sort,
>>>>> programmed to emulate another remote, such as the mce remote bundled
>>>>> with mceusb transceivers, or the imon remote bundled with most imon
>>>>> receivers. I do just that myself.
>>>>>
>>>>> Personally, I've always considered the driver/interface to be the
>>>>> receiver, not the remote. The lirc drivers operate at the receiver
>>>>> level, anyway, and the distinction between different remotes is made by
>>>>> the lirc daemon.
>>>> The fact that lirc does it this way does not necessarily mean it is the
>>>> most corerct way.
>>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>>>
>>>> Do you expect all bluetooth input devices be presented
>>>> as a single blob just because they happen to talk to the sane receiver
>>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>>>> together just because they end up being serviced by the same host
>>>> controller? If not why remotes should be any different?
>>> A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples.
>>
>> Actually remotes do have an ID. They all transmit vendor/device pairs
>> which is exactly how USB works.
>>
>
> Well, the description of NEC and RC5 protocol at http://www.sbprojects.com/knowledge/ir/rc5.htm
> doesn't mention any vendor/device pair, nor I'm able to get them with the IR hardware decoders
> I have.

Some of the protocols were not intended to be multi-vendor  - the
vendor is implicit in the protocol encoding. You don't have to split
the IR codes into vendor/device/command triplets. I just do that
because it is convenient to think of them that way. It is equally
valid to treat them as a 64b integers and use four bits of the int to
encode the protocol.  It should really be a quad
protocol/vendor/device/command and some of the fields may be missing.
Bottom line, you are looking for unique codes how the fields are split
up doesn't really matter.

A fixed protocol receiver is more of a challenge. You have to figure
out how to make a universal remote transmit device codes for a device
you don't already own that is also encoded in the protocol your
hardware supports. There's nothing we can do about that problem in
Linux, its a side effect of fixed protocol decode hardware. You're
just going to have to start guessing devices in the remote until you
find one that uses your fixed protocol and doesn't also activate the
devices you own. We can put suggestions in the doc when working
devices are discovered. With a universal receiver the problem is
simpler, just pick a device you don't own - the encoding protocol
doesn't matter. These are generic problems with IR that are the same
no matter how things get implemented in Linux.


-- 
Jon Smirl
jonsmirl@gmail.com
--
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

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Jon Smirl wrote:
>>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
>>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>>
>>>>> On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
>>>>>> On 12/2/09 12:30 PM, Jon Smirl wrote:
>>>>>>>>>> (for each remote/substream that they can recognize).
>>>>>>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>>>>>>>>> the remote itself), right?
>>>>>>>>> If we could separate by remote transmitter that would be the best I
>>>>>>>>> think, but I understand that it is rarely possible?
>>>>>>> The code I posted using configfs did that. Instead of making apps IR
>>>>>>> aware it mapped the vendor/device/command triplets into standard Linux
>>>>>>> keycodes.  Each remote was its own evdev device.
>>>>>> Note, of course, that you can only do that iff each remote uses distinct
>>>>>> triplets. A good portion of mythtv users use a universal of some sort,
>>>>>> programmed to emulate another remote, such as the mce remote bundled
>>>>>> with mceusb transceivers, or the imon remote bundled with most imon
>>>>>> receivers. I do just that myself.
>>>>>>
>>>>>> Personally, I've always considered the driver/interface to be the
>>>>>> receiver, not the remote. The lirc drivers operate at the receiver
>>>>>> level, anyway, and the distinction between different remotes is made by
>>>>>> the lirc daemon.
>>>>> The fact that lirc does it this way does not necessarily mean it is the
>>>>> most corerct way.
>>>> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>>>>
>>>>> Do you expect all bluetooth input devices be presented
>>>>> as a single blob just because they happen to talk to the sane receiver
>>>>> in yoru laptop? Do you expect your USB mouse and keyboard be merged
>>>>> together just because they end up being serviced by the same host
>>>>> controller? If not why remotes should be any different?
>>>> A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples.
>>> Actually remotes do have an ID. They all transmit vendor/device pairs
>>> which is exactly how USB works.
>>>
>> Well, the description of NEC and RC5 protocol at http://www.sbprojects.com/knowledge/ir/rc5.htm
>> doesn't mention any vendor/device pair, nor I'm able to get them with the IR hardware decoders
>> I have.
> 
> Some of the protocols were not intended to be multi-vendor  - the
> vendor is implicit in the protocol encoding. You don't have to split
> the IR codes into vendor/device/command triplets. I just do that
> because it is convenient to think of them that way. It is equally
> valid to treat them as a 64b integers and use four bits of the int to
> encode the protocol.  It should really be a quad
> protocol/vendor/device/command and some of the fields may be missing.
> Bottom line, you are looking for unique codes how the fields are split
> up doesn't really matter.

Currently, there aren't any in-kernel driver that support 64 bit IR's.
They support only up to 16 bits. So, we have only address (device)/command. 
As I said before, AFAIK, only RC6 mode 6 remotes support 64 bits. 

As pointed by Andy, it is risky to support such protocol in kernel,
since you won't be able to ship the kernel to countries where RC6 patents 
got accepted, or you would need.

> A fixed protocol receiver is more of a challenge. You have to figure
> out how to make a universal remote transmit device codes for a device
> you don't already own that is also encoded in the protocol your
> hardware supports. 
> There's nothing we can do about that problem in
> Linux, its a side effect of fixed protocol decode hardware. 

With hardware decoders, you're limited to the supported protocols, but yet,
you can use a different scancode than the one that comes with the shipped
device.

If you take a look, for example, at the NEC protocol decoder we have on
drivers/media/video/saa7134/saa7134-input.c [1], you'll see that the
tasklet (nec_task) holds CPU control up to 76.5 ms, in order to be able
to receive the entire sequence at the GPIO port. Fortunately, on the device
where this decoder is called (Avermedia M135A), we can trigger the start
of the IR code via IRQ.

[1]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/video/saa7134/saa7134-input.c;h=6e219c2db8419013ab3ced30470ad1c19431974a;hb=HEAD


In this specific decoder I've implemented it some time ago. I think
I tried first to get the pulse/space width using just IRQ without the tasklet,
but the lengths weren't precise enough for decoding. Also, if you have a bad
contact at the IR sensor connector, as it is directly connected to an IRQ pin,
you may end by hanging the machine, if the code is not carefully written.

I remember I had some bad time due to the bad contacts at the IR sensor
with the sample I had available for implementing that IR.

Btw, looking at that code, while it is not impossible to split the 
IR pulse/space measures from the NEC decoder itself, and make it generic
to support other protocols, it is not a trivial task, and may result on
a less stable driver. Without splitting the protocol decoder, even being
able to store raw pulse/space data on some fifo, the driver will still
limit the protocol for that board to NEC (there is a similar code for RC5
there also, using some generic functions [2]).

[2]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/common/ir-functions.c;h=16792a68a44951e1bc1c2cbb1c9da27a2b6b2722;hb=HEAD


The advantage of the NEC decoding approach on saa7134 is that you know for
sure how much time it is required to get the entire code. So, the code 
can easily abort the reception of a bad code. The disadvantage is that 
only one protocol can be decoded at the same time.

The same problem also happens with almost all in-kernel drivers: the decoders
for raw mode were constructed to work with just one pulse/space code at the
same time. A conversion into a generic code can happen, but it will require
several tests to be sure that they won't cause undesirable side-effects.

The advantage of hardware decoders is that you don't need to be polling the
IR serial port at a high rate, as you'll get directly the code. So, you'll
free the CPU to do something else.

> You're just going to have to start guessing devices in the remote until you
> find one that uses your fixed protocol and doesn't also activate the
> devices you own. We can put suggestions in the doc when working
> devices are discovered. With a universal receiver the problem is
> simpler, just pick a device you don't own - the encoding protocol
> doesn't matter. These are generic problems with IR that are the same
> no matter how things get implemented in Linux.

Yes, provided that we can successfully change the drivers to split decoders from
pulse/space counting.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Krzysztof Halasa]

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

> Btw, looking at that code, while it is not impossible to split the 
> IR pulse/space measures from the NEC decoder itself, and make it generic
> to support other protocols, it is not a trivial task, and may result on
> a less stable driver.

And it's not needed at all.
Protocol decoders can be easily run in parallel, I've done it on saa713x
and this is trivial at least there. Can do that when the lirc interface
is available.

> The advantage of the NEC decoding approach on saa7134 is that you know for
> sure how much time it is required to get the entire code. So, the code 
> can easily abort the reception of a bad code. The disadvantage is that 
> only one protocol can be decoded at the same time.

This isn't a hard thing to fix.

> The same problem also happens with almost all in-kernel drivers: the decoders
> for raw mode were constructed to work with just one pulse/space code at the
> same time. A conversion into a generic code can happen, but it will require
> several tests to be sure that they won't cause undesirable side-effects.

IOW any such receiver has to be tested, sure.

> The advantage of hardware decoders is that you don't need to be polling the
> IR serial port at a high rate, as you'll get directly the code. So, you'll
> free the CPU to do something else.

Which device requires polling the port?
Most are IRQ-driven, aren't they?
-- 
Krzysztof Halasa

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> Btw, looking at that code, while it is not impossible to split the 
>> IR pulse/space measures from the NEC decoder itself, and make it generic
>> to support other protocols, it is not a trivial task, and may result on
>> a less stable driver.
> 
> And it's not needed at all.
> Protocol decoders can be easily run in parallel, I've done it on saa713x
> and this is trivial at least there. Can do that when the lirc interface
> is available.

>> The advantage of the NEC decoding approach on saa7134 is that you know for
>> sure how much time it is required to get the entire code. So, the code 
>> can easily abort the reception of a bad code. The disadvantage is that 
>> only one protocol can be decoded at the same time.
> 
> This isn't a hard thing to fix.

Good to know. We're open to patches to improve it. 

The point is that we've got in the past several complains about saa713x
machines hanging due to IRQ's generated by IR sensor port. We ended by adding
an option to disable IR and a code at the driver that disables IR IRQ if it 
happens too often.

> 
>> The same problem also happens with almost all in-kernel drivers: the decoders
>> for raw mode were constructed to work with just one pulse/space code at the
>> same time. A conversion into a generic code can happen, but it will require
>> several tests to be sure that they won't cause undesirable side-effects.
> 
> IOW any such receiver has to be tested, sure.
> 
>> The advantage of hardware decoders is that you don't need to be polling the
>> IR serial port at a high rate, as you'll get directly the code. So, you'll
>> free the CPU to do something else.
> 
> Which device requires polling the port?
> Most are IRQ-driven, aren't they?

Most of the devices that have a hardware IR decodes needs polling. Most of they
simply outputs the scan code on some set of GPIO pins.

In general, the devices with the IR sensor connected to a GPIO pin are IRQ-driven.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Trent Piepho]

On Wed, 2 Dec 2009, Jon Smirl wrote:
> > A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples.
>
> Actually remotes do have an ID. They all transmit vendor/device pairs
> which is exactly how USB works.

*All* remotes?  That's a bold statement.  I'm sure there are some that
only transmit 8 bits of so of scancode.  I think remotes are more like
hosts on a network than usb or bluetooth devices.  Remotes do not join or
leave a receiver, while things like usb devices do explictly join and leave
the hub.

> >> Now I understand that if 2 remotes send completely identical signals we
> >> won't be able to separate them, but in cases when we can I think we
> >> should.
> >
> > I don't have a problem with that, if its a truly desired feature.  But
> > for the most part, I don't see the point.  Generally, you go from
> > having multiple remotes, one per device (where "device" is your TV,
> > amplifier, set top box, htpc, etc), to having a single universal remote
> > that controls all of those devices.  But for each device (IR receiver),
> > *one* IR command set.  The desire to use multiple distinct remotes with
> > a single IR receiver doesn't make sense to me.  Perhaps I'm just not
> > creative enough in my use of IR.  :)

Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
my tv remote generates one set of scancodes for the numeric keys.  The DVD
remote generates a different set.  The amplifier remote in "tv mode"
generates the same codes as the tv remote, and in "dvd mode" the same codes
as the dvd remote.  From the perspective of the IR receiver there is no
difference between having both the DVD and TV remotes, or using the
aplifier remote to control both devices.

Now, my aplifier remote has a number of modes.  Some control devices I
have, like "vcr mode", and there is nothing I can do about that.  Some,
like "md mode" don't control devices I have.  That means they are free to
do things on the computer.  Someone else with the same remote (or any
number of remotes that use the same protocol and scancodes) might have
different devices.

So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore
"JVC VCR #yyy" yets.  Someone with an MD player and not a VCR would want to
opposite.  Rather than force everyone to create custom keymaps, it's much
easier if we can use the standard keymaps from a database of common remotes
and simply tell mythtv to only use remote #xxx or not to use remote #yyy.

It sounds like you're thinking of a receiver that came bundled with a
remote and that's it.  Not someone with a number of remotes that came with
different pieces of AV gear that they want to use with their computer.

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
...
>>>> Now I understand that if 2 remotes send completely identical signals we
>>>> won't be able to separate them, but in cases when we can I think we
>>>> should.
>>> 
>>> I don't have a problem with that, if its a truly desired feature.  But
>>> for the most part, I don't see the point.  Generally, you go from
>>> having multiple remotes, one per device (where "device" is your TV,
>>> amplifier, set top box, htpc, etc), to having a single universal remote
>>> that controls all of those devices.  But for each device (IR receiver),
>>> *one* IR command set.  The desire to use multiple distinct remotes with
>>> a single IR receiver doesn't make sense to me.  Perhaps I'm just not
>>> creative enough in my use of IR.  :)
> 
> Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
> my tv remote generates one set of scancodes for the numeric keys.  The DVD
> remote generates a different set.  The amplifier remote in "tv mode"
> generates the same codes as the tv remote, and in "dvd mode" the same codes
> as the dvd remote.  From the perspective of the IR receiver there is no
> difference between having both the DVD and TV remotes, or using the
> aplifier remote to control both devices.

Okay, in the above scenario, you've still got a single input device...

> Now, my aplifier remote has a number of modes.  Some control devices I
> have, like "vcr mode", and there is nothing I can do about that.  Some,
> like "md mode" don't control devices I have.  That means they are free to
> do things on the computer.  Someone else with the same remote (or any
> number of remotes that use the same protocol and scancodes) might have
> different devices.
> 
> So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore
> "JVC VCR #yyy" yets.  Someone with an MD player and not a VCR would want to
> opposite.  Rather than force everyone to create custom keymaps, it's much
> easier if we can use the standard keymaps from a database of common remotes
> and simply tell mythtv to only use remote #xxx or not to use remote #yyy.

Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per "remote" though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...).

> It sounds like you're thinking of a receiver that came bundled with a
> remote and that's it.  Not someone with a number of remotes that came with
> different pieces of AV gear that they want to use with their computer.

No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one.

Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
> ...
>>>>> Now I understand that if 2 remotes send completely identical signals we
>>>>> won't be able to separate them, but in cases when we can I think we
>>>>> should.
>>>>
>>>> I don't have a problem with that, if its a truly desired feature.  But
>>>> for the most part, I don't see the point.  Generally, you go from
>>>> having multiple remotes, one per device (where "device" is your TV,
>>>> amplifier, set top box, htpc, etc), to having a single universal remote
>>>> that controls all of those devices.  But for each device (IR receiver),
>>>> *one* IR command set.  The desire to use multiple distinct remotes with
>>>> a single IR receiver doesn't make sense to me.  Perhaps I'm just not
>>>> creative enough in my use of IR.  :)
>>
>> Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
>> my tv remote generates one set of scancodes for the numeric keys.  The DVD
>> remote generates a different set.  The amplifier remote in "tv mode"
>> generates the same codes as the tv remote, and in "dvd mode" the same codes
>> as the dvd remote.  From the perspective of the IR receiver there is no
>> difference between having both the DVD and TV remotes, or using the
>> aplifier remote to control both devices.
>
> Okay, in the above scenario, you've still got a single input device...
>
>> Now, my aplifier remote has a number of modes.  Some control devices I
>> have, like "vcr mode", and there is nothing I can do about that.  Some,
>> like "md mode" don't control devices I have.  That means they are free to
>> do things on the computer.  Someone else with the same remote (or any
>> number of remotes that use the same protocol and scancodes) might have
>> different devices.
>>
>> So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore
>> "JVC VCR #yyy" yets.  Someone with an MD player and not a VCR would want to
>> opposite.  Rather than force everyone to create custom keymaps, it's much
>> easier if we can use the standard keymaps from a database of common remotes
>> and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
>
> Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per "remote" though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...).
>
>> It sounds like you're thinking of a receiver that came bundled with a
>> remote and that's it.  Not someone with a number of remotes that came with
>> different pieces of AV gear that they want to use with their computer.
>
> No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one.
>
> Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it.

Simple use case:

You have a multifunction remote. Press the CABLE key - it sends out
commands that control the cable box, press the TV key - now the
commands control the TV, press CD - now the CD player, etc.

Now imagine a headless Linux box running a music server and a home
automation app. Press the CD key - commands get routed to the music
server, press the AUX key - commands get routed to the home automation
app.

This is accomplished by recognizing the device code part of the IR
signal and figuring out that there are two different device codes in
use. The commands of then routed to two evdev devices corresponding to
the two different device codes.

Using things like Alt-Tab to switch apps is impossible. There's no
screen to look at.

>
> --
> Jarod Wilson
> jarod@wilsonet.com
>
>
>
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
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

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
>> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
>> ...
>>>>>> Now I understand that if 2 remotes send completely identical signals we
>>>>>> won't be able to separate them, but in cases when we can I think we
>>>>>> should.
>>>>> I don't have a problem with that, if its a truly desired feature.  But
>>>>> for the most part, I don't see the point.  Generally, you go from
>>>>> having multiple remotes, one per device (where "device" is your TV,
>>>>> amplifier, set top box, htpc, etc), to having a single universal remote
>>>>> that controls all of those devices.  But for each device (IR receiver),
>>>>> *one* IR command set.  The desire to use multiple distinct remotes with
>>>>> a single IR receiver doesn't make sense to me.  Perhaps I'm just not
>>>>> creative enough in my use of IR.  :)
>>> Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
>>> my tv remote generates one set of scancodes for the numeric keys.  The DVD
>>> remote generates a different set.  The amplifier remote in "tv mode"
>>> generates the same codes as the tv remote, and in "dvd mode" the same codes
>>> as the dvd remote.  From the perspective of the IR receiver there is no
>>> difference between having both the DVD and TV remotes, or using the
>>> aplifier remote to control both devices.
>> Okay, in the above scenario, you've still got a single input device...
>>
>>> Now, my aplifier remote has a number of modes.  Some control devices I
>>> have, like "vcr mode", and there is nothing I can do about that.  Some,
>>> like "md mode" don't control devices I have.  That means they are free to
>>> do things on the computer.  Someone else with the same remote (or any
>>> number of remotes that use the same protocol and scancodes) might have
>>> different devices.
>>>
>>> So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore
>>> "JVC VCR #yyy" yets.  Someone with an MD player and not a VCR would want to
>>> opposite.  Rather than force everyone to create custom keymaps, it's much
>>> easier if we can use the standard keymaps from a database of common remotes
>>> and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
>> Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per "remote" though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...).
>>
>>> It sounds like you're thinking of a receiver that came bundled with a
>>> remote and that's it.  Not someone with a number of remotes that came with
>>> different pieces of AV gear that they want to use with their computer.
>> No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one.
>>
>> Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it.
> 
> Simple use case:
> 
> You have a multifunction remote. Press the CABLE key - it sends out
> commands that control the cable box, press the TV key - now the
> commands control the TV, press CD - now the CD player, etc.
> 
> Now imagine a headless Linux box running a music server and a home
> automation app. Press the CD key - commands get routed to the music
> server, press the AUX key - commands get routed to the home automation
> app.
> 
> This is accomplished by recognizing the device code part of the IR
> signal and figuring out that there are two different device codes in
> use. The commands of then routed to two evdev devices corresponding to
> the two different device codes.
> 
> Using things like Alt-Tab to switch apps is impossible. There's no
> screen to look at.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups. 

Also, as you're thinking on 64 bits scancodes, this also means that the
current evdev KABI and API will require changes to support bigger scancodes.

Anyway, IMO, this subject should be handled as a different requirement than
integrating the lirc drivers.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[alhaz]

Quoting Jon Smirl <jonsmirl@gmail.com>:

>>> Now I understand that if 2 remotes send completely identical signals we
>>> won't be able to separate them, but in cases when we can I think we
>>> should.
>>
>> I don't have a problem with that, if its a truly desired feature.   
>> But for the most part, I don't see the point. Generally, you go   
>> from having multiple remotes, one per device (where "device" is   
>> your TV, amplifier, set top box, htpc, etc), to having a single   
>> universal remote that controls all of those devices. But for each   
>> device (IR receiver), *one* IR command set. The desire to use   
>> multiple distinct remotes with a single IR receiver doesn't make   
>> sense to me. Perhaps I'm just not creative enough in my use of IR. :)

 From a hobbiest's perspective there's likely rarely any reason to be  
able to do the same thing with two different remotes that send  
different signals, but i could see it come up - For example if you  
wanted to have both a feature-rich,  busy/complicated remote but also  
wanted to provide a simpler remote with a relatively small number of  
large buttons on it for basic functions, as for children or people  
with poor eyesight or poor motor control.

 From a business perspective, I've worked for a company that sold  
turn-key video training systems, and depending on the whims of our  
so-called business partners and the desires of customers, there were  
as many as three distinct remotes that might get shipped with the  
training system, and they all sent different signals.

That was a less than ideal situation, and if we had been really on top  
of things we'd have just declined to use any of those remotes and  
bought custom remotes from any of the numerous vendors that sell them  
which would allow us to have one set of IR signals used by remotes  
with different features - but for whatever reason that wasn't how  
management decided to do things.

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
>> The raw interface applies only to the devices that doesn't have a hardware decoder
>> (something between 40%-60% of the currently supported devices).
> 
> 50% is quite a number I think. But if driver does not allow access to
> the raw stream - it will refuse binding to lirc_dev interface.

Ok.

> We need to cater to the future cases as well. I don't want to redesign
> it in 2 years. But for devices that have only hardware decoders I
> suppose we can short-curcuit "interfaces" and have a library-like module
> creating input devices directly.

We really need only one interface for those devices. However, protocol selection
is needed, as it is associated with the scantable on those devices.
a sysfs entry would solve this issue.

Also, we need a better schema to cleanup the keycode table. Currently, the only way 
I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or
to KEY_RESERVED.

>> In the case of the cheap devices with just raw interfaces, running in-kernel
>> decoders, while it will work if you create one interface per protocol
>> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
>> just create additional complexity at the kernelspace and at the userspace, since
>> now userspace programs will need to open more than one device to receive the
>> keycodes.
> 
> _Yes_!!! You open as many event devices as there are devices you are
> interested in receiving data from. Multiplexing devices are bad, bad,
> bad. Witness /dev/input/mouse and all the attempts at working around the
> fact that if you have a special driver for one of your devices you
> receive events from the same device through 2 interfaces and all kind of
> "grab", "super-grab", "smart-grab" schemes are born.

The only device that the driver can actually see is the IR receiver. There's no way to
know if there is only one physical IR sending signals to it or several different models,
especially if we consider that programmable IR's can be able even to generate more than one
protocol at the same time, and can emulate other IR types.

You might create some artificial schema to try to deal with different IR's being received
at the same IR receiver, but, IMHO, this will just add a complex abstraction layer.

Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you
can handle it differently.

>>> (for each remote/substream that they can recognize).
>> I'm assuming that, by remote, you're referring to a remote receiver (and not to 
>> the remote itself), right?
> 
> If we could separate by remote transmitter that would be the best I
> think, but I understand that it is rarely possible?

IMHO, the better is to use a separate interface for the IR transmitters,
on the devices that support this feature. There are only a few devices
I'm aware of that are able to transmit IR codes.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Dmitry Torokhov wrote:
>>> The raw interface applies only to the devices that doesn't have a hardware decoder
>>> (something between 40%-60% of the currently supported devices).
>>
>> 50% is quite a number I think. But if driver does not allow access to
>> the raw stream - it will refuse binding to lirc_dev interface.
>
> Ok.
>
>> We need to cater to the future cases as well. I don't want to redesign
>> it in 2 years. But for devices that have only hardware decoders I
>> suppose we can short-curcuit "interfaces" and have a library-like module
>> creating input devices directly.
>
> We really need only one interface for those devices. However, protocol selection
> is needed, as it is associated with the scantable on those devices.
> a sysfs entry would solve this issue.
>
> Also, we need a better schema to cleanup the keycode table. Currently, the only way
> I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or
> to KEY_RESERVED.
>
>>> In the case of the cheap devices with just raw interfaces, running in-kernel
>>> decoders, while it will work if you create one interface per protocol
>>> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
>>> just create additional complexity at the kernelspace and at the userspace, since
>>> now userspace programs will need to open more than one device to receive the
>>> keycodes.
>>
>> _Yes_!!! You open as many event devices as there are devices you are
>> interested in receiving data from. Multiplexing devices are bad, bad,
>> bad. Witness /dev/input/mouse and all the attempts at working around the
>> fact that if you have a special driver for one of your devices you
>> receive events from the same device through 2 interfaces and all kind of
>> "grab", "super-grab", "smart-grab" schemes are born.
>
> The only device that the driver can actually see is the IR receiver. There's no way to
> know if there is only one physical IR sending signals to it or several different models,
> especially if we consider that programmable IR's can be able even to generate more than one
> protocol at the same time, and can emulate other IR types.

IR devices transmit vendor/device/command triplets. They are easy to
tell apart and create an evdev device corresponding to each
vendor/device pair or something else along those lines.

If I tell a programmable remote to send out the same commands as my
Sony remote that's the same thing as owning two identical Sony
remotes. I'd expect them to be indistinguishable. If you want to be
able to tell your remotes apart, don't program them to emulate each
other.

I've published code that can split these devices apart, it's not
impossible to do.

802.11 receivers have the same problem, there is one receiver and many
transmitters. The networking code doesn't have problems with sorting
this out and separating the streams.

> You might create some artificial schema to try to deal with different IR's being received
> at the same IR receiver, but, IMHO, this will just add a complex abstraction layer.
>
> Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you
> can handle it differently.

Reusing the keycode is fine if they on different evdev devices. A key
feature is creating one evdev device for each remote.

>
>>>> (for each remote/substream that they can recognize).
>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>> the remote itself), right?
>>
>> If we could separate by remote transmitter that would be the best I
>> think, but I understand that it is rarely possible?
>
> IMHO, the better is to use a separate interface for the IR transmitters,
> on the devices that support this feature. There are only a few devices
> I'm aware of that are able to transmit IR codes.
>
> Cheers,
> Mauro.
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Dmitry Torokhov wrote:
>>>> The raw interface applies only to the devices that doesn't have a hardware decoder
>>>> (something between 40%-60% of the currently supported devices).
>>>
>>> 50% is quite a number I think. But if driver does not allow access to
>>> the raw stream - it will refuse binding to lirc_dev interface.
>>
>> Ok.
>>
>>> We need to cater to the future cases as well. I don't want to redesign
>>> it in 2 years. But for devices that have only hardware decoders I
>>> suppose we can short-curcuit "interfaces" and have a library-like module
>>> creating input devices directly.
>>
>> We really need only one interface for those devices. However, protocol selection
>> is needed, as it is associated with the scantable on those devices.
>> a sysfs entry would solve this issue.
>>
>> Also, we need a better schema to cleanup the keycode table. Currently, the only way
>> I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or
>> to KEY_RESERVED.
>>
>>>> In the case of the cheap devices with just raw interfaces, running in-kernel
>>>> decoders, while it will work if you create one interface per protocol
>>>> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
>>>> just create additional complexity at the kernelspace and at the userspace, since
>>>> now userspace programs will need to open more than one device to receive the
>>>> keycodes.
>>>
>>> _Yes_!!! You open as many event devices as there are devices you are
>>> interested in receiving data from. Multiplexing devices are bad, bad,
>>> bad. Witness /dev/input/mouse and all the attempts at working around the
>>> fact that if you have a special driver for one of your devices you
>>> receive events from the same device through 2 interfaces and all kind of
>>> "grab", "super-grab", "smart-grab" schemes are born.
>>
>> The only device that the driver can actually see is the IR receiver. There's no way to
>> know if there is only one physical IR sending signals to it or several different models,
>> especially if we consider that programmable IR's can be able even to generate more than one
>> protocol at the same time, and can emulate other IR types.
>
> IR devices transmit vendor/device/command triplets. They are easy to
> tell apart and create an evdev device corresponding to each
> vendor/device pair or something else along those lines.

I forgot about fixed function receivers - ones that only receive codes
from a specific vendor/device pair and decode them in hardware. Those
devices would just create a fixed entry in the configfs which would
then allow a keycode mapping to be loaded. Or a parallel scheme for
setkeys IOCTL. These device can only receive from a single remote.

>
> If I tell a programmable remote to send out the same commands as my
> Sony remote that's the same thing as owning two identical Sony
> remotes. I'd expect them to be indistinguishable. If you want to be
> able to tell your remotes apart, don't program them to emulate each
> other.
>
> I've published code that can split these devices apart, it's not
> impossible to do.
>
> 802.11 receivers have the same problem, there is one receiver and many
> transmitters. The networking code doesn't have problems with sorting
> this out and separating the streams.
>
>> You might create some artificial schema to try to deal with different IR's being received
>> at the same IR receiver, but, IMHO, this will just add a complex abstraction layer.
>>
>> Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you
>> can handle it differently.
>
> Reusing the keycode is fine if they on different evdev devices. A key
> feature is creating one evdev device for each remote.
>
>>
>>>>> (for each remote/substream that they can recognize).
>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
>>>> the remote itself), right?
>>>
>>> If we could separate by remote transmitter that would be the best I
>>> think, but I understand that it is rarely possible?
>>
>> IMHO, the better is to use a separate interface for the IR transmitters,
>> on the devices that support this feature. There are only a few devices
>> I'm aware of that are able to transmit IR codes.
>>
>> Cheers,
>> Mauro.
>>
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Jon Smirl wrote:

> IR devices transmit vendor/device/command triplets. They are easy to
> tell apart and create an evdev device corresponding to each
> vendor/device pair or something else along those lines.

What they transmit depend on the used protocol. With NEC and RC5 (currently, the
most common protocols), they transmit only address (TV, VCR, SAT) and command.

If you have two IR's that not fully follow RC5 standard, they may use distinct
addresses. So, if you're lucky enough, you'll be able to guess the IR vendor,
based on the 8 bit address code.

I think that you can get the vendor only with RC6 IR's on some modes. 
In the case of RC6, as pointed by Andy, there are some patents envolved, 
meaning that we probably will need to decode it on userspace, except if 
someone can get the proper patent rights for its used on Linux.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

> Dmitry Torokhov wrote:
>> 
...
>>>> (for each remote/substream that they can recognize).
>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to 
>>> the remote itself), right?
>> 
>> If we could separate by remote transmitter that would be the best I
>> think, but I understand that it is rarely possible?
> 
> IMHO, the better is to use a separate interface for the IR transmitters,
> on the devices that support this feature. There are only a few devices
> I'm aware of that are able to transmit IR codes.

If I'm thinking clearly, there are only three lirc kernel drivers that support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb driver was posted, so I won't rehash what it is here. The zilog driver binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c, found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR, etc). The serial driver is fairly self-explanatory as well.

There are also a few userspace-driven devices that do transmit, but I'm assuming they're (currently) irrelevant to this discussion.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [RFC v2] Another approach to IR

[Andy Walls]

On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
> 
> > Dmitry Torokhov wrote:
> >> 
> ...
> >>>> (for each remote/substream that they can recognize).
> >>> I'm assuming that, by remote, you're referring to a remote receiver (and not to 
> >>> the remote itself), right?
> >> 
> >> If we could separate by remote transmitter that would be the best I
> >> think, but I understand that it is rarely possible?
> > 
> > IMHO, the better is to use a separate interface for the IR transmitters,
> > on the devices that support this feature. There are only a few devices
> > I'm aware of that are able to transmit IR codes.
> 
> If I'm thinking clearly, there are only three lirc kernel drivers that
> support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
> driver was posted, so I won't rehash what it is here. The zilog driver
> binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
> found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
> etc). The serial driver is fairly self-explanatory as well.
> 
> There are also a few userspace-driven devices that do transmit, but
> I'm assuming they're (currently) irrelevant to this discussion.


I've got the CX23888 integrated IR Rx done and Tx nearly done.  I was
waiting to see how kfifo and lirc_dev panned out before making the
interface to userspace.

The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
I hope to have CX23885 IR done by Christmas.

Both of those IR devices are/will be encapsulated in a v4l2_subdevice
object internally.  I was going to write lirc_v4l glue between the
v4l2_device/v4l2_subdev_ir_ops and lirc_dev.

As for the the I2C chips, I was going to go back and encapsulate those
in the v4l2_subdevice object as well, so then my notional lirc_v4l could
pick those up too.  The I2C subsystem only allows one binding to an I2C
client address/name on a bus.  So without some new glue like a notional
lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
lirc_zilog.

Regards,
Andy

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Andy Walls wrote:
> On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
>>
>>> Dmitry Torokhov wrote:
>> ...
>>>>>> (for each remote/substream that they can recognize).
>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to 
>>>>> the remote itself), right?
>>>> If we could separate by remote transmitter that would be the best I
>>>> think, but I understand that it is rarely possible?
>>> IMHO, the better is to use a separate interface for the IR transmitters,
>>> on the devices that support this feature. There are only a few devices
>>> I'm aware of that are able to transmit IR codes.
>> If I'm thinking clearly, there are only three lirc kernel drivers that
>> support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
>> driver was posted, so I won't rehash what it is here. The zilog driver
>> binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
>> found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
>> etc). The serial driver is fairly self-explanatory as well.
>>
>> There are also a few userspace-driven devices that do transmit, but
>> I'm assuming they're (currently) irrelevant to this discussion.
> 
> 
> I've got the CX23888 integrated IR Rx done and Tx nearly done.  I was
> waiting to see how kfifo and lirc_dev panned out before making the
> interface to userspace.
> 
> The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
> I hope to have CX23885 IR done by Christmas.
> 
> Both of those IR devices are/will be encapsulated in a v4l2_subdevice
> object internally.  I was going to write lirc_v4l glue between the
> v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
> 
> As for the the I2C chips, I was going to go back and encapsulate those
> in the v4l2_subdevice object as well, so then my notional lirc_v4l could
> pick those up too.  The I2C subsystem only allows one binding to an I2C
> client address/name on a bus.  So without some new glue like a notional
> lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
> lirc_zilog.

Maybe you're having a bad time because you may be trying to integrate lirc
at the wrong place.

All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
(at /drivers/media/common tree) module to communicate to IR's. 
I'm preparing some patches to extend this also to dvb-usb devices 
(that uses a close enough infrastructure). 

Also, most of the decoding code are there, in a form of helper routines.

As the idea is to provide lirc interface to all devices that can work with
raw pulse/space, the proper place is to write a subroutine there that, once
called, will make those pulse/space raw codes available to lirc and will
call the needed decoders to export them also to evdev.

The code at ir-common module was originally built to be used by V4L, but I'm
porting the code there to be generic enough to be a library that can be used
by other drivers. So, lirc_zilog and other lirc devices that will need to open
evdev interfaces after running a decoder can use them.

Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
be implemented as a separate module.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Andy Walls]

On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
> >> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 
> > Both of those IR devices are/will be encapsulated in a v4l2_subdevice
> > object internally.  I was going to write lirc_v4l glue between the
> > v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
> > 
> > As for the the I2C chips, I was going to go back and encapsulate those
> > in the v4l2_subdevice object as well, so then my notional lirc_v4l could
> > pick those up too.  The I2C subsystem only allows one binding to an I2C
> > client address/name on a bus.  So without some new glue like a notional
> > lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
> > lirc_zilog.
> 
> Maybe you're having a bad time because you may be trying to integrate lirc
> at the wrong place.

These were just ideas.  I haven't done *anything* yet. ;)


> All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
> (at /drivers/media/common tree) module to communicate to IR's. 
> I'm preparing some patches to extend this also to dvb-usb devices 
> (that uses a close enough infrastructure). 
> 
> Also, most of the decoding code are there, in a form of helper routines.
> 
> As the idea is to provide lirc interface to all devices that can work with
> raw pulse/space, the proper place is to write a subroutine there that, once
> called, will make those pulse/space raw codes available to lirc and will
> call the needed decoders to export them also to evdev.
> 
> The code at ir-common module was originally built to be used by V4L, but I'm
> porting the code there to be generic enough to be a library that can be used
> by other drivers. So, lirc_zilog and other lirc devices that will need to open
> evdev interfaces after running a decoder can use them.

I think I see what you are saying (I wish could see look at a whiteboard
somewhere...).  Wherever we come through internally to split to 2
different userspace interfaces is fine, if you've got a big picture plan
you think is feasible.

That seems like a bit of perturbation to lirc_zilog and lirc_i2c.  My
thought was that lirc_v4l using the standardized v4l2_subdev_ir_ops
interface, and maybe some new calls associted with v4l2_device, could
subsume/unify all the functionality of lirc_i2c, lirc_zilog, ...
lirc_whatever.

Maybe that's just a poorly thought out dream though...


> Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
> a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
> be implemented as a separate module.

The v4l_subdevice just abstracted the IR hardware into a nice (mental)
box for me -- easier to keep hardware separate from software decoders
and userspace interface logic.

Also, since v4l2_subdevices may have per subdevice /dev nodes and
the /dev/../mcN nodes providing a discovery mechanism due to the Meda
Controller framework, wrapping things in v4l2_subdevice may be handy for
development and debug.  Or ... as an additional operational interface to
userspace. :D  *ducks and runs for cover*

Regards,
Andy

> Cheers,
> Mauro.

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Andy Walls wrote:
> On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
>> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:
>>
>>> Dmitry Torokhov wrote:
>> ...
>>>>>> (for each remote/substream that they can recognize).
>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to 
>>>>> the remote itself), right?
>>>> If we could separate by remote transmitter that would be the best I
>>>> think, but I understand that it is rarely possible?
>>> IMHO, the better is to use a separate interface for the IR transmitters,
>>> on the devices that support this feature. There are only a few devices
>>> I'm aware of that are able to transmit IR codes.
>> If I'm thinking clearly, there are only three lirc kernel drivers that
>> support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
>> driver was posted, so I won't rehash what it is here. The zilog driver
>> binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
>> found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
>> etc). The serial driver is fairly self-explanatory as well.
>>
>> There are also a few userspace-driven devices that do transmit, but
>> I'm assuming they're (currently) irrelevant to this discussion.
> 
> 
> I've got the CX23888 integrated IR Rx done and Tx nearly done.  I was
> waiting to see how kfifo and lirc_dev panned out before making the
> interface to userspace.
> 
> The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
> I hope to have CX23885 IR done by Christmas.
> 
> Both of those IR devices are/will be encapsulated in a v4l2_subdevice
> object internally.  I was going to write lirc_v4l glue between the
> v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
> 
> As for the the I2C chips, I was going to go back and encapsulate those
> in the v4l2_subdevice object as well, so then my notional lirc_v4l could
> pick those up too.  The I2C subsystem only allows one binding to an I2C
> client address/name on a bus.  So without some new glue like a notional
> lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
> lirc_zilog.

The better is to add the lirc glue at ir-common module. There, we have the support
functions used by all V4L devices, and they'll be expanded to cover also
dvb-usb, as soon as I can find some time to do a patch for it.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 05:33:34PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> >> The raw interface applies only to the devices that doesn't have a hardware decoder
> >> (something between 40%-60% of the currently supported devices).
> > 
> > 50% is quite a number I think. But if driver does not allow access to
> > the raw stream - it will refuse binding to lirc_dev interface.
> 
> Ok.
> 
> > We need to cater to the future cases as well. I don't want to redesign
> > it in 2 years. But for devices that have only hardware decoders I
> > suppose we can short-curcuit "interfaces" and have a library-like module
> > creating input devices directly.
> 
> We really need only one interface for those devices. However, protocol selection
> is needed, as it is associated with the scantable on those devices.
> a sysfs entry would solve this issue.
> 
> Also, we need a better schema to cleanup the keycode table. Currently, the only way 
> I'm aware is to run a loop from 0 to 65535 associating a scancode to KEY_UNKNOWN or
> to KEY_RESERVED.

I guess we could entertain EVIOCSKMAPFLUSH or something...

> 
> >> In the case of the cheap devices with just raw interfaces, running in-kernel
> >> decoders, while it will work if you create one interface per protocol
> >> per IR receiver, this also seems overkill. Why to do that? It sounds that it will
> >> just create additional complexity at the kernelspace and at the userspace, since
> >> now userspace programs will need to open more than one device to receive the
> >> keycodes.
> > 
> > _Yes_!!! You open as many event devices as there are devices you are
> > interested in receiving data from. Multiplexing devices are bad, bad,
> > bad. Witness /dev/input/mouse and all the attempts at working around the
> > fact that if you have a special driver for one of your devices you
> > receive events from the same device through 2 interfaces and all kind of
> > "grab", "super-grab", "smart-grab" schemes are born.
> 
> The only device that the driver can actually see is the IR receiver. There's no way to
> know if there is only one physical IR sending signals to it or several different models,
> especially if we consider that programmable IR's can be able even to generate more than one
> protocol at the same time, and can emulate other IR types.
> 
> You might create some artificial schema to try to deal with different IR's being received
> at the same IR receiver, but, IMHO, this will just add a complex abstraction layer.
> 
> Also, this won't give any real gain, as either both IR's will generate the same scancodes (and you can't distinguish what IR generated that code), or the scancode is different, and you
> can handle it differently.

No it will. User will have _an option_ of assigning a particular remote
to a particular application. Whether he or she will chose to entertain
this option is up to that user.

> 
> >>> (for each remote/substream that they can recognize).
> >> I'm assuming that, by remote, you're referring to a remote receiver (and not to 
> >> the remote itself), right?
> > 
> > If we could separate by remote transmitter that would be the best I
> > think, but I understand that it is rarely possible?
> 
> IMHO, the better is to use a separate interface for the IR transmitters,
> on the devices that support this feature. There are only a few devices
> I'm aware of that are able to transmit IR codes.

-ENOOPINION at the moment.

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>> > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
>> >> Dmitry Torokhov wrote:
>> >>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
>> >>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
>> >>>> to change the protocol in runtime.
>> >>>>
>> >>> Mauro,
>> >>>
>> >>> I think this kind of confuguration belongs to lirc device space,
>> >>> not input/evdev. This is the same as protocol selection for psmouse
>> >>> module: while it is normally auto-detected we have sysfs attribute to
>> >>> force one or another and it is tied to serio device, not input
>> >>> device.
>> >> Dmitry,
>> >>
>> >> This has nothing to do with the raw interface nor with lirc. This problem
>> >> happens with the evdev interface and already affects the in-kernel drivers.
>> >>
>> >> In this case, psmouse is not a good example. With a mouse, when a movement
>> >> occurs, you'll receive some data from its port. So, a software can autodetect
>> >> the protocol. The same principle can be used also with a raw pulse/space
>> >> interface, where software can autodetect the protocol.
>> >
>> > Or, in certain cases, it can not.
>> >
>> > [... skipped rationale for adding a way to control protocol (with which
>> > I agree) ...]
>> >
>> >> To solve this, we really need to extend evdev API to do 3 things: enumberate the
>> >> supported protocols, get the current protocol(s), and select the protocol(s) that
>> >> will be used by a newer table.
>> >>
>> >
>> > And here we start disagreeing. My preference would be for adding this
>> > API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
>> > since it only applicable to IR, not to input devices in general.
>> >
>> > Once you selected proper protocol(s) and maybe instantiated several
>> > input devices then udev (by examining input device capabilities and
>> > optionally looking up at the parent device properties) would use
>> > input evdev API to load proper keymap. Because translation of
>> > driver-specific codes into standard key definitions is in the input
>> > realm. Reading these driver-specific codes from hardware is outside of
>> > input layer domain.
>> >
>> > Just as psmouse ability to specify protocol is not shoved into evdev;
>> > just as atkbd quirks (force release key list and other driver-specific
>> > options) are not in evdev either; we should not overload evdev interface
>> > with IR-specific items.
>>
>> I'm not against mapping those features as sysfs atributes, but they don't belong
>> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
>> interface to allow the direct usage of raw IO. However, IR protocol is a property
>> that is not related to raw IO mode but, instead, to evdev mode.
>>
>
> Why would protocol relate to evdev node? Evdev does not really care what
> how the fact that a certain button was pressed was communicated to it.
> It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
> or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
> some custom IR protocol. It makes no difference _whatsoever_ to evdev
> nor any users of evdev care about protocol used by underlying hardware
> device to transmit the data.
>
>> We might add a /sys/class/IR and add IR specific stuff there, but it seems
>> overkill to me and will hide the fact that those parameters are part of the evdev
>> interface.
>>
>> So, I would just add the IR sysfs parameters at the /sys/class/input, if
>> the device is an IR (or create it is /sys/class/input/IR).
>>
>> I agree that the code to implement the IR specific sysfs parameter should be kept
>> oustide input core, as they're specific to IR implementations.
>>
>> Would this work for you?
>
> I am seeing a little bit differently structured subsystem for IR at the
> moment. I think we should do something like this:
>
> - receivers create /sys/class/lirc devices. These devices provide API
>  with a ring buffer (fifo) for the raw data stream coming from (and to)
>  them.

The FIFO will have to appear as a /dev/device or be in debugfs. GregKH
sent earlier mail telling me to get the FIFO out of sysfs.

> - we allow registering several data interfaces/decoders that can be bound
>  (manually or maybe automatically) to lirc devices. lirc devices may
>  provide hints as to which interface(s) better suited for handling the
>  data coming form particular receiver. Several interfaces may be bound
>  to one device at a time.
> - one of the interfaces is interface implementing current lirc_dev
> - other interfaces may be in-kernel RC-5 decoder or other decoders.
>  decoders will create instances of input devices (for each
>  remote/substream that they can recognize).

This includes defining IR events for evdev with vendor/device/command triplets?
You need those standard events to make apps IR aware.

LIRC will also need to inject those events after decoding pulse data.

>
> This way there is clear layering, protocol selection is kept at lirc
> level.

Did you checkout capabilities bits in evdev?

>
> Would this work?
>
> --
> Dmitry
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
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

Re: [RFC v2] Another approach to IR

[Dmitry Torokhov]

On Wed, Dec 02, 2009 at 10:37:02AM -0500, Jon Smirl wrote:
> On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote:
> >> Dmitry Torokhov wrote:
> >> > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> >> >> Dmitry Torokhov wrote:
> >> >>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >> >>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver
> >> >>>> to change the protocol in runtime.
> >> >>>>
> >> >>> Mauro,
> >> >>>
> >> >>> I think this kind of confuguration belongs to lirc device space,
> >> >>> not input/evdev. This is the same as protocol selection for psmouse
> >> >>> module: while it is normally auto-detected we have sysfs attribute to
> >> >>> force one or another and it is tied to serio device, not input
> >> >>> device.
> >> >> Dmitry,
> >> >>
> >> >> This has nothing to do with the raw interface nor with lirc. This problem
> >> >> happens with the evdev interface and already affects the in-kernel drivers.
> >> >>
> >> >> In this case, psmouse is not a good example. With a mouse, when a movement
> >> >> occurs, you'll receive some data from its port. So, a software can autodetect
> >> >> the protocol. The same principle can be used also with a raw pulse/space
> >> >> interface, where software can autodetect the protocol.
> >> >
> >> > Or, in certain cases, it can not.
> >> >
> >> > [... skipped rationale for adding a way to control protocol (with which
> >> > I agree) ...]
> >> >
> >> >> To solve this, we really need to extend evdev API to do 3 things: enumberate the
> >> >> supported protocols, get the current protocol(s), and select the protocol(s) that
> >> >> will be used by a newer table.
> >> >>
> >> >
> >> > And here we start disagreeing. My preference would be for adding this
> >> > API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
> >> > since it only applicable to IR, not to input devices in general.
> >> >
> >> > Once you selected proper protocol(s) and maybe instantiated several
> >> > input devices then udev (by examining input device capabilities and
> >> > optionally looking up at the parent device properties) would use
> >> > input evdev API to load proper keymap. Because translation of
> >> > driver-specific codes into standard key definitions is in the input
> >> > realm. Reading these driver-specific codes from hardware is outside of
> >> > input layer domain.
> >> >
> >> > Just as psmouse ability to specify protocol is not shoved into evdev;
> >> > just as atkbd quirks (force release key list and other driver-specific
> >> > options) are not in evdev either; we should not overload evdev interface
> >> > with IR-specific items.
> >>
> >> I'm not against mapping those features as sysfs atributes, but they don't belong
> >> to lirc, as far as I understand. From all we've discussed, we'll create a lirc
> >> interface to allow the direct usage of raw IO. However, IR protocol is a property
> >> that is not related to raw IO mode but, instead, to evdev mode.
> >>
> >
> > Why would protocol relate to evdev node? Evdev does not really care what
> > how the fact that a certain button was pressed was communicated to it.
> > It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID,
> > or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or
> > some custom IR protocol. It makes no difference _whatsoever_ to evdev
> > nor any users of evdev care about protocol used by underlying hardware
> > device to transmit the data.
> >
> >> We might add a /sys/class/IR and add IR specific stuff there, but it seems
> >> overkill to me and will hide the fact that those parameters are part of the evdev
> >> interface.
> >>
> >> So, I would just add the IR sysfs parameters at the /sys/class/input, if
> >> the device is an IR (or create it is /sys/class/input/IR).
> >>
> >> I agree that the code to implement the IR specific sysfs parameter should be kept
> >> oustide input core, as they're specific to IR implementations.
> >>
> >> Would this work for you?
> >
> > I am seeing a little bit differently structured subsystem for IR at the
> > moment. I think we should do something like this:
> >
> > - receivers create /sys/class/lirc devices. These devices provide API
> >  with a ring buffer (fifo) for the raw data stream coming from (and to)
> >  them.
> 
> The FIFO will have to appear as a /dev/device or be in debugfs. GregKH
> sent earlier mail telling me to get the FIFO out of sysfs.
>

No, I expect it not to be directly exposed to userspace at all, just a
part of in-kernel subsystem API. This is the way interfaces/decoders
will communicate with drivers. lirc_dev interface will take data from
fifo and send to userspace.

> > - we allow registering several data interfaces/decoders that can be bound
> >  (manually or maybe automatically) to lirc devices. lirc devices may
> >  provide hints as to which interface(s) better suited for handling the
> >  data coming form particular receiver. Several interfaces may be bound
> >  to one device at a time.
> > - one of the interfaces is interface implementing current lirc_dev
> > - other interfaces may be in-kernel RC-5 decoder or other decoders.
> >  decoders will create instances of input devices (for each
> >  remote/substream that they can recognize).
> 
> This includes defining IR events for evdev with vendor/device/command triplets?

No, I believe that adding EV_IR type of events to evdev would be a
mistake.

> You need those standard events to make apps IR aware.
> 

But I do not want to make application IR-aware. If applications want to
be IR-aware they can work with lircd. I want applications react to
buttons/actions no matter which device issues those as long as the codes
are the same. IOW if you happen to have multimedia-type USB keyboard that
has button for play and you have a IR that has that button as well I'd
expect application to perform the same response (start playing).

> LIRC will also need to inject those events after decoding pulse data.
> 

LIRC will need to inject EV_KEY events.

> >
> > This way there is clear layering, protocol selection is kept at lirc
> > level.
> 
> Did you checkout capabilities bits in evdev?

Not sure if I understand the question.. Yes, I am aware that evdev
presents capabilities of the device userspace; no, I do not think that
they are applicable here (since there won't be EV_IR events).

-- 
Dmitry

Re: [RFC v2] Another approach to IR

[Gerd Hoffmann]

On 12/01/09 22:05, Mauro Carvalho Chehab wrote:
> So, I would just add the IR sysfs parameters at the /sys/class/input, if
> the device is an IR (or create it is /sys/class/input/IR).

No, you add it to the physical device node.

The usb mouse on the system I'm working on is here:

zweiblum kraxel $ ll /sys/class/input/ | grep usb2
lrwxrwxrwx. 1 root root 0 Dec  2 12:07 event7 -> 
../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/
lrwxrwxrwx. 1 root root 0 Dec  2 12:07 input7 -> 
../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/
lrwxrwxrwx. 1 root root 0 Dec  2 12:07 mouse2 -> 
../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/

So "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0" is the device 
node of the physical device, and the input devices belonging to it are 
in the "input" subdirectory.

If the mouse would be a usb IR receiver the IR attributes should go to 
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' 
subdirectory there.

HTH,
   Gerd

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Gerd Hoffmann wrote:
> On 12/01/09 22:05, Mauro Carvalho Chehab wrote:
>> So, I would just add the IR sysfs parameters at the /sys/class/input, if
>> the device is an IR (or create it is /sys/class/input/IR).
> 
> No, you add it to the physical device node.
> 
> The usb mouse on the system I'm working on is here:
> 
> zweiblum kraxel $ ll /sys/class/input/ | grep usb2
> lrwxrwxrwx. 1 root root 0 Dec  2 12:07 event7 ->
> ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/
> lrwxrwxrwx. 1 root root 0 Dec  2 12:07 input7 ->
> ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/
> lrwxrwxrwx. 1 root root 0 Dec  2 12:07 mouse2 ->
> ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/
> 
> So "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0" is the device
> node of the physical device, and the input devices belonging to it are
> in the "input" subdirectory.
> 
> If the mouse would be a usb IR receiver the IR attributes should go to
> /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir'
> subdirectory there.

This makes sense to me.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Patrick Boettcher]

Hi,
On Tue, 1 Dec 2009, Devin Heitmueller wrote:

> On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Just taking an example from the dibcom0700 driver (as the same driver
>> supports several different RC5 and NEC codes at the same time),
>> the kernel table has several keycodes added there, all working
>> at the same time. Providing that the scancodes won't overlap, you can
>> map two different scancodes (from different IR's) to return the same
>> keycode (table is not complete - I just got a few common keycodes):
>
> Mauro,
>
> Just to be clear, the dib0700 does not actually support receiving RC5
> or NEC codes at the same time.  You have to tell the chip which mode
> to operate in, via a REQUEST_SET_RC to the firmware (see
> dib0700_core.c:405).  The em28xx works the same way (you have to tell
> it what type of IR format to receive).
>
> The fact that the driver currently uses the same lookup table for both
> types of remote controls however, was perhaps not the best design
> choice.  It really should be separated out, and merged with the
> regular ir-functions.c.  I just never got around to it.

I did not follow all the discussion, still I have a comment:

I will soon work on a device where it is the driver who is doing the 
decoding of the IR-frames. It is (maybe, I'm still missing some pieces to 
be sure) possible to receive different protocols at the same time with 
this hardware.

--

Patrick 
http://www.kernellabs.com/

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Patrick Boettcher wrote:

>> The fact that the driver currently uses the same lookup table for both
>> types of remote controls however, was perhaps not the best design
>> choice.  It really should be separated out, and merged with the
>> regular ir-functions.c.  I just never got around to it.
> 
> I did not follow all the discussion, still I have a comment:
> 
> I will soon work on a device where it is the driver who is doing the
> decoding of the IR-frames. It is (maybe, I'm still missing some pieces
> to be sure) possible to receive different protocols at the same time
> with this hardware.

That's good news! Needing to pass a modprobe parameter to select the protocol
is not nice, and, while an ioctl will be needed to select IR protocols
(as there are some hardwares where this is not possible at all), the better
is to auto-detect the protocol.

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Jon Smirl]

On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Hi Jon,
> So, what we can do is to have a "default" keycode table mapping several
> different IR's there to be used by drivers that are shipped with an IR
> that can be fully mapped by the default table. However, for devices
> with scancodes that overlaps with the default table, we'll need a separate
> table.

The goal is to try and design a set of zero config defaults that can
work for 90% of users.

LIRC merges two different things, basic IR driver support and
application scripting for non-IR aware apps. Application scripting for
unaware apps is always going to happen in user space and it will
always need to be manually configured.  But scripting should be
optional.

I'm looking at the driver half and I'd like to explore how zero config
support can be built for IR aware apps. Of course we don't have any IR
aware apps today because no kernel IR event types have been defined
yet. It is better to simply make the apps IR aware and have them
process IR events from evdev (in other words forget about the configs
code it was a poor man's scripting scheme).

For mouse/keyboard support something parallel to USB HID is needed. A
couple of common device profiles would be mapped to keyboard/mouse
events by default. That should support 90% of users. The other 10% can
use a set keys IOCTL to change the mappings.

A couple of use cases:
  insert MSMCE IR device
  kernel automatically loads all drivers
  IR events appear in evdev as vendor/device/command triplets

  apt-get mythtv
  set universal remote to xmit DVR commands
  everything just works

  set universal remote to xmit device A commands
  device A commands mapped to keyboard/mouse movements
  everything just works

For these default cases you just have to read enough docs to know what
device to set your universal remote to.

The scenario I'd like to achieve
   install TV app
   install audio app
   install home automation app
   use multi-function remote to control in parallel with zero config
other than setting three devices into the remote.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab]

Maxim Levitsky wrote:
> On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: 
>> While reading all of these IR threads another way of handling IR
>> occurred to me that pretty much eliminates the need for LIRC and
>> configuration files in default cases. The best way to make everything
>> "just work" is to eliminate it.
>>
>> The first observation is that the IR profile of various devices are
>> well known. Most devices profiles are in the published One-for-All
>> database. These device profiles consist of vendor/device/command
>> triplets. There is one triplet for each command like play, pause, 1,
>> 2, 3, power, etc.
>>
>> The second observation is that universal remotes know how to generate
>> commands for all of the common devices.
>>
>> Let's define evdev messages for IR than contain vendor/device/command
>> triplets. I already posted code for doing that in my original patch
>> set. These messages are generated from in-kernel code.
>>
>> Now add a small amount of code to MythTV, etc to act on these evdev
>> messages. Default MythTV, etc to respond to the IR commands for a
>> common DVR device. Program your universal remote to send the commands
>> for this device. You're done. Everything will "just work" - no LIRC,
>> no irrecord, no config files, no command mapping, etc.
> You are making one  big wrong assumption that everyone that has a remote
> uses mythtv, and only it.
> 
> Many users including me, use the remote just like a keyboard, or even
> like a mouse.

+1. 

I also use the remote as a keyboard replacement. I used an IR like
that for a long time while teaching, using a standard USB video board,
as a way to remotely control my notebook.

Well, now I have an USB IR for this usage, using HID, that emulates
both keyboard and mouse. In fact, the application didn't change. 
I'm just using the standard USB class for HID, instead of using
vendor class to generate the same kind of evdev events ;)

Cheers,
Mauro.

Re: [RFC v2] Another approach to IR

[Guus Sliepen]

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

Hello,

Some years ago I wrote a tool called "inputlirc" that translates evdev events
into LIRC events, to allow remotes that then already used the input system to
work with LIRC.  At the time, lircd itself could do this, but you had to
"train" it to "decode" evdev bitstreams. Instead, inputlirc uses a fixed
mapping between evdev names and LIRC key names, so you don't need to train or
configure anything.

It seems that if you want to merge LIRC into the kernel, and have it generate
standard events, then inputlirc can be used to provide backwards compatibility
to those applications that only work with LIRC, or that rely on LIRC specific
behaviour (such as mode switching).

Debian package:  http://packages.debian.org/inputlirc
Git repository:  http://git.sliepen.org/inputlirc/

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus@sliepen.org>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [RFC v2] Another approach to IR

[Jarod Wilson]

On 12/3/09 2:47 PM, Guus Sliepen wrote:
> Hello,
>
> Some years ago I wrote a tool called "inputlirc" that translates evdev events
> into LIRC events, to allow remotes that then already used the input system to
> work with LIRC.  At the time, lircd itself could do this, but you had to
> "train" it to "decode" evdev bitstreams. Instead, inputlirc uses a fixed
> mapping between evdev names and LIRC key names, so you don't need to train or
> configure anything.

No longer necessary, there's a proper devinput lircd userspace driver 
that when paired with an lircd.conf (auto-generated based on 
linux/input.h) Just Works.

http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput

> It seems that if you want to merge LIRC into the kernel, and have it generate
> standard events,

It already can. If your button names in lircd.conf match button names in 
input.h, lircd can reinject the key presses into the input subsystem via 
uinput.

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC v2] Another approach to IR

[Guus Sliepen]

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

On Thu, Dec 03, 2009 at 04:53:54PM -0500, Jarod Wilson wrote:

> >Some years ago I wrote a tool called "inputlirc" that translates evdev events
> >into LIRC events,
[...]
> No longer necessary, there's a proper devinput lircd userspace
> driver that when paired with an lircd.conf (auto-generated based on
> linux/input.h) Just Works.
> 
> http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput

Ah, great, I can retire inputlirc then.

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus@sliepen.org>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]