From: Axel T. <Axe...@ph...> - 2003-11-23 21:57:39
|
Hi, I am packaging lirc for all non-EOLed RHL/FC distros on http://atrpms.physik.fu-berlin.de/name/lirc/ mostly for myth/mplayer consumers. =46rom a packager's POV it would be nice to have as many drivers build as possible. "any" already gives a few, and I rebuild for several kernel modules. Unfortunately lircd and irrecord seem to build driver dependent, e.g. I have to build them for each driver separately and rename them to lircd-<driver>. Is that necessary? Could there be a switch to have them build all possible hw_* modules (an "all" or "almostall" driver)? AFAICT there are no hardwired settings in these modules (like irq, port etc). The same switch could build all kernel module drivers with default settings. Ideally one would wish the hardwired settings to become kernel module parameters in the far future. Thanks. --=20 Axe...@ph... |
From: Joe S. <jo...@jo...> - 2003-11-23 22:24:41
|
IIRC my CVS snapshot (0.7pre2)'s lircd took a --driver option ... I could be wrong though (maybe I'm misunderstanding). --Joe > Hi, > > I am packaging lirc for all non-EOLed RHL/FC distros on > http://atrpms.physik.fu-berlin.de/name/lirc/ > mostly for myth/mplayer consumers. > > From a packager's POV it would be nice to have as many drivers build > as possible. "any" already gives a few, and I rebuild for several > kernel modules. > > Unfortunately lircd and irrecord seem to build driver dependent, > e.g. I have to build them for each driver separately and rename them > to lircd-<driver>. Is that necessary? Could there be a switch to have > them build all possible hw_* modules (an "all" or "almostall" driver)? > AFAICT there are no hardwired settings in these modules (like irq, > port etc). > > The same switch could build all kernel module drivers with default > settings. Ideally one would wish the hardwired settings to become > kernel module parameters in the far future. > > Thanks. > -- > Axe...@ph... > -- Joe Stump <jo...@jo...> http://www.joestump.net "Label makers are proof God wants Sys Admins to be happy." |
From: Axel T. <Axe...@ph...> - 2003-11-24 11:09:20
|
On Sun, Nov 23, 2003 at 05:19:33PM -0500, Joe Stump wrote: > > I am packaging lirc for all non-EOLed RHL/FC distros on > > http://atrpms.physik.fu-berlin.de/name/lirc/ > > mostly for myth/mplayer consumers. > > > > From a packager's POV it would be nice to have as many drivers build > > as possible. "any" already gives a few, and I rebuild for several > > kernel modules. > > > > Unfortunately lircd and irrecord seem to build driver dependent, > > e.g. I have to build them for each driver separately and rename them > > to lircd-<driver>. > IIRC my CVS snapshot (0.7pre2)'s lircd took a --driver option ... I could > be wrong though (maybe I'm misunderstanding). Yes, it does so, but will work only for the built in drivers. If the configure script didn't include the hw_<driver>.o module, you will not be able to choose it (If I understand this right, please note, that I don't even have any lirc devices, I am packaging on request, e.g. blindly). > > Is that necessary? Could there be a switch to have > > them build all possible hw_* modules (an "all" or "almostall" driver)? > > AFAICT there are no hardwired settings in these modules (like irq, > > port etc). > > > > The same switch could build all kernel module drivers with default > > settings. Ideally one would wish the hardwired settings to become > > kernel module parameters in the far future. Somehow unrelated: The liblirc_client requires a running lircd, e.g. for a package split like lircd/lirc-tools/liblirc/lirc-kmdl liblirc and lirc-tools would require lircd, and lircd would require lirc-kmdl? Thanks. --=20 Axe...@ph... |
From: Axel T. <Axe...@ph...> - 2004-02-05 08:05:42
|
Hi, a wishlist w/o a patch :( could lircd and irrecord be built with all modules linked in? Also could userland builds be separated from kernel module builds? This would make it possible to generate driver independent binaries, so that users need not built their own lirc anymore. Also it would help multiple driver setups, e.g. dual setups could use the same lircd called with different options. Not to speak of packagers that would like to present a complete runs-on-all-hardware solutions :) Thanks! On Sun, Nov 23, 2003 at 10:57:32PM +0100, Axel Thimm wrote: > From a packager's POV it would be nice to have as many drivers build > as possible. "any" already gives a few, and I rebuild for several > kernel modules. >=20 > Unfortunately lircd and irrecord seem to build driver dependent, > e.g. I have to build them for each driver separately and rename them > to lircd-<driver>. Is that necessary? Could there be a switch to have > them build all possible hw_* modules (an "all" or "almostall" driver)? > AFAICT there are no hardwired settings in these modules (like irq, > port etc). >=20 > The same switch could build all kernel module drivers with default > settings. Ideally one would wish the hardwired settings to become > kernel module parameters in the far future. --=20 Axe...@ph... |
From: <li...@ba...> - 2004-02-05 21:35:18
|
Hi! Axel Thimm "Axe...@ph..." wrote: [...] > could lircd and irrecord be built with all modules linked in? Also > could userland builds be separated from kernel module builds? Could you explain in more detail why ./configure --with-driver=any is not enough? Christoph |
From: Axel T. <Axe...@ph...> - 2004-02-06 10:45:36
|
Hi, On Thu, Feb 05, 2004 at 08:21:00PM +0100, Christoph Bartelmus wrote: > Axel Thimm "Axe...@ph..." wrote: > [...] > > could lircd and irrecord be built with all modules linked in? Also > > could userland builds be separated from kernel module builds? >=20 > Could you explain in more detail why > ./configure --with-driver=3Dany > is not enough? Because I am greedy! >8-] :) Seriously, "any will build multiple drivers into lircd and runtime selection will be possible. However, not all drivers are included, so in some cases you will have to select the appropriate driver and not any." This seems to be the case with some popular lirc devices as found on various TV cards. If I add support for Hauppauge I kill Pinnacle, or AverMedia or something else and vice versa. There are many such requests on the mythtv list, but only a few make it to the right list (here). With "any" for example no drivers with kernel modules will be built (lirc_driver=3D"none"). Similar for hw_module, which is more important. Building the kernel modules in multiple passes is less of an issue, but building different lircd/irrecords produce different binaries supporting different drivers (as a different set of hw_modules will be compiled in). I'd like to be able to build a lircd/irrecord with as many hw_modules as possible in them. What I would love is something like =2E/configure ... --with-driver=3Dall --with-kerneldir=3Dnone make userland make install for kernel in 2.4.20 2.4.22 ...; do for kmdldriver in X Y Z ...; do make clean ./configure ... --with-driver=3DXYZ --with-kerneldir=3D/path/to/kernels= rcdir/$kernel make kernel-modules make install done done It would make creating prepackaged lirc binaries a child's play :) --=20 Axe...@ph... |
From: <li...@ba...> - 2004-02-06 20:36:09
|
Hi! Axel Thimm "Axe...@ph..." wrote: [...] >>> could lircd and irrecord be built with all modules linked in? Also >>> could userland builds be separated from kernel module builds? >> >> Could you explain in more detail why >> ./configure --with-driver=any >> is not enough? [...] > This seems to be the case with some popular lirc devices as found on > various TV cards. If I add support for Hauppauge I kill Pinnacle, or > AverMedia or something else and vice versa. That's not really correct. Hauppauge uses the lirc_i2c kernel module, Pinnacle uses a standard serial port interface and AVerMedia needs the lirc_gpio kernel module. lircd needs to include the "default" driver for Hauppauge and AVerMedia cards and the "pctv" driver for the Pinnacle. Both drivers will be included when compiling with "any". [...] > With "any" for example no drivers with kernel modules will be built The kernel modules themselves are not built. That's a difference. [...] > I'd like to be able to build a lircd/irrecord with as many hw_modules > as possible in them. What I would love is something like I think this is already possible and Manuel does it this way for the Debian package AFAIK. Christoph |
From: Axel T. <Axe...@ph...> - 2004-02-07 11:31:54
|
Hi, On Fri, Feb 06, 2004 at 09:13:00PM +0100, Christoph Bartelmus wrote: > Axel Thimm "Axe...@ph..." wrote: > [...] > >>> could lircd and irrecord be built with all modules linked in? Also > >>> could userland builds be separated from kernel module builds? > >> > >> Could you explain in more detail why > >> ./configure --with-driver=3Dany > >> is not enough? > [...] > > This seems to be the case with some popular lirc devices as found on > > various TV cards. If I add support for Hauppauge I kill Pinnacle, or > > AverMedia or something else and vice versa. >=20 > That's not really correct. Hauppauge uses the lirc_i2c kernel module, =20 > Pinnacle uses a standard serial port interface and AVerMedia needs the = =20 > lirc_gpio kernel module. Well, that were examples from real life reported on the mythtv lists. Note that I (unfortunately) have no lirc devices, so I am relying on the users' reports. > lircd needs to include the "default" driver for Hauppauge and AVerMedia = =20 > cards and the "pctv" driver for the Pinnacle. Both drivers will be =20 > included when compiling with "any". "any" for lircd/irrecord only takes into account the basic hw_modules hw_default.o receive.o transmit.o and hw_creative.o serial.o, is this right? So all other hw_modules are left out. A grep of (an old) CVS configure.in version shows: hw_audio.o hw_bte.o hw_caraca.o hw_creative_infracd.o hw_creative.o hw_default.o hw_devinput.o hw_dsp.o hw_irman.o hw_irreal.o hw_livedrive_common.o hw_livedrive_midi.o hw_livedrive_seq.o hw_logitech.o hw_mp3anywhere.o hw_pinsys.o hw_pixelview.o hw_silitek.o hw_slinke.o hw_tira.o hw_udp.o hw_uirt2_common.o hw_uirt2.o hw_uirt2_raw.o receive.o serial.o transmit.o (Doesn't pctv require hw_pinsys.o? "any" would not include that) A driver=3D"full" should add more hw_modules, possible even all, if there are no conflicts. Ideally lirc would not have a compile time switch for chosing the driver, but deal with it only at runtime. > [...] > > With "any" for example no drivers with kernel modules will be built >=20 > The kernel modules themselves are not built. That's a difference. That is not a problem, these can be built in multiple passes (but what's the reason that "any" isn't building them?). > [...] > > I'd like to be able to build a lircd/irrecord with as many hw_modules > > as possible in them. What I would love is something like >=20 > I think this is already possible and Manuel does it this way for the =20 > Debian package AFAIK. (I think) the Debian packages use "any" for lircd/irrecord. --=20 Axe...@ph... |
From: <li...@ba...> - 2004-02-07 15:47:39
|
Hi! Axel Thimm "Axe...@ph..." wrote: [buidling with --with-driver=any] > "any" for lircd/irrecord only takes into account the basic hw_modules > hw_default.o receive.o transmit.o and hw_creative.o serial.o, is this > right? No, "any" will include almost any user-space driver. Drivers that require external libraries might not be built. YMMV. Here's the output from lircd built with "any": > ./lircd --driver=foo Driver `foo' not supported. Supported drivers: audio bte creative creative_infracd default dev/input dsp irman livedrive_midi livedrive_seq logitech mp3anywhere null pinsys pixelview silitek tira udp uirt2 uirt2_raw > So all other hw_modules are left out. No. [...] > (Doesn't pctv require hw_pinsys.o? "any" would not include that) Yes, it does include hw_pinsys.o. If it doesn't, than something is broken. [...] >> The kernel modules themselves are not built. That's a difference. > That is not a problem, these can be built in multiple passes (but > what's the reason that "any" isn't building them?). Manuel has implemented support for "any". Probably he didn't want to build them because he made separate packages for user space applications and kernel modules that are built on demand on Debian AFAIK. Christoph |
From: Axel T. <Axe...@ph...> - 2004-02-08 00:54:25
|
On Fri, Feb 06, 2004 at 09:13:00PM +0100, Christoph Bartelmus wrote: > > This seems to be the case with some popular lirc devices as found on > > various TV cards. If I add support for Hauppauge I kill Pinnacle, or > > AverMedia or something else and vice versa. >=20 > That's not really correct. Hauppauge uses the lirc_i2c kernel module, =20 > Pinnacle uses a standard serial port interface and AVerMedia needs the = =20 > lirc_gpio kernel module. >=20 > lircd needs to include the "default" driver for Hauppauge and AVerMedia = =20 > cards and the "pctv" driver for the Pinnacle. Both drivers will be =20 > included when compiling with "any". On Sat, Feb 07, 2004 at 01:27:00PM +0100, Christoph Bartelmus wrote: > No, "any" will include almost any user-space driver. Drivers that =20 > require external libraries might not be built. YMMV. > Here's the output from lircd built with "any": > > ./lircd --driver=3Dfoo > Driver `foo' not supported. > Supported drivers: > audio > bte > creative > creative_infracd > default > dev/input > dsp > irman > livedrive_midi > livedrive_seq > logitech > mp3anywhere > null > pinsys > pixelview > silitek > tira > udp > uirt2 > uirt2_raw I am a bit lost now, are Hauppauge/Pinnacle/AverMedia supported by "any" (not counting kernel modules) or not? I know I was building lircd with "any" and Hauppauge users complained until I switched to "hauppauge". --=20 Axe...@ph... |
From: <li...@ba...> - 2004-02-08 13:35:19
|
Hi! Axel Thimm "Axe...@ph..." wrote: [...] > I am a bit lost now, are Hauppauge/Pinnacle/AverMedia supported by "any" > (not counting kernel modules) or not? I know I was building lircd with > "any" and Hauppauge users complained until I switched to "hauppauge". Hauppauge works with: lircd --driver=default. Pinnacle works with: lircd --driver=pinsys. Yes, it's confusing. Christoph |
From: Axel T. <Axe...@ph...> - 2004-02-14 08:29:03
|
Hi, OK, following Christoph's advice I have build lirc rpms with rather complete support (all lirc kernel modules in their default configuration, userland with "any") for Red Hat Linux 9,8.0,7.3 and Fedora Core 1: http://atrpms.physik.fu-berlin.de/name/lirc/ It is based on a CVS co from a week ago. Let me know if this work well for you (and for which devices you tested it). --=20 Axe...@ph... |