[RFC] Infrared Keycode standardization

[RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

After years of analyzing the existing code and receiving/merging patches
related to IR, and taking a looking at the current scenario, it is clear to me
that something need to be done, in order to have some standard way to map and
to give precise key meanings for each used media keycode found on
include/linux/input.h.

Just as an example, I've parsed the bigger keymap file we have
(linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are
common between several different models. Yet, we've got almost 500 different
mappings there (and I removed from my parser all the "obvious" keys that there
weren't any comment about what is labeled for that key on the IR).

The same key name is mapped differently, depending only at the wish of the
patch author, as shown at:

	http://linuxtv.org/wiki/index.php/Ir-common.c

It doesn't come by surprise, but currently, almost all media player
applications don't care to properly map all those keys.

I've tried to find comments and/or descriptions about each media keys defined
at input.h without success. Just a few keys are commented at the file itself.
(or maybe I've just seek them at the wrong places).

So, I took the initiative of doing a proposition for standardizing those keys
at:

	http://linuxtv.org/wiki/index.php/Proposal

While I tried to use the most common binding for a key, sometimes the "commonly
used" one is so weird that I've used a different key mapping.

Please, don't take it as a finished proposal. For sure we need to adjust it.
Being it at wiki provides a way for people to edit, add comments and propose
additional keycode matches.

Also, there are several keys found on just one IR that didn't match any existing
keycode. So, I just decided to keep those outside the table, for now, to focus
on the mostly used ones.

That's said, please review my proposal. Feel free to update the proposal and
the current status if you think it is pertinent for this discussion.

I'm not currently proposing to create any new keycode, but it probably makes
sense to create a few ones, like KEY_PIP (for picture in picture).

If we can go to a common sense, I intend to add it into a chapter at V4L2 API,
in order to be used by both driver and userspace developers, submit some
patches to fix some mappings and to add the proper comments to input.h.

Comments?

Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Peter Brouwer]

Mauro Carvalho Chehab wrote:

Hi Mauro, All

Would it be an alternative to let lirc do the mapping and just let the driver 
pass the codes of the remote to the event port.
That way you do not need to patch the kernel for each new card/remote that comes 
out.
Just release a different map file for lirc for the remote of choice.

Peter
> After years of analyzing the existing code and receiving/merging patches
> related to IR, and taking a looking at the current scenario, it is clear to me
> that something need to be done, in order to have some standard way to map and
> to give precise key meanings for each used media keycode found on
> include/linux/input.h.
> 
> Just as an example, I've parsed the bigger keymap file we have
> (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are
> common between several different models. Yet, we've got almost 500 different
> mappings there (and I removed from my parser all the "obvious" keys that there
> weren't any comment about what is labeled for that key on the IR).
> 
> The same key name is mapped differently, depending only at the wish of the
> patch author, as shown at:
> 
> 	http://linuxtv.org/wiki/index.php/Ir-common.c
> 
> It doesn't come by surprise, but currently, almost all media player
> applications don't care to properly map all those keys.
> 
> I've tried to find comments and/or descriptions about each media keys defined
> at input.h without success. Just a few keys are commented at the file itself.
> (or maybe I've just seek them at the wrong places).
> 
> So, I took the initiative of doing a proposition for standardizing those keys
> at:
> 
> 	http://linuxtv.org/wiki/index.php/Proposal
> 
> While I tried to use the most common binding for a key, sometimes the "commonly
> used" one is so weird that I've used a different key mapping.
> 
> Please, don't take it as a finished proposal. For sure we need to adjust it.
> Being it at wiki provides a way for people to edit, add comments and propose
> additional keycode matches.
> 
> Also, there are several keys found on just one IR that didn't match any existing
> keycode. So, I just decided to keep those outside the table, for now, to focus
> on the mostly used ones.
> 
> That's said, please review my proposal. Feel free to update the proposal and
> the current status if you think it is pertinent for this discussion.
> 
> I'm not currently proposing to create any new keycode, but it probably makes
> sense to create a few ones, like KEY_PIP (for picture in picture).
> 
> If we can go to a common sense, I intend to add it into a chapter at V4L2 API,
> in order to be used by both driver and userspace developers, submit some
> patches to fix some mappings and to add the proper comments to input.h.
> 
> Comments?
> 
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] Infrared Keycode standardization

[Jarod Wilson]

On Aug 27, 2009, at 1:06 PM, Peter Brouwer wrote:

> Mauro Carvalho Chehab wrote:
>
> Hi Mauro, All
>
> Would it be an alternative to let lirc do the mapping and just let  
> the driver pass the codes of the remote to the event port.
> That way you do not need to patch the kernel for each new card/ 
> remote that comes out.
> Just release a different map file for lirc for the remote of choice.

But even if lirc is opening the event device, its worth standardizing  
what keys send which event code. I still need to read over the entire  
proposal, as well as some earlier related threads, been busy with  
other things.

Sidenote: someone (me) also needs to stop sloughing and submit lirc  
drivers upstream again...


>> After years of analyzing the existing code and receiving/merging  
>> patches
>> related to IR, and taking a looking at the current scenario, it is  
>> clear to me
>> that something need to be done, in order to have some standard way  
>> to map and
>> to give precise key meanings for each used media keycode found on
>> include/linux/input.h.

...

-- 
Jarod Wilson
jarod@wilsonet.com

Re: [RFC] Infrared Keycode standardization

[Devin Heitmueller]

On Thu, Aug 27, 2009 at 1:06 PM, Peter
Brouwer<pb.maillists@googlemail.com> wrote:
> Mauro Carvalho Chehab wrote:
>
> Hi Mauro, All
>
> Would it be an alternative to let lirc do the mapping and just let the
> driver pass the codes of the remote to the event port.
> That way you do not need to patch the kernel for each new card/remote that
> comes out.
> Just release a different map file for lirc for the remote of choice.
>
> Peter

The biggest challenge with that approach is that lirc is still
maintained out-of-kernel, and the inputdev solution does not require
lirc at all (which is good for inexperienced end users who want their
product to "just work").

Keeping the remote definitions in-kernel also helps developers adding
support for new products, since they can be sure that both the device
and its remote will appear in the same kernel version (they are
inherently in-sync compared to cases where the distribution upgrades
the kernel but not necessarily the lircd version they bundle).

The other big issue is that right now remotes get associated
automaticallywith products as part of the device profile.  While this
has the disadvantage that there is not a uniform mechanism to specify
a different remote than the one that ships with the product, it does
have the advantage of the product working "out-of-the-box" with
whatever remote it came with.  It's a usability issue, but what I
would consider a pretty important one.

That said, if we had a way to have some sort of remote control
signature that can be associated with lirc remote control definitions,
which can be referenced in-kernel, that would solve the above
mentioned problem of making the product work by default with the
remote it shipped with.

Devin

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

Re: [RFC] Infrared Keycode standardization

[Trent Piepho]

On Thu, 27 Aug 2009, Devin Heitmueller wrote:
> The biggest challenge with that approach is that lirc is still
> maintained out-of-kernel, and the inputdev solution does not require
> lirc at all (which is good for inexperienced end users who want their
> product to "just work").

If distros started packing lirc as a basic system daemon things would
generally just work too.  After all, there is plenty of other user space
software one needs to do anything.

> The other big issue is that right now remotes get associated
> automaticallywith products as part of the device profile.  While this
> has the disadvantage that there is not a uniform mechanism to specify
> a different remote than the one that ships with the product, it does
> have the advantage of the product working "out-of-the-box" with
> whatever remote it came with.  It's a usability issue, but what I
> would consider a pretty important one.

lirc isn't limited to one remote at a time.  You can have many different
remotes supported at once.  So it's not always necessary to know which
remote you have before the remote will work.

Re: [RFC] Infrared Keycode standardization

[Devin Heitmueller]

On Thu, Aug 27, 2009 at 2:29 PM, Trent Piepho<xyzzy@speakeasy.org> wrote:
> On Thu, 27 Aug 2009, Devin Heitmueller wrote:
>> The biggest challenge with that approach is that lirc is still
>> maintained out-of-kernel, and the inputdev solution does not require
>> lirc at all (which is good for inexperienced end users who want their
>> product to "just work").
>
> If distros started packing lirc as a basic system daemon things would
> generally just work too.  After all, there is plenty of other user space
> software one needs to do anything.

Sure, and when that day comes my opinion will change.  In the
meantime, users will see a regression (their remotes will stop working
whereas they worked before the upgrade).

>> The other big issue is that right now remotes get associated
>> automaticallywith products as part of the device profile.  While this
>> has the disadvantage that there is not a uniform mechanism to specify
>> a different remote than the one that ships with the product, it does
>> have the advantage of the product working "out-of-the-box" with
>> whatever remote it came with.  It's a usability issue, but what I
>> would consider a pretty important one.
>
> lirc isn't limited to one remote at a time.  You can have many different
> remotes supported at once.  So it's not always necessary to know which
> remote you have before the remote will work.

I recognize that lirc can support multiple remotes.  However, at a
minimum the lirc receiver should work out of the box with the remote
the product comes with.  And that means there needs to be some way in
the driver to associate the tuner with some remote control profile
that has its layout defined in lirc.  Sure, if the user wants to then
say "I want to use this different remote instead..." then that should
be supported as well if the user does the appropriate configuration.

While I can appreciate the desire to support all sorts of advanced
configurations, this shouldn't be at the cost of the simple
configurations not working out-of-the-box.

Devin

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

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

> I recognize that lirc can support multiple remotes.  However, at a
> minimum the lirc receiver should work out of the box with the remote
> the product comes with.  And that means there needs to be some way in
> the driver to associate the tuner with some remote control profile
> that has its layout defined in lirc.  Sure, if the user wants to then
> say "I want to use this different remote instead..." then that should
> be supported as well if the user does the appropriate configuration.

No doubt that lirc has its usage, but its usage requires either an out-of-tree
kernel module, whose setup is not trivial, especially if the distro comes
without support for it, or its event interface.

>From what I've found looking at a few lirc kernel modules, they also need a
better glue with the device drivers, to do some needed locks.

Either way, lirc setup is not that easy, since you need to properly configure
the /etc/lirc*conf, in order to match your board, your IR and your desired
applications.

The event interface also requires that you need to have your device connected
before calling the daemon, and that the user discover what's the event
interface used by a device, to fill its command line:

$ lircd -H devinput -d /dev/input/event6

IMHO, this has practical usage only with non-hotpluggable (e. g. PCI) devices.

Yet, if we provide a standard set of defined keys for IR, it would be possible
to have standard configurations for event interface on lirc that will work with the
IR that is provided together with the device, since the keycodes for starting
TV, changing channels, etc will be the same no matter what video board you're using.

So, it would be easier for distros to find some ways for it to work
out-of-the-box with their systems, provided that someone invest some time
improving the lirc event interface to better work with hot-pluggable devices or
on create some udev rules to start/stop lircd when an IR event interface is
created.

> While I can appreciate the desire to support all sorts of advanced
> configurations, this shouldn't be at the cost of the simple
> configurations not working out-of-the-box.

Agreed. The usage of lirc should be optional, not mandatory.



Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Thu, 27 Aug 2009 13:17:57 -0400
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> On Thu, Aug 27, 2009 at 1:06 PM, Peter
> Brouwer<pb.maillists@googlemail.com> wrote:
> > Mauro Carvalho Chehab wrote:
> >
> > Hi Mauro, All
> >
> > Would it be an alternative to let lirc do the mapping and just let the
> > driver pass the codes of the remote to the event port.

For most devices, this is already allowed, via the standard
EVIOCGKEYCODE/EVIOCSKEYCODE ioctl. 

There's a small application showing how to change the keycodes. It is called
"keytable", and it is avalable at v4l2-apps/util directory at our development
tree:
	http://linuxtv.org/hg/v4l-dvb

Yet, there are some DVB-only devices that use a different way to support event
interface that doesn't allow userspace to replace the IR tables. I've looked on
the dvb-usb code recently. While a patch for it is not trivial, it shouldn't be
that hard to change it to support the key GET/SET ioctls, but a patch for it
requires some care, since it will touch on several different places and drivers.

I'll probably try to address this later.

Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Dmitry Torokhov]

On Thu, Aug 27, 2009 at 06:06:13PM +0100, Peter Brouwer wrote:
> Mauro Carvalho Chehab wrote:
>
> Hi Mauro, All
>
> Would it be an alternative to let lirc do the mapping and just let the 
> driver pass the codes of the remote to the event port.

I don't think that blindly passing IR codes through input layer is a
good idea, for the same reason we don't do that for HID and PS/2
anymore - task of the kernel is to provide unified interface to the
hardware devices instead of letting userspace deal with the raw data
streams.

-- 
Dmitry

Re: [RFC] Infrared Keycode standardization

[semiRocket]

On Thu, 27 Aug 2009 19:06:13 +0200, Peter Brouwer
<pb.maillists@googlemail.com> wrote:

>> After years of analyzing the existing code and receiving/merging patches
>> related to IR, and taking a looking at the current scenario, it is  
>> clear to me
>> that something need to be done, in order to have some standard way to  
>> map and
>> to give precise key meanings for each used media keycode found on
>> include/linux/input.h.

<snip>

Hi all,

Some end user thoughts, perhaps unwelcome but here it goes :)

I think that standardization of buttons is really needed that application
programmers can relly on, for example I see this like following:

I think that specific MCE compatible buttons need to be implemented that
are specific on most todays remotes. And I imagine a Linux Media Center
that works out-of-the-box. I plug in my Linux supported card, point my
remote and press Media center button which runs media center application.
Because it's standard and that's applications programers implemeted it as
key that triggers their app. If press Videos button on my remote, the app
switches to videos directory, because it's standard, and most remotes have
it, etc.

http://www.spinics.net/lists/linux-media/msg07705.html

And thinking of that, I have configuring nothing, it's already configured
because of standardization of buttons. And, if some advanced user doesn't
like this behavior, he can always tamper configuration files to suite his
need.

Forgive me if I'm missing something, as I don't know how it all works
together, but I think you've figured out the point of the meaning :).

I also welcome this effort.

Cheers,
Samuel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [RFC] Infrared Keycode standardization

[Ville Syrjälä]

On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote:
> After years of analyzing the existing code and receiving/merging patches
> related to IR, and taking a looking at the current scenario, it is clear to me
> that something need to be done, in order to have some standard way to map and
> to give precise key meanings for each used media keycode found on
> include/linux/input.h.
> 
> Just as an example, I've parsed the bigger keymap file we have
> (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are
> common between several different models. Yet, we've got almost 500 different
> mappings there (and I removed from my parser all the "obvious" keys that there
> weren't any comment about what is labeled for that key on the IR).
> 
> The same key name is mapped differently, depending only at the wish of the
> patch author, as shown at:
> 
> 	http://linuxtv.org/wiki/index.php/Ir-common.c
> 
> It doesn't come by surprise, but currently, almost all media player
> applications don't care to properly map all those keys.
> 
> I've tried to find comments and/or descriptions about each media keys defined
> at input.h without success. Just a few keys are commented at the file itself.
> (or maybe I've just seek them at the wrong places).
> 
> So, I took the initiative of doing a proposition for standardizing those keys
> at:
> 
> 	http://linuxtv.org/wiki/index.php/Proposal

I welcome this effort. It would be nice to have some kind of consistent
behaviour between devices. But just limiting the effort to IR devices
doesn't make sense. It shouldn't matter how the device is connected.

FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would
make most sense if FASTFORWARD and REWIND were paired and FORWARD and
BACK were paired. I actually have those two a bit confused in
ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should
be REWIND instead.

Also I should probably use ZOOM for the maximize/restore button (it's
FRONT now), and maybe SETUP instead of ENTER for another. It has a
picture of a checkbox, Windows software apparently shows a setup menu
when it's pressed.

There are also a couple of buttons where no keycode really seems to
match. One is the mouse button drag. I suppose I could implement the
drag lock feature in the driver but I'm not sure if that's a good idea.
It would make that button special and unmappable. Currently I have that
mapped to EDIT IIRC.

The other oddball button has a picture of a stopwatch (I think, it's
not very clear). Currently it uses COFFEE, but maybe TIMER or something
like that should be added. The Windows software's manual just say it
toggles TV-on-demand, but I have no idea what that actually is.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
--
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] Infrared Keycode standardization

[Dmitry Torokhov]

On Thu, Aug 27, 2009 at 09:36:36PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote:
> > After years of analyzing the existing code and receiving/merging patches
> > related to IR, and taking a looking at the current scenario, it is clear to me
> > that something need to be done, in order to have some standard way to map and
> > to give precise key meanings for each used media keycode found on
> > include/linux/input.h.
> > 
> > Just as an example, I've parsed the bigger keymap file we have
> > (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are
> > common between several different models. Yet, we've got almost 500 different
> > mappings there (and I removed from my parser all the "obvious" keys that there
> > weren't any comment about what is labeled for that key on the IR).
> > 
> > The same key name is mapped differently, depending only at the wish of the
> > patch author, as shown at:
> > 
> > 	http://linuxtv.org/wiki/index.php/Ir-common.c
> > 
> > It doesn't come by surprise, but currently, almost all media player
> > applications don't care to properly map all those keys.
> > 
> > I've tried to find comments and/or descriptions about each media keys defined
> > at input.h without success. Just a few keys are commented at the file itself.
> > (or maybe I've just seek them at the wrong places).
> > 
> > So, I took the initiative of doing a proposition for standardizing those keys
> > at:
> > 
> > 	http://linuxtv.org/wiki/index.php/Proposal
> 
> I welcome this effort. It would be nice to have some kind of consistent
> behaviour between devices. But just limiting the effort to IR devices
> doesn't make sense. It shouldn't matter how the device is connected.
> 
> FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would
> make most sense if FASTFORWARD and REWIND were paired and FORWARD and
> BACK were paired. I actually have those two a bit confused in
> ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should
> be REWIND instead.
> 
> Also I should probably use ZOOM for the maximize/restore button (it's
> FRONT now), and maybe SETUP instead of ENTER for another. It has a
> picture of a checkbox, Windows software apparently shows a setup menu
> when it's pressed.
> 
> There are also a couple of buttons where no keycode really seems to
> match. One is the mouse button drag. I suppose I could implement the
> drag lock feature in the driver but I'm not sure if that's a good idea.
> It would make that button special and unmappable. Currently I have that
> mapped to EDIT IIRC.

Unmappable keys should probably emit KEY_UNKNOWN. When I last talked
with Richard Hughes there was an idea that userspace may detect
KEY_UNKNOWN and alert user that key needs to be mapped since it lacks
standard assignment. EV_MSC/MSC_SCAN was supposed to aid in fuguring out
what key it was so that usersoace can issue proper EVIOCSKEYCODE...

> 
> The other oddball button has a picture of a stopwatch (I think, it's
> not very clear). Currently it uses COFFEE, but maybe TIMER or something
> like that should be added. The Windows software's manual just say it
> toggles TV-on-demand, but I have no idea what that actually is.
> 

I'd start by looking at HID usage tables and borrowing [missing]
definitions from there. Patches commenting on intended use of input
keycodes are always welcome.

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

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Thu, 27 Aug 2009 13:15:12 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> escreveu:

> On Thu, Aug 27, 2009 at 09:36:36PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote:
> > > After years of analyzing the existing code and receiving/merging patches
> > > related to IR, and taking a looking at the current scenario, it is clear to me
> > > that something need to be done, in order to have some standard way to map and
> > > to give precise key meanings for each used media keycode found on
> > > include/linux/input.h.
> > > 
> > > Just as an example, I've parsed the bigger keymap file we have
> > > (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are
> > > common between several different models. Yet, we've got almost 500 different
> > > mappings there (and I removed from my parser all the "obvious" keys that there
> > > weren't any comment about what is labeled for that key on the IR).
> > > 
> > > The same key name is mapped differently, depending only at the wish of the
> > > patch author, as shown at:
> > > 
> > > 	http://linuxtv.org/wiki/index.php/Ir-common.c
> > > 
> > > It doesn't come by surprise, but currently, almost all media player
> > > applications don't care to properly map all those keys.
> > > 
> > > I've tried to find comments and/or descriptions about each media keys defined
> > > at input.h without success. Just a few keys are commented at the file itself.
> > > (or maybe I've just seek them at the wrong places).
> > > 
> > > So, I took the initiative of doing a proposition for standardizing those keys
> > > at:
> > > 
> > > 	http://linuxtv.org/wiki/index.php/Proposal
> > 
> > I welcome this effort. It would be nice to have some kind of consistent
> > behaviour between devices. But just limiting the effort to IR devices
> > doesn't make sense. It shouldn't matter how the device is connected.
> > 
> > FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would
> > make most sense if FASTFORWARD and REWIND were paired and FORWARD and
> > BACK were paired. I actually have those two a bit confused in
> > ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should
> > be REWIND instead.
> > 
> > Also I should probably use ZOOM for the maximize/restore button (it's
> > FRONT now), and maybe SETUP instead of ENTER for another. It has a
> > picture of a checkbox, Windows software apparently shows a setup menu
> > when it's pressed.
> > 
> > There are also a couple of buttons where no keycode really seems to
> > match. One is the mouse button drag. I suppose I could implement the
> > drag lock feature in the driver but I'm not sure if that's a good idea.
> > It would make that button special and unmappable. Currently I have that
> > mapped to EDIT IIRC.
> 
> Unmappable keys should probably emit KEY_UNKNOWN. When I last talked
> with Richard Hughes there was an idea that userspace may detect
> KEY_UNKNOWN and alert user that key needs to be mapped since it lacks
> standard assignment. EV_MSC/MSC_SCAN was supposed to aid in fuguring out
> what key it was so that usersoace can issue proper EVIOCSKEYCODE...

This seems to be a good idea, for those keys that aren't at rc5 spec.

> > 
> > The other oddball button has a picture of a stopwatch (I think, it's
> > not very clear). Currently it uses COFFEE, but maybe TIMER or something
> > like that should be added. The Windows software's manual just say it
> > toggles TV-on-demand, but I have no idea what that actually is.
> > 
> 
> I'd start by looking at HID usage tables and borrowing [missing]
> definitions from there. Patches commenting on intended use of input
> keycodes are always welcome.

After we've agreed on a common base, I'll send a patch documenting the keys as
used on IR. It would be good if you could take some time and see if I'm not
abusing of any key at the current proposal[1]. Some of the used keys may
already be mapped to do something else at kde, gnome or x11.

[1] http://linuxtv.org/wiki/index.php/Proposal



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

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Thu, 27 Aug 2009 21:36:36 +0300
Ville Syrjälä <syrjala@sci.fi> escreveu:


> I welcome this effort. It would be nice to have some kind of consistent
> behaviour between devices. But just limiting the effort to IR devices
> doesn't make sense. It shouldn't matter how the device is connected.

Agreed.

> 
> FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would
> make most sense if FASTFORWARD and REWIND were paired and FORWARD and
> BACK were paired. I actually have those two a bit confused in
> ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should
> be REWIND instead.

Makes sense. I updated it at the wiki. I also tried to group the keycodes by
function there.

> Also I should probably use ZOOM for the maximize/restore button (it's
> FRONT now), and maybe SETUP instead of ENTER for another. It has a
> picture of a checkbox, Windows software apparently shows a setup menu
> when it's pressed.
> 
> There are also a couple of buttons where no keycode really seems to
> match. One is the mouse button drag. I suppose I could implement the
> drag lock feature in the driver but I'm not sure if that's a good idea.
> It would make that button special and unmappable. Currently I have that
> mapped to EDIT IIRC.

I'm not sure what we should do with those buttons. 

Probably, the most complete IR spec is the RC5 codes:
	http://c6000.spectrumdigital.com/davincievm/revf/files/msp430/rc5_codes.pdf
(not sure if this table is complete or accurate, but on a search I did
today, this is the one that gave me a better documentation)

I suspect that, after solving the most used cases, we'll need to take a better look on it,
identifying the missing cases of the real implementations and add them to input.h.

> The other oddball button has a picture of a stopwatch (I think, it's
> not very clear). Currently it uses COFFEE, but maybe TIMER or something
> like that should be added. The Windows software's manual just say it
> toggles TV-on-demand, but I have no idea what that actually is.

Hmm... Maybe TV-on-demand is another name for pay-per-view?



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

Re: [RFC] Infrared Keycode standardization

[Devin Heitmueller]

On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Thu, 27 Aug 2009 21:36:36 +0300
> Ville Syrjälä <syrjala@sci.fi> escreveu:
>
>
>> I welcome this effort. It would be nice to have some kind of consistent
>> behaviour between devices. But just limiting the effort to IR devices
>> doesn't make sense. It shouldn't matter how the device is connected.
>
> Agreed.
>
>>
>> FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would
>> make most sense if FASTFORWARD and REWIND were paired and FORWARD and
>> BACK were paired. I actually have those two a bit confused in
>> ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should
>> be REWIND instead.
>
> Makes sense. I updated it at the wiki. I also tried to group the keycodes by
> function there.
>
>> Also I should probably use ZOOM for the maximize/restore button (it's
>> FRONT now), and maybe SETUP instead of ENTER for another. It has a
>> picture of a checkbox, Windows software apparently shows a setup menu
>> when it's pressed.
>>
>> There are also a couple of buttons where no keycode really seems to
>> match. One is the mouse button drag. I suppose I could implement the
>> drag lock feature in the driver but I'm not sure if that's a good idea.
>> It would make that button special and unmappable. Currently I have that
>> mapped to EDIT IIRC.
>
> I'm not sure what we should do with those buttons.
>
> Probably, the most complete IR spec is the RC5 codes:
>        http://c6000.spectrumdigital.com/davincievm/revf/files/msp430/rc5_codes.pdf
> (not sure if this table is complete or accurate, but on a search I did
> today, this is the one that gave me a better documentation)
>
> I suspect that, after solving the most used cases, we'll need to take a better look on it,
> identifying the missing cases of the real implementations and add them to input.h.
>
>> The other oddball button has a picture of a stopwatch (I think, it's
>> not very clear). Currently it uses COFFEE, but maybe TIMER or something
>> like that should be added. The Windows software's manual just say it
>> toggles TV-on-demand, but I have no idea what that actually is.
>
> Hmm... Maybe TV-on-demand is another name for pay-per-view?
>
>
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Since we're on the topic of IR support, there are probably a couple of
other things we may want to be thinking about if we plan on
refactoring the API at all:

1.  The fact that for RC5 remote controls, the tables in ir-keymaps.c
only have the second byte.  In theory, they should have both bytes
since the vendor byte helps prevents receiving spurious commands from
unrelated remote controls.  We should include the ability to "ignore
the vendor byte" so we can continue to support all the remotes
currently in the ir-keymaps.c where we don't know what the vendor byte
should contain.

2..  The fact that the current API provides no real way to change the
mode of operation for the IR receiver, for those receivers that
support multiple modes (NEC/RC5/RC6).  While you have the ability to
change the mapping table from userland via the keytable program, there
is currently no way to tell the IR receiver which mode to operate in.

One would argue that the above keymaps structure should include new
fields to indicate what type of remote it is (NEC/RC5/RC6 etc), as
well as field to indicate that the vendor codes are absent from the
key mapping for that remote).  Given this, I can change the dib0700
and em28xx IR receivers to automatically set the IR capture mode
appropriate based on which remote is in the device profile.

Devin

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

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Thu, 27 Aug 2009 18:06:51 -0400
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> Since we're on the topic of IR support, there are probably a couple of
> other things we may want to be thinking about if we plan on
> refactoring the API at all:
> 
> 1.  The fact that for RC5 remote controls, the tables in ir-keymaps.c
> only have the second byte.  In theory, they should have both bytes
> since the vendor byte helps prevents receiving spurious commands from
> unrelated remote controls.  We should include the ability to "ignore
> the vendor byte" so we can continue to support all the remotes
> currently in the ir-keymaps.c where we don't know what the vendor byte
> should contain.

This were done due to at least two reasons:

1) Several boards uses a few GPIO bits (in general 7 or less bits) for IR.
There's one logic at ir-common.ko to convert a 32 bits GPIO read into a 7 bits
scancode.

2) In order to properly support the default EVIOCGKEYCODE/EVIOCSKEYCODE
handlers, we need to have keycode table, where the scan code is the index. So,
if we use 14 bits for it, this means that this table would reserve 16384 bytes,
and will probably a very few of those bytes (on a IR with 64 keys, it would
need only 64 entries).

As it seems that there are some ways to replace the default
getkeycode/setkeycode handlers, I suspect that we can get rid of this limitation.

I'll do some tests here with a dib0700 and an em28xx devices.

> 2..  The fact that the current API provides no real way to change the
> mode of operation for the IR receiver, for those receivers that
> support multiple modes (NEC/RC5/RC6).  While you have the ability to
> change the mapping table from userland via the keytable program, there
> is currently no way to tell the IR receiver which mode to operate in.

In this case, we'll need to have a set of new ioctls at the event interface, to
allow enum/get/set the IR protocol type(s) per event device.

> One would argue that the above keymaps structure should include new
> fields to indicate what type of remote it is (NEC/RC5/RC6 etc), as
> well as field to indicate that the vendor codes are absent from the
> key mapping for that remote).  Given this, I can change the dib0700
> and em28xx IR receivers to automatically set the IR capture mode
> appropriate based on which remote is in the device profile.

Let's go step by step. Adding the ability of dynamically change the type of
remote will likely cause major changes at the GPIO polling code, since we'll
need to move some code from bttv and saa7134 into ir-functions.c and rework on
it. We'll probably end by converting the remaining polling code to use high
precision timers as we've done with cx88.

So, we need a sort of TODO list for IR changes. A start point (on a random
order) would be something like:

1) Standardize the keycodes;
2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE;
3) use a different arrangement for IR tables to not spend 16 K for IR table,
yet allowing RC5 full table;
4) Use the common IR framework at the dvb drivers with their own iplementation;
5) Allow getkeycode/setkeycode to work with the dvb framework using the new
methods;
6) implement new event ioctls (EVIOEPROTO/EVIOGPROTO/EVIOSPROTO ?), to allow
enumerating/getting/setting the IR protocol types;
7) Change the non-gpio drivers to support IR protocol type;
8) Create a gpio handler that supports changing the protocol type;
9) Migrate the remaining drivers to the new gpio handler methods;
10) Merge pertinent lirc drivers;
11) Add missing keys at input.h.



Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Fri, 28 Aug 2009 00:46:28 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:

> So, we need a sort of TODO list for IR changes. A start point (on a random
> order) would be something like:
> 
> 2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE;
> 3) use a different arrangement for IR tables to not spend 16 K for IR table,
> yet allowing RC5 full table;
> 4) Use the common IR framework at the dvb drivers with their own iplementation;
> 5) Allow getkeycode/setkeycode to work with the dvb framework using the new
> methods;

Ok, I have a code that handles the above for dvb-usb. Se enclosed. It turned to be
simpler than what I've expected originally ;)

Tested with kernel 2.6.30.3 and a dibcom device.

While this patch works fine, for now, it is just a proof of concept, since there are a few
details to be decided/solved for a version 2, as described bellow.

I'm committing at the development tree some improvements at keytable util for
it to handle those 16 bits tables



Cheers,
Mauro
---

dvb-usb: allow userspace replacement of IR keycodes

Implements handler for EVIOCGKEYCODE/EVIOCSKEYCODE via adding two new callbacks
to the input device.

Since on dvb-usb a scan code has 16 bits, to fulfill rc5 standard codes, the default
getkeycode/setkeycode input methods would require the driver to spend up to 64 Kb of
a sparse table. Instead, add two new callbacks to the event device.

With this, it is now possible to replace the keycode tables. There are, however, a few
implementation details at the current patch:

