Both ATI and Nvidia started making their own drivers for Linux because the high-end video card market was dominiated by Unix machines and people were beginning to move from Unix machines to Linux PC for cost reasons. If you look back at ATI Linux driver history the first drivers that came out of Linux for modern ATI cards from ATI were originally designed for their FireGL line of cards... due to their similarity to regular consumer cards some people were able to make the firegl drivers work ok with their regular ati cards.
Nvidia has had that unified driver archatecture thing built into their hardware design since forever so it was even easier for them to port to Linux and get good driver support across their line of cards.
In Windows there are numerious examples of hardware driver manufacturers jumping thru hoops to circumvent Windows limitations.
The one example that I know most about (which is still fairly limited) is sound card support for doing music production stuff. When Microsoft made the transition from the much simplier Win9x sound driver model to the Win2k and WinXP NT-based windows versions they introduced changes to how the windows sound driver subsystem works that ended up making Windows XP and such very unsuitable for music production in many ways.
For example the default way to do stuff was to route all the sound thru the 'kmix' software sound mixer. This made it easier for the average user because the mixer interface was the same irregardless of what sound card they happen to be using... if you ever used alsamixer app in Linux you'd quickly notice that it's got many different mixers and channels depending on the sound card... also it easily allowed you to run multiple sound sources and have everything mix properly since it's all done in software.
The downside is that it introduced large latencies into the sound feeds. You'd get average latencies as bad as 300 msecs (anything above 10msecs is considured perceivable by human ears), which makes doing things like matching beats or mixing multiple inputs realtime very difficult.
Plus due to the nature of the NT kernel it has poor 'realtime'-style performance and you'd easily get pops and squels and other artifacts in your sound recording when the system gets hit with heavy I/O or high cpu demands like when a virus scanner kicks in.
However since Windows is very popular sound card and sound application manufacturers had to start making their own special driver model for it called ASIO that bypasses the normal Windows sound software stack and reduces the amount of latency and helps minimize Windows XP's realtime-style limitations. Of course you have to have special drivers, ASIO-enabled sound cards, and applications to be able to use this stuff.
They also had ASIO for Mac, but it's largely no longer nessicary.. With OS X they have much superior realtime-style capabilities and the "Core Audio" stuff enables applications and sound cards to interact and easily get under 10msec latency performance on a modern machine and sub-3msec peformance in many cases. It's very nice.
With Linux I can go very extreme and modify the kernel with realtime-preempt patches. Also it allows 'software IRQ' to were I can do wacky stuff like give my Jack audio server higher priorities in the system scedualer then even disk controller I/O. This allows me to EASILY get sub-5msec performance with my Jack audio server (allows midi/sound apps to route sound and midi signals to each other and with sound cards and external devices) with no xruns (buffer underflows) even with the cpu at 70-100% and heavy disk activity. I can even obtain sub-1msec performance with no xruns, except that system performance is severly degraded. (need faster CPU for that stuff.) Obviously this sort of stuff is not something that most people want to do to their computer, but is OK for a dedicated audio workstation.
