[MPlayer-users] Re: Display card recommendations

[Arpi]

Hi,

> I understand what Robert is saying, that there very well could be source that 
> NVidia uses in their drivers that they shouldn't, and that is a concern. 
> Though that never seems to be part of the arguement. The arguement always 
> comes out as "they are anti-open source, open source drivers are always 
> better and therefore all linux drivers should be open source"(though not 

no!

i like linux because i can access (mean: modify & recompile) the source
of everything on my system. if, when i find a bug, a missing feature, or i
just want something to work different, i can change it and enjoy!
i've already patched hundreds of apps and drivers, it took me days to apply
these after a fresh install on a new machine.
i can't do that on windows. and i can't do that with binary-only drivers,
programs, codecs etc. i can use them as-is, usually with no garantee.
if it doesn't work, it is _my_problem_, they don't give any support.
and i can't help me, as i can't access the source, i won't get a hexeditor
and start random modifying the binary until it starts working....

the other thing is code quality.
i worked for some company on commercial programming projects earlier.
i could see the development of several years projects.
i hope i don't have to sit in a car controlled by such software...
the most important difference between these free (and also opensource)
projects and commercial programs is that the former is developed as a
hobby in teh spare time of programmers, they develop it for themself,
ie they won't make shit. they always do their best.
while, in a commercial project, you have a spec of in/out data & algo,
and no one cares how do you implement the code.

ah. Robert mentioned it too.
look at the old nvidia HAL driver sources they released ~ 2 years ago,
when they started their linux driver development.
yes, they released something they called 'source', it was actually messed
up 'enough to compile but no one can read this' style.
i don't remember exactly, but at least 30% of the code were pure workarounds
for various hardware bugs. they do (did?) cheap shit in hw, and fix it in
software later. clever technologie - you have to implement sw only once but
you have to create teh hw as many times as you sell it.
they spend their energy on sw development instead of hw.
they do create chips capable of many many varions things, close to random
mix of transistors, and then thousand coders sit down and starts hacking
features together in software. ok it was a bit sci-fi, but not so far from
the reality... IMHO, of course.

and now a real life example:
there is the shitty Xv interface out there.
ppl who used X11 earlier liek it, for a while.
then they find that there are visual issues, jittering, flickering etc.
also, performance isn't the best - every Xv driver has a big slow memcpy()
inside to copy the image from systemram to videoram.

so, we started to write own drivers for mplayer, think of mga_vid, and
nowdays vidix. we couldn't do that without having access to teh Xv driver
sources and the hardware specs.
look at nvidia_vid.c (ok don't look it's already deleted from CSV afaik)
it was started then we realized that no hw specs, no source, and reverse
engineering eth binary driver would take years. so gave up.

mga_vid, tdfxfb and vidix drivers solve the limitations of Xv:
- direct access to video ram - faster rendering (the codec/filter writes
  directly to video ram - less sysram usage and free'd the cpu needed for memcpy)
- triple and higher buffering - solves jittering and flickering problems
- support for more YUV formats, like YVU9 etc. most Xv driver only supports
  YUY2, and has very very slow unoptimized C yv12->yuy2 converter inside.

it would be all impossible without opensource drivers and open specs.

anyway the progress of opensource nvidia Xv driver development is very nice
- maybe one day you'll get working vidix driver for your nvidia card.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu