Intel Continues To Divest In Wayland

[dungeon]

Yeah and mostly you can see Daniel's comment on that video, is how it is major PITA for nearly anybody to really understand what X does. Yeah it is PITA, but that does not mean that X is that BAD

It means just that X has its tradition and is used for many different purposes over time, supporting everything it can.... but from 10 years ago many things are also changed there, it became more modern than it was and serve just fine its current 99.99% users.

[justmy2cents]

Yeah and mostly you can see Daniel's comment on that video, is how it is major PITA for nearly anybody to really understand what X does. Yeah it is PITA, but that does not mean that X is that BAD

It means just that X has its tradition and is used for many different purposes over time, supporting everything it can.... but from 10 years ago many things are also changed there, it became more modern than it was and serve just fine its current 99.99% users.

problem being not if it serves ok for 99.99%, but rather if it is future proof which X simply is not. mixed DPI multiple monitors and other things... no one will ever implement that for X. most of the reason would be that developers them selves gave up on it. and the only thing that it changed for better is the fact that they introduced compositors which avoid X in the first place. relevant part of the talk https://youtu.be/RIctzAQOe44?t=1120

here is my personal example, kind of similar to X and also reason why i understand that position really well. as my daily bread job i write low level libraries (not OSS and acting as hired gun) which have 2 main requirements beside what and how it does what does
- 100% stable api (makes evolution really hard and it is most important requirement there is)
- no bugs

do they work? yes. 6 years without one single bug on being heart and soul of 30+ really large applications. am i proud of this fact? yes. do i get headache when i look at same must be stable code now? yes, but my code writing never changed. just my view on what i am solving and how ugly different some things became with time (original request being X and later it turns they actually wanted Y)

right now i'm working on new implementation from scratch for 2 reasons (not even requested or paid)
- i learned a lot new things about the problem i'm solving i couldn't even imagine and i learned what was good and was was not (not talking code, but problem solving). sad thing being that compatibility layer is taking 70% of my time, because patching new things into old one would still be more work long term due to second reason
- working around to add things is a really straining work and with each time, my strain grows bigger and bigger as does my dissatisfaction

in short, writing new one + compatibility layer is still less work long term for the same money. except everyones life will be much better. now the funny thing, i'm hearing same kind of scepticisms from my clients and these kind of doubts in me kind of piss me off. i mean, i wrote the first one from get go, wtf wouldn't i be able to write second? in reality they are just scared that if something wouldn't work out with compatibility layer they would need to work them selves too

[cjcox]

Answering (I think) my own question. Wayland isn't X in that it's not a network aware manager over a display. So, if I understand correctly, for most cases that would be fulfilled by running some sort of X that can talk to Wayland. So... rats... I was hoping somebody solved the current FreeNX woes (lack thereof) and the current state of x2go.

[Delgarde]

Answering (I think) my own question. Wayland isn't X in that it's not a network aware manager over a display. So, if I understand correctly, for most cases that would be fulfilled by running some sort of X that can talk to Wayland. So... rats... I was hoping somebody solved the current FreeNX woes (lack thereof) and the current state of x2go.

It's not a subject the developers appear to have put any effort into yet, beyond theory. But the answer does seem to be that it should be handled by the compositor, instead of trying to build transparency at the protocol level like X11 - apps just render their windows, and the compositor will be responsible for the network side of things, copying the data to another compositor on the other end of the link. Presumably, the underlying protocol will be something more like VNC than X11, but I don't think much work has gone into implementing that yet - X11 keeps working for the time being.

[MartinN]

To my understanding Wayland's rather robust as it is. Who Michael should be baiting instead (or in addition to) with his posts are framework developers like KDE and GNOME at this point to speed up w/getting rid of X and porting their frameworks/DEs.... and last but not least, the major distro makers - redhat, suse, arch, ubuntu, gentoo... to adopt them as quickly as possible/permissible.

[jrch2k8]

some Q and A, for those interested

Q.) X11 will dissapear?
A.) no, X11 will stay in maintence mode after maybe couple more releases, you just need to pick a more stable distro that provide X by default (slackware/Centos/RHEL are good candidates)

Q.) So after wayland is default i will loose my apps or whatever?
A.) No, wayland provide Xwayland to run your X apps, If by any chance one of your apps need a full X server is extremely likely your distro/Desktop provide a safe fallback just installing X from a stable repository(read you distro policy once the change happens)

Q.) I can disable or remove wayland compositor like i do in X today?
A.) No, but there is no reason to do so, In X compositors are not even considered in the protocol(compositing is probably 15 years newer than the latest X11 draft) and require many many roundabouts and hacks to work that can introduce glitches or performance hits compared to an old school software renderer blit/mask window manager but in Wayland compositing is added from the ground up and is direct(read no roundabouts or hacks) and is entirely hardware accelerated. Please note compositor doesn't mean "eye candy" but composite surfaces and input into a final image for you monitor, eye candy filters can be attached to that process tho without leaving the GPU(as long the language allows it aka DSA) and those filter can be deactivated if the compositor allows it(KWin effects for example)

Q.) Wayland will have remote rendering?
A.) no because wayland is not a server and is not aware of what is happening in the screen at all, only the compositor and toolkits are aware, each on its own scope of the render process, initially may seem a let down but protocols like RDP are performance hit free in the compositor and more efficient than X but for now we have to wait until desktops reach that point and start developing proper tools, for now you can keep using X for this need for all the time you want

Q.) Wayland is for embedded and such devices only?
A.) No, wayland was always focused for desktop and X11 replacement but the complexity of desktops (think something like Gnome 3) has make the adoption process slower(plus big desktop need to keep supporting X thus making it even harder/longer) whereas cellphones, embedded, IvI, and many other small devices don't require X compatibility and are actually pretty pretty simplistic compared to a full desktop hence thus have started to use wayland fully, way faster than fully fledged desktops.

Q.) Wayland support multi gpu and assymetrical screens?
A.) Yes, probably easier than Windows or Mac do, since the compositor and the applications have actual full hardware control(in their own scope) and is actually done in a secure way, for example:
1.) App A can request a surface in the GPU1 output 3 where your fancy 144Hz monitor is connected and will work at 144hz while App B request a default surface at GPU0 Output 1 where your regular 60hz 1080p monitor is and that one will work at 60hz but if you tell the compositor to move App A to your 1080p monitor it will start working magically at 60hz(dma_buf magic ), Ofcourse if your app do something too extreme to keep missing the hardware vsync that is another story regardless the system

Q.) Is true wayland can save lots of battery life in my portable devices?
A.) to certain extent yes, the way X handle rendering(specially with compositing active) always keep background noise in your CPU and GPU long enough to perturbate considerably the sleep process(mostly Xdamage and CPU-GPu sync fighting each other to death to keep a coherent image in the screen) but wayland handle hardware acceleration pretty efficiently and doesn't to use the CPU unless input is received or texture upload are requested(to the GPU) allowing the hardware to sleep more often and lowering frame latency very considerably. Notice many other factors can affect your battery life

Q.) Wayland play video perfectly or share the same sync issue with X?
A.) yes and no, Wayland can show video hardware overlays directly to the compositors(aka fully hardware accelerated) or use zero copy to tiled textures(need wayland 1.9) to capture the video from other sources(CPu bytestream output, opengl, v4l, DSP, State Trackers, etc)

Q.) Wayland have full driver support?
A.) No, so far only OSS drivers support wayland (RadeonSI so far must offer the best experience since it suport proper EGL 1.5 and GL 4+) but unlike X is currently missing support from propietary drivers like nVidia's. In the case of nVidia latest driver include strong signs that wayland and EGL support are on the work and may appear in future releases.
For now stay on X if this affects you.

Q.) Wayland support gaming?
A.) Yes, but for now X is a better option for gaming but is not a limitation in the protocol, simply put this area has seen lot of work lately but there are few implementation quirks left on the compositors to be tackled. For example:

1.) Input redirection need more work since right now the compositor and your game will fight to death to get input focus since neither can tell each other they are in fullscreen(or need exclusive grab) due to the lack of standarization, which is normal in the development stage but several desktop solution are being talked
2.) Wayland support true fullscreen GPU exclusive apps but the compositor still don't know this, because X didn't have this feature hence compositors require to actually code this and all agree in a way to do it(probably XDG_SHELL can help here) but it is in the works
3.) Im not 100% sure here but i think some compositors still can't handle directly certain types of texture and may slow down your games requiring to perform texture convertions, X didn't suffer from this since XPIXMAP is pretty much it for X texturing, but again is in the works

[jrch2k8]

some Q and A, for those interested

Q.) X11 will dissapear?
A.) no, X11 will stay in maintence mode after maybe couple more releases, you just need to pick a more stable distro that provide X by default (slackware/Centos/RHEL are good candidates)

Q.) So after wayland is default i will loose my apps or whatever?
A.) No, wayland provide Xwayland to run your X apps, If by any chance one of your apps need a full X server is extremely likely your distro/Desktop provide a safe fallback just installing X from a stable repository(read you distro policy once the change happens)

