ir-core and default IR maps

ir-core and default IR maps

[jonsmirl]

I thought about this some more and I think the default maps should
stay in the drivers. The maps are marked __init so they don't take any
room after they are loaded. This is an important piece and plug and
play and we should keep it. Only the keymaps for default remote
controls that ship with the specific hardware should be included in
the driver. All other keymaps are in user space.

Upsides:
  plug and play
  no requirement to have a user space IR component installed

Downsides:
  compile time - minor and it only impacts developers
  maintaining two copies - one in the kernel source and another in the
user space package. This can be handled via scripts.

If you have user space support installed, you should be able to:
  1) delete/replace the pre-loaded keymaps
  2) load any number of your own maps (receivers should support an
arbitrary number of remotes if the hardware can do it).
  3) use unhandled key events to search through the library of maps to
find the right one and then modify init scripts to load it.

All of the hundred plus in-kernel driver keymaps should also be
duplicated into the user space package. That lets you use these
remotes with other receivers.

Per the discussions at plumbers all decoders that the receiver
supports should be enabled all of the time. If we get data saying this
is a bad idea it can be changed. But disabling multiple drivers does
nothing to improve the performance of another driver. For example if
you have an RC5 remote and you disable the Sony protocol, the decode
error rate on the RC5 decoders is not going to change since the
protocol decoders don't talk to each other. Worst case the command
will decode in both protocols and be filtered by the loaded keymaps.
This is just one less thing for the user to be concerned with. It also
makes the identification of new remotes easier since all of the
protocols will be turned on.  Of course modify this appropriately for
non-general purpose hardware. (Now that Linux supports generate
purpose decoding, vendors can build general purpose receives and save
some money).

-- 
Jon Smirl
jonsmirl@gmail.com

Re: ir-core and default IR maps

[Dmitry Torokhov]

On Sat, Nov 06, 2010 at 06:08:57PM -0400, jonsmirl@gmail.com wrote:
> I thought about this some more and I think the default maps should
> stay in the drivers. The maps are marked __init so they don't take any
> room after they are loaded. This is an important piece and plug and
> play and we should keep it. Only the keymaps for default remote
> controls that ship with the specific hardware should be included in
> the driver. All other keymaps are in user space.
> 

Plug and play does not have to be implemented in kernel and udev is
perfectly capable doing it in userspace for us. Embedded products that
absolutely not want to ship udev and want to limit themselves to a
single vendor-supplied remote will have to adjust their startup scripts
to load the proper keymap.

Keymap in the kernel are needed for devices that are required to boot
(keyboards) - and even then it might be only basic keymap, not the full
multimedia goodness with 300+ distinct keys. I am not accepting any new
mappings for AT keyboard driver and I believe both I and Jiri would like
to delete bunch of HID sub-drivers that only do key remapping.

Attempting to keep keymaps in several places will likely cause them to
diverge, makes user confused where changes should be applied and who is
the authoritative source is, that is why it makes sense to remove them
from the kernel.

Thanks.

-- 
Dmitry

Re: ir-core and default IR maps

[jonsmirl]

On Sun, Nov 7, 2010 at 1:01 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sat, Nov 06, 2010 at 06:08:57PM -0400, jonsmirl@gmail.com wrote:
>> I thought about this some more and I think the default maps should
>> stay in the drivers. The maps are marked __init so they don't take any
>> room after they are loaded. This is an important piece and plug and
>> play and we should keep it. Only the keymaps for default remote
>> controls that ship with the specific hardware should be included in
>> the driver. All other keymaps are in user space.
>>
>
> Plug and play does not have to be implemented in kernel and udev is
> perfectly capable doing it in userspace for us. Embedded products that
> absolutely not want to ship udev and want to limit themselves to a
> single vendor-supplied remote will have to adjust their startup scripts
> to load the proper keymap.

I agree that it doesn't have to be implemented in the kernel. This is
an ease of use decision, not a requirement.

For user space support either the end user has to be aware that after
he buys the MSMCE he also has to install a user space package to make
it work, or the distros always have to install the package.

For the kernel side I only see a maintenance issue. All of the keycode
support is marked _init and vaporizes after boot so there is no
run-time impact.

Another solution could be for the distros to add a distro specific
default udev action that installs the package if the user starts using
IR. This has to be distro specific since they all install things
differently. What we need is a hardware triggered package install
mechanism paralleling what happens with loadmodule. On windows it pops
up and says - search for a driver - we don't have that on any Linux
distribution I've used.

If we don't have something like this the user plugs the new device in
and it doesn't work. Then they have to Google until they figure out
they need to load user space drivers for their specific distro.

>
> Keymap in the kernel are needed for devices that are required to boot
> (keyboards) - and even then it might be only basic keymap, not the full
> multimedia goodness with 300+ distinct keys. I am not accepting any new
> mappings for AT keyboard driver and I believe both I and Jiri would like
> to delete bunch of HID sub-drivers that only do key remapping.
>
> Attempting to keep keymaps in several places will likely cause them to
> diverge, makes user confused where changes should be applied and who is
> the authoritative source is, that is why it makes sense to remove them
> from the kernel.
>
> Thanks.
>
> --
> Dmitry
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: ir-core and default IR maps

[Dmitry Torokhov]