1) It will replace the existing device keytable, instead of creating an instance
of the data. This works. However, if two devices pointing to the same table
were connected, changing the IR table of one will also change the IR table for
the other (the solution for this one is simple: just kmalloc some memory);

2) In order to change the scan code, you need first to change the key to
KEY_RESERVED or KEY_UNKNOWN to free some space at the table (solution: allocate
some additional space for newer scan codes or allow dynamic table grow);

3) The table size cannot be extended. It would be easy to allow the table to
grow dynamically: just calling kmalloc(size+1); kfree(old). Yet, maybe we can
just create a bigger table with a fixed size, like for example a table with 128
entries. This should be enough even for a very big IR.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff -r ec87db9cb8db linux/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
--- a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c	Fri Aug 28 02:12:12 2009 -0300
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c	Fri Aug 28 03:46:35 2009 -0300
@@ -12,6 +12,65 @@
 #include <linux/usb_input.h>
 #endif
 
+static int dvb_usb_getkeycode(struct input_dev *dev,
+				    int scancode, int *keycode)
+{
+	struct dvb_usb_device *d = input_get_drvdata(dev);
+
+	struct dvb_usb_rc_key *keymap = d->props.rc_key_map;
+	int custom = (scancode >> 8) & 0xff;
+	int data = scancode & 0xff;
+	int i;
+
+	/* See if we can match the raw key code. */
+	for (i = 0; i < d->props.rc_key_map_size; i++)
+		if (keymap[i].custom == custom &&
+			keymap[i].data == data) {
+			*keycode = keymap[i].event;
+			return 0;
+		}
+	return -EINVAL;
+}
+
+static int dvb_usb_setkeycode(struct input_dev *dev,
+				    int scancode, int keycode)
+{
+	struct dvb_usb_device *d = input_get_drvdata(dev);
+
+	struct dvb_usb_rc_key *keymap = d->props.rc_key_map;
+	int custom = (scancode >> 8) & 0xff;
+	int data = scancode & 0xff;
+	int i;
+
+	/* Search if it is replacing an existing keycode */
+	for (i = 0; i < d->props.rc_key_map_size; i++)
+		if (keymap[i].custom == custom &&
+			keymap[i].data == data) {
+			keymap[i].event = keycode;
+			return 0;
+		}
+
+	/* Search if is there a clean entry. If so, use it */
+	for (i = 0; i < d->props.rc_key_map_size; i++)
+		if (keymap[i].event == KEY_RESERVED ||
+		    keymap[i].event == KEY_UNKNOWN) {
+			keymap[i].custom = custom;
+			keymap[i].data = data;
+			keymap[i].event = keycode;
+			return 0;
+		}
+
+	/*
+	 * FIXME: Currently, it is not possible to increase the size of
+	 * scancode table. For it to happen, one possibility
+	 * would be to allocate a table with key_map_size + 1,
+	 * copying data, appending the new key on it, and freeing
+	 * the old one - or maybe just allocating some spare space
+	 */
+
+	return -EINVAL;
+}
+
 /* Remote-control poll function - called every dib->rc_query_interval ms to see
  * whether the remote control has received anything.
  *
@@ -127,6 +186,8 @@
 #else
 	input_dev->cdev.dev = &d->udev->dev;
 #endif
+	input_dev->getkeycode = dvb_usb_getkeycode;
+	input_dev->setkeycode = dvb_usb_setkeycode;
 
 	/* set the bits for the keys */
 	deb_rc("key map size: %d\n", d->props.rc_key_map_size);
