Re: [PATCH] lirc: remove backwards compatibility macro obfuscation
Hi Vincent, on 02 Feb 07 at 12:04, you wrote: > On 2/2/07, Pekka J Enberg <[EMAIL PROTECTED]> wrote: >> From: Pekka Enberg <[EMAIL PROTECTED]> >> [...] >> drivers/lirc_atiusb/lirc_atiusb.c | 102 - > ^^ > > I may be mistaken, but the lirc_atiusb module looks redondant with > the driver already in drivers/usb/input/ati_remote.c. > Moreover, I was under the impression that the input layer was > currently considered the "right way" to implement the kernel side lirc > needs No. Using the input layer makes no sense for most lirc drivers. The hardare used does not decode the IR signals itself but only provides raw signal timings. Those signals are decoded in userspace by lircd. It would be a really bad idea trying to do this decoding in kernel space. Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lirc: remove backwards compatibility macro obfuscation
Hi Pekka, on 02 Feb 07 at 10:39, you wrote: [...] > On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> > wrote: >> Any help welcome. > Here's a start. As I'm running a 2.4 kernel myself you will probably understand that I am a bit reluctant to drop 2.4 support from LIRC right now. Possible ways to handle this: 1. lirc-0.8.2 will be the last release officially supporting 2.4. I remove backwards compatibility after this release. 2. I create a CVS branch for 2.6 only version. Drawbacks of 1.: also support for some older 2.6 kernels would have to be dropped as there have been API changes in 2.6 kernels. Drawbacks of 2.: have to maintain 2 branches in parallel for some time. But before continuing to discuss the further procedure and minor code optimisations you should know which major changes need to be done to LIRC drivers before thinking of a merge to the kernel: 1. LIRC requires an official device major number! A minor number system should be defined. 2. Some of the drivers need to be rewritten to support more than one device at a time. Esp. lirc_serial needs to be rewritten to handle more than one serial port in parallel. Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lirc: remove backwards compatibility macro obfuscation
Hi Pekka, on 02 Feb 07 at 10:39, you wrote: [...] On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus [EMAIL PROTECTED] wrote: Any help welcome. Here's a start. As I'm running a 2.4 kernel myself you will probably understand that I am a bit reluctant to drop 2.4 support from LIRC right now. Possible ways to handle this: 1. lirc-0.8.2 will be the last release officially supporting 2.4. I remove backwards compatibility after this release. 2. I create a CVS branch for 2.6 only version. Drawbacks of 1.: also support for some older 2.6 kernels would have to be dropped as there have been API changes in 2.6 kernels. Drawbacks of 2.: have to maintain 2 branches in parallel for some time. But before continuing to discuss the further procedure and minor code optimisations you should know which major changes need to be done to LIRC drivers before thinking of a merge to the kernel: 1. LIRC requires an official device major number! A minor number system should be defined. 2. Some of the drivers need to be rewritten to support more than one device at a time. Esp. lirc_serial needs to be rewritten to handle more than one serial port in parallel. Christoph - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lirc: remove backwards compatibility macro obfuscation
Hi Vincent, on 02 Feb 07 at 12:04, you wrote: On 2/2/07, Pekka J Enberg [EMAIL PROTECTED] wrote: From: Pekka Enberg [EMAIL PROTECTED] [...] drivers/lirc_atiusb/lirc_atiusb.c | 102 - ^^ I may be mistaken, but the lirc_atiusb module looks redondant with the driver already in drivers/usb/input/ati_remote.c. Moreover, I was under the impression that the input layer was currently considered the right way to implement the kernel side lirc needs No. Using the input layer makes no sense for most lirc drivers. The hardare used does not decode the IR signals itself but only provides raw signal timings. Those signals are decoded in userspace by lircd. It would be a really bad idea trying to do this decoding in kernel space. Christoph - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
On Wed, 31 Jan 2007 21:20:06 +0100 Greg KH wrote: > On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote: >> I'd really love if the same offer was extended to GPL out-of-tree >> driver trees. > > This kind of offer has _always_ been there for out-of-tree GPL > drivers. I have contacted many different groups and driver authors > over the years to offer my help in trying to get their code into the > mainline kernel. > > Some take me up on the offer, others ignore it, and still others > activly refuse to do so, saying they want to stay out-of-the tree > (lirc is one of these examples...) I'm the LIRC maintainer. I don't know what let's you think LIRC wants to stay out-of-the-tree. I just made clear that I don't have the time to do the merging of LIRC drivers to the kernel myself. In fact a lot of work still needs to be done before LIRC drivers are ready to be included into the kernel. Spreading the impression that LIRC refuses to work with kernel developers is not particularly helpful... Any help welcome. Christoph Pls Cc me on replies, I'm not subscribed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
On Wed, 31 Jan 2007 21:20:06 +0100 Greg KH wrote: On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote: I'd really love if the same offer was extended to GPL out-of-tree driver trees. This kind of offer has _always_ been there for out-of-tree GPL drivers. I have contacted many different groups and driver authors over the years to offer my help in trying to get their code into the mainline kernel. Some take me up on the offer, others ignore it, and still others activly refuse to do so, saying they want to stay out-of-the tree (lirc is one of these examples...) I'm the LIRC maintainer. I don't know what let's you think LIRC wants to stay out-of-the-tree. I just made clear that I don't have the time to do the merging of LIRC drivers to the kernel myself. In fact a lot of work still needs to be done before LIRC drivers are ready to be included into the kernel. Spreading the impression that LIRC refuses to work with kernel developers is not particularly helpful... Any help welcome. Christoph Pls Cc me on replies, I'm not subscribed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