On Sun, Nov 07, 2010 at 09:36:23AM -0500, jonsmirl@gmail.com wrote:
> On Sun, Nov 7, 2010 at 1:01 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Sat, Nov 06, 2010 at 06:08:57PM -0400, jonsmirl@gmail.com wrote:
> >> I thought about this some more and I think the default maps should
> >> stay in the drivers. The maps are marked __init so they don't take any
> >> room after they are loaded. This is an important piece and plug and
> >> play and we should keep it. Only the keymaps for default remote
> >> controls that ship with the specific hardware should be included in
> >> the driver. All other keymaps are in user space.
> >>
> >
> > Plug and play does not have to be implemented in kernel and udev is
> > perfectly capable doing it in userspace for us. Embedded products that
> > absolutely not want to ship udev and want to limit themselves to a
> > single vendor-supplied remote will have to adjust their startup scripts
> > to load the proper keymap.
> 
> I agree that it doesn't have to be implemented in the kernel. This is
> an ease of use decision, not a requirement.

For the user it will be completely transparent (on a sane distribution)
even if keymaps are managed by udev.

> 
> For user space support either the end user has to be aware that after
> he buys the MSMCE he also has to install a user space package to make
> it work, or the distros always have to install the package.

The distributions will install the package, the same way they install
lirc, udev, firmware (you noticed we do not ship most firmware with the
kernel anymore?) and other things.

> 
> For the kernel side I only see a maintenance issue. All of the keycode
> support is marked _init and vaporizes after boot so there is no
> run-time impact.
> 
> Another solution could be for the distros to add a distro specific
> default udev action that installs the package if the user starts using
> IR. This has to be distro specific since they all install things
> differently. What we need is a hardware triggered package install
> mechanism paralleling what happens with loadmodule. On windows it pops
> up and says - search for a driver - we don't have that on any Linux
> distribution I've used.

I'd expect this package either be always installed or marked as a
prerequisite for programs that might use remote controllers (mplayer,
mythtv, etc). Always installed is probably the simplest option.

-- 
Dmitry

Re: ir-core and default IR maps

[Mauro Carvalho Chehab]

Em 07-11-2010 12:36, jonsmirl@gmail.com escreveu:
> On Sun, Nov 7, 2010 at 1:01 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Sat, Nov 06, 2010 at 06:08:57PM -0400, jonsmirl@gmail.com wrote:
>>> I thought about this some more and I think the default maps should
>>> stay in the drivers. The maps are marked __init so they don't take any
>>> room after they are loaded. This is an important piece and plug and
>>> play and we should keep it. Only the keymaps for default remote
>>> controls that ship with the specific hardware should be included in
>>> the driver. All other keymaps are in user space.
>>>
>>
>> Plug and play does not have to be implemented in kernel and udev is
>> perfectly capable doing it in userspace for us. Embedded products that
>> absolutely not want to ship udev and want to limit themselves to a
>> single vendor-supplied remote will have to adjust their startup scripts
>> to load the proper keymap.
> 
> I agree that it doesn't have to be implemented in the kernel. This is
> an ease of use decision, not a requirement.
> 
> For user space support either the end user has to be aware that after
> he buys the MSMCE he also has to install a user space package to make
> it work, or the distros always have to install the package.

IMO, the best solution is to have the package at distros. People need it
anyway, if they want to use webcams, as libv4l (part of v4l-utils) is a
requirement to decode webcam video streams (as most webcams don't use some
proprietary formats, and video applications rely on libv4l to decode those
unusual protocols).

This of course means that distro media packages like mplayer, vlc, lirc,
xine, etc should now require v4l-utils.

> For the kernel side I only see a maintenance issue. All of the keycode
> support is marked _init and vaporizes after boot so there is no
> run-time impact.

Unfortunately, I think that marking as _init won't work, as a device may be
removed/replugged.

> Another solution could be for the distros to add a distro specific
> default udev action that installs the package if the user starts using
> IR. This has to be distro specific since they all install things
> differently. What we need is a hardware triggered package install
> mechanism paralleling what happens with loadmodule. On windows it pops
> up and says - search for a driver - we don't have that on any Linux
> distribution I've used.

It would be an interesting idea, although this is not specific to IR devices.

Yet, I think that, if distros cover the usual cases (e. g. making sure that
v4l-utils will be installed to the media applications), this will cover all
the common cases.

> If we don't have something like this the user plugs the new device in
> and it doesn't work. Then they have to Google until they figure out
> they need to load user space drivers for their specific distro.
> 
>>
>> Keymap in the kernel are needed for devices that are required to boot
>> (keyboards) - and even then it might be only basic keymap, not the full
>> multimedia goodness with 300+ distinct keys. I am not accepting any new
>> mappings for AT keyboard driver and I believe both I and Jiri would like
>> to delete bunch of HID sub-drivers that only do key remapping.
>>
>> Attempting to keep keymaps in several places will likely cause them to
>> diverge, makes user confused where changes should be applied and who is
>> the authoritative source is, that is why it makes sense to remove them
>> from the kernel.

Agreed.

Also, new remote keymap additions happen all the time. By keeping them at kernel
level, this means that an user will need to wait for the next kernel cycle to be
completed, and for the distro to backport those patches.

IMO, having it at an userspace package makes easier for them to use a new keyboard
map.

Cheers,
Mauro

Re: ir-core and default IR maps

[jonsmirl]