@@ -144,6 +205,8 @@
 	input_dev->rep[REP_PERIOD] = d->props.rc_interval;
 	input_dev->rep[REP_DELAY]  = d->props.rc_interval + 150;
 
+	input_set_drvdata(input_dev, d);
+
 	err = input_register_device(input_dev);
 	if (err) {
 		input_free_device(input_dev);

Re: [RFC] Infrared Keycode standardization

[Peter Brouwer]

Would like to add one more dimension to the discussion.

The situation of having multiple DVB type boards in one system.

Using one remote would be enough to control the system. So we should have a 
mechanism/kernel config option, to enable/disable an IR device on a board.
For multiple boards of the same type, enable the first and disable any 
subsequently detected boards.

Peter

> 

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Fri, 28 Aug 2009 11:13:33 +0100
Peter Brouwer <pb.maillists@googlemail.com> escreveu:

> 
> Would like to add one more dimension to the discussion.
> 
> The situation of having multiple DVB type boards in one system.
> 
> Using one remote would be enough to control the system. So we should have a 
> mechanism/kernel config option, to enable/disable an IR device on a board.
> For multiple boards of the same type, enable the first and disable any 
> subsequently detected boards.

I agree that this feature would be useful, but we shouldn't assume that the
user doesn't expect to have more than one IR working. With USB keyboard/mouse
and computers supporting video cards with multiple heads, it is possible to use
one server to handle several virtual machines with their own keyboard, mouse,
video and IR (in fact, I've already seen similar scenarios on some expositions).

Anyway, for this to happen with all drivers, the better way would be to use a
common IR framework.



Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Alistair Buxton]

2009/8/28 Peter Brouwer <pb.maillists@googlemail.com>:
>
> Would like to add one more dimension to the discussion.
>
> The situation of having multiple DVB type boards in one system.
>
> Using one remote would be enough to control the system. So we should have a
> mechanism/kernel config option, to enable/disable an IR device on a board.
> For multiple boards of the same type, enable the first and disable any
> subsequently detected boards.

Don't forget that completely different boards can have identical
remotes. For example the RTL2831 driver has an almost identical copy
of dvb-usb IR code in it. See here for in depth explanation and patch
that makes it use dvb-usb instead:
http://patchwork.kernel.org/patch/38794/

Now I'm not really familiar with frontends and tuners so it may be
that the RTL driver should be reimplemented within dvb-usb instead,
but if it can't be it would be nice if that IR code could be shared
without pulling in all the rest of dvb-usb modules too. I'm told that
the excessive code duplication is the reason this driver isn't in
mainline yet - I've been using it with no problems for over two years
now.

-- 
Alistair Buxton
a.j.buxton@gmail.com

Re: [RFC] Infrared Keycode standardization

[Patrick Boettcher]

Hi Mauro,

On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:

> Em Fri, 28 Aug 2009 00:46:28 -0300
> Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:
>
>> So, we need a sort of TODO list for IR changes. A start point (on a random
>> order) would be something like:
>>
>> 2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE;
>> 3) use a different arrangement for IR tables to not spend 16 K for IR table,
>> yet allowing RC5 full table;
>> 4) Use the common IR framework at the dvb drivers with their own iplementation;
>> 5) Allow getkeycode/setkeycode to work with the dvb framework using the new
>> methods;
>
> Ok, I have a code that handles the above for dvb-usb. Se enclosed. It turned to be
> simpler than what I've expected originally ;)

