The way to Wayland: Preparing for life After X [LWN.net]

The way to Wayland: Preparing for life After X

Posted Nov 19, 2010 15:01 UTC (Fri) by quotemstr (subscriber, #45331)
Parent article: The way to Wayland: Preparing for life After X

> Wayland is also poised to support GPU hotswapping

For Christ's sake, you Jacobins complain that "nobody" uses network transparency, then you go on to tout *GPU HOTSWAPPING*? That's brazen and maddening. It smacks of other motivations.

I can't believe you people aim to utterly castrate the Linux desktop for... this. You still can't explain exactly what it is about X11 that you find so distasteful. You can't demonstrate what aspects of its architecture cause local performance issues or come up with benchmarks to support your dubious assertions about network transparency harming performance. X11 could support every feature you mention; every previous challenge has been successfully met with an X11 extension. Your particular case is no different.

It seems as if you're entirely motivated by a simplistic rejection of the old in favor of the new ---- no matter what the relative merits of the two. Wayland has nothing to do with improving the state of the desktop and everything to do with a bunch of cretins burning down the great old edifice of Unix out ignorance and fear. It's as if you think X11 is some evil demon that need to be driven out. It'd be ridiculous if distributors weren't listening, but they seem to be full of adherents to this asinine, reactionary religion.

(Log in to post comments)

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 19:49 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

Not tearing doesn't require ditching X. All you have to do is have the compositor synchronize with the display: you can do that with triple bufering, or by putting the compositor in the X server.

What part of that requires ditching the X protocol and architecture?

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 20:29 UTC (Sat) by glisse (subscriber, #44837) [Link]

Tearing can be solve not too badly with compositor but without compositor please feel free to show me how to do it (it means thinks 10 times before even remotely believe you have one solution).

So now with a compositor here is what happens :
app->toolkit->render window(gtk/qt/cairo ...)->upload to X as a pixmap (memcpy new buffer allocation + others overhead)->compositor use it has a texture->screen

Wayland:
app->toolkit->render window(gtk/qt/cairo...)->give buffer id(ie send an int)->compositor use it as texture->screen

Suddenly you removed all the X protocol, all the memcpy non sense, all the painfull path to try to make it right in the DDX. And now life is beautifull. I am not even mentioning app half rendered and others rendering non sense of X.

X is painfull to accelerate and even more to get it right, i have been writing X driver for few years now and what i can tell you is that i prefer writing a GL driver than an X driver.

But please if you feel X is the right way come join us and wrote driver to truely use GPU with X.

Bottom line is if all X people says that they want wayland then it just means it's what you will get in your distribution sooner or later unless new people step up and shows all the X people how X was supposed to be done.

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 20:45 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

Tearing can be solve not too badly with compositor

So you concede that tearing can be fixed within the X protocol.

please feel free to show me how to do it

You can do it with a novel technique called double buffering. I mean, it was only invented in the 1980s: you may not have heard of it yet.

app->toolkit->render window(gtk/qt/cairo ...)->upload to X as a pixmap (memcpy new buffer allocation + others overhead)->compositor use it has a texture->screen

Cairo and other toolkits can render directly using XRENDER or OpenGL. The XRENDER and OpenGL operations are sent symbolically to the X server, which then hands them off directly to the GPU. There's no client-side pixmap and memcpy involved. You're either disingenuous or ignorant.

X is painfull to accelerate and even more to get it righ

Boo hoo, programming is hard! Let's burn the place down instead.

wrote driver to truely use GPU with X

What specific operations that are not accelerated today would be accelerated under your proposed architecture?

i prefer writing a GL driver than an X driver

Your statement is nonsense. What's the difference? When writing an X driver, you don't have to care about it being for X per se. A graphics driver deals with the same primitives in any environment: mode setting and acceleration. That's why nVidia can use the same codebase for its drivers on all platforms.

if all X people says that they want wayland

If that's the case, then the X people have lost their minds.

The way to Wayland: Preparing for life After X

Posted Nov 20, 2010 23:55 UTC (Sat) by glisse (subscriber, #44837) [Link]

Double buffering, i surely never heard of it ... Likely because i am an ignorant :) But i don't want to be more disingenuous with you, was fun talking with you, can't wait seeing you on Xorg devel you have a lot of things to teach us.

The way to Wayland: Preparing for life After X

Posted Nov 22, 2010 0:32 UTC (Mon) by bronson (subscriber, #4806) [Link]

quotemstr, you sound like you're saying "It's just a software problem! That's easy!!"

Have you contributed any code to X? If you actually do have real-world experience with this codebase, then I am definitely interested in what you have to say. But if your point is that someone else can fix everything, I can only conclude that your shrill opinion carries very little water at all.