Luc Calls For A Dead Linux Desktop If Keith Gets His Way

[smitty3268]

How about a bit of a compromise: keep actively developed drivers (radeon, intel, nouvoeu) out, but move the old drivers in permanent maintenance mode back in to allow for easier updating. I imagine that would make it easier to change the API in X if wanted, as well as leaving the drivers people care about able to release on their own schedules.

[V!NCENT]

Seems like a two year old fight;
"We're gonna do this my way!"
-"No my way is better!"
"Shut up!"
-"No you shut"
"My plan is the best!"
-"Your plan is going to destroy the world!"
"OK... Your plan is realy good, except for the fact that it will make the project fail!"

Seriously, with all that limited manpower; Why even bother with all the extra work it is going to take?
*sigh*

[FireBurn]

I'm still not getting the issue, I'm sure if there was an artical saying the drivers would be twice as fast by bringing them into the Xserver again people would be singing a different tune

Also they want to bring the DDX driver back into the Xserver not the Mesa 3D drivers which would mean the likes of Wayland wouldn't be effected

As someone who used to compile the whole of the Xstack daily I'm not seeing the problem at all, especally as drivers won't require as much IFDEFing as it only has to be compatible with the current Xserver not a multitude of servers

It's like Intel simplifying their stack, the fewer combinations there are the more likely there will be a working path

As for the Xserver being hairy or difficult to build - I've never had any issues - but if that is true I doubt it would stay like that long

It really would be interesting to know how many people in this flame war actually build anything directly from source pulled from git

As for the noise makers, try and remember who puts in all the work, it's the Devs, they should be the ones who choose, not people who install nightly binaries from DEB or RPM repos

[squirrl]

Oh yeah and it's almost 2011 like my prediction-._

[squirrl]

http://www.mail-archive.com/[email protected]/msg42660.html

Last year they called me a troll.
see above.

[allquixotic]

+1 for mostly maintaining the status quo.

Extra-extra-modularizing stuff even more than today would be bad for performance (all that dynamic linking and vtable lookups and runtime checking and void* APIs). Demodularizing stuff back to pre-modular X days would be bad for maintainability, and reintroduce the distribution headaches that made the stack so broken back then.

So I think the model that has been working well for Xserver 1.6, 1.7, 1.8, 1.9 should continue. Trying to change it either for more modularization or less is going to slow down progress on all the current driver work, create unnecessary churn, and cause problems in the long run. Leave well enough alone. God, software engineers are the worst example of people fixing things that aren't broken.

[bridgman]

In all of this, I keep coming back to the question of Mesa. Why are there "Mesa drivers" for different hardware? Mesa claims to be a software implementation of OpenGL. As such, there should be no drivers tied into it.

I think the real problem here is a slightly old web page. When Mesa was initially implemented and documented (16 years ago) it *was* a software implementation of "a graphics language similar to OpenGL". Hardware driver support was added later -- back when GPU hardware was *designed* around the OpenGL pipeline -- and the classic mesa HW driver interface reflects the fact that it was designed around "OpenGL-influenced hardware".

GPU internals have become much more programmable over the last 10 years, and the Gallium3D HW driver interface was proposed as a more modern replacement - designed around common GPU features rather than around OpenGL features. The Gallium3D HW drivers have been moved out of the mesa tree (although not the mesa *project*) so I think all the things you want are happening.

**

OpenGL driver is in /mesa/mesa project, src/mesa folder

Classic HW drivers were in mesa/mesa project, src/mesa/drivers/dri folder (inside mesa)

Gallium3D drivers are in mesa/mesa project, src/gallium folder (outside mesa)

[pingufunkybeat]

In all of this, I keep coming back to the question of Mesa. Why are there "Mesa drivers" for different hardware? Mesa claims to be a software implementation of OpenGL. As such, there should be no drivers tied into it. One should create a GL driver, and where the hardware does not support a feature you can add a dependancy on Mesa to handle it in software (very slowly). It seems that instead things are flipped around and Mesa is the center of the universe and it has drivers to *help it* where possible. IMHO if you have hardware that supports some GL version, you should be able to implement a driver that supports that with no Mesa dependency at all. Or is this what Gallium is attempting to do?

Each driver which accelerates OpenGL must have an implementation of the OpenGL API, which is a huge amount of work. Mesa is such an implementation, and adding a different codepath to already existing functions is easier than rewriting OpenGL from scratch.

Keep it modular and work on getting hardware specific code out of Mesa.

This is roughly what the Galium3d infrastructure brings.

[nanonyme]

In all of this, I keep coming back to the question of Mesa. Why are there "Mesa drivers" for different hardware? Mesa claims to be a software implementation of OpenGL.

*cough* Similar to OpenGL.

[personman]

*rant* *rant* Can somebody of phonorix please change the title from 'Luc Calls For' to 'Luc Warns For'. Please don't put up such nonsense titles again phonorix.

Thats what I said!

http://www.phoronix.com/forums/showpost.php?p=148258&postcount=7

Where exactly is the "call for a dead linux desktop?"

A developer theorizes that moving the drivers in to the server will kill the linux desktop... He doesn't "call for it."

I theorize that a volcano will erupt... Does this mean I advocate volcanoes?

"Luc is very much in starch opposition..."

Potatoe fight?

Ridiculous... Before there was the "disaster" of an RC1 KERNEL with a performance degredation.

You know... we have a fairly high-brow, technicly proficient audience here.

BS and sensationalism is unneccasary. IIRC, I've seen threads on other sites using Phoronix as a joke/insult because of these over-sensationalized headlines.

-Andy