Yeah, this is due to the nature of modularity of dvb-usb. Saying that, all 
drivers which have (re)implemented IR-handling needs to ported as well. Or 
included in dvb-usb :P .

> Tested with kernel 2.6.30.3 and a dibcom device.
>
> While this patch works fine, for now, it is just a proof of concept, since there are a few
> details to be decided/solved for a version 2, as described bellow.

This is the answer to the question I had several times in the past years.

Very good job. It will solve the memory waste in the driver for 
key-tables filled up with keys for different remotes where the user of 
one board only has one. The code will also be smaller and easier to read.

This also allows the user to use any remote with any (sensitive) 
ir-sensor in a USB device.

Is there a feature in 'input' which allows to request a file (like 
request_firmware)? This would be ideal for a transition from 
in-kernel-keymaps to user-space-keymap-loading: By default it would 
request the file corresponding to the remote delivered with the device.

Is that possible somehow?

Patrick.

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Fri, 28 Aug 2009 12:50:27 +0200 (CEST)
Patrick Boettcher <pboettcher@kernellabs.com> escreveu:

> Hi Mauro,
> 
> On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:
> 
> > Em Fri, 28 Aug 2009 00:46:28 -0300
> > Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:
> >
> >> So, we need a sort of TODO list for IR changes. A start point (on a random
> >> order) would be something like:
> >>
> >> 2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE;
> >> 3) use a different arrangement for IR tables to not spend 16 K for IR table,
> >> yet allowing RC5 full table;
> >> 4) Use the common IR framework at the dvb drivers with their own iplementation;
> >> 5) Allow getkeycode/setkeycode to work with the dvb framework using the new
> >> methods;
> >
> > Ok, I have a code that handles the above for dvb-usb. Se enclosed. It turned to be
> > simpler than what I've expected originally ;)
> 
> Yeah, this is due to the nature of modularity of dvb-usb. 

