[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: USB Camera - Detected through Kudzu butnot configurable through gtkcam

On Tue, 2003-02-04 at 19:48, Jim Cornette wrote:

> My point was that dumbing down the interface wouldn't attract the
> mainstream users for long. If they were to just buy a product off of the
> shelf and not check to see if it was supported by Linux.Most people
> would blame the computing environment and not the hardware device
> distributor.
If people want to be blind to the realities of what it takes to do
hardware support I can't stop them...and I'm pretty sure the developers
at redhat know how important it is to get all the gadgetry working.
Look...a lot of hardware when it comes out gets supported in windows and
mac initially because the hardware manufactures included the necessary
drivers to get the device working.  I doubt MS hacks away on device
drivers without a significant effort on the hardware manufacturers part
to work with MS. Chicken and egg problem at this point....if hardware
manufacturers would play ball and just make an effort to publish
reasonable specs(or use standard protocals, and luckily it seems digital
cameras are finally standardizing somewhat from my small amount of
reading on the subject)...things get much easier for everyone.  Redhat
does not have the developer man power to reverse-engineer a system for
every addon piece of hardware in existance...throw away peripherals like
digital cameras are rightly pretty low on the developer how to spend
time wishlist...compared to say video cards....  

But you touch on a much harder problem of hardware certification....and
its come up on the beta lists in the past...how would anyone actually
organize a box branding effort that certified a product as being linux
supported.  Products can claim windows or mac support becuase MS or
apple sells the brand to put on the box, and supposedly have some
testing done to actually see if the device works. If Redhat started
doing this unilaterally in the linux world..so that addon hardware were
branded as "Redhat" compatible...it would spark a heated religious
battle and more Redhat=MS-linux flames. But trying to brand any hardware
as "linux" compatible would be a major task...
> It would serve these developers to add a prompt screen for the users to
> take the product back. "There is no Linux support from the vendor for
> this product." Having a prompt that tells you that your camera is not
> detected shades the blame on the lack of the developer's motivation.

Thats a very good idea.....right out in the users face....and again the
idea for this at the Redhat distribution level has been debated on
previous incarnations of the beta list. Not to rehash it...i forget who
I argued about with for like 80 or so messages in one thread, but the
idea that Redhat use its hardware compatibility list on its website in a
more prominent way seems to be popular impossibility  I think it might
be a very clever thing indeed if redhat could tie its hardware
compatibility database on its website into kudzu somehow and be able to
give users an up2date representation of what hardware was
supported...and what wasn't as soon as you plugged it in.

> I will look into the flash readers. Though for the camera presently,
> I'll boot into windows and download them. Maybe dropping a line to
> gphoto will get some results for more camera support.

Sandisk SDDR-31 USB cf reader works well enough for me.  

> Now, about which project the drivers for recognition of hardware. I
> would venture that it is best to have the device interact through the
> "platform". 

It is best for the platform to configure the hardware...ala kudzu...but
if the underlying project Redhat is relying to provide support for a
certain class of devices (gphoto for cameras, sane for scanners) doesn't
support the device, redhat probably can't do much about it except wring
their hands in frustration...there are so many unsupported
peripherals...if it were just a matter of manhours to code it all up,
redhat could prob throw some developer time and money at the problem and
make some progress...but if the underlying problem is some serious
reverse-engineering of oddball devices...well thats prob not a wise use
of distribution level developer time.  

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]