On Mon, Nov 8, 2010 at 8:09 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 07-11-2010 12:36, jonsmirl@gmail.com escreveu:
>> On Sun, Nov 7, 2010 at 1:01 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>>> On Sat, Nov 06, 2010 at 06:08:57PM -0400, jonsmirl@gmail.com wrote:
>>>> I thought about this some more and I think the default maps should
>>>> stay in the drivers. The maps are marked __init so they don't take any
>>>> room after they are loaded. This is an important piece and plug and
>>>> play and we should keep it. Only the keymaps for default remote
>>>> controls that ship with the specific hardware should be included in
>>>> the driver. All other keymaps are in user space.
>>>>
>>>
>>> Plug and play does not have to be implemented in kernel and udev is
>>> perfectly capable doing it in userspace for us. Embedded products that
>>> absolutely not want to ship udev and want to limit themselves to a
>>> single vendor-supplied remote will have to adjust their startup scripts
>>> to load the proper keymap.
>>
>> I agree that it doesn't have to be implemented in the kernel. This is
>> an ease of use decision, not a requirement.
>>
>> For user space support either the end user has to be aware that after
>> he buys the MSMCE he also has to install a user space package to make
>> it work, or the distros always have to install the package.
>
> IMO, the best solution is to have the package at distros. People need it
> anyway, if they want to use webcams, as libv4l (part of v4l-utils) is a
> requirement to decode webcam video streams (as most webcams don't use some
> proprietary formats, and video applications rely on libv4l to decode those
> unusual protocols).
>
> This of course means that distro media packages like mplayer, vlc, lirc,
> xine, etc should now require v4l-utils.
>
>> For the kernel side I only see a maintenance issue. All of the keycode
>> support is marked _init and vaporizes after boot so there is no
>> run-time impact.
>
> Unfortunately, I think that marking as _init won't work, as a device may be
> removed/replugged.
>
>> Another solution could be for the distros to add a distro specific
>> default udev action that installs the package if the user starts using
>> IR. This has to be distro specific since they all install things
>> differently. What we need is a hardware triggered package install
>> mechanism paralleling what happens with loadmodule. On windows it pops
>> up and says - search for a driver - we don't have that on any Linux
>> distribution I've used.
>
> It would be an interesting idea, although this is not specific to IR devices.
>
> Yet, I think that, if distros cover the usual cases (e. g. making sure that
> v4l-utils will be installed to the media applications), this will cover all
> the common cases.
>
>> If we don't have something like this the user plugs the new device in
>> and it doesn't work. Then they have to Google until they figure out
>> they need to load user space drivers for their specific distro.
>>
>>>
>>> Keymap in the kernel are needed for devices that are required to boot
>>> (keyboards) - and even then it might be only basic keymap, not the full
>>> multimedia goodness with 300+ distinct keys. I am not accepting any new
>>> mappings for AT keyboard driver and I believe both I and Jiri would like
>>> to delete bunch of HID sub-drivers that only do key remapping.
>>>
>>> Attempting to keep keymaps in several places will likely cause them to
>>> diverge, makes user confused where changes should be applied and who is
>>> the authoritative source is, that is why it makes sense to remove them
>>> from the kernel.
>
> Agreed.
>
> Also, new remote keymap additions happen all the time. By keeping them at kernel
> level, this means that an user will need to wait for the next kernel cycle to be
> completed, and for the distro to backport those patches.

I only want the keymaps for remotes that are bundled with the hardware
to be included in their kernel driver. All other maps would ship in
the user space package. The maps for the bundled remotes would also be
duplicated in the user space package.

To achieve plug and play at least one of four choices has to happen:
1) maps for bundled remotes in the kernel drivers
2) the distros always install the IR remotes map package
3) every app that could possibly use IR adds the map package as a
dependency (may not work for IR keyboards)
4) We figure out some way of implementing the Windows search for
drivers dialog. This could be possible with a udev 'catch all' script.

All four of these will work, but we need to be sure at least one of
them gets implement. If not we end up with the user plugging in the
hardware and Googling to find out why it doesn't work.


>
> IMO, having it at an userspace package makes easier for them to use a new keyboard
> map.
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
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: ir-core and default IR maps

[jonsmirl]

On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> To achieve plug and play at least one of four choices has to happen:

There is another option, the IR maps get integrated into user space
keyboard mapping package. This may be possible with the new
libxkbcommon package.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: ir-core and default IR maps

[Mauro Carvalho Chehab]

Em 08-11-2010 11:41, jonsmirl@gmail.com escreveu:
> On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> To achieve plug and play at least one of four choices has to happen:
> 
> There is another option, the IR maps get integrated into user space
> keyboard mapping package. This may be possible with the new
> libxkbcommon package.

That seems interesting.

Cheers,
Mauro.

Re: ir-core and default IR maps

[Dmitry Torokhov]

On Mon, Nov 08, 2010 at 12:14:48PM -0200, Mauro Carvalho Chehab wrote:
> Em 08-11-2010 11:41, jonsmirl@gmail.com escreveu:
> > On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >> To achieve plug and play at least one of four choices has to happen:
> > 
> > There is another option, the IR maps get integrated into user space
> > keyboard mapping package. This may be possible with the new
> > libxkbcommon package.
> 
> That seems interesting.
> 

I disagree here. libxkbcommon provides X interface while applications
might want to access evdev nodes directly. If anything, parts of
ir-utils dealing with keymap selection should be moved into udev. Maybe
we should split utilities that select protocol from the keymap setting
and use udev keymap utilities to do the task.

Thanks.

-- 
Dmitry

Re: ir-core and default IR maps

[Mauro Carvalho Chehab]

Em 09-11-2010 04:32, Dmitry Torokhov escreveu:
> On Mon, Nov 08, 2010 at 12:14:48PM -0200, Mauro Carvalho Chehab wrote:
>> Em 08-11-2010 11:41, jonsmirl@gmail.com escreveu:
>>> On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> To achieve plug and play at least one of four choices has to happen:
>>>
>>> There is another option, the IR maps get integrated into user space
>>> keyboard mapping package. This may be possible with the new
>>> libxkbcommon package.
>>
>> That seems interesting.
>>
> 
> I disagree here. libxkbcommon provides X interface while applications
> might want to access evdev nodes directly. 

