Re: ac15 and 2.4.5-pre6, pwc format conversion
Greetings, Coalescing two messages in one: On 25-May-01 Alan Cox wrote: > Nope. Its been policy since 2.0. Its both v4l1 and v4l2 policy. In fact its > fairly nonsensical to handle any format conversions in kernel unless the > device outputs a unique format of its own. Oh come on. 2.0 has been out since, what? 1996? Methinks you have had plenty of time to really do something about it then. You are now simply too late. > It breaks apps by doing conversions, and it breaks important apps like H263 > codecs not silly little camera viewers, because you trash the performance This is a NULL argument. First, it doesn´t break anything; I think H263 is smart to pick a YUV format if it´s available. Second, conversion has to be done at one point or another. If the native format of the camera is RGB, H263 will have to convert to YUV. Wether or not this is done in kernel space or user space doesn´t matter: it has to be done. And in case the native format of the camera doesn´t resemble anything in V4L, you will have TWO conversion: first, in kernel from native to V4L palette, and then in your tool from V4L to whatever format you need, while maybe the driver could do it all in one stage. On 25-May-01 Alan Cox wrote: >> > that none of the sound drivers does sample rate conversion although >> > some sound chips are locked at 48kHz only. >> >> True, but a number of audio tools will break, because they don=B4t supp= > > So fix the tools > >> if you limit the number of available palettes per driver. Plus, you wil= >> l get >> severe fragmentation of which program works with which driver. Which is >> unacceptable, in my opinion (and certainly NOT the idea behind a common= >> API!) > > Fix the tools. Gee, ¨Fix the tools¨ seems to be your mantra :-(. Anyway, breaking the tools doesn´t necessarely mean they are going to get fixed; not all are being actively maintained at the moment (okay, that´s a pity; still it´s a shame). And you are probably not going to get the endless streams of mails to the webcam developers which state: ¨I upgraded my kernel to 2.4.X and my webcam broke!¨ Do you really think we will enjoy replying time after time: ¨Yes, I know, but Alan Cox told me to do so¨. No. To a lot of users, and even application developers, this just plainly sucks. >> routines, while (nearly) nothing has been said about other (USB) webcam >> drivers which have conversion routines. > > I have those in my firing line too. It has always been the policy that > format > conversions go in user space. The kernel is an arbitrator of resources it > is not a shit bucket for solving other peoples incompetence. Now you are being insulting, really. There are a lot of competent people who put a lot of time and effort into these tools. But the Video4Linux API is not complete and not completely suitable for webcams. For example, it misses the quite fundamental call to query the available palettes; nor does the V4L API give any hint that the number of palettes might be severely limited. The first tools that were created had the luxury of hardware that did all the work for them, so why not use it? Webcams are not so lucky. There´s no need to penalize them, because if the change goes through, a lot of tools will not work with webcams but with TV cards. ... Anyway, I am not going to debate this any further at this point. Johannes, please remove my webcam driver from the USB source tree, until the software YUV/RGB conversion has been removed from ALL other video devices (preferably all at the same time). I will *not* have a crippled driver into the Linux kernel. If this is going to be policy, fine. But then this policy will apply to ALL drivers equally, not just mine because suddenly Alan realizes he has been sleeping for the past 5 years and decides to implement a policy hardly noone ever knew existed. - Nemosoft - Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000 URL: neverIRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft >> Never mind the daylight << - 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: ac15 and 2.4.5-pre6, pwc format conversion
Greetings, On 25-May-01 Erik Mouw wrote: > On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote: >> That´s what you get for ripping out the guts of a driver. Have a nice >> day. > > The format conversion shouldn't be there in the first place. Format > conversion is policy, so it doesn't belong in kernel. Note for example > that none of the sound drivers does sample rate conversion although > some sound chips are locked at 48kHz only. True, but a number of audio tools will break, because they don´t support that samplerate (mpg123 0.59r, one of the more popular MP3 players, segfaults when it has to do conversion of 44.1 KHz to 48 KHz). Recording from such a source is usually less of a problem, although some post-processing is then necessary (not all tools support samplerate conversion natively). The situation for video devices is worse. 80% of the video tools will break if you limit the number of available palettes per driver. Plus, you will get severe fragmentation of which program works with which driver. Which is unacceptable, in my opinion (and certainly NOT the idea behind a common API!) You can blame the authors of those video tools, but that´s not really fair. The original Video4Linux API was based upon TV grabber cards. Most of them do YUV/RGB conversion in hardware, so most tools expected that all or most palettes would always be available, since supporting a palette would not require any extra CPU cycles [1]. Some tools like RGB, and others YUV, so the authors happily selected the palette of their choice and never even considered building in functions for doing conversion. And then I am not even talking about the RGB/BGR mess. Then along came parallel-port and USB webcams, which have a number of ´native´ formats which only sometimes match the defined V4L palettes. So some conversion, albeit trivial, is necessary. Might as well do the full conversion to various YUV/RGB palettes then, to accomodate as much programs as possible (granted, some tools are really braindead). Which is exactly what I did, and therefor I was quite sarcastic in my previous mail because my driver was targeted for removal of ALL conversion routines, while (nearly) nothing has been said about other (USB) webcam drivers which have conversion routines. Johannes Erdfeld (current USB maintainer) said he would go over the other USB drivers and see which ones are eligeble for removal of YUV->RGB conversion (which are, btw: ov511 and cpia; ibmcam flatly refuses anything except RGB24). I warned him that if he does so, he will get a lot of angry looks from users. I do agree that the kernel may not be the proper place for these kind of conversions. But as I wrote to Alan Cox earlier today that if he wanted to fix this, he should fix the problem, which are ´simplistic´ programs and a hardware specific API (V4L1, and V4L2 isn´t that much better), and not target the drivers. But it will take something really radical (like removing the V4L API altogether), that will wake up the authors of ALL video tools and ´fix´ their programs. Alan Cox certainly isn´t going to do that himself, and neither am I :) In other words: if you want to break it, break it well. Don´t smash the saucer without the cup. - Nemosoft [1] There´s an additional problem, which has plagued my driver for quite some time: TV cards can scale the image to any size, again in hardware. For webcams which only have a few fixed sizes, some padding or cropping may be required (this can usually be programmed very easily, and requires only a few extra CPU cycles). Scaling on the fly is definitely out of the question, even for me. - Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000 URL: neverIRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft >> Never mind the daylight << - 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: ac15 and 2.4.5-pre6, pwc format conversion
Greetings, On 25-May-01 Norbert Preining wrote: > Hi! > > According to ac ChangeLog: > o Rip format conversion out of the pwc driver (me) > | It belongs in user space.. > > This change is included in 2.4.5-pre6, but > drivers/usb/pwc-uncompress.c > still relies on this files: > gcc -D__KERNEL__ -I/usr/src/linux-2.4.5.6-packet/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -mpreferred-stack-boundary=2 -march=k6 -DMODULE -DEXPORT_SYMTAB -c > pwc-uncompress.c > pwc-uncompress.c:25: vcvt.h: No such file or directory > pwc-uncompress.c: In function `pwc_decompress': > pwc-uncompress.c:158: warning: implicit declaration of function > `vcvt_420i_rgb24' > pwc-uncompress.c:161: warning: implicit declaration of function > `vcvt_420i_bgr24' > pwc-uncompress.c:164: warning: implicit declaration of function > `vcvt_420i_rgb32' > pwc-uncompress.c:167: warning: implicit declaration of function > `vcvt_420i_bgr32' > pwc-uncompress.c:171: warning: implicit declaration of function > `vcvt_420i_yuyv' > pwc-uncompress.c:185: warning: implicit declaration of function > `vcvt_420i_420p' That´s what you get for ripping out the guts of a driver. Have a nice day. - Nemosoft (the pwc module maintainer) - Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000 URL: neverIRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft >> Never mind the daylight << - 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: ac15 and 2.4.5-pre6, pwc format conversion
Greetings, On 25-May-01 Norbert Preining wrote: Hi! According to ac ChangeLog: o Rip format conversion out of the pwc driver (me) | It belongs in user space.. This change is included in 2.4.5-pre6, but drivers/usb/pwc-uncompress.c still relies on this files: gcc -D__KERNEL__ -I/usr/src/linux-2.4.5.6-packet/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=k6 -DMODULE -DEXPORT_SYMTAB -c pwc-uncompress.c pwc-uncompress.c:25: vcvt.h: No such file or directory pwc-uncompress.c: In function `pwc_decompress': pwc-uncompress.c:158: warning: implicit declaration of function `vcvt_420i_rgb24' pwc-uncompress.c:161: warning: implicit declaration of function `vcvt_420i_bgr24' pwc-uncompress.c:164: warning: implicit declaration of function `vcvt_420i_rgb32' pwc-uncompress.c:167: warning: implicit declaration of function `vcvt_420i_bgr32' pwc-uncompress.c:171: warning: implicit declaration of function `vcvt_420i_yuyv' pwc-uncompress.c:185: warning: implicit declaration of function `vcvt_420i_420p' That´s what you get for ripping out the guts of a driver. Have a nice day. - Nemosoft (the pwc module maintainer) - Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000 URL: neverIRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft Never mind the daylight - 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: ac15 and 2.4.5-pre6, pwc format conversion
Greetings, Coalescing two messages in one: On 25-May-01 Alan Cox wrote: Nope. Its been policy since 2.0. Its both v4l1 and v4l2 policy. In fact its fairly nonsensical to handle any format conversions in kernel unless the device outputs a unique format of its own. Oh come on. 2.0 has been out since, what? 1996? Methinks you have had plenty of time to really do something about it then. You are now simply too late. It breaks apps by doing conversions, and it breaks important apps like H263 codecs not silly little camera viewers, because you trash the performance This is a NULL argument. First, it doesn´t break anything; I think H263 is smart to pick a YUV format if it´s available. Second, conversion has to be done at one point or another. If the native format of the camera is RGB, H263 will have to convert to YUV. Wether or not this is done in kernel space or user space doesn´t matter: it has to be done. And in case the native format of the camera doesn´t resemble anything in V4L, you will have TWO conversion: first, in kernel from native to V4L palette, and then in your tool from V4L to whatever format you need, while maybe the driver could do it all in one stage. On 25-May-01 Alan Cox wrote: that none of the sound drivers does sample rate conversion although some sound chips are locked at 48kHz only. True, but a number of audio tools will break, because they don=B4t supp= So fix the tools if you limit the number of available palettes per driver. Plus, you wil= l get severe fragmentation of which program works with which driver. Which is unacceptable, in my opinion (and certainly NOT the idea behind a common= API!) Fix the tools. Gee, ¨Fix the tools¨ seems to be your mantra :-(. Anyway, breaking the tools doesn´t necessarely mean they are going to get fixed; not all are being actively maintained at the moment (okay, that´s a pity; still it´s a shame). And you are probably not going to get the endless streams of mails to the webcam developers which state: ¨I upgraded my kernel to 2.4.X and my webcam broke!¨ Do you really think we will enjoy replying time after time: ¨Yes, I know, but Alan Cox told me to do so¨. No. To a lot of users, and even application developers, this just plainly sucks. routines, while (nearly) nothing has been said about other (USB) webcam drivers which have conversion routines. I have those in my firing line too. It has always been the policy that format conversions go in user space. The kernel is an arbitrator of resources it is not a shit bucket for solving other peoples incompetence. Now you are being insulting, really. There are a lot of competent people who put a lot of time and effort into these tools. But the Video4Linux API is not complete and not completely suitable for webcams. For example, it misses the quite fundamental call to query the available palettes; nor does the V4L API give any hint that the number of palettes might be severely limited. The first tools that were created had the luxury of hardware that did all the work for them, so why not use it? Webcams are not so lucky. There´s no need to penalize them, because if the change goes through, a lot of tools will not work with webcams but with TV cards. ... Anyway, I am not going to debate this any further at this point. Johannes, please remove my webcam driver from the USB source tree, until the software YUV/RGB conversion has been removed from ALL other video devices (preferably all at the same time). I will *not* have a crippled driver into the Linux kernel. If this is going to be policy, fine. But then this policy will apply to ALL drivers equally, not just mine because suddenly Alan realizes he has been sleeping for the past 5 years and decides to implement a policy hardly noone ever knew existed. - Nemosoft - Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000 URL: neverIRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft Never mind the daylight - 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: ac15 and 2.4.5-pre6, pwc format conversion
Greetings, On 25-May-01 Erik Mouw wrote: On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote: That´s what you get for ripping out the guts of a driver. Have a nice day. The format conversion shouldn't be there in the first place. Format conversion is policy, so it doesn't belong in kernel. Note for example that none of the sound drivers does sample rate conversion although some sound chips are locked at 48kHz only. True, but a number of audio tools will break, because they don´t support that samplerate (mpg123 0.59r, one of the more popular MP3 players, segfaults when it has to do conversion of 44.1 KHz to 48 KHz). Recording from such a source is usually less of a problem, although some post-processing is then necessary (not all tools support samplerate conversion natively). The situation for video devices is worse. 80% of the video tools will break if you limit the number of available palettes per driver. Plus, you will get severe fragmentation of which program works with which driver. Which is unacceptable, in my opinion (and certainly NOT the idea behind a common API!) You can blame the authors of those video tools, but that´s not really fair. The original Video4Linux API was based upon TV grabber cards. Most of them do YUV/RGB conversion in hardware, so most tools expected that all or most palettes would always be available, since supporting a palette would not require any extra CPU cycles [1]. Some tools like RGB, and others YUV, so the authors happily selected the palette of their choice and never even considered building in functions for doing conversion. And then I am not even talking about the RGB/BGR mess. Then along came parallel-port and USB webcams, which have a number of ´native´ formats which only sometimes match the defined V4L palettes. So some conversion, albeit trivial, is necessary. Might as well do the full conversion to various YUV/RGB palettes then, to accomodate as much programs as possible (granted, some tools are really braindead). Which is exactly what I did, and therefor I was quite sarcastic in my previous mail because my driver was targeted for removal of ALL conversion routines, while (nearly) nothing has been said about other (USB) webcam drivers which have conversion routines. Johannes Erdfeld (current USB maintainer) said he would go over the other USB drivers and see which ones are eligeble for removal of YUV-RGB conversion (which are, btw: ov511 and cpia; ibmcam flatly refuses anything except RGB24). I warned him that if he does so, he will get a lot of angry looks from users. I do agree that the kernel may not be the proper place for these kind of conversions. But as I wrote to Alan Cox earlier today that if he wanted to fix this, he should fix the problem, which are ´simplistic´ programs and a hardware specific API (V4L1, and V4L2 isn´t that much better), and not target the drivers. But it will take something really radical (like removing the V4L API altogether), that will wake up the authors of ALL video tools and ´fix´ their programs. Alan Cox certainly isn´t going to do that himself, and neither am I :) In other words: if you want to break it, break it well. Don´t smash the saucer without the cup. - Nemosoft [1] There´s an additional problem, which has plagued my driver for quite some time: TV cards can scale the image to any size, again in hardware. For webcams which only have a few fixed sizes, some padding or cropping may be required (this can usually be programmed very easily, and requires only a few extra CPU cycles). Scaling on the fly is definitely out of the question, even for me. - Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000 URL: neverIRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft Never mind the daylight - 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/
