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: <m3d439rojj.fsf@intrepid.localdomain>
Date:	Mon, 23 Nov 2009 21:09:36 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	James Mastros <james@...tros.biz>
Cc:	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Jarod Wilson <jarod@...hat.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org,
	Mario Limonciello <superm1@...ntu.com>,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org,
	Janne Grunau <j@...nau.net>,
	Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was:  Re: [PATCH 1/3 v2] lirc core device driver infrastructure

James Mastros <james@...tros.biz> writes:

> (This is the
> difference with a ps2 keyboard -- a ps2 keyboard gets a map assigned
> to it at boottime, so it works out-of-box.  This isn't really possible
> with an IR remote -- though perhaps rc5 is standarized enough, I don't
> think other protocols neccessarly are.)

Even with RC5 this isn't really possible. RC5 specifies several classes
of remotes, and with a typical HTPC scenario the sensor will pick up
more than one remote codeset - e.g. one for the display, one for TV
card, and maybe others (all those codes may be coming from a single
remote). We have no way to know in advance which one code set is for the
PC.

The only thing which we can "preconfigure" is the remote bundled with
the sensor (card etc). And even this can be incorrect. Several sensors
don't came with a remote controller.

I think the default sensor->remote assignment may only make sense in
userspace, while configuring the mapping.


Of course all the above changes when the sensors can't present the
"raw" data (IR on/off) but does all the decoding internally (and for
example can't decode all RC5 but only keys used on its remote). In such
unfortunate cases it has to go to the input layer directly.

> Userspace would have to load a keymap; those don't really belong in
> kernel code.  Of course, userspace could look at the device
> identifiers to pick a reasonable default keymap if it's not configured
> to load another, solving the out-of-box experince.

Precisely.
-- 
Krzysztof Halasa
--
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