[ANNOUNCE] Deprecation of xf86-video-nv

[Piotr Gluszenia Slawinski]

On Wed, 31 Mar 2010, Dave Airlie wrote:

> On Tue, Mar 30, 2010 at 7:31 PM, Piotr Gluszenia Slawinski
> <curious at bwv190.internetdsl.tpnet.pl> wrote:
>> On Mon, 29 Mar 2010, Andy Ritger wrote:
>>
>>>
>>> On Sat, 27 Mar 2010, Piotr Gluszenia Slawinski wrote:
>>>
>>>>
>>>>
>>>>  --
>>>>  On Fri, 26 Mar 2010, Andy Ritger wrote:
>>>>
>>>>>>  Historically, NVIDIA developed and maintained the xf86-video-nv X >
>>>>>>  driver,
>>>>>>  Our advice to owners of NVIDIA GPUs running Linux is to use the VESA
>>>>>> X
>>>>>  driver from the time of Linux distribution installation until they can
>>>>>  download and install the NVIDIA Linux driver from their distribution
>>>>>  repositories or from nvidia.com.
>>>>
>>>>  then NVIDIA could be so kind and fix the "NVIDIA Linux driver"
>>>>  to build and work properly with alternate libc implementations, like
>>>>  uclibc (glibc is hard-linked in libGL supplied with The Driver)
>>>
>>> Hello, Piotr.
>>>
>>> No, glibc is not statically linked into NVIDIA's libGL.so, if that is what
>>> you mean to imply.
>>
>> no, it just expects glibc being in the system.
>>
>>> If uclibc provided the same ABI as glibc then I would expect NVIDIA's
>>> libGL.so to work with uclibc.  However, my understanding is that binary
>>> compatiblity (either with glibc or even with prior uclibc releases)
>>> is a non-goal of the uclibc project.
>>
>> yes, it is not binary-compatible glibc.
>>
>>> For better or worse, the NVIDIA driver is provided as binary-only,
>>> so it is not terribly well suited to deal with system library binary
>>> interface changes.
>>>
>>> Sorry,
>>> - Andy
>>
>> well, and that is what i'm complaining about...
>> mind you glibc will not be always binary compatible either across
>> it's own versions  - same
>> as libc5 to glibc ("libc6") transition occured ad some point...
>>
>> this limits nvidia driver usage to specific libc implementation,
>> with specific version.
>>
>> nv driver itself served well for i.e. people who could sacrifice
>> 3d performance in i.e. netbooks, where they would rather focus
>> on battery and storage usage when choosing libc implementation.
>> if it quits being maintained and users are advised to move to
>> binary driver - it would be nice to make it actually compile on such
>> systems...
>
> Just to posit, if you are intending on installing the nvidia binary driver
> on a niche built by hand system, then I don't think the glibc overheads
> would give you much cause. Wierdly you'd have gotten better battery
> life most likely using the binary driver since -nv doesn't have any powersaving
> abilities. So you are probably shooting yourself in the face to spite your foot
> or something.


yes, current state of nvidia driver(s) make such choice bad.

glibc overhead is not something 'worth' the 'powersaving abilities'
in many cases, so best choice is usually to just get laptop with other GPU
chipset, and use whatever one feels works best to him, despite being
'niche' .

i'm not going to discuss performance issues of such setup on this group
as this is largedly offtopic, recalling also times of libc5 transition,
when there was large group of people not believing 'heavy' glibc
implementation will be ever used by larger group of users...
also linux is 'niche' system in general , so this makes little point.

my point of above is that encouraging users to use driver which
does not compile on plenty of systems, and is limited in future 
development by simple design flaw ,  will generate lot of 
un-satisfied users. it is not impossible thing to fix it,
while there is still anyone caring to maintain the driver
(note many cards will be 'obsoleted' by nvidia pretty soon and
people will be left on their own with the drivers... better them be
as flexible and adaptable for system upgrades as possible)

--