From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jarod Wilson <jarod@wilsonet.com>
Cc: Jarod Wilson <jarod@redhat.com>, Jon Smirl <jonsmirl@gmail.com>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
Devin Heitmueller <dheitmueller@kernellabs.com>,
Maxim Levitsky <maximlevitsky@gmail.com>,
awalls@radix.net, j@jannau.net, khc@pm.waw.pl,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, lirc-list@lists.sourceforge.net,
superm1@ubuntu.com, Christoph Bartelmus <lirc@bartelmus.de>
Subject: Re: [RFC v2] Another approach to IR
Date: Wed, 2 Dec 2009 12:14:05 -0800 [thread overview]
Message-ID: <20091202201404.GD22689@core.coreip.homeip.net> (raw)
In-Reply-To: <2D11378A-041C-4B56-91FF-3E62F5F19753@wilsonet.com>
On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>
> > On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
> >> On 12/2/09 12:30 PM, Jon Smirl wrote:
> >>>>>> (for each remote/substream that they can recognize).
> >>>>>>>
> >>>>>>> I'm assuming that, by remote, you're referring to a remote receiver (and not to
> >>>>>>> the remote itself), right?
> >>>>>
> >>>>> If we could separate by remote transmitter that would be the best I
> >>>>> think, but I understand that it is rarely possible?
> >>>
> >>> The code I posted using configfs did that. Instead of making apps IR
> >>> aware it mapped the vendor/device/command triplets into standard Linux
> >>> keycodes. Each remote was its own evdev device.
> >>
> >> Note, of course, that you can only do that iff each remote uses distinct
> >> triplets. A good portion of mythtv users use a universal of some sort,
> >> programmed to emulate another remote, such as the mce remote bundled
> >> with mceusb transceivers, or the imon remote bundled with most imon
> >> receivers. I do just that myself.
> >>
> >> Personally, I've always considered the driver/interface to be the
> >> receiver, not the remote. The lirc drivers operate at the receiver
> >> level, anyway, and the distinction between different remotes is made by
> >> the lirc daemon.
> >
> > The fact that lirc does it this way does not necessarily mean it is the
> > most corerct way.
>
> No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way.
>
> > Do you expect all bluetooth input devices be presented
> > as a single blob just because they happen to talk to the sane receiver
> > in yoru laptop? Do you expect your USB mouse and keyboard be merged
> > together just because they end up being serviced by the same host
> > controller? If not why remotes should be any different?
>
> A bluetooth remote has a specific device ID that the receiver has to
> pair with. Your usb mouse and keyboard each have specific device IDs.
> A usb IR *receiver* has a specific device ID, the remotes do not. So
> there's the major difference from your examples.
>
Not exactly... I can have 2 identical USB keyboadrs form the same
manufacturer and they will still be treated separately. BT has session
ID to help distinguish between devices.
> > Now I understand that if 2 remotes send completely identical signals we
> > won't be able to separete them, but in cases when we can I think we
> > should.
>
> I don't have a problem with that, if its a truly desired feature. But
> for the most part, I don't see the point. Generally, you go from
> having multiple remotes, one per device (where "device" is your TV,
> amplifier, set top box, htpc, etc), to having a single universal
> remote that controls all of those devices. But for each device (IR
> receiver), *one* IR command set. The desire to use multiple distinct
> remotes with a single IR receiver doesn't make sense to me. Perhaps
> I'm just not creative enough in my use of IR. :)
Didn't Jon posted his example whith programmable remote pretending to be
several separate remotes (depending on the mode of operation) so that
several devices/applications can be controlled without interfering with
each other?
--
Dmitry
next prev parent reply other threads:[~2009-12-02 20:14 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 15:08 [RFC v2] Another approach to IR Jon Smirl
2009-12-01 15:47 ` Maxim Levitsky
2009-12-01 16:16 ` Jon Smirl
2009-12-01 17:03 ` Mauro Carvalho Chehab
2009-12-01 17:09 ` Devin Heitmueller
2009-12-01 17:29 ` Mauro Carvalho Chehab
2009-12-01 17:54 ` Dmitry Torokhov
2009-12-01 19:00 ` Mauro Carvalho Chehab
2009-12-01 19:27 ` Jon Smirl
2009-12-01 20:11 ` Dmitry Torokhov
2009-12-01 21:05 ` Mauro Carvalho Chehab
2009-12-02 9:38 ` Dmitry Torokhov
2009-12-02 12:44 ` Mauro Carvalho Chehab
2009-12-02 17:10 ` Dmitry Torokhov
2009-12-02 17:30 ` Jon Smirl
2009-12-02 18:23 ` Dmitry Torokhov
2009-12-02 18:57 ` Jon Smirl
2009-12-02 20:54 ` Mauro Carvalho Chehab
2009-12-02 19:22 ` Jarod Wilson
2009-12-02 19:56 ` Dmitry Torokhov
2009-12-02 20:04 ` Jarod Wilson
2009-12-02 20:14 ` Dmitry Torokhov [this message]
2009-12-02 20:23 ` Mauro Carvalho Chehab
2009-12-02 20:53 ` Dmitry Torokhov
2009-12-02 21:13 ` Mauro Carvalho Chehab
2009-12-03 16:03 ` Ferenc Wagner
2009-12-03 16:33 ` Mauro Carvalho Chehab
2009-12-03 16:50 ` Jon Smirl
2009-12-03 17:19 ` Mauro Carvalho Chehab
2009-12-03 17:31 ` Dmitry Torokhov
2009-12-04 16:11 ` Ferenc Wagner
2009-12-02 20:42 ` Jarod Wilson
2009-12-02 20:48 ` Dmitry Torokhov
2009-12-02 20:57 ` Jarod Wilson
2009-12-02 21:12 ` Trent Piepho
2009-12-02 21:28 ` Jarod Wilson
2009-12-02 21:40 ` Mauro Carvalho Chehab
2009-12-03 18:06 ` Krzysztof Halasa
2009-12-03 1:19 ` Andy Walls
2009-12-03 2:27 ` hermann pitton
2009-12-03 0:20 ` Jon Smirl
2009-12-03 2:22 ` Mauro Carvalho Chehab
2009-12-03 5:08 ` Jon Smirl
2009-12-03 11:09 ` Mauro Carvalho Chehab
2009-12-03 18:18 ` Krzysztof Halasa
2009-12-03 20:54 ` Mauro Carvalho Chehab
2009-12-03 2:48 ` Trent Piepho
2009-12-03 4:13 ` Jarod Wilson
2009-12-03 5:18 ` Jon Smirl
2009-12-03 11:20 ` Mauro Carvalho Chehab
2009-12-03 19:48 ` alhaz
2009-12-02 19:33 ` Mauro Carvalho Chehab
2009-12-02 19:50 ` Jon Smirl
2009-12-02 19:58 ` Jon Smirl
2009-12-02 20:47 ` Mauro Carvalho Chehab
2009-12-02 19:55 ` Jarod Wilson
2009-12-03 1:02 ` Andy Walls
2009-12-03 10:00 ` Mauro Carvalho Chehab
2009-12-03 12:02 ` Andy Walls
2009-12-03 11:09 ` Mauro Carvalho Chehab
2009-12-02 20:01 ` Dmitry Torokhov
2009-12-02 15:37 ` Jon Smirl
2009-12-02 17:00 ` Dmitry Torokhov
2009-12-02 11:26 ` Gerd Hoffmann
2009-12-02 12:45 ` Mauro Carvalho Chehab
2009-12-01 17:35 ` Patrick Boettcher
2009-12-01 17:41 ` Mauro Carvalho Chehab
2009-12-01 18:19 ` Jon Smirl
2009-12-01 17:37 ` Mauro Carvalho Chehab
-- strict thread matches above, loose matches on Subject: below --
2009-12-03 19:47 Guus Sliepen
2009-12-03 21:53 ` Jarod Wilson
2009-12-05 11:23 ` Guus Sliepen
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=20091202201404.GD22689@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=awalls@radix.net \
--cc=dheitmueller@kernellabs.com \
--cc=j@jannau.net \
--cc=jarod@redhat.com \
--cc=jarod@wilsonet.com \
--cc=jonsmirl@gmail.com \
--cc=khc@pm.waw.pl \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lirc-list@lists.sourceforge.net \
--cc=lirc@bartelmus.de \
--cc=maximlevitsky@gmail.com \
--cc=mchehab@redhat.com \
--cc=superm1@ubuntu.com \
/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).