linux-kernel - Re: [RFC v2] Another approach to IR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <2D11378A-041C-4B56-91FF-3E62F5F19753@wilsonet.com>
Date:	Wed, 2 Dec 2009 15:04:30 -0500
From:	Jarod Wilson <jarod@...sonet.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jarod Wilson <jarod@...hat.com>, Jon Smirl <jonsmirl@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
	j@...nau.net, khc@...waw.pl, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	lirc-list@...ts.sourceforge.net, superm1@...ntu.com,
	Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC v2] Another approach to IR

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.

> 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. :)

-- 
Jarod Wilson
jarod@...sonet.com



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