More Work On Red Hat's Wayland Project

[elanthis]

And performance will suck
source: http://www.kernel.org/pub/linux/docs/lkml/#s15-3

Taking advice from quotes from 5+ years ago about problems encountered 17+ years ago by people who were never knowledgeable C++ programmers is pretty stupid. C++ has no problems with kernels or performance on any sane compiler when being used by any sane developer. Anyone thinking otherwise has their head up their arse, and that fully includes Linus and company.

[Vighy]

Personally I'd love to see a c++ OS project doing a microkernel and using a linux driver compatibility layer for a lot of hardware support at the start. It'd be doable and interesting but wouldn't be useful for a long time.

And performance will suck
source: http://www.kernel.org/pub/linux/docs/lkml/#s15-3

[Ze..]

I guess in theory it would remove the additional context switches from dispatching window events and stuff, but then to really get any advantage you'd need to move the whole WM and Compositor into the kernel.

Then you end up moving everything into the kernel and ending up with a single address space instead of virtual memory.

Really, the only reason modesetting, memory management, and command submission belong in the kernel is because the kernel _needs_ them to be able to reclaim control of the display. The kernel has zero use for window management, window event dispatch, or so on, so there is absolutely no need for those functions in the kernel.

The alternative is to go to a micro-kernel based operating system and a lot of these issues disappear (others come up though).

Personally I'd love to see a c++ OS project doing a microkernel and using a linux driver compatibility layer for a lot of hardware support at the start. It'd be doable and interesting but wouldn't be useful for a long time.

[elanthis]

Not sure I agree. Once you put modesetting, memory management and command submission into the kernel you don't gain much from moving anything else down.

I guess in theory it would remove the additional context switches from dispatching window events and stuff, but then to really get any advantage you'd need to move the whole WM and Compositor into the kernel.

And, honestly, there's no guarantee that would actually make any noticeable difference besides having a more crash-happy and insecure kernel. The only time I feel any latency in Linux desktop stuff is when X is doing a bunch of rendering/blitting work because my video chipset still lacks EXA/GL acceleration.

Really, the only reason modesetting, memory management, and command submission belong in the kernel is because the kernel _needs_ them to be able to reclaim control of the display. The kernel has zero use for window management, window event dispatch, or so on, so there is absolutely no need for those functions in the kernel.

[bridgman]

Not sure I agree. Once you put modesetting, memory management and command submission into the kernel you don't gain much from moving anything else down.

[lmax]

Why not put Xserver into kernel? Linus should consider..

As a service in user space, xorg can NEVER be efficient as WinXP.

[Vighy]

what can we learn through Wayland?

What X could gain from it?

[TechMage89]

Quartz might be messed up under the hood, but at the very least, they built it from scratch, based on what they needed, and based on what modern hardware can do.

X still has the problem that much of its internals are based on decades-old assumptions of needs, and trying to fix all that while maintain compatibility and continuity is a serious challenge.

I would welcome of new X implementation. Even neglecting the benefit of being able to build on a new, clean, codebase and not have the cruft and legacy code that have plagued Xorg, having choice is good, even for something as fundamental as an Xserver.

Choice is very useful in open-source software, and having choice in an Xserver might be helpful. Wayland, alas, is not quite it. (Although it is an interesting project in its own right.)

[puelocesar]

Srsly,I bet Quartz is just as messed up under the hood as Xorg is.

Well, it can be, we don't know, but at least it works WAY better! Faster and more lightweight too

I was horrified when I installed a Hackintosh on a Celeron D, using a VESA driver and it was much faster (2D at least) then my linux box, and it also could do shadows, transparency, scale and all these 2D fancy things without any lost of performance..

Don't get me wrong, freedom in linux and openness of the platform is much better then all that lock-in and arrogance from Apple, but we have to admit they really do nice graphics

[Zhick]

Well, so it's sad, because I really hoped of a new, modern replacement to old X... We are lagging years behind Apple with their Quartz..

Srsly,I bet Quartz is just as messed up under the hood as Xorg is.