Q.) I can disable or remove wayland compositor like i do in X today?
A.) No, but there is no reason to do so, In X compositors are not even considered in the protocol(compositing is probably 15 years newer than the latest X11 draft) and require many many roundabouts and hacks to work that can introduce glitches or performance hits compared to an old school software renderer blit/mask window manager but in Wayland compositing is added from the ground up and is direct(read no roundabouts or hacks) and is entirely hardware accelerated. Please note compositor doesn't mean "eye candy" but composite surfaces and input into a final image for you monitor, eye candy filters can be attached to that process tho without leaving the GPU(as long the language allows it aka DSA) and those filter can be deactivated if the compositor allows it(KWin effects for example)

Q.) Wayland will have remote rendering?
A.) no because wayland is not a server and is not aware of what is happening in the screen at all, only the compositor and toolkits are aware, each on its own scope of the render process, initially may seem a let down but protocols like RDP are performance hit free in the compositor and more efficient than X but for now we have to wait until desktops reach that point and start developing proper tools, for now you can keep using X for this need for all the time you want

Q.) Wayland is for embedded and such devices only?
A.) No, wayland was always focused for desktop and X11 replacement but the complexity of desktops (think something like Gnome 3) has make the adoption process slower(plus big desktop need to keep supporting X thus making it even harder/longer) whereas cellphones, embedded, IvI, and many other small devices don't require X compatibility and are actually pretty pretty simplistic compared to a full desktop hence thus have started to use wayland fully, way faster than fully fledged desktops.

Q.) Wayland support multi gpu and assymetrical screens?
A.) Yes, probably easier than Windows or Mac do, since the compositor and the applications have actual full hardware control(in their own scope) and is actually done in a secure way, for example:
1.) App A can request a surface in the GPU1 output 3 where your fancy 144Hz monitor is connected and will work at 144hz while App B request a default surface at GPU0 Output 1 where your regular 60hz 1080p monitor is and that one will work at 60hz but if you tell the compositor to move App A to your 1080p monitor it will start working magically at 60hz(dma_buf magic ), Ofcourse if your app do something too extreme to keep missing the hardware vsync that is another story regardless the system

Q.) Is true wayland can save lots of battery life in my portable devices?
A.) to certain extent yes, the way X handle rendering(specially with compositing active) always keep background noise in your CPU and GPU long enough to perturbate considerably the sleep process(mostly Xdamage and CPU-GPu sync fighting each other to death to keep a coherent image in the screen) but wayland handle hardware acceleration pretty efficiently and doesn't to use the CPU unless input is received or texture upload are requested(to the GPU) allowing the hardware to sleep more often and lowering frame latency very considerably. Notice many other factors can affect your battery life

Q.) Wayland play video perfectly or share the same sync issue with X?
A.) yes and no, Wayland can show video hardware overlays directly to the compositors(aka fully hardware accelerated) or use zero copy to tiled textures(need wayland 1.9) to capture the video from other sources(CPu bytestream output, opengl, v4l, DSP, State Trackers, etc)

Q.) Wayland have full driver support?
A.) No, so far only OSS drivers support wayland (RadeonSI so far must offer the best experience since it suport proper EGL 1.5 and GL 4+) but unlike X is currently missing support from propietary drivers like nVidia's. In the case of nVidia latest driver include strong signs that wayland and EGL support are on the work and may appear in future releases.
For now stay on X if this affects you.

Q.) Wayland support gaming?
A.) Yes, but for now X is a better option for gaming but is not a limitation in the protocol, simply put this area has seen lot of work lately but there are few implementation quirks left on the compositors to be tackled. For example:

1.) Input redirection need more work since right now the compositor and your game will fight to death to get input focus since neither can tell each other they are in fullscreen(or need exclusive grab) due to the lack of standarization, which is normal in the development stage but several desktop solution are being talked
2.) Wayland support true fullscreen GPU exclusive apps but the compositor still don't know this, because X didn't have this feature hence compositors require to actually code this and all agree in a way to do it(probably XDG_SHELL can help here) but it is in the works
3.) Im not 100% sure here but i think some compositors still can't handle directly certain types of texture and may slow down your games/apps requiring to perform texture convertions, X didn't suffer from this since XPIXMAP is pretty much it for X texturing, but again is in the works

[darkbasic]

Thanks jrch2k8

[Luke_Wolf]

Michael, Ericg, jrch2k8 can you guys create a new extended FAQ article on Wayland using this content and otherwise so we have a modern version to point people to outside that forum post?