Let me express better: I don't think we should integrate X with the udev tool, 
but, eventually, we could make some X package dependent of v4l-utils. Not sure
if libxkbdcommon is the better way to do it, as I don't have it installed here
on my machines.

> If anything, parts of
> ir-utils dealing with keymap selection should be moved into udev. Maybe
> we should split utilities that select protocol from the keymap setting
> and use udev keymap utilities to do the task.

It doesn't make sense to split keymap and protocol selection. Just loading a
keyboard table but not changing the IR protocol is useless, as the device will
not be selected. Besides that, the tool that do both is really simple (and, btw,
it also allows changing the map for a non-RC device, by using one parameter that
skips the usage of the sysfs nodes at /sys/class/rc):

# ir-keytable -d /dev/input/event4 -r
scancode 0x0000 = KEY_LEFTCTRL (0x1d)
Enabled protocols: 

Cheers,
Mauro

Re: ir-core and default IR maps

[Dmitry Torokhov]

On Tue, Nov 09, 2010 at 08:21:34AM -0200, Mauro Carvalho Chehab wrote:
> Em 09-11-2010 04:32, Dmitry Torokhov escreveu:
> > On Mon, Nov 08, 2010 at 12:14:48PM -0200, Mauro Carvalho Chehab wrote:
> >> Em 08-11-2010 11:41, jonsmirl@gmail.com escreveu:
> >>> On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >>>> To achieve plug and play at least one of four choices has to happen:
> >>>
> >>> There is another option, the IR maps get integrated into user space
> >>> keyboard mapping package. This may be possible with the new
> >>> libxkbcommon package.
> >>
> >> That seems interesting.
> >>
> > 
> > I disagree here. libxkbcommon provides X interface while applications
> > might want to access evdev nodes directly. 
> 
> Let me express better: I don't think we should integrate X with the udev tool, 
> but, eventually, we could make some X package dependent of v4l-utils. Not sure
> if libxkbdcommon is the better way to do it, as I don't have it installed here
> on my machines.
> 
> > If anything, parts of
> > ir-utils dealing with keymap selection should be moved into udev. Maybe
> > we should split utilities that select protocol from the keymap setting
> > and use udev keymap utilities to do the task.
> 
> It doesn't make sense to split keymap and protocol selection. Just loading a
> keyboard table but not changing the IR protocol is useless, as the device will
> not be selected. Besides that, the tool that do both is really simple (and, btw,
> it also allows changing the map for a non-RC device, by using one parameter that
> skips the usage of the sysfs nodes at /sys/class/rc):
> 
> # ir-keytable -d /dev/input/event4 -r
> scancode 0x0000 = KEY_LEFTCTRL (0x1d)
> Enabled protocols: 

OTOH loading keymap and selecting protocol are 2 distinct actions and
udev already has a tool to load keymaps that should also work for all
devices, including remotes.

Basically I do not see the reason for having 2 tools doing pretty much
the same thing.

-- 
Dmitry

Re: ir-core and default IR maps

[Mauro Carvalho Chehab]

Em 10-11-2010 04:51, Dmitry Torokhov escreveu:
> On Tue, Nov 09, 2010 at 08:21:34AM -0200, Mauro Carvalho Chehab wrote:
>> Em 09-11-2010 04:32, Dmitry Torokhov escreveu:
>>> On Mon, Nov 08, 2010 at 12:14:48PM -0200, Mauro Carvalho Chehab wrote:
>>>> Em 08-11-2010 11:41, jonsmirl@gmail.com escreveu:
>>>>> On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>>> To achieve plug and play at least one of four choices has to happen:
>>>>>
>>>>> There is another option, the IR maps get integrated into user space
>>>>> keyboard mapping package. This may be possible with the new
>>>>> libxkbcommon package.
>>>>
>>>> That seems interesting.
>>>>
>>>
>>> I disagree here. libxkbcommon provides X interface while applications
>>> might want to access evdev nodes directly. 
>>
>> Let me express better: I don't think we should integrate X with the udev tool, 
>> but, eventually, we could make some X package dependent of v4l-utils. Not sure
>> if libxkbdcommon is the better way to do it, as I don't have it installed here
>> on my machines.
>>
>>> If anything, parts of
>>> ir-utils dealing with keymap selection should be moved into udev. Maybe
>>> we should split utilities that select protocol from the keymap setting
>>> and use udev keymap utilities to do the task.
>>
>> It doesn't make sense to split keymap and protocol selection. Just loading a
>> keyboard table but not changing the IR protocol is useless, as the device will
>> not be selected. Besides that, the tool that do both is really simple (and, btw,
>> it also allows changing the map for a non-RC device, by using one parameter that
>> skips the usage of the sysfs nodes at /sys/class/rc):
>>
>> # ir-keytable -d /dev/input/event4 -r
>> scancode 0x0000 = KEY_LEFTCTRL (0x1d)
>> Enabled protocols: 
> 
> OTOH loading keymap and selecting protocol are 2 distinct actions and
> udev already has a tool to load keymaps that should also work for all
> devices, including remotes.

How this tool decide what scancode should be associated with a remote controller?
There are, currently, 86 different keytables, one for each known bundled remote,
and the decision about what keymap should be load needs to take some hints provided
via RC sysfs nodes, in order to get the right table.

The two distinct actions are not independent. A keycode table should dictate what 
protocol is needed, as the same device can support more than one protocol, and the
in-hardware decoders will only produce scancodes if the protocol is properly selected.
So, the udev tool needs to do both actions at the same time.

> Basically I do not see the reason for having 2 tools doing pretty much
> the same thing.
 
We may replace the old tool, or merge both tools, but the point is that the
needs are different. For example, for Remote Controllers, before loading a keytable, 
the tool needs to clean-up the previous table, as the bundled keyboard (or a previous keytable
load) may map different scancodes than the ones that exist at the newer table. Then,
it needs to select the protocol and load the new keytable.

Also, for Remote Controllers, kernel provides some additional hints at /sys/class/rc/rc?/uevent,
specifying the name of the real driver that is loading the device and the name of
the bundled remote. Those info should be taken into account, in order to select the
proper keycode table.

On the other side, a tool to change those things at runtime is also needed. So, what I did
to avoid tools duplication is that I've added everything needed by Remote Controllers
at the very same tool, preventing duplication.

Cheers,
Mauro

Re: ir-core and default IR maps

[Dmitry Torokhov]

On Wed, Nov 10, 2010 at 11:30:25AM -0200, Mauro Carvalho Chehab wrote:
> Em 10-11-2010 04:51, Dmitry Torokhov escreveu:
> > On Tue, Nov 09, 2010 at 08:21:34AM -0200, Mauro Carvalho Chehab wrote:
> >> Em 09-11-2010 04:32, Dmitry Torokhov escreveu:
> >>> On Mon, Nov 08, 2010 at 12:14:48PM -0200, Mauro Carvalho Chehab wrote:
> >>>> Em 08-11-2010 11:41, jonsmirl@gmail.com escreveu:
> >>>>> On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >>>>>> To achieve plug and play at least one of four choices has to happen:
> >>>>>
> >>>>> There is another option, the IR maps get integrated into user space
> >>>>> keyboard mapping package. This may be possible with the new
> >>>>> libxkbcommon package.
> >>>>
> >>>> That seems interesting.
> >>>>
> >>>
> >>> I disagree here. libxkbcommon provides X interface while applications
> >>> might want to access evdev nodes directly. 
> >>
> >> Let me express better: I don't think we should integrate X with the udev tool, 
> >> but, eventually, we could make some X package dependent of v4l-utils. Not sure
> >> if libxkbdcommon is the better way to do it, as I don't have it installed here
> >> on my machines.
> >>
> >>> If anything, parts of
> >>> ir-utils dealing with keymap selection should be moved into udev. Maybe
> >>> we should split utilities that select protocol from the keymap setting
> >>> and use udev keymap utilities to do the task.
> >>
> >> It doesn't make sense to split keymap and protocol selection. Just loading a
> >> keyboard table but not changing the IR protocol is useless, as the device will
> >> not be selected. Besides that, the tool that do both is really simple (and, btw,
> >> it also allows changing the map for a non-RC device, by using one parameter that
> >> skips the usage of the sysfs nodes at /sys/class/rc):
> >>
> >> # ir-keytable -d /dev/input/event4 -r
> >> scancode 0x0000 = KEY_LEFTCTRL (0x1d)
> >> Enabled protocols: 
> > 
> > OTOH loading keymap and selecting protocol are 2 distinct actions and
> > udev already has a tool to load keymaps that should also work for all
> > devices, including remotes.
> 
> How this tool decide what scancode should be associated with a remote controller?
> There are, currently, 86 different keytables, one for each known bundled remote,
> and the decision about what keymap should be load needs to take some hints provided
> via RC sysfs nodes, in order to get the right table.

And udev has access to this data, hasn't it? Once proper keymap is
identified the generic tool can load it, it does not matter whether
target device is an RC or a keypad.

> 
> The two distinct actions are not independent. A keycode table should dictate what 
> protocol is needed, as the same device can support more than one protocol, and the
> in-hardware decoders will only produce scancodes if the protocol is properly selected.
> So, the udev tool needs to do both actions at the same time.

Or udev could call 2 utilities. First would select the protocol and
second would load the keymap. This is actually main Unix principle - do
one thing and do it well instead of trying to make a swiss army
knife-type program.

> 
> > Basically I do not see the reason for having 2 tools doing pretty much
> > the same thing.
>  
> We may replace the old tool, or merge both tools, but the point is that the
> needs are different. For example, for Remote Controllers, before loading a keytable, 
> the tool needs to clean-up the previous table, as the bundled keyboard (or a previous keytable
> load) may map different scancodes than the ones that exist at the newer table. Then,
> it needs to select the protocol and load the new keytable.
> 
> Also, for Remote Controllers, kernel provides some additional hints at /sys/class/rc/rc?/uevent,
> specifying the name of the real driver that is loading the device and the name of
> the bundled remote. Those info should be taken into account, in order to select the
> proper keycode table.
> 
> On the other side, a tool to change those things at runtime is also needed. So, what I did
> to avoid tools duplication is that I've added everything needed by Remote Controllers
> at the very same tool, preventing duplication.


See above. But anyway, I think we already spent too much time discussing
this point, if you decide to merge with used - fine, if not - it's OK
too ;)

Thanks.

-- 
Dmitry

Re: ir-core and default IR maps

[jonsmirl]

On Tue, Nov 9, 2010 at 1:32 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Mon, Nov 08, 2010 at 12:14:48PM -0200, Mauro Carvalho Chehab wrote:
>> Em 08-11-2010 11:41, jonsmirl@gmail.com escreveu:
>> > On Mon, Nov 8, 2010 at 8:34 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> >> To achieve plug and play at least one of four choices has to happen:
>> >
>> > There is another option, the IR maps get integrated into user space
>> > keyboard mapping package. This may be possible with the new
>> > libxkbcommon package.
>>
>> That seems interesting.
>>
>
> I disagree here. libxkbcommon provides X interface while applications

