From: Tom W. <ts...@jo...> - 2004-02-04 00:43:53
|
I've been a "user" of LIRC for over a year, and it works quite well in the environment I'm using it in (control of a box). In looking at the web site (lirc.org) I see that the last "official" release is 0.6.6, and if one looks at the directory, there is a release after that in testing (0.7.0?). The last release was in 2002, and here it is in 2004, and the list abounds with people indicating flaws, new drivers (USB comes to mind) and fixes. While this is all good, and I probably COULD get the "latest" from the CVS repository, maybe it is time for an official release. Is this a reasonable goal? A new release of some sort?? Thanks. Off topic inquiry from this message: I have a keyboard (much like a PC keyboard) that generates IR for keys pressed (and probably released). Is there a configuration file for this?? -- Tom Watson Generic short signature ts...@jo... (I'm at home now) |
From: <li...@ba...> - 2004-02-05 18:03:38
|
Hi! Tom Watson "ts...@jo..." wrote: [...] > Is this a reasonable goal? A new release of some sort?? There's not much use for a release without 2.6 support. Everybody who can help with this is very welcome. [...] > Off topic inquiry from this message: > I have a keyboard (much like a PC keyboard) that generates IR for keys > pressed (and probably released). Is there a configuration file for > this?? It probably does not use remote control protocols. Christoph |
From: Flameeyes <dg...@us...> - 2004-02-05 18:16:10
|
On Thursday 05 February 2004 19:03, Christoph Bartelmus wrote: > There's not much use for a release without 2.6 support. > Everybody who can help with this is very welcome. We can merge my patched drivers for 2.6 with the one in the cvs, so we have the same .c for both versions (like lirc_atiusb driver from Paul Miller). After this, adding support for kbuild is a little step. -- Flameeyes <dg...@us...> You can find LIRC for 2.6 kernels at http://flameeyes.web.ctonet.it/ |
From: <li...@ba...> - 2004-02-06 06:45:34
|
Hi! Flameeyes "dg...@us..." wrote: > On Thursday 05 February 2004 19:03, Christoph Bartelmus wrote: >> There's not much use for a release without 2.6 support. >> Everybody who can help with this is very welcome. > We can merge my patched drivers for 2.6 with the one in the cvs, so we have > the same .c for both versions (like lirc_atiusb driver from Paul Miller). The main point is: the drivers have to compile and work on 2.2 and 2.4 as well. If it were that easy I would have included your patch a long time ago. > After this, adding support for kbuild is a little step. Do you think you can give it a try? Patches welcome. Christoph |
From: Flameeyes <dg...@us...> - 2004-02-06 09:36:15
|
On Thursday 05 February 2004 21:03, Christoph Bartelmus wrote: > The main point is: the drivers have to compile and work on 2.2 and 2.4 > as well. If it were that easy I would have included your patch a long > time ago. I know, but we can use some conditional-code, so it shouldn't be too much trouble I think. I'll take a look for this asap. -- Flameeyes <dg...@us...> You can find LIRC for 2.6 kernels at http://flameeyes.web.ctonet.it/ |
From: Gerd K. <kr...@by...> - 2004-02-06 09:50:10
|
li...@ba... (Christoph Bartelmus) writes: > The main point is: the drivers have to compile and work on 2.2 and 2.4 > as well. If it were that easy I would have included your patch a long > time ago. Do they _really_ have to work on 2.2? According to feedback I get for the stuff I'm maintaining people start to switch over from 2.4 to 2.6 right now, and there was is absolutely *nothing* for 2.2 last months. Even anything older than 2.4.20 is very unusual. I have a old "known-good-on-2.2" bttv tarball available for download with a more-than-one-year-old driver release and that's it. Why not simply point users using old kernels to the old releases? And drop the old cruft from the current drivers? Gerd -- "... und auch das ganze Wochenende oll" -- Wetterbericht auf RadioEins |
From: <li...@ba...> - 2004-02-06 20:36:00
|
Hi! Gerd Knorr "kr...@by..." wrote: [...] >> The main point is: the drivers have to compile and work on 2.2 and 2.4 >> as well. If it were that easy I would have included your patch a long >> time ago. > Do they _really_ have to work on 2.2? [...] > Why not simply point users using old kernels to the old releases? And > drop the old cruft from the current drivers? Of course you are right. I plan to make the next release to be the last one with 2.2 support. Too many new drivers have been included since 0.6.6 to drop support right now. Anyway, there is no big difference in the effort spent to support 2.2, 2.4 and 2.6 compared with just 2.4 and 2.6. Christoph |
From: Gerd K. <kr...@by...> - 2004-02-06 23:20:27
|
li...@ba... (Christoph Bartelmus) writes: > > Why not simply point users using old kernels to the old releases? And > > drop the old cruft from the current drivers? > > Of course you are right. I plan to make the next release to be the last > one with 2.2 support. Too many new drivers have been included since > 0.6.6 to drop support right now. Ok, sounds reasonable. Any concrete plans for the next release already? I certainly will use something newer than the prehistoric 0.6.6 version for the next SuSE release. I'd prefeare a official 0.7 release, but failing that I'll rather go with a cvs snapshot than with 0.6.6. Current state is Flameeyes's 2.6 kernel patches + userspace stuff from cvs. There is one month time from now to get stuff sorted. I also have some wishlist items from a packagers point of view: (1) please split userspace and kernel stuff into separate packages. That would also allow to have multiple kernel packages, one 2.2/2.4 and one 2.6 (with all old stuff dropped) for example. (2) compile time options are evil. The userspace code should just compile all possible drivers into the lircd / ... binaries. The kernel modules should use insmod options instead of CONFIG_* variables for configuration. > Anyway, there is no big difference in the effort spent to support 2.2, > 2.4 and 2.6 compared with just 2.4 and 2.6. Yup, also dropping 2.4 support would simplify things even more ;) Unfortunately this isn't possible right now. 2.6 has some very nice new features: tasklets for example. Using them would basically obsolete the lirc_dev kernel thread helper module. Gerd -- "... und auch das ganze Wochenende oll" -- Wetterbericht auf RadioEins |
From: <li...@ba...> - 2004-02-07 15:26:12
|
Hi! Gerd Knorr "kr...@by..." wrote: [...] > Ok, sounds reasonable. Any concrete plans for the next release > already? No, it will be ready once it's ready. [...] > I certainly will use something newer than the prehistoric 0.6.6 > version for the next SuSE release. I'd prefeare a official 0.7 > release, but failing that I'll rather go with a cvs snapshot than with > 0.6.6. I think any CVS snapshot should be at least as stable as 0.6.6. [...] > I also have some wishlist items from a packagers point of view: > > (1) please split userspace and kernel stuff into separate packages. > That would also allow to have multiple kernel packages, one > 2.2/2.4 and one 2.6 (with all old stuff dropped) for example. Ok, but not very likely to happen anytime soon. > (2) compile time options are evil. The userspace code should just > compile all possible drivers into the lircd / ... binaries. Compare other thread. > The > kernel modules should use insmod options instead of CONFIG_* > variables for configuration. Well, most compile-time settings only should set some default values, which are also run-time configurable. If you have something special in mind, drop me a note or even better send patches. >> Anyway, there is no big difference in the effort spent to support 2.2, >> 2.4 and 2.6 compared with just 2.4 and 2.6. > Yup, also dropping 2.4 support would simplify things even more ;) > Unfortunately this isn't possible right now. 2.6 has some very nice > new features: tasklets for example. Using them would basically > obsolete the lirc_dev kernel thread helper module. lirc_dev should do the file operations and buffer handling, so other drivers don't have to reimplement them each time. Christoph |