[cleanup] wayland

[stefansaraev]

wayland support is unmaintained, and heavily depends on boost.

fyi @FernetMenta

[FernetMenta]

+1
jenkins build this please

[a1rwulf]

Maybe dump question:
Will Wayland still replace X in the future?

[fritsch]

@a1rwulf yes it will. Remember "revert" is always an option. If someone wants to work on wayland he can exactly start with this code.

[a1rwulf]

+1 then :)

[FernetMenta]

http://wayland.freedesktop.org/faq.html#heading_toc_j_4

nobody knows when and how. I don't think OpenGL will be dropped in favour of GLES. Means this code needs to support OpenGL too. I don't think "revert" of the drop will ever be an option but github don't forget this code and snippets can be reused.

[MaxKellermann]

FYI: I will revert this (undocumented!) commit in my Kodi fork, because I was about to switch my Kodi box to Wayland. Then I will fix all occurring issues. Just in case somebody's interested in my code, you know where to find it.

[FernetMenta]

thanks. good to know.are you going to drop boost from this code?

[MaxKellermann]

From a first glance, it looks like Kodi's Wayland code uses only Boost libraries that were obsoleted by C++11. With some time (and confidence that you're going to merge it), I'll replace that, but that's a minor priority. My goal is to make it work and make it stable, and removing Boost doesn't help with that goal.

[FernetMenta]

I would redesign this from scratch, maybe reuse some code. Under windowing Wayland needs to be at the level of X11, OSX, Windows, not in the mess of egl. It should be ready to support OpenGL and GLES. The current limitation of GLES only makes it pretty useless for most systems because neither VAAPI nor VDPAU work.

[fritsch]

VAAPI can be made working, nvidia can't even without X11 dependencies, it needs X11.
Better said: VDPAU currently only has X11 integreation: http://http.download.nvidia.com/XFree86/vdpau/doxygen/html/group__api__winsys__x11.html

[FernetMenta]

VAAPI can be made working

theoretically. in our code VAAPI rendering is bound to OpenGL. do you want to move this to GLES? have fun :)

[fritsch]

Nope - I just have the fun of my life with the current project ...

[MaxKellermann]

How is EGL a mess? EGL is a perfectly fine way to initialize OpenGL or GLES on Wayland. Actually, it is THE ONE way to do it. See http://wayland.freedesktop.org/faq.html

Does anybody here believe that Wayland is limited to GLES, and cannot use OpenGL? That would not be true.

There's a lot of wrong and overly complicated in Kodi's EGL initialization code, yes. It's a fragile and bloated mess of spaghetti code. But there's nothing wrong with EGL itself.

[MaxKellermann]

I can now run Kodi on Wayland + EGL + GLES2. Fixes are in my fork's master branch (https://github.com/MaxKellermann/xbmc).

[lrusak]

@MaxKellermann thanks for updating wayland in your branch. I maintain an OpenELEC version that is using wayland. see https://github.com/lrusak/OpenELEC.tv/tree/wayland

Using your branch I was able to get Kodi built with VAAPI support on wayland. However I don't have any intel graphics so I am unable to test. If anyone would like to test the build is available at https://openelec.freestylephenoms.com/wayland/

Hopefully we can work at getting Wayland support back into Kodi ;)

[MaxKellermann]

I run Kodi on a NUC with an Intel GPU. I havn't tested Wayland+VAAPI yet, but I will soon. If it doesn't work, I'll fix it.

[lrusak]

@MaxKellermann I had another OpenELEC team member test your wayland build with my OpenELEC build. The results are good and not so good.

https://github.com/lrusak/OpenELEC.tv/issues/1

Let's take the conversation over there to avoid spamming everyone here.

[MaxKellermann]

Upon @FernetMenta's request, I removed Boost from the Wayland code, replacing with standard C++11 - except for boost::scope_exit and boost::tokenizer.

[MaxKellermann]

After fixing @lrusak's problem (https://github.com/MaxKellermann/xbmc/commit/f693ebc4), video playback works very well with Wayland/EGL+GLES2+VAAPI on my NUC with Intel GPU. My fix is not specific to Wayland, but was an incomplete shader implementation that affects all GLES2 platforms, but was never visible, because apparently only VAAPI uses that YUV encoding. You're welcome to cherry-pick that bugfix (or cherry-pick many more of my commits).

[FernetMenta]

