Status for LIRC (remote support)

[<loi...@gm...>]

Hi dear members of UMC, Elisa and Lirc !

---  This mail is more for UMC members, but if you want to improve Lirc,
join us !

As told in a previous mail, I want to give a 'picture' of the work done on
Lirc part, the remote control support for ours media center (
https://wiki.ubuntu.com/UbuntuMediaCenterTeam) (
https://wiki.ubuntu.com/RemoteControls). I worked on some points to improve
Lirc with Arnaud (and the Lirc team) :

- Write some specifications of the remote control for UMC
- Think about new functionality to add
- Improve Lirc

For those tasks, I did some works :

1) Lirc signal naming. As told in the wiki page, Lirc works with two files =
:

- lircd.conf : the binding of the IR signal and the key that you would. For
example, a press on "button power" on your remote is generating the signal
0x0000EF12. So you can name this signal in lircd.conf, three examples below
:

button_power    0x0000EF12
power                0x0000EF12
KEY_POWER      0x0000EF12

Maybe you understand the problem. Everyone can write a lircd.conf. The
applications that used Lirc can't provide a Lirc file, because it can't
match every file (every lircd.conf). So the applications use the lircrc
file,

- lircrc : the binding of the keys described on the lircd.conf and the keys
used in some programs. The user must write this file. Example with the
precedent name "KEY_POWER" for Elisa :

begin
    prog =3D elisa
    button =3D KEY_POWER
    config =3D close_key
end

But it the same problem, everyone writes his lircrc file. So a proposition
was to create a common key naming scheme. To do this, I wrote a script in
perl  that analyze the directory of lircd.conf ang give some stats of the
current naming scheme. You can see that at
http://d.gardon.free.fr/vase/lirc/ . It's divide in two part, the light and
full analyze. For the moment, we want to close the light part (only remotes
support by Lirc I guess). The different files (html1, html2) show the stats
and html3 show the new name space, based on the file input.h (include in th=
e
kernel). Now we have about 120 keys, and before about 1127 for 110
definitions of remotes.

I also add a function to the script (./lirc-cns -help for more informations=
)
to convert remote definition with the new name space. We wait for a feedbac=
k
of the Lirc team. But every name are not traduced, and some work can be don=
e
here. We hope that this new naming scheme allow applications to distribute
lircrc_app file, so the user must not write this file (with a standard name
space, every app can match lircd.conf).


2) Parseable compatibility list

LIRC doesn't provide a parseable compatibility list. This would help in:

- creating configuration wizard, for selecting easily the right remote from
a graphical list
- feeding Ubuntu Hardware Database

An other script in bash is used to generate this list. Work done. It's the
first step for a graphical tool for Lirc.


3) Lirc Applet

It is very hard to configure Lirc. For those who have try, run a shell, re
build lirc, run the lircd deamon... isn't very easy for a end user. The ide=
a
is to provide a applet to run easily Lirc :
https://wiki.ubuntu.com/RemoteControlApplet
Some work is done, but it's really the beginning. I try to contact the
leader of kdelirc (it's something like an applet that allow you to configur=
e
lirc), but no reply for the moment :(. Here I need some guys (or girls ;))
to help me.


There are lot of other interesting things with Lirc, like the Drivers
recompilation.

So I think it's team to create a team especially for Lirc/Remote support,
because it's a base of the UMC (imagine a media center without remote.. ;))=
.
I wait for your application for this, everyone is welcome, especially if
you're bored with the spec of the project ;) ! "Close" quickly the part of
remote support will be very nice !!!

See you soon and excuse my perfect english !

--=20
Lo=EFc Dardant