Yes, but I was afraid that we would need to use a different struct for IR's.
This feature is already available for years at V4L, but the tables needed to
use scancode as their indexes to use the default handlers (I'm not sure, but
afaik, in the past there weren't ways to override them).

> Saying that, all 
> drivers which have (re)implemented IR-handling needs to ported as well. Or 
> included in dvb-usb :P .

My suggestion is to port the current implementation to ir-common.ko. This
module is not dependent of any other V4L or DVB specifics and has already
some code to handle GPIO polling based and GPIO IRQ based IR's. It contains
some IR tables for IR's that are used also on dvb-usb, like Hauppauge IR
keycodes.

Yet, we will need first to change ir-common.ko, since it is currently using the
tables indexed by a 7bit scancode (due to size constraints, V4L code discards
one RC5 byte), but this is already on our todo list (due to keycode
standardization).

> > Tested with kernel 2.6.30.3 and a dibcom device.
> >
> > While this patch works fine, for now, it is just a proof of concept, since there are a few
> > details to be decided/solved for a version 2, as described bellow.
> 
> This is the answer to the question I had several times in the past years.
> 
> Very good job. It will solve the memory waste in the driver for 
> key-tables filled up with keys for different remotes where the user of 
> one board only has one. The code will also be smaller and easier to read.
> 
> This also allows the user to use any remote with any (sensitive) 
> ir-sensor in a USB device.

True.

> Is there a feature in 'input' which allows to request a file (like 
> request_firmware)? This would be ideal for a transition from 
> in-kernel-keymaps to user-space-keymap-loading: By default it would 
> request the file corresponding to the remote delivered with the device.
> 
> Is that possible somehow?

There's nothing that I'm aware of, but I suspect that it shouldn't be hard to do it
via udev. 

We'll need to do some work there, in order to be sure that each V4L and DVB
device will have their own unique IR board ID's. We may then do an application
based on  v4l2-apps/util/keytable that will use the IR board ID to 
dynamically load the keytable, with a default config of loading the board's own
IR, but allowing the user to replace it by a custom one.

Currently, the Makefile at v4l2-apps/util creates a directory (keycodes) that
contains lots of IR tables. It does it by parsing the existing IR tables at V4L
side. After having all tables looking the same, it won't be hard to change it
to parse all MCE tables, creating an updated repository of the existing
scancode/keycode association.



Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Fri, 28 Aug 2009 09:30:42 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:

> Em Fri, 28 Aug 2009 12:50:27 +0200 (CEST)
> Patrick Boettcher <pboettcher@kernellabs.com> escreveu:
> 
> > Hi Mauro,
> > 
> > On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:
> > 
> > > Em Fri, 28 Aug 2009 00:46:28 -0300
> > > Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:
> > >
> > >> So, we need a sort of TODO list for IR changes. A start point (on a random
> > >> order) would be something like:
> > >>
> > >> 2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE;
> > >> 3) use a different arrangement for IR tables to not spend 16 K for IR table,
> > >> yet allowing RC5 full table;
> > >> 4) Use the common IR framework at the dvb drivers with their own iplementation;
> > >> 5) Allow getkeycode/setkeycode to work with the dvb framework using the new
> > >> methods;
> > >
> > > Ok, I have a code that handles the above for dvb-usb. Se enclosed. It turned to be
> > > simpler than what I've expected originally ;)
> > 
> > Yeah, this is due to the nature of modularity of dvb-usb. 
> 
> Yes, but I was afraid that we would need to use a different struct for IR's.
> This feature is already available for years at V4L, but the tables needed to
> use scancode as their indexes to use the default handlers (I'm not sure, but
> afaik, in the past there weren't ways to override them).
> 
> > Saying that, all 
> > drivers which have (re)implemented IR-handling needs to ported as well. Or 
> > included in dvb-usb :P .
> 
> My suggestion is to port the current implementation to ir-common.ko. This
> module is not dependent of any other V4L or DVB specifics and has already
> some code to handle GPIO polling based and GPIO IRQ based IR's. It contains
> some IR tables for IR's that are used also on dvb-usb, like Hauppauge IR
> keycodes.
> 
> Yet, we will need first to change ir-common.ko, since it is currently using the
> tables indexed by a 7bit scancode (due to size constraints, V4L code discards
> one RC5 byte), but this is already on our todo list (due to keycode
> standardization).

Ok, I've did several changes on both V4L and dvb-usb IR implementations. They
scancode tables are now implemented at the same way, at:
	http://linuxtv.org/hg/~mchehab/IR

I've also added there the current version of the getkeycode/setkeycode patch.

Ah, the v4l2-apps/util/Makefile will now generate the scancode userspace tables
for DVB IR's as well (currently, we have 85 IR layouts generated from source files).

What's still missing:

- For now, V4L is still using internally the old decoding process, based on the
7bit array of keycode.

- I haven't yet added some extra empty data at dvb scancode tables;

- although they're using the same structs, the code is still different.

Please review.



Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Sat, 29 Aug 2009 15:45:28 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:

> Ok, I've did several changes on both V4L and dvb-usb IR implementations. They
> scancode tables are now implemented at the same way, at:
> 	http://linuxtv.org/hg/~mchehab/IR

Ok, I've also updated the V4L2 API spec with the default keyboard mapping on
the above URL. If nobody complains, I'll update our development tree with the
above changes likely today (Aug, 31) night, and prepare the changesets to be
added at linux-next.

Cheers,
Mauro

Re: [RFC] Infrared Keycode standardization

[Dmitry Torokhov]

Mauro,

On Mon, Aug 31, 2009 at 02:47:41AM -0300, Mauro Carvalho Chehab wrote:
> Em Sat, 29 Aug 2009 15:45:28 -0300
> Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:
> 
> > Ok, I've did several changes on both V4L and dvb-usb IR implementations. They
> > scancode tables are now implemented at the same way, at:
> > 	http://linuxtv.org/hg/~mchehab/IR
> 
> Ok, I've also updated the V4L2 API spec with the default keyboard mapping on
> the above URL. If nobody complains, I'll update our development tree with the
> above changes likely today (Aug, 31) night, and prepare the changesets to be
> added at linux-next.
> 

I see that you changed from KEY_KP* to KEY_*, unfortunately this change
will break users who have digits in upper register. KEY_KP* were not
perfect either since they are affected by NumLock state. I would
recommend moving to KEY_NUMERIC_* which should be unaffected by either
register, shift state or NumLock state.

Of course there is an issue of them being absent from most keymaps; but
nothing is perfect in thsi world ;)

-- 
Dmitry

Re: [RFC] Infrared Keycode standardization

[Jarod Wilson]

On Thursday 27 August 2009 18:06:51 Devin Heitmueller wrote:
> On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> Chehab<mchehab@infradead.org> wrote:
> > Em Thu, 27 Aug 2009 21:36:36 +0300
> > Ville Syrjälä <syrjala@sci.fi> escreveu:
> >
> >
> >> I welcome this effort. It would be nice to have some kind of consistent
> >> behaviour between devices. But just limiting the effort to IR devices
> >> doesn't make sense. It shouldn't matter how the device is connected.
> >
> > Agreed.
> >
> >>
> >> FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would
> >> make most sense if FASTFORWARD and REWIND were paired and FORWARD and
> >> BACK were paired. I actually have those two a bit confused in
> >> ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should
> >> be REWIND instead.
> >
> > Makes sense. I updated it at the wiki. I also tried to group the keycodes by
> > function there.
> >
> >> Also I should probably use ZOOM for the maximize/restore button (it's
> >> FRONT now), and maybe SETUP instead of ENTER for another. It has a
> >> picture of a checkbox, Windows software apparently shows a setup menu
> >> when it's pressed.
> >>
> >> There are also a couple of buttons where no keycode really seems to
> >> match. One is the mouse button drag. I suppose I could implement the
> >> drag lock feature in the driver but I'm not sure if that's a good idea.
> >> It would make that button special and unmappable. Currently I have that
> >> mapped to EDIT IIRC.
> >
> > I'm not sure what we should do with those buttons.
> >
> > Probably, the most complete IR spec is the RC5 codes:
> >        http://c6000.spectrumdigital.com/davincievm/revf/files/msp430/rc5_codes.pdf
> > (not sure if this table is complete or accurate, but on a search I did
> > today, this is the one that gave me a better documentation)
> >
> > I suspect that, after solving the most used cases, we'll need to take a better look on it,
> > identifying the missing cases of the real implementations and add them to input.h.
> >
> >> The other oddball button has a picture of a stopwatch (I think, it's
> >> not very clear). Currently it uses COFFEE, but maybe TIMER or something
> >> like that should be added. The Windows software's manual just say it
> >> toggles TV-on-demand, but I have no idea what that actually is.
> >
> > Hmm... Maybe TV-on-demand is another name for pay-per-view?
> >
> >
> >
> > Cheers,
> > Mauro
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> Since we're on the topic of IR support, there are probably a couple of
> other things we may want to be thinking about if we plan on
> refactoring the API at all:
> 
> 1.  The fact that for RC5 remote controls, the tables in ir-keymaps.c
> only have the second byte.  In theory, they should have both bytes
> since the vendor byte helps prevents receiving spurious commands from
> unrelated remote controls.  We should include the ability to "ignore
> the vendor byte" so we can continue to support all the remotes
> currently in the ir-keymaps.c where we don't know what the vendor byte
> should contain.
> 
> 2..  The fact that the current API provides no real way to change the
> mode of operation for the IR receiver, for those receivers that
> support multiple modes (NEC/RC5/RC6).  While you have the ability to
> change the mapping table from userland via the keytable program, there
> is currently no way to tell the IR receiver which mode to operate in.
> 
> One would argue that the above keymaps structure should include new
> fields to indicate what type of remote it is (NEC/RC5/RC6 etc), as
> well as field to indicate that the vendor codes are absent from the
> key mapping for that remote).  Given this, I can change the dib0700
> and em28xx IR receivers to automatically set the IR capture mode
> appropriate based on which remote is in the device profile.

Jon Smirl actually wrote some fully functional proof-of-concept IR
handling code about a year ago, that included auto-detection and auto
decoding of several protocols. Perhaps some of that is relevant and
reusable here? (I still have a copy of the tree here somewhere...)

I've been toying with the notion of extending the input device support
that was added to the lirc_imon driver a bit ago, and add a full key
map that delivers events (we already do this for mouse functionality),
but include the ability to also use the remote and/or receiver in a
raw IR mode with lircd. Wouldn't be terribly difficult I think to do
something similar for the standard MCE remotes and receivers... Just
a simple matter of some time and some code. Unfortunately, I'm a bit
short on the time part right now...

-- 
Jarod Wilson
jarod@wilsonet.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] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Fri, 28 Aug 2009 00:00:54 -0400
Jarod Wilson <jarod@wilsonet.com> escreveu:

> On Thursday 27 August 2009 18:06:51 Devin Heitmueller wrote:
> > On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> > Chehab<mchehab@infradead.org> wrote:
> > > Em Thu, 27 Aug 2009 21:36:36 +0300
> > > Ville Syrjälä <syrjala@sci.fi> escreveu:
> > >
> > >
> > >> I welcome this effort. It would be nice to have some kind of consistent
> > >> behaviour between devices. But just limiting the effort to IR devices
> > >> doesn't make sense. It shouldn't matter how the device is connected.
> > >
> > > Agreed.
> > >
> > >>
> > >> FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would
> > >> make most sense if FASTFORWARD and REWIND were paired and FORWARD and
> > >> BACK were paired. I actually have those two a bit confused in
> > >> ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should
> > >> be REWIND instead.
> > >
> > > Makes sense. I updated it at the wiki. I also tried to group the keycodes by
> > > function there.
> > >
> > >> Also I should probably use ZOOM for the maximize/restore button (it's
> > >> FRONT now), and maybe SETUP instead of ENTER for another. It has a
> > >> picture of a checkbox, Windows software apparently shows a setup menu
> > >> when it's pressed.
> > >>
> > >> There are also a couple of buttons where no keycode really seems to
> > >> match. One is the mouse button drag. I suppose I could implement the
> > >> drag lock feature in the driver but I'm not sure if that's a good idea.
> > >> It would make that button special and unmappable. Currently I have that
> > >> mapped to EDIT IIRC.
> > >
> > > I'm not sure what we should do with those buttons.
> > >
> > > Probably, the most complete IR spec is the RC5 codes:
> > >        http://c6000.spectrumdigital.com/davincievm/revf/files/msp430/rc5_codes.pdf
> > > (not sure if this table is complete or accurate, but on a search I did
> > > today, this is the one that gave me a better documentation)
> > >
> > > I suspect that, after solving the most used cases, we'll need to take a better look on it,
> > > identifying the missing cases of the real implementations and add them to input.h.
> > >
> > >> The other oddball button has a picture of a stopwatch (I think, it's
> > >> not very clear). Currently it uses COFFEE, but maybe TIMER or something
> > >> like that should be added. The Windows software's manual just say it
> > >> toggles TV-on-demand, but I have no idea what that actually is.
> > >
> > > Hmm... Maybe TV-on-demand is another name for pay-per-view?
> > >
> > >
> > >
> > > Cheers,
> > > Mauro
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > 
> > Since we're on the topic of IR support, there are probably a couple of
> > other things we may want to be thinking about if we plan on
> > refactoring the API at all:
> > 
> > 1.  The fact that for RC5 remote controls, the tables in ir-keymaps.c
> > only have the second byte.  In theory, they should have both bytes
> > since the vendor byte helps prevents receiving spurious commands from
> > unrelated remote controls.  We should include the ability to "ignore
> > the vendor byte" so we can continue to support all the remotes
> > currently in the ir-keymaps.c where we don't know what the vendor byte
> > should contain.
> > 
> > 2..  The fact that the current API provides no real way to change the
> > mode of operation for the IR receiver, for those receivers that
> > support multiple modes (NEC/RC5/RC6).  While you have the ability to
> > change the mapping table from userland via the keytable program, there
> > is currently no way to tell the IR receiver which mode to operate in.
> > 
> > One would argue that the above keymaps structure should include new
> > fields to indicate what type of remote it is (NEC/RC5/RC6 etc), as
> > well as field to indicate that the vendor codes are absent from the
> > key mapping for that remote).  Given this, I can change the dib0700
> > and em28xx IR receivers to automatically set the IR capture mode
> > appropriate based on which remote is in the device profile.
> 
> Jon Smirl actually wrote some fully functional proof-of-concept IR
> handling code about a year ago, that included auto-detection and auto
> decoding of several protocols. Perhaps some of that is relevant and
> reusable here? (I still have a copy of the tree here somewhere...)

Yes, it seems interesting. We may try to merge his code at ir-functions.

> I've been toying with the notion of extending the input device support
> that was added to the lirc_imon driver a bit ago, and add a full key
> map that delivers events (we already do this for mouse functionality),
> but include the ability to also use the remote and/or receiver in a
> raw IR mode with lircd. Wouldn't be terribly difficult I think to do
> something similar for the standard MCE remotes and receivers... Just
> a simple matter of some time and some code. Unfortunately, I'm a bit
> short on the time part right now...

Interesting. This could work fine with the IR's that are directly connected to
a GPIO pin at the MCE receivers.



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

Re: [RFC] Infrared Keycode standardization

[Andy Walls]

On Thu, 2009-08-27 at 18:06 -0400, Devin Heitmueller wrote:
> On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> Chehab<mchehab@infradead.org> wrote:
> > Em Thu, 27 Aug 2009 21:36:36 +0300
> > Ville Syrjälä <syrjala@sci.fi> escreveu:

> Since we're on the topic of IR support, there are probably a couple of
> other things we may want to be thinking about if we plan on
> refactoring the API at all:
> 
> 1.  The fact that for RC5 remote controls, the tables in ir-keymaps.c
> only have the second byte.  In theory, they should have both bytes
> since the vendor byte helps prevents receiving spurious commands from
> unrelated remote controls.  We should include the ability to "ignore
> the vendor byte" so we can continue to support all the remotes
> currently in the ir-keymaps.c where we don't know what the vendor byte
> should contain.

Since I uncovered this in my research, I thought I'd share...

RC-6A has a third (or thrid and fouth) byte:

http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/info_rc6_uk.htm

for the "Customer Identifier".

It appears that the mode bits in the header determine if RC-6 (mode 0)
or RC-6A is in use.  The position of the mode bits in the header are
documented here:

http://www.sbprojects.com/knowledge/ir/rc6.htm

I'm guesing some MCE remotes use RC-6A.  When I get CX23888 IR support
to the point of actually working, I'll check both of my MCE remotes.

Regards,
Andy


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

Re: [RFC] Infrared Keycode standardization

[Mauro Carvalho Chehab]

Em Fri, 28 Aug 2009 07:41:22 -0400
Andy Walls <awalls@radix.net> escreveu:

> On Thu, 2009-08-27 at 18:06 -0400, Devin Heitmueller wrote:
> > On Thu, Aug 27, 2009 at 5:58 PM, Mauro Carvalho
> > Chehab<mchehab@infradead.org> wrote:
> > > Em Thu, 27 Aug 2009 21:36:36 +0300
> > > Ville Syrjälä <syrjala@sci.fi> escreveu:
> 
> > Since we're on the topic of IR support, there are probably a couple of
> > other things we may want to be thinking about if we plan on
> > refactoring the API at all:
> > 
> > 1.  The fact that for RC5 remote controls, the tables in ir-keymaps.c
> > only have the second byte.  In theory, they should have both bytes
> > since the vendor byte helps prevents receiving spurious commands from
> > unrelated remote controls.  We should include the ability to "ignore
> > the vendor byte" so we can continue to support all the remotes
> > currently in the ir-keymaps.c where we don't know what the vendor byte
> > should contain.
> 
> Since I uncovered this in my research, I thought I'd share...
> 
> RC-6A has a third (or thrid and fouth) byte:
> 
> http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/info_rc6_uk.htm
> 
> for the "Customer Identifier".
> 
> It appears that the mode bits in the header determine if RC-6 (mode 0)
> or RC-6A is in use.  The position of the mode bits in the header are
> documented here:
> 
> http://www.sbprojects.com/knowledge/ir/rc6.htm
> 
> I'm guesing some MCE remotes use RC-6A.  When I get CX23888 IR support
> to the point of actually working, I'll check both of my MCE remotes.

Andy,

If you look at the get_key functions at ir-kbd-i2c, you'll see that some
remotes (and/or maybe the ir decoding chip) sends code with up to 6 chars (some
bits were used there for keycode sync). So, probably, there are already some
rc6 IR's around.

While it would theoretically be possible to still use
EVIOCGKEYCODE/EVIOCSKEYCODE for handling 24 or 32 bits scan codes at the way I've
proposed, I suspect that this won't scale. In order to get the current keycode
table, userspace needs to do something like:
	for (i = 0; i <= LAST_SCANCODE; i++)
		ioctl(fd, EVIOCGKEYCODE, codes);

On a set operation, it will do about the same loop 4 times - since internally a
set operation also calls a get, and since we need first to clean the entire
table before adding the new codes (so, we'll have 2^32 to 2^34 get/set
operations).

On my tests, with MAX_SCANCODE of 0xffff (the maximum currently supported by
dvb-usb), this happens really fast. Still, this is not an efficient code, since a
real table size is generally lower than 40 scancodes wide, but as keycode table
load is not a frequent operation (generally, it will happen only during boot
time, on a real case), I don't think we should bother with optimizing it for
2^16.

I haven't tested, but I doubt that seeking for a 4 byte scancode would be fast
enough, since it is a wild goose chase to seek for 40 valid codes in the
middle of 2^32 to 2^34 codes, during a keycode table load/save operation.

I can see a few possible solutions for it:

1) send some IR mask to the driver (or hardcode the mask) for the driver to
filter just the valid the IR codes, and use a 16 bit scancode for it. This will
use a strategy similar to what we currently have at ir-common, and could mean
that we'll have to discuss the approach again some years later;

2) create some EVIOCGKEYCODE/EVIOCSKEYCODE variants that will be based on a sequencial
index, not based on scancode.

3) create some table load/save methods at the input system, to allow
changing the entire table at once, maybe using an approach similar to
request_firmware.

Currently, V4L drivers have their IR tables declared as:

u32 ir_table[IR_KEYTAB_SIZE];	/* IR_KEYTAB_SIZE is the size of the scantable, currently 128 */

while dvb-usb (and some other DVB drivers) use:

struct dvb_usb_rc_key {
        u8 custom,data;
        u32 event;
};

In order to implement the second approach, the better would be to use something like:

	struct {
		be32 scancode;
		u32 keycode;
	};

It shouldn't be hard to write a few scripts for doing this conversion for both
DVB and V4L type of tables.

Even if we opt for a different approach, I still think that the better is to
merge "custom" and "data" at scancode, since it would be easier to extend
the number of bits, if later needed.

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