You are assuming that libxkbcommon stays X specific. I'm pushing to
turn it into a generic keymapping solution. Wayland sure doesn't want
to inherit all of the baggage of X keymaps. This is also an
opportunity to address internationalization at the console level. This
is an opportunity to clean up the whole key mapping mess in user
space.

Writing a generic keymapping library is a good project if someone is
looking for something to do. It's not too complicated since you can
use libxkbcommon as guidance.

> might want to access evdev nodes directly. If anything, parts of
> ir-utils dealing with keymap selection should be moved into udev. Maybe
> we should split utilities that select protocol from the keymap setting
> and use udev keymap utilities to do the task.
>
> Thanks.
>
> --
> Dmitry
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: ir-core and default IR maps

[Mauro Carvalho Chehab]

Em 08-11-2010 11:34, jonsmirl@gmail.com escreveu:
> On Mon, Nov 8, 2010 at 8:09 AM, Mauro Carvalho Chehab

> I only want the keymaps for remotes that are bundled with the hardware
> to be included in their kernel driver. All other maps would ship in
> the user space package. The maps for the bundled remotes would also be
> duplicated in the user space package.

All current RC maps in kernel are for the bundled hardware. There are, currently,
86 keymaps there. To be consistent, we should break the dibcom tables (there are 2 
"big" tables there, that supports lots of different remotes that came from dib0700 driver.
There are also several dvb-usb drivers that still use their own RC keycodes bundled
inside the driver's source code. So, we have 100+ keycode tables in kernel.

This seems too much to keep synced between kernel and the userspace application.

> To achieve plug and play at least one of four choices has to happen:
> 1) maps for bundled remotes in the kernel drivers
> 2) the distros always install the IR remotes map package
> 3) every app that could possibly use IR adds the map package as a
> dependency (may not work for IR keyboards)

We don't have any IR keyboards right now at RC core. Do you know about any?

> 4) We figure out some way of implementing the Windows search for
> drivers dialog. This could be possible with a udev 'catch all' script.


I like (3). I also think that (4) is a good long-term solution. Some distros
like Fedora and Knoppix are adding some auto-search stuff (like printers,
codec drivers, unknown commands, etc).

I doubt I would have any time to work on (4), but, it shouldn't be hard to write
generic auto-catch udev application that can open a dialog window at the windows
manager, pointing that a newly plugged device requires some additional userspace
package to be installed, in order to work. Of course, it will need to have a way
to specify the command line to install a package (as it will be distro-specific).
I think that it would be possible to have a config file that could explain the
hardware/package dependencies, and the command lines needed to install an
application.

> All four of these will work, but we need to be sure at least one of
> them gets implement. If not we end up with the user plugging in the
> hardware and Googling to find out why it doesn't work.

Yes. I think we should try to make everything working fine for .38 with some distros,
making the in-kernel keytables as deprecated, but giving some time for all distros
to adopt it, before actually removing them.

Cheers,
Mauro

Re: ir-core and default IR maps

[jonsmirl]

On Mon, Nov 8, 2010 at 9:11 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 08-11-2010 11:34, jonsmirl@gmail.com escreveu:
>> On Mon, Nov 8, 2010 at 8:09 AM, Mauro Carvalho Chehab
>
>> I only want the keymaps for remotes that are bundled with the hardware
>> to be included in their kernel driver. All other maps would ship in
>> the user space package. The maps for the bundled remotes would also be
>> duplicated in the user space package.
>
> All current RC maps in kernel are for the bundled hardware. There are, currently,
> 86 keymaps there. To be consistent, we should break the dibcom tables (there are 2
> "big" tables there, that supports lots of different remotes that came from dib0700 driver.
> There are also several dvb-usb drivers that still use their own RC keycodes bundled
> inside the driver's source code. So, we have 100+ keycode tables in kernel.
>
> This seems too much to keep synced between kernel and the userspace application.

You could write a script to do this. Use the user space versions as
master and then generate .h files that get included by the various
receivers. Regenerate on each release and send a single delta to
Linus.

>> To achieve plug and play at least one of four choices has to happen:
>> 1) maps for bundled remotes in the kernel drivers
>> 2) the distros always install the IR remotes map package
>> 3) every app that could possibly use IR adds the map package as a
>> dependency (may not work for IR keyboards)
>
> We don't have any IR keyboards right now at RC core. Do you know about any?

They exist, here are a few. I've only used them in hotel rooms so I'm
not sure how they work.
Some of these are probably IRDA.

http://www.goldmine-elec-products.com/prodinfo.asp?number=G15326&variation=
http://www.markertek.com/Structured-Premise-Wiring/Infrared-Extenders-Receivers/Amino/IR-KEYBOARD.xhtml
http://www.abesofmaine.com/itemB.do?item=SKIRKEYBOARD&id=SKIRKEYBOARD&l=FROOGLE
http://pcmonde.com/index.php?page=shop.product_details&flypage=flypage.tpl&option=com_virtuemart&Itemid=5&product_id=841


>
>> 4) We figure out some way of implementing the Windows search for
>> drivers dialog. This could be possible with a udev 'catch all' script.
>
>
> I like (3). I also think that (4) is a good long-term solution. Some distros
> like Fedora and Knoppix are adding some auto-search stuff (like printers,
> codec drivers, unknown commands, etc).
>
> I doubt I would have any time to work on (4), but, it shouldn't be hard to write
> generic auto-catch udev application that can open a dialog window at the windows
> manager, pointing that a newly plugged device requires some additional userspace
> package to be installed, in order to work. Of course, it will need to have a way
> to specify the command line to install a package (as it will be distro-specific).
> I think that it would be possible to have a config file that could explain the
> hardware/package dependencies, and the command lines needed to install an
> application.

The difficulty of getting all of the distros to build this is why I
thought it was easier to leave the bundled maps in the drivers until
the distros are ready.

>
>> All four of these will work, but we need to be sure at least one of
>> them gets implement. If not we end up with the user plugging in the
>> hardware and Googling to find out why it doesn't work.
>
> Yes. I think we should try to make everything working fine for .38 with some distros,
> making the in-kernel keytables as deprecated, but giving some time for all distros
> to adopt it, before actually removing them.
>
> Cheers,
> Mauro
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: ir-core and default IR maps

[Jarod Wilson]

On Mon, Nov 08, 2010 at 10:07:25AM -0500, jonsmirl@gmail.com wrote:
> On Mon, Nov 8, 2010 at 9:11 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> > Em 08-11-2010 11:34, jonsmirl@gmail.com escreveu:
> >> On Mon, Nov 8, 2010 at 8:09 AM, Mauro Carvalho Chehab
> >
> >> I only want the keymaps for remotes that are bundled with the hardware
> >> to be included in their kernel driver. All other maps would ship in
> >> the user space package. The maps for the bundled remotes would also be
> >> duplicated in the user space package.
> >
> > All current RC maps in kernel are for the bundled hardware. There are, currently,
> > 86 keymaps there. To be consistent, we should break the dibcom tables (there are 2
> > "big" tables there, that supports lots of different remotes that came from dib0700 driver.
> > There are also several dvb-usb drivers that still use their own RC keycodes bundled
> > inside the driver's source code. So, we have 100+ keycode tables in kernel.
> >
> > This seems too much to keep synced between kernel and the userspace application.
> 
> You could write a script to do this. Use the user space versions as
> master and then generate .h files that get included by the various
> receivers. Regenerate on each release and send a single delta to
> Linus.
> 
> >> To achieve plug and play at least one of four choices has to happen:
> >> 1) maps for bundled remotes in the kernel drivers
> >> 2) the distros always install the IR remotes map package
> >> 3) every app that could possibly use IR adds the map package as a
> >> dependency (may not work for IR keyboards)
> >
> > We don't have any IR keyboards right now at RC core. Do you know about any?
> 
> They exist, here are a few. I've only used them in hotel rooms so I'm
> not sure how they work.
> Some of these are probably IRDA.
> 
> http://www.goldmine-elec-products.com/prodinfo.asp?number=G15326&variation=
> http://www.markertek.com/Structured-Premise-Wiring/Infrared-Extenders-Receivers/Amino/IR-KEYBOARD.xhtml
> http://www.abesofmaine.com/itemB.do?item=SKIRKEYBOARD&id=SKIRKEYBOARD&l=FROOGLE
> http://pcmonde.com/index.php?page=shop.product_details&flypage=flypage.tpl&option=com_virtuemart&Itemid=5&product_id=841

I have this one in my possession, with intentions to add support for it:

http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-00004/dp/B000AOAAN8/ref=sr_1_1?ie=UTF8&qid=1289230388&sr=8-1

There's an lirc-mod-mce sourceforge project that support{ed,s} it. Been on
my TODO list for a while to get that integrated into the IR core, probably
as an additional IR protocol decoder that registers its own keyboard and
mouse input devices, rather than piggy-backing on a receiver's remote
device.

> >> 4) We figure out some way of implementing the Windows search for
> >> drivers dialog. This could be possible with a udev 'catch all' script.
> >
> >
> > I like (3). I also think that (4) is a good long-term solution. Some distros
> > like Fedora and Knoppix are adding some auto-search stuff (like printers,
> > codec drivers, unknown commands, etc).

Yeah, this is part of DeviceKit in Fedora-land, iirc. Or some other
BumpyCapsKit. We could certainly add a trigger for installing v4l-utils if
we see an rc class device.

> > I doubt I would have any time to work on (4), but, it shouldn't be hard to write
> > generic auto-catch udev application that can open a dialog window at the windows
> > manager, pointing that a newly plugged device requires some additional userspace
> > package to be installed, in order to work. Of course, it will need to have a way
> > to specify the command line to install a package (as it will be distro-specific).
> > I think that it would be possible to have a config file that could explain the
> > hardware/package dependencies, and the command lines needed to install an
> > application.
> 
> The difficulty of getting all of the distros to build this is why I
> thought it was easier to leave the bundled maps in the drivers until
> the distros are ready.

True, certain fairly popular distros (Ubuntu) apparently don't even have
v4l-utils available in their package repositories yet...

-- 
Jarod Wilson
jarod@redhat.com

Re: ir-core and default IR maps

[Mauro Carvalho Chehab]

