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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gerd Hoffmann <kraxel@xxxxxxxxxx> 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-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux