linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

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 18:47:46 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Gerd Hoffmann <kraxel@...hat.com>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, jonsmirl@...il.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR  system?

Gerd Hoffmann <kraxel@...hat.com> writes:

> I'd pick a more descriptive name like 'bundled_remote'.
> Maybe an additional attribute could say which protocol the bundled
> remote speaks (rc5, ...), so userspace could do something sensible by
> default even if it has no data about the bundled remote.

This is problematic since there can be more that one remote bundled.
If we export the sensor (tuner etc) name, userspace can make some
decision (or ask the user etc).

The protocol alone won't help - the user will have to teach the system
about the remote anyway. This should be made trivial at least for common
protocols, though.

> Name them by the hardware they are bundled with should work reasonable
> well.

I guess udev can look at parent PCI vendor/device and subsystem
vendor/device for most PCI cases. Ditto with USB. For generic stuff like
TSOP* coupled with a resistor and connected to RS232 port, we can't
guess anyway.

> We also could also provide a list of possible remotes directly via
> sysfs

The kernel has no way to _know_ this information. The policy is better
handled in userland.

>> Anyway, we shouldn't postpone lirc drivers addition due to that.

Actually merging lirc is a prerequisite for a number of changes.
-- 
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/