NVIDIA Provides RandR Patch For Border Property

[JanC]

I'll probably never understand this as I can't fathom how it'd ever be impossible to create a standardized language/ABI which is open to future improvements while retaining backwards compatibility. OpenGL 4.0 exists, why can't Linux Graphics Driver ABI 4.0 exist? You make that part of the kernel, and then you can use any driver that supports LGDABI 4.0 or older. :P This would allow drivers to be shipped along with hardware and give users, developers, and hardware vendors more freedom and flexibility.

Standards = freedom = good.

The linux kernel & X have some more-or-less standardized APIs that some hardware manufacturers support to some degree; but obviously not all of them want to support all of it (currently), and certainly not many support all of those APIs. As long as they don't support those APIs, there is an almost zero chance that a common ABI can exist. In any case such an ABI would probably (have to) change quite regularly for the semi-near future anyway.

One reason why a GPU manufacturer/designer doesn't support current APIs might be that those APIs don't fit well with either their hardware or their current driver core. It seems like several manufacturers chose to create their own alternative for those APIs, instead of trying to help to fix the current API so that it works well for everybody (or maybe some "users" of the current API try to slow down changes?). At least Nvidia did the right thing for RandR this time (although a bit late maybe, but the final effort counts).

But unfortunately, GPU manufacturers aren't used to collaboration, and they don't (yet?) seem to see the advantage of it... (I'm not talking about individual cases here; individual developers inside those companies, etc.).

And of course there are the issues with patents & other stupid blah blah blah...

[Yfrwlf]

The linux kernel & X have some more-or-less standardized APIs that some hardware manufacturers support to some degree; but obviously not all of them want to support all of it (currently), and certainly not many support all of those APIs. As long as they don't support those APIs, there is an almost zero chance that a common ABI can exist. In any case such an ABI would probably (have to) change quite regularly for the semi-near future anyway.

One reason why a GPU manufacturer/designer doesn't support current APIs might be that those APIs don't fit well with either their hardware or their current driver core. It seems like several manufacturers chose to create their own alternative for those APIs, instead of trying to help to fix the current API so that it works well for everybody (or maybe some "users" of the current API try to slow down changes?). At least Nvidia did the right thing for RandR this time (although a bit late maybe, but the final effort counts).

But unfortunately, GPU manufacturers aren't used to collaboration, and they don't (yet?) seem to see the advantage of it... (I'm not talking about individual cases here; individual developers inside those companies, etc.).

And of course there are the issues with patents & other stupid blah blah blah...

It seems like DirectX was fairly successful, but who knows if that is due to it being an ABI graphics card makers liked, or if it was simply due to the monopoly of Windows, but either way Linux needs the same thing for all of it's graphics needs as well. Fortunately now some of the new X window managers are using OpenGL and whatnot, but of course that doesn't address the kernel ABI issue. The only standard I know of that gets used is DKMS, but that's more of an automatic compilation mechanism and while welcome doesn't count as a standard ABI. So what if it would be a fairly big project to add such a feature to Linux, it would be such a nice feature.

It's sad when projects lack standardised ABIs. Take Firefox for instance. Always making plugin developers have to update their plugins for newer versions of Firefox. Firefox devs need to stop and make a standard ABI for plugins to solve that problem. Maybe the issue is the same for both projects and it's that they're unsure of what all that standard needs to include, or they know that many more features need to be added in the future so feel it'd be a waste to add it now. To that I'd call bollox, because there's no reason current features couldn't use a current ABI, and then you extend the ABI later on once you have newer features in place. Are drivers/modules/plugins working now? Yes? Then why don't you have an ABI now for them? I don't think there's an excuse other than, "I don't want to do even more work, even though that work will make much less work for others and will be a loved feature".

[jonwil]

Part of the problem I suspect is that graphics vendors dont want to use the Linux APIs that exist because that would make it harder to keep their linux and windows drivers largely the same under the hood (i.e. they want to keep the amount of linux specific code in their proprietary drivers as small as possible). For example, its much easier for ATI/NVIDIA to keep using their own OpenGL stacks (that are shared between Windows and Linux) than to try and work with MESA/Gallium3D/whatever.

Also, the licenses for some of these libraries and things are such that using them requires the vendor to open up more of their code than they would like.

[Brandon Kevin]

clip off a section and take it to your local nursery they will identify it








_____________________________