In comp.os.linux.advocacy, Moshe Goldfarb.
<brick_n_straw@xxxxxxxxx>
wrote
on Tue, 1 Jul 2008 15:19:07 -0400
<1nmtph7zd12o7.gb2ae55yhmbp.dlg@xxxxxxxxxx>:
> On Tue, 01 Jul 2008 15:37:34 +0100, Roy Schestowitz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Support for 100+ webcams in Linux 2.6.27 (USB Video Class Driver)
>
> But.,.......
>
> You Linux boobs have been telling us for years that these things "just
> work" with Linux.
> Somebody isn't telling the truth.
That's correct. *We* are not telling the truth. Allow me
to digress a bit on that score, and to hopefully
inject something approaching honesty.
First, bear in mind what a driver *is* -- it's a set of
instructions (written in C, for the most part, and compiled
during a kernel build, either by the user setting up his
system or, more likely, by the distro vendor while setting
up the image) for interacting with the processor-visible
[*] side of a solution, wehther that solution be a webcam,
display system, keyboard, network interface card, sound
chip, or Lin/Winmodem [%]. Linux can organize these drivers
either as loadable modules, or just fold them directly into
the kernel proper -- a bit like deciding when to fold nuts
into a pudding, perhaps.
Somebody has to write that driver. Who? If one's lucky,
the manufacturer (more precisely, an engineer employed
thereby) will create a driver and release it under the
LGPL. If one's less lucky, a binary version of the driver
can be encapsulated -- nvidia, fglrx, and some wifi units
are the result of this sort of thinking.
If one's unlucky, an enterprising hacker, hopefully with
accurate technical data (not a strict requirement!),
will pick up a unit and a version of Linux, and cobble
up a driver for that unit that works with that version
of Linux. If the technical data and the hacker are good,
one gets a reasonably workable driver, and even if the
driver is just a hackup job, some chances are that some
other hacker sees the faults and attempts a fix, which
Linus and company ultimately validate and take (no, I have
no idea as to the details). The process works, though
it's a bit hit and miss, especially if Linux undergoes a
major upgrade in the meantime -- though I doubt anyone's
modified the driver superstructure all that much lately,
really, unlike Microsoft Windows.
At that, Linux's process is probably more structured
than Windows'...though it may depend on how involved
Windows and the vendor are.
If one's *really* unlucky (or bleeding-edge), one has to
pick up an existing driver and try to copy it -- though
at this stage I'd suspect that one might only do this if
one's developing a new piece of hardware, which looks more
like strands of very thin wirewrapped spaghetti (AWG 30,
actually) stuffed into a desktop unit specifically used
for prototyping boards.
However, without that driver, Linux won't work -- for
that unit, anyway. Even with that driver, there are no
guarantees, though with PCI as opposed to ISA one might
have a fighting chance of correctly identifying precisely
what's in the machine, then selecting the correct module.
Second: Linux contains a lot of drivers, of varying
authenticity, functionality, and reliability, along with
its superstructures and other modules. Most of them work
reasonably well; the especially beaten ones (IDE, SCSI,
older NICs) will hopefully have the bugs flushed out
by now -- after a lot of bugfixes. Of course the newer
ones may not. Webcams aren't among the essential devices
necessary to get a Linux system to boot; therefore less
time is spent thereon, presumably.
Third: the user may not have a clue as to exactly what the
device *is*, without help. "A webcam" is a very generic
designation, for example; one might envision a Firewire or
USB unit, or something that goes through the printer port,
or even have its own card (this is probably rare nowadays).
That's probably four different general driver types right there.
I can't say without looking around. Pick the wrong one, and
you'll be lucky to get blank video.
And last: Linux won't boot without help. That help is
usually an initrd, which is basically a compressed ramdisk,
plus a boot manager such as GRUB or LILO (NTLDR can also
be used); drivers and scripts on that disk do most of
the autodetection magic. Get those scripts and drivers
wrong, and things won't work well, or won't work at all.
(I had to modify an initrd once to boot from a SCSI disk,
for example.)
FLOSS is not magic, and never was.
Comparing this to Windows is instructive -- though there's
not much to compare, beyond noting that the driver
source isn't usually available on Windows. However,
the manufacturer, or Microsoft in lieu thereof, is far
more likely to write *and support* at least binary-only
drivers for Windows, as Windows is the predominant desktop
solution. [+]
Also, binary-only drivers will work on (almost?) any
Windows system. This is mostly because Windows only
works on iNtel-compatible PCI clone hardware -- far
more restrictive than Linux's hardware space. There's a
certain synergy there, though "synergy" might not be quite
the correct word; at times one wonders if the PC makers
want something more advanced than Windows can give them.
Perhaps "parasitic" is equally distant here from the true
relationship of Windows and desktop hardware?
As for webcams...I'm not familiar with them, but suspect
that there might be a standard or two in there, though
there are no guarantees that a webcam will follow them
100%.
But they *will* work with Windows -- as it's in Microsoft's
interest for them to do so. (Otherwise, they get the
complaints, deserved or no.)
>
> My money is on the COLA Linux loons.....
>
Good luck with that bet.
[*] clearly a driver can't wiggle anything the processor
can't send things to; in the case of the x86 one is
limited to IN, OUT, and maybe memory mapping, and the
680x0 series is even more restrictive. If the card
doesn't give the processor direct access to a register,
there's no way a driver can, either, though indirect
things such as interrupts or other registers can of
course modify the hardware's behavior.
[%] As far as Linux is concerned, printers are mostly
communications through the parallel port (or in
some cases serial port or nowadays network card);
conversions of text and pictures are done at a higher
level, using CUPS. They're a bit of a special case.
[+] Vista did introduce some interesting twists into this
mess for awhile, though. I frankly don't know if
Vista and nVidia have kissed and made up; one would
hope so by now as it's been a year and a half.
--
#191, ewill3@xxxxxxxxxxxxx
Linux. An OS which actually, unlike certain other offerings, works.
** Posted from http://www.teranews.com **
|
|
