If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Out of the box support is highly unlikely. You have to lead the release of the hardware by an absolute minimum of 6 months. More likely closer to a year. And that's of course ignoring the LTS distros that don't update their kernels or drivers for years at a time.

A stable API would be much more useful. A stable ABI isn't so necessary, at least for FOSS drivers. Something like DKMS is more than sufficient; recompile the driver is the kernel is updated. Not super ideal, but it works. If installation CDs have a compiler on them and the system has enough temporary memory, it means you can even get a driver installed via USB stick or somesuch when your SCSI/RAID/SATA controller is missing the driver it needs to install. A stable API is sufficient to ensure that the user can grab a driver and install it on recent Linux distributions.

A stable ABI would be most user-friendly, but is literally never ever going to happen. The Linux developers actively despise making users' life easy because it requires them to spend more than 2 seconds thinking about their kernel interfaces.

First off, this is about the most sensible post in this whole thread. You put your finger on the issue correctly with the last sentence.

That being said; the API does not need to be stable, it should evolve naturally. But it will automatically and naturally become more stable and future-proof if developers do spend more than 2 seconds thinking about their interfaces. Everything else comes from there, naturally, and almost painlessly (it is less painful than the current situation, that's for sure).

Everybody could win, if only the supposedly more clued people would spend some time using that bigger brain that they are supposed to have. Or put differently: by continuing to refuse to work like this, those refusing only prove that they are not deserving of the status that they like to claim for themselves.

Comment

I think a good compromise would be if intel provided some backports for the most used distros

Some backports for some distributions is rather limiting.

What we need is driver developer provided backwards compatibility (with some features disabled) for some distributions: ideally, compatible with debian stable. The likes of Redhat, Canonical and SuSE can then do the rest of the work for their older enterprise releases (for which they get paid). The job of supporting such older infrastructure will also be overseeable in such a constellation.

This way, every user can do one of the following to get drivers installed:
1) install packages built by distribution maintainers, who also have an easy task, so updates are plenty and frequent
2) build driver stacks from source for a reasonably current distribution
3) spend some time on getting the code compatible
4) buy support
5) update infrastructure
6) use a closed driver (for the sake of argument)

Depending on different user classes, you can then start guessing at the numbers.

Guess what, those selling support will actually fare better:
* the user experience will vastly improve
* the market share will also improve (over time, we made a horrible impression so far)
* the manpower needed to provide graphics driver support will be reduced and can be rerouted to do more useful things

And, for graphics driver developers, there are the following advantages:
* vastly increased userbase for recent code: better testing!
* easier direct debugging: testing different versions of both driverstack and infrastructure is feasible
* easier user debugging
* less time spent dealing with bugs and support, more with development (but slightly more time will be needed there anyway)
* more pressure for closed vendors to open up
* bigger market share for free software

All that takes is the willingness to state: "Yes, we support up to debian stable", and to make that happen. When given the ability, users will then provide loads of testing, and will make sure that such support is not broken easily.

Comment

Out of the box support is highly unlikely. You have to lead the release of the hardware by an absolute minimum of 6 months. More likely closer to a year. And that's of course ignoring the LTS distros that don't update their kernels or drivers for years at a time.

No, this is our job, and we blew it for Sandy Bridge. We're supposed to do development well ahead of product release, and make sure distros include the necessary code to get things working (we have separate teams to do development and aid distros in backporting, though most of them can handle it by themselves these days).

I could give you all sorts of explanations as to why this is (Sandy Bridge is a big architectural change, we made some mistakes in defining our development milestones, and we didn't work hard enough to get our changes backported), but really there's no excuse. Fortunately we've learned from this and are giving ourselves more time and planning better for Sandy Bridge's successor, Ivy Bridge.

As for a stable ABI, yes it would definitely help situations like this and make lives easier for distros, device manufacturers, and probably users. But it would make life harder for developers, and as we all know, open source development is driven by developers, and we're a whiny and lazy bunch. (Yes, this is a flippant remark, don't take it too seriously since I omit much of the complexity behind the "life harder for developers" part that has big implications for users, distros, and device manufacturers; it's a complicated issue.)