this is the continuation of a thread started a long time ago (in a
galaxy not so far away ;) ):
This time, I will address each point separately, starting with the key
namespace. Also, this time I have some help (thanks to Loic Dardant),
and another interest
Well, the LIRC namespace issue is well known:
- there is no common namespace to describe the keys in lircd.conf files.
- there is so a wide variety of names defined in the various
lircd.conf files existing, all for the same key. For example, the play
button can be named
* "PLAY" (streamzap),
* "PLAY_DOWN" and "PLAY_UP" (animax),
* "Play" (mceusb), ...
There are some interesting stats there:
- 104 remote definitions,
- 1073 unique key names (in case insensitive: 830)
This lack of standard has the major drawback to force a user to create
a new lircrc file which matches his remote's signal names and the
desired actions, which stops most basic user.
This also make the creation of configuration GUIs for LIRC a really hard task.
This finally do not allow remote makers to ship an LIRC conf with
their devices and officially support LIRC.
I will propose a RFC soon to begin discussion, but need the following
to be answered first:
1) the general keyname: complete name, abrev, or symbol
ie: Forward, Fwd, >>
I'm personaly for the complete, with an exception for:
- numbers: 0 to 9
- special symbols such as # * .
2) case: upper, lower or mixed (lower with upper for the first letter).
ie: FORWARD, forward, Forward
I'm personaly for the mixed.
3) separator: case, underscore, ...
ie: FastForward, FAST_FORWARD, ...
I'm personaly for the case.
4) Some remote have both <button>_UP and <button>_DOWN signals.
What to do with these. Duplicate the signal, or keep only one (the down one)?
Comments and feedback welcome.
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/