(2017-03-10, 11:24)RockerC Wrote: other than compiling Kodi and looking at the code, you and other students should really checkout all the accepted proposals from previous years of GSoC:

http://forum.kodi.tv/forumdisplay.php?fid=220
http://forum.kodi.tv/forumdisplay.php?fid=191
http://forum.kodi.tv/forumdisplay.php?fid=161

If you read through all those accepted proposals then you should get an idea how to write your own proposal and how-to engage with the community here on the forum.

Another tip from previous years not mentioned here yet is to submit your proposal(s) early as you can always make changes to details of your proposal(s).

You can submit more than one prososal. You could post one seperate proposal for each idea, as that means less risk all of your ideas conflict with other students.

Advice from looking at previous years would be; submit early, submit many, submit revisions often, and get feedback in back-and-forth discussions with community.

(2017-03-10, 10:14)yolk Wrote: Hi,


I've seen that there is a suggested task in the Wiki list about (re)introducing Wayland support into Kodi, which I'm interested in. I've searched around a bit and found the old pull request that was rejected. But it seems that the Kodi Wayland fork of Max Kellermann is still being actively maintained and updated. So, for GSoC, what exactly should be done? Is it expected to grab Max' code and try to get it merged (with modifications if necessary)? If so, this would be very difficult to propose as a project without knowing exactly what kinds of problems the Kodi team sees with the current state of the code - which is probably quite different from back when the Wayland support was removed from the main repository. Or are there substantial problems with the current solution that require a complete rewrite from scratch?

(2017-03-10, 12:03)RockerC Wrote: So if you have time right now then you could just try to merge the Wayland code into FernetMenta's "kodi-agile" fork of Kodi to see if it will even fit with all the reworked code changes for Kodi already in there:

(2017-03-11, 08:55)FernetMenta Wrote: Hi, thanks for showing interest. New Wayland support should be implemented the same way like X11 or Mir. Mir support is relatively new can can be taken as a good example of how it should be. In Kodi's context Wayland is a platform or windowing systems. Check out X11, Windows, or Mir folders under xmbc/windowing:
https://github.com/xbmc/xbmc/tree/master/xbmc/windowing

The old implementation was done in the messy structure in egl (windowing/egl). EGL itself is not a platform or windowing systems, means that basically all platforms you find under the egl folder need rework.

(2017-03-11, 08:55)FernetMenta Wrote: The new implementation should consider that we finally want support for wayland protocols like "presentation time".

(2017-03-17, 00:42)yolk Wrote: Seems Max Kellermann has started dealing with this: https://github.com/MaxKellermann/xbmc/commit/5f0fbc9904b1123458fe3c3ef93b3ff140293619 - granted, it's only renaming files, but it shows that he might be considering to continue to work on this. I would want to avoid having two people work separately on this, which means some coordination/communication might be required.

(2017-03-17, 00:42)yolk Wrote: So going forward, am I understanding you correctly that you want relevant portions of the EGL code (which will still be needed since Wayland requires EGL for GL contexts) moved/copied to the Wayland windowing system, like it was done with Mir? Or do you want some kind of central place for the EGL code, just not the way it is now (thinking about the other platforms based on egl that will also need to be modified some day)? I think that the CGLContextEGL required for Wayland would be mostly equal to the one Mir currently uses.

