[Lancaster] Re: Help -- Video importing/processing software

[Martyn Welch]

On Wednesday 02 August 2006 08:59, Ken Hough wrote:
> Martyn Welch wrote:
> >The kernel maintainers don't want them - once a binary blob has been added
> > to the kernel it becomes very difficult for them to debug crashes and
> > alike, it also becomes quite hard to deal with on the licensing front. I
> > understand that people want good hardware compatibility, to use the
> > "best" hardware available and (sometimes) use Linux. The problem is
> > without the hardware being openly documented this becomes virtually
> > impossible in an opensource context.
> >
> >The solution is to spend your money wisely, support those companies
> > willing to give you enough information to allow you to use the device you
> > purchased in whatever manner you see fit. Even if this does mean using a
> > device not considered to be the "best" on the market - lets face it, it's
> > only the "best" choice for you if it works...
>
> I have little choice, especially as I intend to carry out already
> documented hardware mods to the webcam. This make/type of webcam is
> recognised as being simply the best for the job. Other makes don't even
> come close.
>

Yeah - same problem I face some times. Niche fields don't generally have the 
clout to get what they want/need, unless of course they have *lots* of money.

> I understand the philosophy that you describe, but we live in the real
> world. Surely, the best way to propagate Linux is to encourage people to
> use it and that means enabling them to use the best available hardware.

I disagree, I think that the best way to propergate Linux is not to overly 
dilute what it stands for and if people find it a compelling alternative then 
they will use it.

Linux is growing in popularity in the real world without diluting. It doesn't 
ask for, or take the same approach that is taken by proprietary software 
vendors but that is one of the things that many like about it.

I am strongly of the opinion that specs for interfacing to hardware should be 
readily available to those who buy the product and in a way the Linux 
approach is helping to encourage this.

The issue of hardware compatibility is a real world problem and Linux provides 
one approach to solving it - provide open specifications for communicating 
with hardware.

> When we have a guy who is doing his best to provide help despite being
> stapped by a NDA, and there is no alternative to hand, then surely it is
> foolish to kick him in the teeth. If it wasn't for him, I would have no
> alternative but to use MS Windows.
>

I've done some extra reading around this subject since I made my last post, it 
seems that the NDA had expired, so as far as I can tell he is legally in a 
position to release the compression code as GPL. He didn't want to as 
Philips, who make the chipset, are still using it in current devices and 
licensing the technology to others, he doesn't want to rock the boat. I 
rather doubt that Philips would be overly concerned if the shoe had been on 
the other foot.

I seems that the driver is back in the kernel (Alan Cox has taken on the 
maintenance) and some basic reverse engineering has been done to include the 
functionality of the originally non-GPL-d portion, though there seems to be 
some further disagreement over the process used.

Interestingly there is some debate as to whether the kernel should have the 
compression code in it at all, there are some who believe that the kernel 
should pass the uncompressed stream to userland for decompression. This 
approach would probably by-pass most of the problem.

> Webcams are now a common part of desktop computer systems.
>

I've just been looking for one with good Linux compatibility - they're harder 
to find than working wifi cards!

> Only, when more hardware suppliers realise that there is a meaningful
> base of non Microsoft users will the situation change for the better. We
> need a 'hearts and minds' approach. That's not going to happen with a
> purist 'head in the sand' approach from the
> Linux community.
>

The danger is that the Linux environment is treated the same as the 
proprietary software world, by which I mean that they produce half-baked 
closed drivers. OK if you want the hardware to work with a standard x86 
computer, really bad if you happen to use the powerPC processor or something 
like the xscale. Also a bitch to fix and maintain as the kernel evolves, 
leading to loss of compatibility when the producers decide to stop supporting 
it.

> IMHO, it is plain stupid to discourage help from the one available source.
>

It must be noted that he was disobeying the rules with regards to including 
code in the Linux kernel. The rules state that hooks solely for loading 
binary blobs into the kernel are not allowed. He didn't follow the rules and 
now he's acting a bit like a big baby.

> The use of 'ndiswrapper' allows commercial wifi drivers to be used under
> Linux. I know that this does not involve a kernel patch, but as I wrote
> in my previous message "Where there's a will.....".
>

Which is an interesting case study.

Ndiswrapper is not included in the stock kernel exactly because of this issue. 
Sure many of the distributions add it, but it's not in the vanilla kernel. It 
is maintained as an add-on, the original writer of the pwc driver had this 
option but didn't want to use it.

Martyn

-- 

Martyn Welch (martyn at welchs.me.uk)

PGP Key : http://www.welchs.me.uk/martyn/pgpkey/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mailman.lug.org.uk/pipermail/lancaster/attachments/20060802/ebff2c59/attachment.bin