Mesa Developers Discussing Again Whether To Fork Or Drop Non-Gallium3D Drivers

[smitty3268]

Yes, but things glibc and xserver change frequently. A fork of mesa wouldn't even compile in a year or two at best.

What makes you think a LTS fork wouldn't be maintained?

Isn't that the entire implication of calling it "Long Term Support", and not an "Abandoned" fork?

Presumably the devs will make sure it all continues to compile and work on modern systems, they just wouldn't be adding any new features to it anymore.

Oh, and xserver is definitely not changing frequently anymore.

[duby229]

What makes you think a LTS fork wouldn't be maintained?

Isn't that the entire implication of calling it "Long Term Support", and not an "Abandoned" fork?

Presumably the devs will make sure it all continues to compile and work on modern systems, they just wouldn't be adding any new features to it anymore.

Oh, and xserver is definitely not changing frequently anymore.

Because that's the entire reason for wanting the fork... If they don't want to maintain old drivers now, what makes you think they will keep an old fork compiling that they don't want to maintain? They can call it what they want but the end result is that some user somewhere is going to get stuck with the burden of their decision.

[smitty3268]

Because that's the entire reason for wanting the fork...

Keeping drivers working with new kernels/compilers/x isn't the reason they want to fork.

If they don't want to maintain old drivers now, what makes you think they will keep an old fork compiling that they don't want to maintain?

Keeping existing code working isn't the problem. It's updates in common code made for newer hardware that then break older hardware drivers that is the problem.

[fuzz]

The drivers are all open source. Anyone is free to step up and write a new driver or help maintain the code, etc. It's supposed to be an open source community.

Is there some good documentation somewhere on how to start with driver development? I think, for most of us, the problem is more capability than will.

[agd5f]

Is there some good documentation somewhere on how to start with driver development? I think, for most of us, the problem is more capability than will.

Curiosity and the desire to learn. Most open source developers started out just poking around in the driver, gradually growing their understanding. Read through the source code. Add print statements and try to understand the basic flow. In general most drivers do a bunch of stuff at load time and then just sit there waiting for someone to call an ioctl. Look at patches and try to understand how the patch solves the stated problem. Then start to tinker yourself. Try changing a parameter here or there and see how it changes some operation. Rinse and repeat. Feel free to ask questions on the mailing lists or IRC. Before you know it, you'll be creating your own patches.

[fuzz]

Curiosity and the desire to learn. Most open source developers started out just poking around in the driver, gradually growing their understanding. Read through the source code. Add print statements and try to understand the basic flow. In general most drivers do a bunch of stuff at load time and then just sit there waiting for someone to call an ioctl. Look at patches and try to understand how the patch solves the stated problem. Then start to tinker yourself. Try changing a parameter here or there and see how it changes some operation. Rinse and repeat. Feel free to ask questions on the mailing lists or IRC. Before you know it, you'll be creating your own patches.

Thanks, it's often just the little things on how to get started.