Re: Binary Drivers

[Martin Knoblauch <knobi@knobisoft.de>]

--- James C Georgas <jgeorgas@rogers.com> wrote:

> On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote:
> > On 12/25/06, David Schwartz <davids@xxxxxxxxxxxxx> wrote:
> > 
> > >   If I bought the car from the manufacturer, it also must
> > > include any rights the manufacturer might have to the car's use.
> > > That includes using the car to violate emission control measures.
> > > If I didn't buy the right to use the car that way (insofar as
> > > that right was owned by the car manufacturer), I didn't
> > > buy the whole care -- just *some* of the rights to use it.
> > 
> >  just to be dense - what makes you think that the car manufacturer
> has
> > any legal right to violate emission control measures? What an utter
> > nonsense (sorry).
> > 
> >  So, lets stop the stupid car comparisons. They are no being funny
> any
> > more.
> 
> Let's summarize the current situation:
> 
> 1) Hardware vendors don't have to tell us how to program their
> products, as long as they provide some way to use it 
> (i.e. binary blob driver).
>

 Correct, as far as I can tell.
 
> 2) Hardware vendors don't want to tell us how to program their
> products, because they think this information is their secret
> sauce (or maybe their competitor's secret sauce).
>

 - or they are ashamed to show the world what kind of crap they sell
 - or they have lost (never had) the documentation themselves. I tend
to no believe this

> 3) Hardware vendors don't tell us how to program their products,
> because they know about (1) and they believe (2).
>

 - or they are just ignorant
  
> 4) We need products with datasheets because of our development model.
>

 - correct
 
> 5) We want products with capabilities that these vendors advertise.
>

 we want open-spec products that meet the performance of the high-end
closed-spec products
 
> 6) Products that satisfy both (4) and (5) are often scarce or
> non-existent.
>

 unfortunatelly
 
> 
> So far, the suggestions I've seen to resolve the above conflict fall
> into three categories:
> 
> a) Force vendors to provide datasheets. 
> 
> b) Entice vendors to provide datasheets.
> 
> c) Reverse engineer the hardware and write our own datasheets.
> 
> Solution (a) involves denial of point (1), mostly through the use of
> analogy and allegory. Alternatively, one can try to change the law
> through government channels.
>

  good luck
 
> Solution (b) requires market pressure, charity, or visionary
> management.
> We can't exert enough market pressure currently to make much
> difference.
> Charity sometimes gives us datasheets for old hardware. Visionary
> management is the future.
> 

 - Old hardware is not interesting in most markets
 - Visionary mamangement is rare

> Solution (c) is what we do now, with varying degrees of success. A
> good example is the R300 support in the radeon DRM module.
> 

 But the R300 does not meet 5)

Cheers
Martin

------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de
-
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/