Messages in this thread | | | Date | Fri, 27 Aug 2004 16:04:55 -0700 | From | Craig Milo Rogers <> | Subject | Re: Termination of the Philips Webcam Driver (pwc) |
| |
On 04.08.27, Nemosoft Unv. wrote: > > So I'd personally much prefer the user mode approach. At that point it's > > still closed-source, but at least there is not even a whiff of a "hook" > > inside the kernel. > > My problem with that is that it makes using such cams a lot harder for both > users and developers of webcam tools. Basicly, every tool that wanted to > use webcam X that has some binary-only library would need to specifically > support it, use probing routines, check which formats are supported, set up > the decompressor, push the data through it, etc. Conversely, every user > that wanted to use webcams X, Y and Z would need to check first if they are > all supported by the program(s) he would like to use.
Pardon me for arguing, but my experience says that it need not be as difficult for the application program as you describe, although a tad complex for the driver & library writer(s). Applications see a user-mode API, and whether the codecs (in this case) reside in the kernel or in their own process need not be of interest to them: it is quite possible to make an API that isolates the application from this detail. Probing routines, interrupt support, etc. would be handled by kernel drivers, which for the purposes of the present discussion we've been assuming are open source kernel modules. The decompression libraries, which may or may not be closed-source, would be loaded from a standard library location using an agreed-upon naming convention.
The mechanics to make this work are well known, although tedious. The kernel driver(s) will supply an identifier for the type(s) of card(s) that are presently available. The identifier(s) will be use to load a library(s) based on a mapping scheme; here are three common schemes: 1) use the identifier as part of the library name , 2) provide a module map file (ala kernel modules), and 3) scan the available libraries on application startup and have them self-register (ala mozilla).
Distribution of the drivers and libraries is also a well-known problem. Linux distributions will typically come with certain drivers and/or codes preinstalled (depending upon the purpose of the distribution, the intellectual property issues involved, etc.) Vendors (enlightened ones!) will provide drivers and libraries on the CDROMs (or other media) that accompany their products. Web sites (vendor supported or not) will offer online upgrades for drivers and/or libraries.
> The point is, the current API for video devices is the Video4Linux of > Video4Linux2 interface. It's relative simple one, but it _works_ the same > on all hardware, either TV card or webcam. What you're proposing is > fragmenting that support into programs that support X, Y or Z, or only a > subset, or none, based on whether or not the developer of said tool had the > time, skill and desire to incorporate these libraries into their program.
Not at all. The application writers might not see any difference at all from the present V4L2 interface, depending upon the details of the API for encasulating the decompression libraries. There may very well be card-specific features that the applications have to know about, but that issue is independent of the location of the decompression routines.
> So instead of putting the support burden on one person (me), you want to > distribute it among a few dozen software developers. I don't think that's > really smart. It also takes the fun out of hacking a small webcam tool > together for whatever purpose, if you need a ton of extra tools, libraries > and program just to get one image.
I'm struggling to compile GnomeMeeting from CVS. I certainly suffer at times from having to deal with dozens of libraries, each loaded from their own little niche on Sourceforge or Apache.org, etc., for various projects. However, and again please permit me to disagree with you, I don't think that Web camera support will be quite that complex. All you need is a common framework, and the driver(s) and library(s) for the card(s) installed on your machine.
> A solution could be something like JACK for the ALSA sound cards, but then > for video. But you need a compelling reason, and somebody (somebodies) to > design, write and maintain it.
So long as someone is available to maintain the closed-source codecs (while, we all hope, working in parallel with the manufacturers involved to secure open-source licensing for any currently closed-source components), I am confident that we can put together a team to implement the rest. I would be pleased to be on the team.
> Anyway... wether or not PWC was illegal under the GPL, technically > undesirable or just not good enough, is irrelevant now. The damage has been > done, and that's just sad.
Please... don't tell me that you've deleted the source files for pwcx!!! That would be sad. Also, I hope that you are willing to consider continuing to maintain the closed-source codecs in pwcx for a while longer, under some circumstances. Your expertise and willingness to help others is really the most valuable resource here, and it would indeed be truly sad if it has been exhausted.
Craig Milo Rogers
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |