DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        b=M9hXC2Ed2uSqTZmB8n2V+CDUJxURzx5Opq5S1bH8J1IXtyRSTFEX7tQcfYJ37S0N7l
         ggThfokoJDvNyOxau4Xu/zP5+MONmqUZ7k946udxlwmeRhh4HWlUEeHH77+6k+my8/d0
         qbxw/d43+AuIL1PPl7lElNtaQvu+dRuH0KoD8=
Date: Wed, 2 Dec 2009 12:14:05 -0800
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
Message-ID: <20091202201404.GD22689@core.coreip.homeip.net>
References: <4B1567D8.7080007@redhat.com> <20091201201158.GA20335@core.coreip.homeip.net> <4B15852D.4050505@redhat.com> <20091202093803.GA8656@core.coreip.homeip.net> <4B16614A.3000208@redhat.com> <20091202171059.GC17839@core.coreip.homeip.net> <9e4733910912020930t3c9fe973k16fd353e916531a4@mail.gmail.com> <4B16BE6A.7000601@redhat.com> <20091202195634.GB22689@core.coreip.homeip.net> <2D11378A-041C-4B56-91FF-3E62F5F19753@wilsonet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2D11378A-041C-4B56-91FF-3E62F5F19753@wilsonet.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3615
Lines: 74

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/