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:	Wed, 2 Dec 2009 18:48:24 -0800 (PST)
From:	Trent Piepho <xyzzy@...akeasy.org>
To:	Jon Smirl <jonsmirl@...il.com>
cc:	Jarod Wilson <jarod@...sonet.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jarod Wilson <jarod@...hat.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 Wed, 2 Dec 2009, Jon Smirl wrote:
> > 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.
>
> Actually remotes do have an ID. They all transmit vendor/device pairs
> which is exactly how USB works.

*All* remotes?  That's a bold statement.  I'm sure there are some that
only transmit 8 bits of so of scancode.  I think remotes are more like
hosts on a network than usb or bluetooth devices.  Remotes do not join or
leave a receiver, while things like usb devices do explictly join and leave
the hub.

> >> Now I understand that if 2 remotes send completely identical signals we
> >> won't be able to separate 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.  :)

Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
my tv remote generates one set of scancodes for the numeric keys.  The DVD
remote generates a different set.  The amplifier remote in "tv mode"
generates the same codes as the tv remote, and in "dvd mode" the same codes
as the dvd remote.  From the perspective of the IR receiver there is no
difference between having both the DVD and TV remotes, or using the
aplifier remote to control both devices.

Now, my aplifier remote has a number of modes.  Some control devices I
have, like "vcr mode", and there is nothing I can do about that.  Some,
like "md mode" don't control devices I have.  That means they are free to
do things on the computer.  Someone else with the same remote (or any
number of remotes that use the same protocol and scancodes) might have
different devices.

So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore
"JVC VCR #yyy" yets.  Someone with an MD player and not a VCR would want to
opposite.  Rather than force everyone to create custom keymaps, it's much
easier if we can use the standard keymaps from a database of common remotes
and simply tell mythtv to only use remote #xxx or not to use remote #yyy.

It sounds like you're thinking of a receiver that came bundled with a
remote and that's it.  Not someone with a number of remotes that came with
different pieces of AV gear that they want to use with their computer.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