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: <alpine.DEB.2.00.0912121445290.3370@asgard.lang.hm>
Date:	Sat, 12 Dec 2009 14:52:33 -0800 (PST)
From:	david@...g.hm
To:	Krzysztof Halasa <khc@...waw.pl>
cc:	Andy Walls <awalls@...ix.net>, Jon Smirl <jonsmirl@...il.com>,
	Christoph Bartelmus <lirc@...telmus.de>,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, kraxel@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

On Sun, 6 Dec 2009, Krzysztof Halasa wrote:

> Andy Walls <awalls@...ix.net> writes:
>
>> Yes, I agree.  I do not know what percentage of current Linux users are
>> technical vs non-technical, so I cannot gauge the current improtance.
>>
>> I can see the trend line though: as time goes by, the percentage of all
>> linux users that have a technical bent will only get smaller.
>
> This IMHO shouldn't matter. If users can configure their keymaps for
> e.g. games with a graphical utility (and  they easily can), they can do
> the same with their remotes, at least with these using common sane
> protocols. The only thing needed is a good GUI utility. Ergo - it's not
> a kernel issue.
>
> The "default bundled", or PnP, won't work well in comparison to a GUI
> utility, I wouldn't worry about it too much (though adding it to udev
> and co is trivial and we should do it - even if not PnP but asking first
> about the actual remote used).

how is this problem any different from figuring out the keymap of a 
keyboard?

there are many defined keymaps (including cases where keys are labled 
different things on the keyboard but send identical codes)

currently in linux distros the user can either select the keymap, or the 
installer will ask the user to press specific keys (or indicate that they 
don't exist) until the installer can guess the keymap to use.

why would this not work for IR remotes as well?

and just like linux has some default keymaps that it uses that mostly work 
for the common case, there could be default IR keymaps that map the common 
keys for all remotes to the appropriate keycodes. it will mean that by 
default you won't see a difference between a DVD, VCR, DVR, etc play 
button, but it will mean that someone picking up a random remote and 
pointing it at the linux box will probably get minimal functionality.

then with a utility to tweak the keymap (or load a more specific one) the 
user can do better.

this would also integrate very nicely with they 'multimedia keyboards' 
that have lots of buttons on them as well, unless you tell it otherwise, 
play is play is play no matter which play button is pressed.

David Lang
--
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