(2017-03-17, 00:42)yolk Wrote: Am I correct that you are referring to this? Should it be used for implementing CVideoSync or do you have anything else in mind? Also, it seems that sadly no compositor except weston even supports it at the moment (I've quickly checked the arguably most important ones, mutter and KWin).

(2017-03-17, 18:20)FernetMenta Wrote: First time I see this. Max Kellermann seems not to accept any guidance so this approach may take forever.

(2017-03-17, 18:20)FernetMenta Wrote: At this time I don't see any benefit from common code for EGL. It's only few line anyways. Have a look at the history of the egl floder. There are only platform specific changes. If it turns out that some common code could be factored out, it can be done at a later time.

(2017-03-17, 18:20)FernetMenta Wrote: Yes, we need a solution for CVideoSync because CVideoSyncDRM and CVideoSyncGLX are deprecated. Using wp_presenatation was actually a suggestion by Intel developers.

(2017-03-17, 23:44)yolk Wrote: OK, so is there anything else you would want to have in the Wayland implementation (or possibly related topics)? I'm still unsure whether I can convincingly fill a 3-month timeline with it as-is.

(2017-03-19, 09:44)FernetMenta Wrote: CVideoSync should work. That is for driving video player clock by vertical retrace.
In addition we need some means to tell how long it will take for a submitted frame to be on screen. Currently we don't really know. We try to guess based on double/triple bufer setting.

(2017-03-19, 09:44)FernetMenta Wrote: Rework use of OS sreensaver. I think this is partly broken in current version.

(2017-03-19, 20:54)yolk Wrote: If presentation-time is supported, that can probably be calculated from the time difference between calling commit() on the surface and the time in the presentation event.

(2017-03-19, 20:54)yolk Wrote: I'll write up a proposal based on the discussions, shall I make a new thread or just post it as reply here?

1. Basic Wayland support
   
   1. Rebase the work of Max Kellermann on current Kodi or kodi-agile git, filtering out stuff unrelated to Wayland
      
   2. Make it independent of CWinSystemEGL and run on full OpenGL
      
   3. Fix fullscreen on HiDPI displays with scale != 1 (does not seem to work currently)
      
   4. Make sure everything else works as expected
      
2. Additional features (in order of priority)
   
   1. Support for the presentation-time protocol extension as CVideoSync implementation
      
   2. Provide ways of controlling the compositor screensaver
      
   3. Allow selecting the preferred wl_output to display on and react to hot-plug events by moving the surface to a different output if necessary
      
   4. Make sure VA-API (still) works
      
   5. Make it run on both OpenGL and OpenGLES
      
   6. Basic touch input single-tap support
      
   7. Windowed mode support (not that easy since it requires Kodi to draw client-side window decorations and support wl_shell_surface::move/resize)
      
3. Possible extensions (if desired and time allows, in no particular order)
   
   1. Make it possible to include both Wayland and X11 (as fallback) in the same build as this would be preferable for distribution packages
      
   2. Support for zero-copy video rendering of video to YUV surfaces (Wayland has native protocol support for YUV surface buffers) - questionable though if the benefits would justify the work that has to be done for this
      
   3. Support for fullscreen with the unstable fullscreen-shell protocol - would allow output mode switching (in theory)
      
   4. Full touch input support with gestures (probably needs to use CGenericTouchInputHandler for gesture detection, wl_touch interface is very similar to evdev though)
      

• Windowing subsystem: New Wayland windowing system must be added
  
• Display configuration menus: The different feature set of Wayland might make it necessary to introduce additional configuration options
  
• Video sync: Depending on the information that Wayland can deliver, the video sync interface could be augmented in order to support this additional information
  
• Video player/rendering: Using YUV surfaces would mean that a compatible renderer must be implemented that renders directly to a Wayland subsurface buffer and not GL
  

• GPU(s) with open-source driver(s) that natively support Wayland, VA-API (e.g. Intel)
  
• C++
  
• Knowledge of Wayland protocols and interaction with EGL/GL/GLES
  

• Support for many Wayland protocols is very limited in practical compositors
  
• Information about outputs is very limited with Wayland - Monitors can only be identified by manufacturer and model, basically: this is a problem when someone has multiple monitors of the same model
  
• Video sync is very complicated to get right
  
• Screensaver is difficult to control compositor-independently: There is an idle-inhibit unstable Wayland protocol, but support varies between compositors; GNOME exhibits org.freedesktop.ScreenSaver interface on DBus but does not implement it currently - only way there would be to use org.gnome.SessionManager (which is GNOME-specific) etc.
  

(2017-03-20, 21:56)FernetMenta Wrote: 1)
I won't use the old egl base as a starting point but that is your decision.

(2017-03-20, 21:56)FernetMenta Wrote: 2)
I would stress the benefits more. Wayland support is absolutely essential for Kodi on Linux. X11 is dying.

(2017-03-20, 21:56)FernetMenta Wrote: 3)
VDPAU won't work because it requires X11. Currently it looks like VDPAU is dead too.

(2017-03-21, 00:24)yolk Wrote:

(2017-03-20, 21:56)FernetMenta Wrote: 3)
VDPAU won't work because it requires X11. Currently it looks like VDPAU is dead too.

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.

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

(2017-03-21, 00:24)yolk Wrote:

(2017-03-20, 21:56)FernetMenta Wrote: 3)
VDPAU won't work because it requires X11. Currently it looks like VDPAU is dead too.

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-03-21, 17:14)FernetMenta Wrote:

(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

AMD is working on this.