linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: "jonsmirl@gmail.com" <jonsmirl@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Linux Input <linux-input@vger.kernel.org>,
	Jiri Kosina <jkosina@suse.cz>, Jarod Wilson <jarod@redhat.com>
Subject: Re: ir-core and default IR maps
Date: Mon, 08 Nov 2010 12:11:36 -0200	[thread overview]
Message-ID: <4CD80518.3060401@redhat.com> (raw)
In-Reply-To: <AANLkTinc_SuTrP6E8aoyXxGKEQwu=QRieRPt3z4b6Xn_@mail.gmail.com>

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

  parent reply	other threads:[~2010-11-08 14:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-06 22:08 ir-core and default IR maps jonsmirl
2010-11-07  6:01 ` Dmitry Torokhov
2010-11-07 14:36   ` jonsmirl
2010-11-08  7:23     ` Dmitry Torokhov
2010-11-08 13:09     ` Mauro Carvalho Chehab
2010-11-08 13:34       ` jonsmirl
2010-11-08 13:41         ` jonsmirl
2010-11-08 14:14           ` Mauro Carvalho Chehab
2010-11-09  6:32             ` Dmitry Torokhov
2010-11-09 10:21               ` Mauro Carvalho Chehab
2010-11-10  6:51                 ` Dmitry Torokhov
2010-11-10 13:30                   ` Mauro Carvalho Chehab
2010-11-11  1:37                     ` Dmitry Torokhov
2010-11-09 12:07               ` jonsmirl
2010-11-08 14:11         ` Mauro Carvalho Chehab [this message]
2010-11-08 15:07           ` jonsmirl
2010-11-08 15:38             ` Jarod Wilson
2010-11-08 16:33               ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD80518.3060401@redhat.com \
    --to=mchehab@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jarod@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=jonsmirl@gmail.com \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).