TX is a completely different history. It has nothing to do with input event
subsystem. So, another approach should be taken for it.
I haven't seen yet a hardware decoder with such parameters, but maybe I just
don't have enough specs here to adjust them. Anyway, one simple way to avoid
resetting the hardware for every new parameter change would be to use a timer
for reset. This way, an userspace application or script that is touching on
several parameters would just send the complete RX init sequence and
after some dozens of milliseconds, the hardware will load the new parameters.
There's an interesting discussion about bitmasks x a list of enumerated values
as a way to represent a bitmask into a series of values on sysfs,
at http://lwn.net/Articles/378219/ (see "A critical look at sysfs attribute values"
article there).
That's said, I'm starting to think that the better is to have some differentiation
there between hardware and software decoders. IMO, software decoders are better
handled with an "enabled" attribute, per software decoder, inside each irrcv.
In the case of hardware decoders, just one attribute is enough to control it. I think
it should be a bitmask parameter, but presented with their aliases, like for example:
$cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
ondemand conservative performance
This is clearly a bitmask, but it is presented as textual values, instead of a
magic number.
So, we may have
/sys/class/irrcv/irrcv0/supported_protocols
as, for example:
RC-5 NEC
and allow setting current_protocol as just "RC-5" or, if the hardware supports
more than one decoder at the same time, as "RC-5 NEC".
--
Cheers,
Mauro
--
