(2017-03-21, 14:33)RockerC Wrote:

(2017-03-21, 00:24)yolk Wrote: Ah OK - I didn't look specifically into VDPAU. But if that's clear there is no reason to include it in the proposal, so I've removed it.

Could substitute VDPAU with VAAPI (VA API)? http://en.wikipedia.org/wiki/Video_Acceleration_API

(2017-05-06, 16:13)FernetMenta Wrote: Kodi's presentation component is independent from decoding APIs like VAAPi or VDPAU. Kodi renders GL textures. The requirement on a windowing system is that Kodi needs to know when a texture rendered through GL becomes visible on screen.

(2017-05-06, 16:13)FernetMenta Wrote: Kodi also needs to sync its clock with vertical retrace aka vblank. The windowing system should provide some mechanism to do so.

(2017-05-06, 18:13)FernetMenta Wrote: 1) presentation
For this thread we stay with GL rendering and our own color management. We have things like 3dlut and I think doing this at the app level leaves us with more options.

Rendering video in paralled to GL may be an option for an additional path. As you said, something for the futur.

(2017-05-06, 18:13)FernetMenta Wrote: 2) vblank
We don't use this for precise timing but to sync the clock. We allow an variance of 30% and also have some error correction if we miss a vblank. The point here is that display fps never matches video frame rate to 100% and if you sync to system clock sooner or later the error gets bigger than frametime. Dropping a frame or duplicating one causes noticeable stutter.

(2017-05-06, 14:34)daniels Wrote: Congratulations on being accepted this year! I'm one of the Wayland developers, and would be more than happy to help and answer any questions you have, either here or as 'daniels' on Freenode.

Using wp_presentation would be really great. Unfortunately it's still not implemented in Mutter for boring internal infrastructural reasons, but I'd expect that to change soon.

Native YUV support would also be really nice to have, though again, Mutter doesn't yet support it. :\ The news article linked to is very old, which mainly describes work with the wl_drm protocol, something which is an internal implementation detail of Mesa and thus not supported on other platforms. We do also reserve the right to break that interface, so please don't rely on it! Instead, I'd be looking more towards the zwp_linux_dmabuf_v1 interface, which is again supported by Weston, and will be supported by Mutter within the next couple of months I hope.

Using dmabuf directly allows you to be in full control of the presentation layer, not having to route around EGL/VA-API's own presentation support. If this is a viable option then I'd personally be very happy to see it, though I wouldn't be surprised if this required a fair bit of rework on Kodi, so please don't necessarily take this as good advice. This is the route VA-API is going down as well: allowing clients to access dmabuf handles directly and drive presentation themselves.

Best of luck with your summer, and please get in touch if I can help at all!

• Decide on what library to use for communication with the compositor: I tried out libwayland-client, the old Kodi-specific Wayland protocol wrappers (from the prior implementation from 2013 or so) and waylandpp. In the end I chose waylandpp because the object-based protocol of Wayland really shines when used with C++ (which rules out libwayland-client, which is C) and the home-grown C++ wrappers were too much of a burden to write by hand, considering that the list of interfaces and methods that needs to be supported grows with each feature. waylandpp seemed abandoned at first but I put out a few pull requests on GitHub which the author promptly merged. This is a very good sign and means that it probably won't be necessary to maintain a Kodi-specific fork of waylandpp. I do have a fork on GitHub though that should be used for the time being for compiling Kodi since I often add new features to waylandpp, use them in Kodi, and then submit a PR to the waylandpp owner afterwards, which means that necessary features might not be upstreamed yet. I expect this to change once things get more stable.
  
• Finish porting all features that the prior implementation had - and more :-) among the additional features are things such as full Unicode input (think e.g. Cyrillic), having a window icon in the task switcher, not displaying a mouse cursor when no mouse input is available, and selecting a monitor for fullscreen display
  
• Work on getting VAAPI support back (in-progress)
  
• Start xdg_shell integration
  
• Do some clean-up in Kodi related to the event system which was based on SDL, which is thoroughly obsolete by now
  

• Basic Wayland windowing support: Got Kodi running on Wayland again with basic features (only full screen, only full GL, mouse/keyboard input)
  
• xdg_shell: Wayland has the core wl_shell protocol for communicating details about toplevel windows, but it is deprecated for all practical purposes. To get better integration, support for the still unstable designated successor xdg_shell (version 6 only) was added.
  
• VAAPI support
  
• GLES support
  
• Screensaver inhibition: Support for both the generic org.freedesktop.ScreenSaver DBus interface as well as the Wayland-specific idle inhibit protocol was added.
  
• Touch input: Kodi/X11 does not have the ability to navigate using multi-touch gestures since touch is only supported via the default X pointer emulation. Kodi/Wayland has full native touch input support.
  
• Paste from clipboard
  
• wp_presentation support: The stable wp_presentation protocol provides detailed timing information about displayed frames and is now used for determining display latency and for syncing to video clock on Kodi/Wayland.
  
• Windowed mode: Most Wayland compositors require applications to draw and handle window decorations themselves (called client-side decorations) if they want to have any. I discussed with my mentor how to go about this and we decided to once again keep things local to the Wayland implementation and draw the decorations there as none of the other windowing systems currently requires this. The other option would have been to somehow integrate the decorations into the Kodi skinning system. This is of course nicer, but far more complicated and probably not worth the trouble. As media center, most users will use Kodi in full screen mode which is also the default, so window decorations that don't look that nice will not be a big problem.
  
• tools/depends integration for CI: Dependencies for the Wayland build (mostly waylandpp) needed to be added to tools/depends in order to have it build on Jenkins, which the Kodi project uses for continuous integration.
  

• Refactor Kodi resolution setting
  
• Kodi skin cursor image could be placed into the Wayland cursor surface to reduce input latency (at the moment the Wayland cursor surface is empty/unused and Kodi paints the cursor directly into its surface with GL)
  
• Allow X11 and Wayland in one Kodi build (at the moment Kodi can only be built with one windowing implementation set at compile time): While this would be desirable to facilitate quick adoption of a Wayland, it was ultimately decided that the Kodi core changes if done right would be too extensive to finish in time. Possible work-arounds include shipping two builds plus a wrapper script that starts the version corresponding to the active display server. See here for more details.
  
• Add facilities to switch resolution and/or frame rate: Wayland currently has no satisfying protocol support for clients that need specific output parameters (except for fullscreen-shell, see below). Therefore, solving this and enabling the resolution adaption in Kodi would require designing and upstreaming a Wayland protocol extension that enables applications to communicate their requirements to the compositor as well as implementing it at least in weston.
  
• Support for unstable fullscreen-shell protocol to provide modesetting: fullscreen-shell is an alternative shell protocol for a single application to run on a compositor in full screen mode. It has modesetting capabilities. Unclear if needed since Kodi now has a native gbm backend that will result in approximately the same thing (minus the Wayland compositor in between). The gbm backend currently only supports GLES, but it could easily be expanded to full GL.
  
• Support for zero-copy video rendering of video to YUV surfaces: Still questionable if benefits justify the necessary work
  

• Stop application on SIGINT and SIGTERM
  
• Fix fallout
  
• Fix XBMC_event fallout in WinEventsWin32
  
• Posix/Win32 main refactor
  
• SDL Event cleanup
  
• More SDL event cleanup
  
• Rework OS screen saver handling
  
• DBus refactoring
  
• DeviceKit cleanup
  
• Restore = default constructor for DBusConnectionDeleter
  
• Modernize CEventGroup
  
• Support more yuv420p bitwidths for direct rendering on Linux
  
• Change CVideoSync stop flag from atomic bool to CEvent
  
• Log filter graph only when video component logging is enabled
  
• Remove autotools files from gitignore
  
• Fix missing include when building for X11 without VAAPI and VDPAU
  
• Remove unused parameters on ResetRenderSystem()
  
• Build libusb without -Werror
  
• Explicitly disable guile in GnuTLS build
  
• Fix crash when VAAPI is not available at runtime
  
• Remove dependency on zip always and on unzip for everything but Android
  
• Fix path autoconf-pre-depends looks in for m4
  
• Assorted touch fixes
  
• Integrate Wayland build into buildsteps
  
• [wayland] Fix compilation with older gcc
  

• Allow copying of empty proxy_t
  
• Allow public access to proxy_t c_ptr() and state
  
• Make proxy_t bool operator and proxy_has_object() const
  
• Fix enum protocol type
  
• Introduce read_intent for announcing FD read intent with RAII
  
• Add wayland:et_log_handler
  
• Add proxy_t::get_version
  
• Add interface_name constant to generated interfaces
  
• Reorganize EGL stuff
  
• Fix empty instance creation from proxy
  
• Install scanner
  
• Unify operators and functions available on wrappers
  
• Improve thread-safety when copying proxy_t
  
• Throw std:ystem_exception when display_t operations fail
  
• Add some const markers and fix dump example
  
• Add helpers for checking availability of functions
  
• Introduce wrapper for wl_fixed_t
  
• Various fixes
  
• Accept empty event_queue_t for proxy_t:et_queue
  
• Fix handling of objects that are owned by other libraries
  
• Accept const reference in egl_window_t constructor
  
• Add support for proxy wrappers
  
• pkgconfig
  

• Wayland thread-safety
  
• wayland: Also support wl_drm version 1
  
• wayland: Do not rely on external library for wl_drm_interface
  
• Wayland fixes
  

• Wayland thread-safety
  
• wayland: Also support wl_drm version 1
  
• Remove generated file from tree and on clean
  
• Fix Wayland crash when globals are removed
  

• bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal
  

• desktop-shell: Track focused shell surface by main surface
  
• libweston-desktop/xdg-shell: Check window geometry instead of surface size against configured size
  
• desktop-shell: Set surface resizing state during interactive resize
  
• libweston: Do not include subsurfaces with NULL buffer in bounding box
  

• screensaver-proxy: Check gnome-session Inhibit call return value
  
• Edge-swipe gestures should be inhibited for full-screen applications
  
• Lockup when using wl_shell_surface:et_transient on same surface
  
• xdg_shell set_fullscreen() output setting is misinterpreted sometimes
  
• surface sizing issues when using zxdg_toplevel_v6:et_fullscreen() with monitors of differing scale
  
• wayland: Allow multitouch on client surfaces with > 2 contact points
  
• wayland: First configure is wrong for subcomposited surfaces
  
• wayland: Crash when destroying subsurface before surface: "assertion failed: (surface->role)"
  

• subcomposited surfaces with content outside shell surface area lack proper damage on some occasions