|
From: <loi...@gm...> - 2007-06-14 16:10:15
|
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 |