I consider this more a feature than a fix because I implemented NV12_RRG for vaapi only and vaapi is only available for OpenGL (in master)
If anybody wants to re-submit wayland, it has to comply to the architecture. That is no components under the folder windowing/egl, no boost.

[MaxKellermann]

Let's get this project started by merging my VAAPI+GLES2 and VAAPI-without-X11 patches. These are not specific to Wayland - they may be used as well by a (future) DRM windowing implementation. I'll write one, which is useful for appliances which do nothing but run Kodi full-screen. No X11, and no Wayland. Just Kodi on an accelerated frame buffer.

[FernetMenta]

Let's get this project started by merging my VAAPI+GLES2 and VAAPI-without-X11 patches

Without the changes that trigger this path it would be dead code. I am not sure how many lines of code I had to clean up because of code implemented for future use. I even have an active PR of that category: https://github.com/xbmc/xbmc/pull/9035/files
Neither the return value nor the parameter of PresentRender were ever used. I hope you understand this.

[MaxKellermann]

@da-anda I understand your worries. Kodi is a giant mess, and is in need of a major rewrite. I understand that going a step backwards appears like the wrong direction. Your worries are ostensibly reasonable.

In this specific case, I tried to explain how I planned to get EGL right, and why this is better to get the old code back first, before doing the actual cleanup. You disagreed. I explained why it's important for me to do it that way. You rejected this. That was your decision.

I won't change my mind about this - I'll just leave the EGL mess up to you, and care for my other projects, no big deal. Just in case you change your minds, just tell me.

[smspillaz]

Hey, as the original author of this code (or mess), just wanted to drop a thanks to @MaxKellermann for maintaining it.

I agree that most of the boost stuff can be dropped if C++11 is the new build target.

I'm also happy to offer my help if its needed.

[MaxKellermann]

@smspillaz already done. In my repository, I have replaced all Boost dependencies with their C++11 counterparts. No Boost required for Wayland.

[smspillaz]

@FernetMenta I might be able to volunteer to clean up the EGL stuff. I remember I was going to look at it some time ago and then life happened.

Back when I worked on this backend, I actually implemented it as a separate window system. I was told that it needed to go into egl/, so I put it into egl/.

I think the architecture that makes more sense is to consider the stuff in egl/ as a "support" library for the rest of the backends. That's how its meant to work anyway. You create a native window on the windowing system and then use a platform native API to get an EGL surface from that. Then you call into EGL and create a context.

Ideally, all the stuff in WinEvents needs to be merged back into their constituent windowing backends too. Its a bit of an artificial separation.

Let me know if you wanted to discuss more over IRC as to how it should be done.

[FernetMenta]

@smspillaz good to hear from you again. Would be great if you could work on this. What timezone are you currently staying? Did you join our Slack channel already?

[smspillaz]

@FernetMenta Likewise! I haven't joined the slack channel yet, though I'm in the IRC channel. I'm currently GMT+8

[FernetMenta]

Update: Wayland does support OpenGL. This makes it even more clear that it makes no sense having it under the crappy EGL tree that is tied to GLES.
It is likely that Wayland will be back in v18.

[MaxKellermann]

So, what's your plan for bringing Wayland back? And what with the other existing ports still using the crappy EGL tree?

[FernetMenta]

So, what's your plan for bringing Wayland back?

The plan for the architecture has not changed. Wayland needs to be implemented as its own windowing system like X11, OSX, or Windows. Further it needs to support OpenGL in the first iteration.

And what with the other existing ports still using the crappy EGL tree?

That is a different story and not related to Wayland. Common code related to EGL can be factored out later.

[MaxKellermann]

My past suggestion was to re-add the old Wayland code and then incrementally refactor all of the existing EGL code, in order to make them all conform to your (yet-to-be-defined) architecture. You rejected that approach back then. Is that still your opinion, or did you change your mind meanwhile?
(I'd like to help, but I will not help with starting from scratch, throwing away all of the existing (working) code for 5 windowing systems. I think that's an unnecessary waste of time.)

[FernetMenta]

The plan won't change. It is fairly simple to move code around and getting a high rate of reuse.

[MaxKellermann]

That does answer my question. Your plan describes only the final goal, not how you achieve it.
But I take this as "you didn't change your mind, and you don't want me to help". Ok.
Anyway, Wayland support in vanilla Kodi is good news. I'm looking forward to see your new code.