From: <li...@ba...> - 2007-06-16 17:42:43
|
Hi *.*, now that 0.8.2 is released I would like to start working on a couple of things. But as my time currently is very limited I would really appreciate any help from you. The points that need to be fixed are: 1. update the autotools setup for the latest versions of autoconf, automake, libtool, etc. 2. fix lirc_gpio to work with latest kernel versions 3. kernel module clean-up: the final goal should be a kernel integration, but there a several fine-grain steps inbetween, like correct usage of __init, __exit, remove all compile time dependancies, enable support for more than one serial port at a time in lirc_serial, remove 2.4 compatibility code, etc. 4. GUI for irrecord 5. HAL support http://www.freedesktop.org/wiki/Software/hal If anything on the list sounds interesting to you please contact me. Christoph |
From: <loi...@gm...> - 2007-06-17 08:40:15
|
16 Jun 2007 19:40:00 +0200, Christoph Bartelmus <li...@ba...>: > > Hi *.*, Hi ! now that 0.8.2 is released I would like to start working on a couple of > things. But as my time currently is very limited I would really > appreciate any help from you. The points that need to be fixed are: > > 1. update the autotools setup for the latest versions of autoconf, > automake, libtool, etc. > > 2. fix lirc_gpio to work with latest kernel versions > > 3. kernel module clean-up: the final goal should be a kernel > integration, but there a several fine-grain steps inbetween, like > correct usage of __init, __exit, remove all compile time dependancies, > enable support for more than one serial port at a time in lirc_serial, > remove 2.4 compatibility code, etc. > > 4. GUI for irrecord What do you mean for this GUI ? Have you seen my mail about UMC ? I have no response of you, about the new name space. Have you seen my try about an applet for Lirc ? I want to create of team for Lirc in UMC, so I guess we can do some work together. 5. HAL support http://www.freedesktop.org/wiki/Software/hal > > If anything on the list sounds interesting to you please contact me. > > Christoph > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > --=20 Lo=EFc Dardant |
From: <li...@ba...> - 2007-06-17 13:35:17
|
Hi! Lo=EFc Dardant "loi...@gm..." wrote: [...] >> 4. GUI for irrecord > What do you mean for this GUI ? Have you seen my mail about UMC ? > I have no response of you, about the new name space. Have you seen my try > about an applet for Lirc ? > > I want to create of team for Lirc in UMC, so I guess we can do some work > together. What I mean is to simply convert irrecord from a console only program to =20 a more user-friendly GUI based program. I guess the applet you are =20 thinking of is more focussed on lircrc configuration. Well, about the new name space: I think it is a good idea and I support =20 this. Still not fully solved to me is what to do with button names that =20 cannot be mapped to the input name space. Also interesting would be to run your scripts on all remote control =20 definitions on lirc.org, not only the ones bundled in the source =20 tarball. One of the next features I will include in lircd is to provide a lirc =20 based input device using uinput. That means once we have a config file =20 fully based on the input name space, lircd will be able to convert IR =20 input directly to key events that can be received by all applications =20 without further configuration. Cf. my discussion with Jon Smirl on the =20 LKML a while ago. Christoph |
From: <loi...@gm...> - 2007-06-17 20:23:55
|
17 Jun 2007 15:34:00 +0200, Christoph Bartelmus <li...@ba...>: > > Hi! > > Lo=EFc Dardant "loi...@gm..." wrote: > [...] > >> 4. GUI for irrecord > > > What do you mean for this GUI ? Have you seen my mail about UMC ? > > I have no response of you, about the new name space. Have you seen my > try > > about an applet for Lirc ? > > > > I want to create of team for Lirc in UMC, so I guess we can do some wor= k > > together. > > What I mean is to simply convert irrecord from a console only program to > a more user-friendly GUI based program. I guess the applet you are > thinking of is more focussed on lircrc configuration. The applet will give (see for spec https://wiki.ubuntu.com/RemoteControlApplet) the right to run/stop the deamon (lircd). I think it's a bit difficult for some users to open a terminal and write some commands. So this applet for the beginning is just for this. But in the umc team we have some guys motivated to develop/improv= e lirc. So maybe this applet can be an entry for a better tool, wich include something for irrecord and provide a list of remote control that you can choose. What do you think about that ? I'm on holiday (student ;)) so I will start this work very quickly. After the first point (run/stop lircd), I guess we can do more ! So if I have understand, irrecord is simply a program that create a lircd.conf file. It will be very nice if we can do this with a GUI, totaly agree with you. If you have some idea of the GUI, don't hesite to tell me. Well, about the new name space: I think it is a good idea and I support > this. Thanks ;) Still not fully solved to me is what to do with button names that > cannot be mapped to the input name space. Yes it's a big problem. Personnaly I think some of them can be delete, to start with a basic file. Later, users can tell you (lirc), to add others keys. I think you should distribute "official" lircd.conf file for each remote control (when the new name space will be available). You know what I mean ? Also interesting would be to run your scripts on all remote control > definitions on lirc.org, not only the ones bundled in the source > tarball. Yes it's what I called "the full analysis". For the moment we can apply my script to all remote control, but some keys are not traduced and I try to "employ" other guys to help me in this task. One of the next features I will include in lircd is to provide a lirc > based input device using uinput. That means once we have a config file > fully based on the input name space, lircd will be able to convert IR > input directly to key events that can be received by all applications > without further configuration. Cf. my discussion with Jon Smirl on the > LKML a while ago. If I have understand (tell if not), it's what I try. If every remote contro= l are with the new name space, lircrc file can be suppressed no ? because the apps can receive directly the keys define in the name space no? I'm very happy to see that we can work together. I wait your mail ;) Christoph > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > --=20 Lo=EFc Dardant |
From: <loi...@gm...> - 2007-06-21 13:43:23
|
Hi ! Does someone know if there is a way to know that irexec is receiving signal ? It's for the applet that I want to create. Ps: Christophe you don't respond to my mail below. Maybe be you don't have time now. Excuse if me if it's the reason. The applet begins to work (start/stop/reload irexec) 2007/6/17, Lo=EFc Dardant <loi...@gm...>: > > > > 17 Jun 2007 15:34:00 +0200, Christoph Bartelmus <li...@ba...>: > > > > Hi! > > > > Lo=EFc Dardant "loi...@gm..." wrote: > > [...] > > >> 4. GUI for irrecord > > > > > What do you mean for this GUI ? Have you seen my mail about UMC ? > > > I have no response of you, about the new name space. Have you seen my > > try > > > about an applet for Lirc ? > > > > > > I want to create of team for Lirc in UMC, so I guess we can do some > > work > > > together. > > > > What I mean is to simply convert irrecord from a console only program t= o > > a more user-friendly GUI based program. I guess the applet you are > > thinking of is more focussed on lircrc configuration. > > > The applet will give (see for spec > https://wiki.ubuntu.com/RemoteControlApplet) the right to run/stop the > deamon (lircd). I think it's a bit difficult for some users to open a > terminal and write some commands. So this applet for the beginning is jus= t > for this. But in the umc team we have some guys motivated to develop/impr= ove > lirc. So maybe this applet can be an entry for a better tool, wich includ= e > something for irrecord and provide a list of remote control that you can > choose. What do you think about that ? > > I'm on holiday (student ;)) so I will start this work very quickly. After > the first point (run/stop lircd), I guess we can do more ! So if I have > understand, irrecord is simply a program that create a lircd.conf file. I= t > will be very nice if we can do this with a GUI, totaly agree with you. If > you have some idea of the GUI, don't hesite to tell me. > > Well, about the new name space: I think it is a good idea and I support > > this. > > > Thanks ;) > > Still not fully solved to me is what to do with button names that > > cannot be mapped to the input name space. > > > Yes it's a big problem. Personnaly I think some of them can be delete, > to start with a basic file. Later, users can tell you (lirc), to add othe= rs > keys. I think you should distribute "official" lircd.conf file for each > remote control (when the new name space will be available). You know what= I > mean ? > > Also interesting would be to run your scripts on all remote control > > definitions on lirc.org, not only the ones bundled in the source > > tarball. > > > Yes it's what I called "the full analysis". For the moment we can apply m= y > script to all remote control, but some keys are not traduced and I try to > "employ" other guys to help me in this task. > > One of the next features I will include in lircd is to provide a lirc > > based input device using uinput. That means once we have a config file > > fully based on the input name space, lircd will be able to convert IR > > input directly to key events that can be received by all applications > > without further configuration. Cf. my discussion with Jon Smirl on the > > LKML a while ago. > > > If I have understand (tell if not), it's what I try. If every remote > control are with the new name space, lircrc file can be suppressed no ? > because the apps can receive directly the keys define in the name space n= o? > > I'm very happy to see that we can work together. I wait your mail ;) > > Christoph > > > > > > -----------------------------------------------------------------------= -- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > > > > > -- > Lo=EFc Dardant --=20 Lo=EFc Dardant |
From: <li...@ba...> - 2007-06-24 16:27:27
|
Hi! Lo=EFc Dardant "loi...@gm..." wrote: [...] >>>> 4. GUI for irrecord [...] > the first point (run/stop lircd), I guess we can do more ! So if I have > understand, irrecord is simply a program that create a lircd.conf file. It > will be very nice if we can do this with a GUI, totaly agree with you. If > you have some idea of the GUI, don't hesite to tell me. The main point about further work on irrecord is that once we switch =20 over to the new namespace, you should make sure that users actually use =20 the namespace and new config files will only use button names from the =20 namespace. Converting irrecord to a GUI program, or probably even better =20 to make a GUI frontend for it, would make it easier to enforce the use =20 of the new namespace. [...] > Still not fully solved to me is what to do with button names that >> cannot be mapped to the input name space. > Yes it's a big problem. Personnaly I think some of them can be delete, Deleting them is not an option for me. Users should still be able to =20 receive and send these signals, even if there is no valid namespace =20 equivalent for them. Maybe if you analyse the existing config files, then there might be some =20 commonly used names that should be added to the Linux input layer =20 namespace. You should consider that the Linux input layer namespace may =20 need to be extended. > If I have understand (tell if not), it's what I try. If every remote cont= rol > are with the new name space, lircrc file can be suppressed no ? because t= he > apps can receive directly the keys define in the name space no? No, I don't think this will ever happen. The possibilities that lircrc =20 gives you are much more powerful than a simple mapping to keyboard =20 events can ever be. Christoph |
From: <loi...@gm...> - 2007-06-27 12:13:40
|
24 Jun 2007 18:26:00 +0200, Christoph Bartelmus <li...@ba...>: > > Hi! Hi Christoph ! Lo=EFc Dardant "loi...@gm..." wrote: > [...] > >>>> 4. GUI for irrecord > [...] > > the first point (run/stop lircd), I guess we can do more ! So if I have > > understand, irrecord is simply a program that create a lircd.conf file. > It > > will be very nice if we can do this with a GUI, totaly agree with you. > If > > you have some idea of the GUI, don't hesite to tell me. > > The main point about further work on irrecord is that once we switch > over to the new namespace, you should make sure that users actually use > the namespace and new config files will only use button names from the > namespace. Converting irrecord to a GUI program, or probably even better > to make a GUI frontend for it, would make it easier to enforce the use > of the new namespace. I've done some work for this point and I want your opinion (and other opinion obviously !) With my pc, I have some problem with irrecord, it doesn't run, saying me that lircd probably run... So I have decided to try with irw. See my capture here : http://d.gardon.free.fr/vase/Capture-1.png It's a simple GUI. At left, you have the different keys of the new name space (to be sure that users would use it ;)). You press one key and at right you can see in red color "press a button with your remote control". When the user do this, I catch the signal from irw and I print this in gree= n color. There is in the menu "Association". It allows you to add a new key (from a combo box) at the bottom. There is also a Trash icon to delete this association, if you want because for example you have not choose the right key. [...] > > Still not fully solved to me is what to do with button names that > >> cannot be mapped to the input name space. > > > Yes it's a big problem. Personnaly I think some of them can be delete= , > > Deleting them is not an option for me. Users should still be able to > receive and send these signals, even if there is no valid namespace > equivalent for them. > Maybe if you analyse the existing config files, then there might be some > commonly used names that should be added to the Linux input layer > namespace. You should consider that the Linux input layer namespace may > need to be extended. Totaly agree with you. the new script shows some keys for extension (currently 5) > If I have understand (tell if not), it's what I try. If every remote > control > > are with the new name space, lircrc file can be suppressed no ? because > the > > apps can receive directly the keys define in the name space no? > > No, I don't think this will ever happen. The possibilities that lircrc > gives you are much more powerful than a simple mapping to keyboard > events can ever be. > > Christoph Or the apps can provide themselves a lircrc file. If you install keiffeine for example, it put in /usr/lirc/conf/lircrc.kaffeine. It's the idea. What do you think about that ? ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > --=20 Lo=EFc Dardant |
From: <li...@ba...> - 2007-07-01 09:55:58
|
Hi! Lo=EFc Dardant "loi...@gm..." wrote: [4. GUI for irrecord] > I've done some work for this point and I want your opinion (and other > opinion obviously !) Already looks very promising. I would organise the screen a bit differently. Instead of adding buttons for every remote button, I'd make a list of =20 already entered remote button names at the left side. On the right side would be a pull-down list (combo box) of available =20 remote button names with a button to "Add new button" when a name was =20 selected in the pull-down list. But I think it also should be possible =20 for the user to specify a non-standard name here when the namespace does =20 not provide a suitable name. Then there should be a button to record the code for the currently =20 selected remote button. Then we need a button to delete the currently =20 selected remote button name with a dialog if the user is really sure. The code of the currently captured remote button should be displayed =20 somewhere like you already did it in the screenshot. Finally we need to save the currently recorded set. When saving you have to make sure that all remote buttons have a valid =20 code assigned to them. > With my pc, I have some problem with irrecord, it doesn't run, saying me > that lircd probably run... So I have decided to try with irw. You have to stop lircd before running irrecord. [...] > Or the apps can provide themselves a lircrc file. If you install keiffeine > for example, it put in /usr/lirc/conf/lircrc.kaffeine. It's the idea. What > do you think about that ? Yes, that is a good idea. The only reason why this is not done yet is =20 that we don't have a standardised namespace. Christoph |
From: Enrique V. <ev...@it...> - 2007-07-01 10:11:04
|
2007-07-01: Christoph Bartelmus dixit: > Loïc Dardant "loi...@gm..." wrote: > [...] > > Or the apps can provide themselves a lircrc file. If you > > install keiffeine for example, it put in > > /usr/lirc/conf/lircrc.kaffeine. It's the idea. What do you > > think about that ? > > Yes, that is a good idea. The only reason why this is not done yet is > that we don't have a standardised namespace. I don't think /usr/lirc/conf/ is a right place to put config files. If you want to build a dedicated system (or for personal taste whatsoever), you typically want to make /usr read-only. Many embedded systems carry it in this way. Please put all config files under /etc. Cheers, Enrique. |
From: <li...@ba...> - 2007-07-01 12:33:43
|
Hi! Enrique Vidal "ev...@it..." wrote: [...] >>> Or the apps can provide themselves a lircrc file. If you >>> install keiffeine for example, it put in >>> /usr/lirc/conf/lircrc.kaffeine. It's the idea. What do you >>> think about that ? >> >> Yes, that is a good idea. The only reason why this is not done yet is >> that we don't have a standardised namespace. > I don't think /usr/lirc/conf/ is a right place to put config > files. I agree. I was refering to the general idea to provide lircrc templates. =20 The location where to put these files is a different story. Christoph |
From: <loi...@gm...> - 2007-07-01 16:23:12
|
01 Jul 2007 09:52:00 +0200, Christoph Bartelmus <li...@ba...>: > > Hi! Hi ! Lo=EFc Dardant "loi...@gm..." wrote: > [4. GUI for irrecord] > > I've done some work for this point and I want your opinion (and other > > opinion obviously !) > > Already looks very promising. Thanks ;) ! I would organise the screen a bit differently. > Instead of adding buttons for every remote button, I'd make a list of > already entered remote button names at the left side. > On the right side would be a pull-down list (combo box) of available > remote button names with a button to "Add new button" when a name was > selected in the pull-down list. But I think it also should be possible > for the user to specify a non-standard name here when the namespace does > not provide a suitable name. Maybe, but with a big warning, to discourage people. Then there should be a button to record the code for the currently > selected remote button. Then we need a button to delete the currently > selected remote button name with a dialog if the user is really sure. > > The code of the currently captured remote button should be displayed > somewhere like you already did it in the screenshot. > > Finally we need to save the currently recorded set. > When saving you have to make sure that all remote buttons have a valid > code assigned to them. Can you draw me a draft Christoph ? For example with Glade, but very simply just to see clearly what you want. If you have the time evidently. If not tell me. > With my pc, I have some problem with irrecord, it doesn't run, saying me > > that lircd probably run... So I have decided to try with irw. > > You have to stop lircd before running irrecord. Yes but with lircd stop, irrecord oesn't work. Very strange... Is it a problem ? Or is it a good idea to simply use irw ? What do you think ? [...] > > Or the apps can provide themselves a lircrc file. If you install > keiffeine > > for example, it put in /usr/lirc/conf/lircrc.kaffeine. It's the idea. > What > > do you think about that ? > > Yes, that is a good idea. The only reason why this is not done yet is > that we don't have a standardised namespace. For the right place, what I gave was just an example. And it's another story, yes ;) I hope the name space will be accepted ;) ! Christoph > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > --=20 Lo=EFc Dardant |
From: Arnaud Q. <aqu...@gm...> - 2007-06-21 21:08:50
|
16 Jun 2007 19:40:00 +0200, Christoph Bartelmus <li...@ba...>: > Hi *.*, > > now that 0.8.2 is released I would like to start working on a couple of > things. But as my time currently is very limited I would really > appreciate any help from you. The points that need to be fixed are: > > 1. update the autotools setup for the latest versions of autoconf, > automake, libtool, etc. > > 2. fix lirc_gpio to work with latest kernel versions > > 3. kernel module clean-up: the final goal should be a kernel > integration, but there a several fine-grain steps inbetween, like > correct usage of __init, __exit, remove all compile time dependancies, > enable support for more than one serial port at a time in lirc_serial, > remove 2.4 compatibility code, etc. > > 4. GUI for irrecord > > 5. HAL support http://www.freedesktop.org/wiki/Software/hal I will investigate that one. > If anything on the list sounds interesting to you please contact me. 6. namespace standardization completion 7. irrexec applet 8. config gui (linked to point 7?) 9. embed pylirc in the source tree or provide some bindings using SWIG 10. configless lirc (well, might be linked to point 5 or to udev otherwise) -- Arnaud |
From: <li...@ba...> - 2007-06-24 13:46:39
|
Hi! there are still many tasks open on the todo list. Feel free to step =20 forward and take over some of them. There are more than 800 people =20 reading this list. It really should be possible that there are some with =20 the required skills. 1. update the autotools setup --> help required 2. fix lirc_gpio to work with latest kernel versions --> help required 3. kernel module clean-up --> help required 4. GUI for irrecord --> ?Lo=EFc and friends? 5. HAL support --> Arnaud 6. namespace standardization completion --> Lo=EFc, Arnaud, Christoph 7. irrexec applet --> Lo=EFc 8. config gui (linked to point 7?) --> ? 9. embed pylirc in the source tree or provide some bindings using SWIG =20 --> ? 10. configless lirc --> ?Arnaud? Christoph |
From: Arnaud Q. <aqu...@gm...> - 2007-07-30 20:37:24
|
c29ycnkgZm9yIHRoZSBsYWcgZ3V5cywgdG9vIGJ1c3kgd2l0aCByZWFsIGxpZmUuCmp1c3QgYSBz bWFsbCBjaGVja3BvaW50IG9uIHRoZSB3aG9sZSB0YXNrcyBsaXN0Li4uCgpidHcsIHNpbmNlIEkn bSBqdXN0IHNpZ25pbmcgZm9yIGJ1eWluZyBhIGhvbWUsIEknbGwgYmUgZXZlbiBtb3JlIGJ1c3ku CnNvIGlmIHlvdSBzZWUgdG9vIG11Y2ggbGFnIGZyb20gbWUsIGRvbid0IGhlc2l0YXRlIHRvIHBp bmcgbWUuLi4KCjI0IEp1biAyMDA3IDE1OjQ0OjAwICswMjAwLCBDaHJpc3RvcGggQmFydGVsbXVz IDxsaXJjQGJhcnRlbG11cy5kZT46Cj4gSGkhCj4KPiB0aGVyZSBhcmUgc3RpbGwgbWFueSB0YXNr cyBvcGVuIG9uIHRoZSB0b2RvIGxpc3QuIEZlZWwgZnJlZSB0byBzdGVwCj4gZm9yd2FyZCBhbmQg dGFrZSBvdmVyIHNvbWUgb2YgdGhlbS4gVGhlcmUgYXJlIG1vcmUgdGhhbiA4MDAgcGVvcGxlCj4g cmVhZGluZyB0aGlzIGxpc3QuIEl0IHJlYWxseSBzaG91bGQgYmUgcG9zc2libGUgdGhhdCB0aGVy ZSBhcmUgc29tZSB3aXRoCj4gdGhlIHJlcXVpcmVkIHNraWxscy4KPgo+IDEuIHVwZGF0ZSB0aGUg YXV0b3Rvb2xzIHNldHVwIC0tPiBoZWxwIHJlcXVpcmVkCgpzZWVtcyBkb25lCgo+IDIuIGZpeCBs aXJjX2dwaW8gdG8gd29yayB3aXRoIGxhdGVzdCBrZXJuZWwgdmVyc2lvbnMgLS0+IGhlbHAgcmVx dWlyZWQKCnN0aWxsIG5vYm9keSBvbiB0aGF0IG9uZQoKPiAzLiBrZXJuZWwgbW9kdWxlIGNsZWFu LXVwIC0tPiBoZWxwIHJlcXVpcmVkCgpNYXJpbyBMaW1vbmNpZWxsbyBpcyB3b3JraW5nIG9uIHRo YXQgb25lLiBidXQgSSd2ZSBzZWVuIG5vIHVwZGF0ZSBub3IgbGttbCBwb3N0CkBNYXJpbzogYW55 IG5ld3Mgb24gdGhpcz8KCj4gNC4gR1VJIGZvciBpcnJlY29yZCAtLT4gP0xvw69jIGFuZCBmcmll bmRzPwoKdGhlcmUgc2VlbXMgdG8gYmUgYSBsb3Qgb2YgcHJvZ3Jlc3MgaGVyZQoKPiA1LiBIQUwg c3VwcG9ydCAtLT4gQXJuYXVkCgpJJ3ZlIGJlZW4gdGhpbmtpbmcgYSBiaXQgYWJvdXQgdGhhdCBh bmQgdGFsa2luZyB3aXRoIEhBTCBndXlzIC4KCnNpbmNlIGl0IHdpbGwgYmUgbGltaXRlZCB0byBV U0IgZGV2aWNlcywgYXQgbGVhc3Qgd2hpbGUgd2FpdGluZyBmb3IKSEFMIHRvIHN1cHBvcnQgbGVn YWN5IGRldmljZXMsIGFuZCB3b24ndCBiZSB1c2VkIGZvciBldmVudCByZXBvcnRpbmcsCnRoZSBj cmVhdGlvbiBvZiBhbiBmZGkgZmlsZSB0byByZXBvcnQgc3RhdGljIGluZm9ybWF0aW9uIChiYXNp Y2FsbHkgYQpuZXcgaW5wdXQgZGV2aWNlLCB3aXRoIHRoZSBtYW51ZmFjdHVyZXIgYW5kIG1vZGVs IG5hbWUsIGFuZCBhbiBleHRyYQpjYXBhYmlsaXR5ICJpbnB1dC5yZW1vdGUiKSB3b3VsZCBiZSBl bm91Z2ggYXQgZmlyc3QuIEFuZCBhbGwgdGhlCm5lZWRlZCBpbmZvIGFyZSBwcmVzZW50IGluIHRo ZSBkcml2ZXIgKFVTQiBJRHMgYW5kIG1hdGNoaW5nIGluZm8pLgoKSSdsbCB0cnkgdG8gcG9zdCBh IGRldGFpbGVkIHByb3Bvc2l0aW9uIHNvb24uCgo+IDYuIG5hbWVzcGFjZSBzdGFuZGFyZGl6YXRp b24gY29tcGxldGlvbiAtLT4gTG/Dr2MsIEFybmF1ZCwgQ2hyaXN0b3BoCgp0aGUgc2FtZSBnb2Vz IGhlcmUuIEkndmUgdGhvdWdodCBhIGJpdCBtb3JlLCBhbmQgd2lsbCBwb3N0IHNvbWV0aGluZwpz byB0aGF0IHdlIGNhbiB0YWtlIGEgZGVjaXNpb24gYW5kIG1vdmUgYWhlYWQgZm9yIDAuOC4zCgo+ IDcuIGlycmV4ZWMgYXBwbGV0IC0tPiBMb8OvYwoKSSB0aGluayBMb8OvYyBoYXMgbWFkZSBzb21l IHByb2dyZXNzLCBidXQgSSd2ZSBzYWRseSBub3QgaGFkIHRpbWUgdG8KZGlzY3VzcyB3aXRoIGhp bSBmb3IgbG9uZy4uLgoKPiA4LiBjb25maWcgZ3VpIChsaW5rZWQgdG8gcG9pbnQgNz8pIC0tPiA/ CgpATG9pYzogYW55IHByb2dyZXNzIG9uIHRoaXM/CgpJIChvciBvbmUpIHdpbGwgaGF2ZSB0byBj b250YWN0IHRoZSBpcmNvbW1hbmQgZ3V5cyB0byB0YWxrIGEgYml0IGFib3V0CmNyZWF0aW5nIGEg Y2VudHJhbCBsaXJjcmMgcmVwb3NpdG9yeS4KClRoZXJlIHNob3VsZCBhbHNvIGJlIGEgcmVmbGV4 aW9uIHVwb24gR2lyZGVyIGZvciBhZHZhbmNlZCBjb25maWcKKG1heWJlIGxpbmtlZCB0byBpcnJl Y29yZCBHVUk/ISkKCj4gOS4gZW1iZWQgcHlsaXJjIGluIHRoZSBzb3VyY2UgdHJlZSBvciBwcm92 aWRlIHNvbWUgYmluZGluZ3MgdXNpbmcgU1dJRwo+IC0tPiA/CgpTV0lHIHNob3VsZCBiZSBldmFs dWF0ZWQgZm9yIGdlbmVyYXRpbmcgdmFyaW91cyBiaW5kaW5ncy4KbWVhbndoaWxlLCBweWxpcmMg Y2FuIGRvIHRoZSBpbnRlcmltIGFzIGEgc3RhbmRhbG9uZSBzb2Z0d2FyZS4KVGhvdWdoIGVtYmVk ZGluZyBpdCBpbiB0aGUgY29udHJpYiBkaXIgd291bGQgbm90IGJlIGNvc3RseS4KYSBkZWNpc2lv biBpcyBuZWVkZWQgdGhlcmU6IHVwIHRvIHlvdSBDaHJpcy4uLgoKPiAxMC4gY29uZmlnbGVzcyBs aXJjIC0tPiA/QXJuYXVkPwoKbm90IG1hbnkgbmV1cm9ucyBidXJudCB0aGVyZS4gd2VsbCwgb25l IHRoaW5nIGluIGZhY3Q6CmxpbWl0aW5nIHRoZSBzY29wZSB0byBVU0IgZGV2aWNlcyBhZ2Fpbiwg d2UgY2FuIGNyZWF0ZSBhbiBoZWxwZXIgYXBwLgoob3Igc2NyaXB0KSB0byBzZXQgdXAgZXZlcnl0 aGluZyAoZnJvbSBjb25maWcgdG8gbW9kdWxlIHN0YXJ0dXApCmNhbGxlZCBieSB1ZGV2LiBUaGUg YWJvdmUgSEFMIHdvcmsgd2lsbCBiZSByZXVzZWQgaGVyZS4KCmNoZWVycywKQXJuYXVkCi0tIApM aW51eCAvIFVuaXggRXhwZXJ0IC0gTUdFIFVQUyBTWVNURU1TIC0gUiZEIERwdApOZXR3b3JrIFVQ UyBUb29scyAoTlVUKSBQcm9qZWN0IExlYWRlciAtIGh0dHA6Ly93d3cubmV0d29ya3Vwc3Rvb2xz Lm9yZy8KRGViaWFuIERldmVsb3BlciAtIGh0dHA6Ly9wZW9wbGUuZGViaWFuLm9yZy9+YXF1ZXR0 ZS8KT3BlblNvdXJjZSBEZXZlbG9wZXIgLSBodHRwOi8vYXJuYXVkLnF1ZXR0ZS5mcmVlLmZyLwo= |
From: <li...@ba...> - 2008-07-31 11:23:09
|
Hi, I've just gone through the list of todos I posted some time ago. Some points are done already but for most of them I have no idea what is the current status: on 24 Jun 07 at 15:44, you wrote: [...] > 1. update the autotools setup --> help required Done. > 2. fix lirc_gpio to work with latest kernel versions --> help required Kernel patch to re-enable old interface is available. > 3. kernel module clean-up --> help required > 4. GUI for irrecord --> ?Loïc and friends? > 5. HAL support --> Arnaud > 6. namespace standardization completion --> Loïc, Arnaud, Christoph > 7. irrexec applet --> Loïc > 8. config gui (linked to point 7?) --> ? > 9. embed pylirc in the source tree or provide some bindings using SWIG > 10. configless lirc --> ?Arnaud? Status? Christoph |
From: L. D. <loi...@gm...> - 2008-07-31 11:52:10
|
Hi Christoph ! 2008/7/31 Christoph Bartelmus <li...@ba...> > Hi, > > I've just gone through the list of todos I posted some time ago. > Some points are done already but for most of them I have no idea what is > the current status: > > on 24 Jun 07 at 15:44, you wrote: > [...] > > 1. update the autotools setup --> help required > > Done. > > > 2. fix lirc_gpio to work with latest kernel versions --> help required > > Kernel patch to re-enable old interface is available. > > > 3. kernel module clean-up --> help required > > 4. GUI for irrecord --> ?Loïc and friends? I've gave the work to other guy (cha...@gm...). I posted long time ago a mail about that, but unluckily not in this list (don't know why, strange). Don't know if my work has been reused. I can put source on an ftp server if some want to see the source (not finished). > > > 5. HAL support --> Arnaud > > 6. namespace standardization completion --> Loïc, Arnaud, Christoph For this point, i've done my work for the moment. I'm currently waiting from Arnaud. > > > 7. irrexec applet --> Loïc Same as GUI for irrecord. > > > 8. config gui (linked to point 7?) --> ? > > 9. embed pylirc in the source tree or provide some bindings using SWIG > > 10. configless lirc --> ?Arnaud? > > Status? > > Christoph > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > I continue to work on the website Christoph. I will give you some information when i will have something to show you. Hope you're fine. -- Loïc Dardant |
From: <li...@ba...> - 2007-07-15 10:57:52
|
Hi! not much has happened since my last request for help. I'm still looking for people that will help working on some open points =20 on the todo list. Maybe some of you have been scared off by the long list, so this time I =20 would like to take out one point which is the most urgent for me: - update the autotools setup for the latest versions of autoconf, automake, libtool, etc. LIRC still relies on automake-1.5 and autoconf-2.13. Most recent =20 distributions do not provide these versions. If you have some knowledge of automake and autoconf, please consider =20 contributing to this project. Christoph |
From: Laurence D. <ld...@tu...> - 2007-07-15 20:18:30
|
Christoph Bartelmus wrote: > Hi! > > not much has happened since my last request for help. > I'm still looking for people that will help working on some open points > on the todo list. > > Maybe some of you have been scared off by the long list, so this time I > would like to take out one point which is the most urgent for me: > > - update the autotools setup for the latest versions of autoconf, > automake, libtool, etc. Hello everyone, I've done this, and will post patches soon. Laurence |
From: Laurence D. <ld...@tu...> - 2007-07-16 23:20:57
Attachments:
autotools.patch.bz2
|
Second patch, autotools.patch, which applies on top of the first, is the main update. The new autogen.sh is probably needs refining, it's a bit brute force at the moment. Please let me know if anything else needs changing or other updates needed I may have missed. Also it might be worth asking aut...@gn... to review the changes. Anyway, it passes some basic tests, with automake 1.10, autoconf 2.61, libtool 1.59, gcc 4.1.2, linux 2.6.21.3: $ ./autogen.sh configure.ac:8: installing `./missing' configure.ac:8: installing `./install-sh' daemons/Makefile.am: installing `./depcomp' Creating setup-driver.sh ... $ ./setup.sh -> audio_alsa -> run configure $ ./configure --with-driver=all && make clean && make $ ./configure --enable-debug --with-driver=all && make clean && make $ ./configure --enable-debug --with-driver=audio_alsa && make clean && make Laurence |
From: <li...@ba...> - 2007-07-21 13:11:34
|
Hi! Laurence Darby "ld...@tu..." wrote: [...] > Second patch, autotools.patch, which applies on top of the first, is > the main update. The new autogen.sh is probably needs refining, it's a > bit brute force at the moment. Excellent. Everything looks fine here. Thanks a lot for your efforts. I have used autoconf 2.61 and automake 1.9.6. If nobody objects, I will commit the changes to CVS soon. Just one thing: autogen.sh used to have some code that would change the configure script to call setup.sh directly if no parameters are passed to configure. Could you add this to the new autogen.sh script as well? Christoph |
From: Laurence D. <ld...@tu...> - 2007-07-21 16:30:53
|
Christoph Bartelmus wrote: > > Just one thing: autogen.sh used to have some code that would change the > configure script to call setup.sh directly if no parameters are passed > to configure. Could you add this to the new autogen.sh script as well? > Thanks, I missed that as I thought it was old auto* stuff. This patch applies on top of last one, I would respin that except I'm afraid of hitting the 20k size limit again... diff -wu lirc.new/autogen.sh lirc.new2/autogen.sh --- lirc.new/autogen.sh 2007-07-21 16:42:54.000000000 +0100 +++ lirc.new2/autogen.sh 2007-07-21 16:53:08.000000000 +0100 @@ -3,6 +3,24 @@ find -name Makefile.in -exec rm {} \; autoreconf -i -f +TMPFILE=$(mktemp) + +cat >$TMPFILE <<EOF +#!/bin/sh +if test "\$#" = "0"; then + if ! ./setup.sh; then + echo "Please read the documentation!!!" + exit 1 + fi + trap - EXIT + exit 0 +fi + +EOF +cat configure >>$TMPFILE +mv $TMPFILE configure +chmod "u=rwx,g=rx,o=rx" configure + echo "Creating setup-driver.sh ..." ./data2setup.sh > setup-driver.sh |
From: <li...@ba...> - 2007-07-22 08:11:39
|
Hi! Laurence Darby "ld...@tu..." wrote: [...] >> Just one thing: autogen.sh used to have some code that would change the [...] > Thanks, I missed that as I thought it was old auto* stuff. This patch > applies on top of last one, I would respin that except I'm afraid of > hitting the 20k size limit again... Applied. Thanks a lot! Christoph |
From: Laurence D. <ld...@tu...> - 2007-07-16 23:16:10
Attachments:
in_to_ac.patch.bz2
|
Here goes, second attempt after it bounced for being too big... I've tried to split the patches to make it easy to review. First patch, in_to_ac.patch, renames configure.in to configure.ac, fixes all references to configure.ac and updates the generic INSTALL file, because that also fixes a reference. Laurence |
From: <li...@ba...> - 2007-07-22 08:11:39
|
Hi! as this has worked so well last time I again would like to pick out one todo item from the long list that needs some work: - fix lirc_gpio to work with latest kernel versions lirc_gpio does not work in latest kernel versions because some required symbols have been removed from the kernel. Who has the required hardware and can work out a patch? Christoph ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ |
From: <li...@ba...> - 2007-11-01 16:18:54
|
Hi, still lirc_gpio is broken on recent kernel versions. Up to now nobody started any work to fix this. If really nobody is interested in using lirc_gpio, then it will be removed in 0.8.3 release. Christoph on 22 Jul 07 at 09:43, Christoph wrote: > Hi! > > as this has worked so well last time I again would like to pick out one > todo item from the long list that needs some work: > > - fix lirc_gpio to work with latest kernel versions > > lirc_gpio does not work in latest kernel versions because some required > symbols have been removed from the kernel. Who has the required hardware > and can work out a patch? > > Christoph > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ |