Re: Still no kmod for new nvidia

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

 



Rick Stevens wrote
> It would also be nice if the manufacturers would release better
> information on the devices themselves.
Yes, this has been hashed, rehashed and burnt to the ground.  
Manufacturers don't want to give away technical secrets and will go to 
great lengths to keep them that way.  Their bottom lines depend on it.  
Yes, AMD/ATI/nVidia/Intel are in business to make money.  In order to 
make money you have to have a feature your competition does not have or 
you have to be super cheap. 
Several independent developers were sued by a now defunct manufacturer 
for reverse 'black box' engineering their chipset just to build drivers 
that the manufacturer PUBLICLY stated they would not build.
> Much of the time spent in FOSS driver development is reverse engineering drivers for Windows because
> of a lack of adequate information--and sometimes bits get left out or don't work well because of it.
>
>   
Describe 'reverse engineer'.  There is looking at the input/outputs of a 
module with no knowledge of the code of the module (called 'black' box) 
and then there is decoding to the machine code level ('white' box or 
'gray' box.) There is a reason that Tandy versus IBM stuck.  Tandy 
watched what happened when an IBM PC booted on power up with a DOS disk 
in the machine (DOS remember was stolen and had been around as source 
code) and found that the Operating System queried a specific location in 
memory for the letters IBM.  They did that and made a better BIOS.  The 
company is now known as Phoenix. Other companies did a line-by-line 
decode of the BIOS and that got them in a bunch of trouble.  That is why 
'black box' is acceptable, but 'white' or 'gray' box is not.
> A few years back, Texas Instruments created a wireless NIC that a number
> of PCMCIA and USB dongles used (mostly from D-Link).  We ended up with
> hack very similar to nVidia kmods that'd use a binary blob from Windows
> for the guts of the driver.
>   
Again, black boxing the 'blob' is ok.  Reverse engineering the code is 
not. 

Now for the problem with RPMFusion.  If they ain't on the stick, someone 
gotta take over.  That means if we can get the 'propriatary' bits and 
then black box them to see what happens and then write our own drivers.  
ATI released a 'blob' for a very famous, but almost defunct, operating 
system.  Maybe they will do this again for those cards they cannot 
financially justify supporting.  Has anyone in the FOSS environment 
approached them?  This might put Fedora and the upstream company above 
their competition if they did.

James McKenzie

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux