linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Devin Heitmueller <dheitmueller@kernellabs.com>
To: Trent Piepho <xyzzy@speakeasy.org>
Cc: Peter Brouwer <pb.maillists@googlemail.com>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Linux Input <linux-input@vger.kernel.org>
Subject: Re: [RFC] Infrared Keycode standardization
Date: Thu, 27 Aug 2009 14:34:11 -0400	[thread overview]
Message-ID: <829197380908271134q26b2d44eg2e8c87a844d2b0b5@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0908271124470.11911@shell2.speakeasy.net>

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

  reply	other threads:[~2009-08-27 18:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-27  7:57 [RFC] Infrared Keycode standardization Mauro Carvalho Chehab
2009-08-27 17:06 ` Peter Brouwer
2009-08-27 17:12   ` Jarod Wilson
2009-08-27 17:17   ` Devin Heitmueller
2009-08-27 18:29     ` Trent Piepho
2009-08-27 18:34       ` Devin Heitmueller [this message]
2009-08-27 19:28         ` Mauro Carvalho Chehab
2009-08-27 19:32     ` Mauro Carvalho Chehab
2009-08-27 20:17   ` Dmitry Torokhov
2009-08-27 21:43   ` semiRocket
2009-08-27 18:36 ` Ville Syrjälä
2009-08-27 20:15   ` Dmitry Torokhov
2009-08-27 22:03     ` Mauro Carvalho Chehab
2009-08-27 21:58   ` Mauro Carvalho Chehab
2009-08-27 22:06     ` Devin Heitmueller
2009-08-28  3:46       ` Mauro Carvalho Chehab
2009-08-28  7:14         ` Mauro Carvalho Chehab
2009-08-28 10:13           ` Peter Brouwer
2009-08-28 12:36             ` Mauro Carvalho Chehab
2009-08-28 14:22             ` Alistair Buxton
2009-08-28 10:50           ` Patrick Boettcher
2009-08-28 12:30             ` Mauro Carvalho Chehab
2009-08-29 18:45               ` Mauro Carvalho Chehab
2009-08-31  5:47                 ` Mauro Carvalho Chehab
2009-09-01  1:38                   ` Dmitry Torokhov
2009-08-28  4:00       ` Jarod Wilson
2009-08-28 14:05         ` Mauro Carvalho Chehab
2009-08-28 11:41       ` Andy Walls
2009-08-28 14:02         ` 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=829197380908271134q26b2d44eg2e8c87a844d2b0b5@mail.gmail.com \
    --to=dheitmueller@kernellabs.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=pb.maillists@googlemail.com \
    --cc=xyzzy@speakeasy.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).