Em 08-11-2010 13:38, Jarod Wilson escreveu:
> On Mon, Nov 08, 2010 at 10:07:25AM -0500, jonsmirl@gmail.com wrote:
>> On Mon, Nov 8, 2010 at 9:11 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> Em 08-11-2010 11:34, jonsmirl@gmail.com escreveu:
>>>> On Mon, Nov 8, 2010 at 8:09 AM, Mauro Carvalho Chehab
>>>
>>>> I only want the keymaps for remotes that are bundled with the hardware
>>>> to be included in their kernel driver. All other maps would ship in
>>>> the user space package. The maps for the bundled remotes would also be
>>>> duplicated in the user space package.
>>>
>>> All current RC maps in kernel are for the bundled hardware. There are, currently,
>>> 86 keymaps there. To be consistent, we should break the dibcom tables (there are 2
>>> "big" tables there, that supports lots of different remotes that came from dib0700 driver.
>>> There are also several dvb-usb drivers that still use their own RC keycodes bundled
>>> inside the driver's source code. So, we have 100+ keycode tables in kernel.
>>>
>>> This seems too much to keep synced between kernel and the userspace application.
>>
>> You could write a script to do this. Use the user space versions as
>> master and then generate .h files that get included by the various
>> receivers. Regenerate on each release and send a single delta to
>> Linus.

Such script already exists. It is at v4l-utils/utils/keytable/Makefile. It is easy to
maintain it, provided that we have kernel as the mandatory source, but, as we start
having people using the userspace tool, this may become a real pain to maintain, as
codes/maps can be added on either userspace or kernelspace maps.

>>>> To achieve plug and play at least one of four choices has to happen:
>>>> 1) maps for bundled remotes in the kernel drivers
>>>> 2) the distros always install the IR remotes map package
>>>> 3) every app that could possibly use IR adds the map package as a
>>>> dependency (may not work for IR keyboards)
>>>
>>> We don't have any IR keyboards right now at RC core. Do you know about any?
>>
>> They exist, here are a few. I've only used them in hotel rooms so I'm
>> not sure how they work.

Yes, I saw one of them at Hyatt during LPC, although I didn't test. 

>> Some of these are probably IRDA.
>>
>> http://www.goldmine-elec-products.com/prodinfo.asp?number=G15326&variation=
>> http://www.markertek.com/Structured-Premise-Wiring/Infrared-Extenders-Receivers/Amino/IR-KEYBOARD.xhtml
>> http://www.abesofmaine.com/itemB.do?item=SKIRKEYBOARD&id=SKIRKEYBOARD&l=FROOGLE
>> http://pcmonde.com/index.php?page=shop.product_details&flypage=flypage.tpl&option=com_virtuemart&Itemid=5&product_id=841
> 
> I have this one in my possession, with intentions to add support for it:
> 
> http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-00004/dp/B000AOAAN8/ref=sr_1_1?ie=UTF8&qid=1289230388&sr=8-1
> 
> There's an lirc-mod-mce sourceforge project that support{ed,s} it. Been on
> my TODO list for a while to get that integrated into the IR core, probably
> as an additional IR protocol decoder that registers its own keyboard and
> mouse input devices, rather than piggy-backing on a receiver's remote
> device.

It might be interesting to have an IR keyboard available during boot time, but
such keyboard won't be able to replace a real keyboard, if the BIOS is not capable
of handling it (as you cannot use it while kernel is not initialized). That was
actually one of the arguments that people told me during Helsinki's V4L mini-summit.

Even if we have its keymap in-kernel, it will probably be too late to use it during
boot time. After udev starts, it will behave just like a regular keyboard. So, I
couldn't see any real advantage of having its table in-kernel.

>>>> 4) We figure out some way of implementing the Windows search for
>>>> drivers dialog. This could be possible with a udev 'catch all' script.
>>>
>>>
>>> I like (3). I also think that (4) is a good long-term solution. Some distros
>>> like Fedora and Knoppix are adding some auto-search stuff (like printers,
>>> codec drivers, unknown commands, etc).
> 
> Yeah, this is part of DeviceKit in Fedora-land, iirc. Or some other
> BumpyCapsKit. We could certainly add a trigger for installing v4l-utils if
> we see an rc class device.
> 
>>> I doubt I would have any time to work on (4), but, it shouldn't be hard to write
>>> generic auto-catch udev application that can open a dialog window at the windows
>>> manager, pointing that a newly plugged device requires some additional userspace
>>> package to be installed, in order to work. Of course, it will need to have a way
>>> to specify the command line to install a package (as it will be distro-specific).
>>> I think that it would be possible to have a config file that could explain the
>>> hardware/package dependencies, and the command lines needed to install an
>>> application.
>>
>> The difficulty of getting all of the distros to build this is why I
>> thought it was easier to leave the bundled maps in the drivers until
>> the distros are ready.
> 
> True, certain fairly popular distros (Ubuntu) apparently don't even have
> v4l-utils available in their package repositories yet...
> 

It is sad to hear about that.

Although I started using Linux on Slackware 0.97 (since kernel 1.0 times), and I've moved to 
several different distros along the time, I never used Ubuntu. So, I can't say much about it,
but, from what I've noticed from some articles at LWN, it seems that they're taking a different 
way of doing common things than other distros. I heard there that they have/had plans to replace 
glibc, gnome-terminal and other things by some other solutions. All I know for sure is that 
that they are/were putting drivers/media drivers and the include files at non-standard 
places, as we needed to write some special logic at the out-of-tree building system
because of that.

We don't have any way to dictate how distros will choose their tools, or how they'll 
package their kernel/userspace modules and write their udev rules, but users of those 
distros should try to push the distro maintainers to do the right thing. Yet, I think
that we should add this mandatory requirement at Documentation/Changes. I'll write a patch
for that and submit to LKML, c/c LMML.

In the case of drivers/media, the required requirements are simple. In order for them to
work properly, distros that compile media drivers should be packaging v4l-utils and dvb-apps.

If they don't package those two mandatory userspace tools, their media support will
be broken, or they'll need to reinvent the wheel, writing their own tools for doing
the same thing.

Cheers,
Mauro