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]
Date:	Thu, 03 Dec 2009 03:27:45 +0100
From:	hermann pitton <hermann-pitton@...or.de>
To:	Andy Walls <awalls@...ix.net>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jarod Wilson <jarod@...sonet.com>,
	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>, 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


Am Mittwoch, den 02.12.2009, 20:19 -0500 schrieb Andy Walls:
> On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote:
> 
> 
> > 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?
> 
> 
> There are a few features that can be used to distinguish remotes:
> 
> 1. Carrier freq
> 2. Protocol (NEC, Sony, JVC, RC-5...)
> 3. Protocol variant (NEC original, NEC with extended addresses,
> 		     RC-5, RC-5 with exteneded commands,
> 		     RC-6 Mode 0, RC-6 Mode 6B, ...)
> 4. System # or Address sent by the remote (16 bits max, I think)
> 5. Set of possible Commands or Information words sent from the remote.
> 6. Pulse width deviation from standard (mean, variance)
> 
> 
> 1, 5, and 6 are really a sort of "fingerprint" and likely not worth the
> effort, even if you have hardware that can measure things with some
> accuracy.

I don't follow closely enough, but eventually we have (different)
remotes a receiver chip can distinguish in hardware, firmware might be
involved too.

If I don't get it wrong, Dmitry is asking in the first place, how such
sender receiver combinations switch to different emulated digital
information for a bunch of different types of hardware in living rooms.

Starting with RC5, IIRC, there is of course such switch over to another
device around. We are only one more.

To repeat, on such bundled cheapest remotes with some TV/DVB cards
around, there are only some minimal implementations of RC5, likely they
use that protocol even illegally, at least they make chips in use
unidentifiable and this seems to be by will.

So, if some try to implement now the highest level, they are far away
from to know what hardware goes how far with them.

At least fun to see they have some starting point ;)

Cheers,
Hermann


--
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/

Powered by blists - more mailing lists