Skip to content

Loading…

Implement support for display on Wayland compositors #2978

Merged
merged 20 commits into from

8 participants

@smspillaz

Implemented initial support for display and input on wayland compositors. The following items should work fine:

  • Display, frame refresh
  • Detecting and selecting different output modes
  • Mouse input (buttons, wheels, motion, cursor hiding)
  • Keyboard input (key repeat)

The following items are not implemented yet

  • Dirty regions (requires core work to support EGL_EXT_buffer_age)

As was suggested in the previous review, libwayland-client.so, libwayland-egl.so and libxkbcommon.so are now loaded as dynamic libraries so that there is no runtime dependency if we want to build in wayland support. Unfortunately, that comes at a cost - we are no longer able to use a lot of the autogenerated protocol boilerplate and must instead use the protocol directly.

As such, any changes to this branch which are strictly protocol related should really be encapsulated in the objects found in the xbmc::wayland namespace.

Due to differences in the way the protocol operates between wayland 1.1 and 1.2+, there is no guaruntee that anything in the xbmc::wayland namespace is going to be running in the same thread. Usually this is not a problem, as the wayland objects are just there to manage the connection with a compositor in the background and don't interact with the rest of xbmc. The only shared state is the available output modes and xbmc does not make any assumptions about deterministic access to these anyways.

There is unit, integration and acceptance test coverage for this branch. Acceptance tests require the weston SDK in order to be built. They also require a weston binary to be available on the system. They shouldn't require any special graphics hardware - the tests use the no-op renderer so there's no checking for things with EGL_bind_wayland_display or the like. I'll need some testing to verify this though.

Screenshot:
wayland-on-weston-on-x

Note if you're testing on wayland-drm: Video playback will skip and stutter. The reason for this is probably because xbmc doesn't have access to your audio hardware from the console session, so SoftAE will keep resetting itself as its unable to push any data to PA.

12:55 < krh> smspillaz: and as for weston-launch, depending on how new your
systemd (logind) is, weston-launch is broken

The workaround is to explicitly make weston launch on the same console you're on, eg:

weston-launch -t `tty`

Newer versions of weston-launch should handle this problem automatically.

@theuni
Team Kodi member

Thanks sam, reviewing now.

@t-nelson t-nelson commented on an outdated diff
xbmc/windowing/WinEventsWayland.cpp
((1,223 lines not shown))
+
+ const bool isNavigationKey = (sym >= 0xff50 && sym <= 0xff58);
+ const bool isModifierKey = (sym >= 0xffe1 && sym <= 0xffee);
+ const bool isKeyPadKey = (sym >= 0xffbd && sym <= 0xffb9);
+ const bool isFKey = (sym >= 0xffbe && sym <= 0xffcc);
+ const bool isMediaKey = (sym >= 0x1008ff26 && sym <= 0x1008ffa2);
+
+ if (isNavigationKey ||
+ isModifierKey ||
+ isKeyPadKey ||
+ isFKey ||
+ isMediaKey)
+ {
+ /* Navigation keys are not in line, so we need to
+ * look them up */
+ struct NavigationKeySyms

static const

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@t-nelson

While @theuni is nit picking coding standard stuff... Please prefix the PV classes with I (that's a capital i in case your font is as ambiguous as mine).

@smspillaz

Sure, I can prefix the interfaces with "I". Its not my preferred style because encoding such information in names usually indicates a problem with the class design, but project-level coding style trumps :)

@smspillaz

Closing, as there is a stray commit in this branch. Re-opening after cherry-pick

@smspillaz smspillaz closed this
@ghost

a pull request tracks a branch. update the branch the pr updates. in particular you can rebase and push -f. that way you dont have to go through the crap of generating a new pr and our hundreds of devs etc dont get all the spam associated with the process. just a fyi.

@smspillaz
@ghost

git push remote localbranch:remotebranch [-f]

you can tard up all you want; git is as life should be, you can always rebase (rewrite) history to cover up stuff you wanna hide ;)

@smspillaz
@smspillaz

Reopening

@smspillaz smspillaz reopened this
@smspillaz

There was a (small) build failure on older versions of wayland (too many initializers for wl_output_interface). My local version was building from wayland-git which very recently had a protocol change. I've added a pkg-config check for the new versions so we can handle both protocols.

@theuni
Team Kodi member

Building on a clean rarring install:
WinEventsWayland.cpp:40:33: fatal error: xkbcommon/xkbcommon.h: No such file or directory

Obviously solved by installing libxkbcommon-dev, but configure needs to check for this and fail appropriately.

@theuni theuni commented on an outdated diff
configure.in
((9 lines not shown))
+ WAYLAND_CLIENT_LIBRARY_LINE=`LIBRARY=\`pkg-config --libs-only-l wayland-client\`; echo ${LIBRARY:2}`;
+ XB_FIND_SONAME([WAYLAND_CLIENT_LIBRARY], ${WAYLAND_CLIENT_LIBRARY_LINE})],
+ AC_MSG_WARN($missing_library))
+ PKG_CHECK_MODULES([WAYLAND_EGL], [wayland-egl],
+ [INCLUDES="$INCLUDES $WAYLAND_EGL_CFLAGS";
+ WAYLAND_EGL_LIBRARY_LINE=`LIBRARY=\`pkg-config --libs-only-l wayland-egl\`; echo ${LIBRARY:2}`
+ XB_FIND_SONAME([WAYLAND_EGL_LIBRARY], ${WAYLAND_EGL_LIBRARY_LINE})],
+ AC_MSG_WARN($missing_library))
+ PKG_CHECK_MODULES([XKBCOMMON], [xkbcommon],
+ [INCLUDES="$INCLUDES $XKBCOMMON_CFLAGS";
+ XKBCOMMON_LIBRARY_LINE=`LIBRARY=\`pkg-config --libs-only-l xkbcommon\`; echo ${LIBRARY:2}`
+ XB_FIND_SONAME([XKBCOMMON_LIBRARY], $XKBCOMMON_LIBRARY_LINE)],
+ AC_MSG_WARN($missing_library))
+ AC_DEFINE([HAVE_WAYLAND], [1], [Define to 1 if you have Wayland libs installed.])
+
+ # Check if we have wayland-client > 1.1.90
@theuni Team Kodi member
theuni added a note

This check (wayland client version) does not work, my guess is because WAYLAND_CLIENT is not unique and the value of the original check is cached. The AC_DEFINE always runs, I had to comment it out in order to build.

@theuni Team Kodi member
theuni added a note

I believe it'd be easier to skip this entirely and use the define in wayland-version.h anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@theuni theuni commented on the diff
xbmc/windowing/egl/EGLNativeTypeWayland.cpp
((1,202 lines not shown))
+ synchronized = true;
+ synchronizeCallback.reset();
+}
+#endif
+
+bool CEGLNativeTypeWayland::CheckCompatibility()
+{
+#if defined(HAVE_WAYLAND)
+ if (!getenv("WAYLAND_DISPLAY"))
+ {
+ CLog::Log(LOGWARNING, "%s:, WAYLAND_DISPLAY is not set",
+ __FUNCTION__);
+ return false;
+ }
+
+ /* FIXME:
@theuni Team Kodi member
theuni added a note

Probably worth moving these into (un)loadWaylandLibs() or so

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@theuni theuni commented on an outdated diff
configure.in
@@ -1102,6 +1112,39 @@ AC_SEARCH_LIBS([dn_expand], resolv)
AC_SEARCH_LIBS([_dn_expand], resolv)
AC_SEARCH_LIBS([__dn_expand],resolv)
+# Wayland
+if test "$use_wayland" = "yes" && test "$host_vendor" != "apple"; then
+ AC_MSG_NOTICE($wayland_enabled)
+ PKG_CHECK_MODULES([WAYLAND_CLIENT], [wayland-client],
+ [INCLUDES="$INCLUDES $WAYLAND_CLIENT_CFLAGS";
+ WAYLAND_CLIENT_LIBRARY_LINE=`LIBRARY=\`pkg-config --libs-only-l wayland-client\`; echo ${LIBRARY:2}`;
+ XB_FIND_SONAME([WAYLAND_CLIENT_LIBRARY], ${WAYLAND_CLIENT_LIBRARY_LINE})],
+ AC_MSG_WARN($missing_library))
@theuni Team Kodi member
theuni added a note

See previous comment, these need to be errors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@theuni theuni commented on an outdated diff
configure.in
@@ -1102,6 +1112,39 @@ AC_SEARCH_LIBS([dn_expand], resolv)
AC_SEARCH_LIBS([_dn_expand], resolv)
AC_SEARCH_LIBS([__dn_expand],resolv)
+# Wayland
+if test "$use_wayland" = "yes" && test "$host_vendor" != "apple"; then
+ AC_MSG_NOTICE($wayland_enabled)
+ PKG_CHECK_MODULES([WAYLAND_CLIENT], [wayland-client],
+ [INCLUDES="$INCLUDES $WAYLAND_CLIENT_CFLAGS";
+ WAYLAND_CLIENT_LIBRARY_LINE=`LIBRARY=\`pkg-config --libs-only-l wayland-client\`; echo ${LIBRARY:2}`;
@theuni Team Kodi member
theuni added a note

need to use ${PKG_CONFIG} here in order to avoid assuming builder == host.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@theuni theuni commented on an outdated diff
xbmc/windowing/egl/EGLNativeTypeWayland.cpp
((19 lines not shown))
+ */
+#include <sstream>
+#include <iostream>
+#include <stdexcept>
+
+#include <boost/noncopyable.hpp>
+#include <boost/function.hpp>
+#include <boost/bind.hpp>
+#include <boost/scoped_ptr.hpp>
+#include <boost/shared_ptr.hpp>
+
+#include <cstdlib>
+
+#include <wayland-client.h>
+
+#include "../DllWaylandClient.h"
@theuni Team Kodi member
theuni added a note

please avoid including parent dirs. xbmc/ is always in the includes list, you should list relative to that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@smspillaz smspillaz referenced this pull request
Closed

Mir and Wayland support #3001

@smspillaz

All review items should be addressed now.

@Xaapyks

With

$ ./configure --enable-wayland --disable-dvdcss

I get

$ make
CPP     xbmc/cores/dvdplayer/DVDPlayerVideo.o
DVDPlayerVideo.cpp: In member function 'void CDVDPlayerVideo::ProcessOverlays(DVDVideoPicture*, double)':
DVDPlayerVideo.cpp:899:8: error: 'g_Windowing' was not declared in this scope
     if(g_Windowing.GetRenderQuirks() & RENDER_QUIRKS_MAJORMEMLEAK_OVERLAYRENDERER)
        ^  

Without the wayland switch it builds correctly. It looks like when using the --enable-wayland switch I have no inclusion of any graphical backend header and hence "g_Windowing" is not defined.

Even though my xbmc/config.h does contain

#define HAVE_WAYLAND 1

But the factory does not seem to check for this define.

@smspillaz
@theuni
Team Kodi member

I'd like to get this in this week if nobody speaks up against.

It's a monster, but I worked with Sam during GSOC, and reviewed along the way. It's a great first crack at Wayland. Also, as big as it is, it's quite localized.

I plan to build every config I can first to verify (as much as possible) that no existing platforms regress.

@MartijnKaijser
Team Kodi member

@theuni
I send you a mail regarding some things in this PR

@ghost

+1 heavily localized and something we want. do it.

@davilla

I'd like to see a little squishing before inject

@smspillaz

Hey @davilla

I carefully thought about how the commits were spaced out. It is important that commits show a logical progression between independent functionality otherwise you can't bisect effectively. However, I'm open to suggestions as to which commits should be squashed together and why. Can you post which commits should be merged?

@t-nelson

@smspillaz Sorry, we haven't taught @davilla that history is a tool yet. It's hard to teach an old dog new tricks. :)

@davilla

If you feel the urgent need to be able to bisect this after inject, it's not ready for inject. Just saying. This is either ready to go in or it's still a work in progress.

Any commits that are independent and required to core for support should be listed 1st so they can be seen right away. For example '[aml] add macro for optional export resolving'.

Move all unit tests to one commit. Right now they are spread across six commits that are all over the place.

Condense all the refactoring and fixes, don't need to see the path to the final solution, the final solution is good enough. Case in point, the ATV2 port which brought in iOS support was condensed from 500+ commits to a little more than 10. NetManager PR (in progress) was 50+ commits to one.

I'd also like to see much, much more comments in code, no one looks at the commit comments once injected so if you have something important enough to to mention in the commit message, comment it in code. Remember that code comments are not for experts, they are for the grunts that have to jump in and fix issues while the experts are unavailable.

I'm not being picky just I feel like it, this PR is a monster and very hard to follow and next to impossible to fix unless you are the one that wrote it. Let's make it just a little easier for the grunts to deal with when it hits XBMC.org mainline.

@Xaapyks

Sorry to bug you again but I still cannot build this even with the latest commits from smspillaz's repository.
Still getting the same error I reported earlier. I think it might be related to EGL/GL support that may be required but not enabled (but when I enable then I have other failures about symbols redefinitions...)
Where can I get in touch directly with you smspillaz to sort this out ? I can't find your e-mail address on github.

@smspillaz
@smspillaz
@davilla

inject as is, I withdraw my comments.

@smspillaz

The revised patchset contains:

  1. More comments (approximately 1000 lines more), especially in funky areas and along class boundaries to show where the main integration points are
  2. --enable-wayland now implies --enable-gles
  3. Some small build fixes (missing #include, not sure how I missed that one).

I haven't done any squashing yet. There seems to be a mixed verdict on squashing and its one of those things that's more difficult to reverse once its done (reverting to a previous HEAD with reflogs doesn't count because there may have been subsequent changes). As such, I've left the history as-is.

I think that more squashing could potentially be a good thing, however I'm mindful of the fact that squashing some parts together could be a week-long job handling conflict fallout, especially where files were split up. We've got automated test coverage on most of this code so there's not a huge amount of risk involved, but its effectively letting the perfect be the enemy of the good.

If the verdict is that squashing is desired before merge, then I'll go ahead and squash based on the plan I outlined earlier. Otherwise it might be better to just leave it be.

Hopefully the revised documentation should help people a little bit in navigating their way around the codebase. I apologize that it has grown to a substantial size, although I'd advise looking past the number of lines changed and more to the structure. I've tried as much as possible to ensure that the codebase forms a directed acyclic graph of nodes, with the following lifecycle:

WinSystemEGL creates EGLNativeTypeWayland which creates:
-> XBMCConnection: responsible for managing all of the global client state in connection with the server
-> XBMCSurface: repsonsible for managing the surface which XBMC is drawn into

XBMCConnection creates a new xbmc::wayland::Registry object which listens on the main connection for any new global interfaces. Once a global interface becomes available (usually immediately) it creates a wrapper object for it (eg, Compositor, Shell, Seat, Output). The Seat global interface is injected into CWinEventsWayland which manages its internal state through xbmc::wayland::InputFactory

xbmc::wayland::InputFactory contains a PointerProcessor, KeyboardProcessor and EventLoop.

EventLoop is the implementation detail for CWinEventsWayland and represents the wayland message pipe. Calling CWinEvents::MessagePump will dispatch either wayland or partially processed wayland events for further processing.

Both are of the former "processor" classes are registered with the xbmc::wayland::Pointer and xbmc::wayland::Keyboard once they come online. When a new pointer or keyboard event occurs, they are forwarded on to the former two classes for "processing" where they are turned into XBMC_Event structures and forwarded on to CApplication.

Since the entire state of the backend is encapsulated in these objects, that part of the backend is effectively torn down as soon as they are destructed. Once EGLNativeTypeWayland is gone, there should be no more owning references to any other objects in the system related to this backend.

Please feel free to ask me questions before merging. I'd hope that there is some general understanding of how things work as opposed to "its a monster but we want it". I've tried to make the design as straightforward as possible, but some abstractions are a little contrived because dependencies needed to be separated for testing purposes. Also consider reading the test code - it should provide some insight into how things are supposed to work.

@FernetMenta FernetMenta commented on an outdated diff
xbmc/windowing/Makefile
((4 lines not shown))
WinSystem.cpp \
WinEvents.cpp
-
+
+# Wayland implementation detail
@FernetMenta Team Kodi member

IMO those should not be included if wayland is not enabled

@FernetMenta Team Kodi member

In general AM_CONDITIONAL should do but afaik our config is a bit weird. Not sure if it would work here.

@davilla
davilla added a note

the configure should also create a USE_WAYLAND for the buildsystem side. The use that in the Makefile like

ifeq (@USE_OPENGLES@,1)
SRCS += AMLUtils.cpp
endif

This also begs the point that about 1/2 our code uses build guards (#ifdef HAVE_WAYLAND), the other 1/2 handles it in the Makefile (ifeq (@USE_WAYLAND@,1)) . We really should make up our minds with way we want to do this.

@theuni Team Kodi member
theuni added a note

Hmm, yea, I missed this on review.

@smspillaz: to add to what @davilla said, you'll need to mv xbmc/windowing/Makefile to xbmc/windowing/Makefile.in and add it to the list in configure.in (look for the other Makefiles at the end). Then you can define USE_WAYLAND or so in configure.in if wayland should be built, and AC_SUBST it so that it's available for substituting in the Makefile.in.

@theuni Team Kodi member
theuni added a note

I think history is fine how it is. They're in logical chunks that make the thing easier to digest.

@theuni Team Kodi member
theuni added a note

@smspillaz EGLNativeTypeWayland.cpp needs a bit of fixing up as well. It tries to include the wayland headers that don't exist.

For that particular file, I'd prefer to guard with defines rather than skipping the files. Otherwise I'm afraid that someone will start adding one-or-the-other logic in that factory eventually, rather than just building everything we have the headers for.

With that fixed, Android builds and runs fine.

After that, and the changes you're working on, i'll hit the button.

@theuni Team Kodi member
theuni added a note

I doubt we're going to get many thorough conceptual reviews at this point because it has a pretty high barrier for entry: requires a recent Linux distro, obscure (relatively) display server, in-flux protocol, etc. I wouldn't take that as though it's not documented enough, rather that most devs can't be arsed (and rightly so given the above) to wrestle with this too much just yet. That's why "localized" is the big feature here ;)

That said, I think it far exceeds the usual "first attempt" at this kind of thing, so I see no reason to hold it up. Besides, the devil's in the details with a feature like this, so the interesting part will be to let it loose on users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@FernetMenta
Team Kodi member

+1 for merge. As long as it is not in the repo it won't get too much attention. It's important that we support this technology. (and of course continue working on this)

@smspillaz

New changes in this patchset:

  1. Include guards have been removed from most files, except the ones as specified above
  2. Adapted some of the test fixtures to work with newer versions of weston

All the tests for the wayland build are passing:

[----------] 2 tests from EGLNativeTypeWaylandWestonTest
[ RUN      ] EGLNativeTypeWaylandWestonTest.TestCheckCompatibilityWithEnvSet
[       OK ] EGLNativeTypeWaylandWestonTest.TestCheckCompatibilityWithEnvSet (312 ms)
[ RUN      ] EGLNativeTypeWaylandWestonTest.TestCheckCompatibilityWithEnvNotSet
[       OK ] EGLNativeTypeWaylandWestonTest.TestCheckCompatibilityWithEnvNotSet (324 ms)
[----------] 2 tests from EGLNativeTypeWaylandWestonTest (636 ms total)

[----------] 1 test from CompatibleEGLNativeTypeWaylandWestonTest
[ RUN      ] CompatibleEGLNativeTypeWaylandWestonTest.TestConnection
[       OK ] CompatibleEGLNativeTypeWaylandWestonTest.TestConnection (343 ms)
[----------] 1 test from CompatibleEGLNativeTypeWaylandWestonTest (343 ms total)

[----------] 5 tests from ConnectedEGLNativeTypeWaylandWestonTest
[ RUN      ] ConnectedEGLNativeTypeWaylandWestonTest.CreateNativeWindowSuccess
[       OK ] ConnectedEGLNativeTypeWaylandWestonTest.CreateNativeWindowSuccess (339 ms)
[ RUN      ] ConnectedEGLNativeTypeWaylandWestonTest.ProbeResolutionsSuccess
[       OK ] ConnectedEGLNativeTypeWaylandWestonTest.ProbeResolutionsSuccess (336 ms)
[ RUN      ] ConnectedEGLNativeTypeWaylandWestonTest.PreferredResolutionSuccess
[       OK ] ConnectedEGLNativeTypeWaylandWestonTest.PreferredResolutionSuccess (344 ms)
[ RUN      ] ConnectedEGLNativeTypeWaylandWestonTest.CurrentNativeSuccess
[       OK ] ConnectedEGLNativeTypeWaylandWestonTest.CurrentNativeSuccess (340 ms)
[ RUN      ] ConnectedEGLNativeTypeWaylandWestonTest.GetMostRecentSurface
[       OK ] ConnectedEGLNativeTypeWaylandWestonTest.GetMostRecentSurface (340 ms)
[----------] 5 tests from ConnectedEGLNativeTypeWaylandWestonTest (1700 ms total)

[----------] 4 tests from AssistedEGLNativeTypeWaylandTest
[ RUN      ] AssistedEGLNativeTypeWaylandTest.TestGotXBMCWayland
[       OK ] AssistedEGLNativeTypeWaylandTest.TestGotXBMCWayland (348 ms)
[ RUN      ] AssistedEGLNativeTypeWaylandTest.AdditionalResolutions
[       OK ] AssistedEGLNativeTypeWaylandTest.AdditionalResolutions (341 ms)
[ RUN      ] AssistedEGLNativeTypeWaylandTest.PreferredResolutionChange
[       OK ] AssistedEGLNativeTypeWaylandTest.PreferredResolutionChange (350 ms)
[ RUN      ] AssistedEGLNativeTypeWaylandTest.CurrentResolutionChange
[       OK ] AssistedEGLNativeTypeWaylandTest.CurrentResolutionChange (331 ms)
[----------] 4 tests from AssistedEGLNativeTypeWaylandTest (1371 ms total)

[----------] 2 tests from WaylandPointerProcessor
[ RUN      ] WaylandPointerProcessor.Motion
[       OK ] WaylandPointerProcessor.Motion (0 ms)
[ RUN      ] WaylandPointerProcessor.MotionThenButton
[       OK ] WaylandPointerProcessor.MotionThenButton (0 ms)
[----------] 2 tests from WaylandPointerProcessor (0 ms total)

[----------] 8 tests from EventQueues/InputEventQueueWestonTest/0, where TypeParam = (anonymous namespace)::SingleThreadedEventQueue
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.Construction
[       OK ] EventQueues/InputEventQueueWestonTest/0.Construction (330 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.MotionEvent
[       OK ] EventQueues/InputEventQueueWestonTest/0.MotionEvent (338 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.ButtonEvent
[       OK ] EventQueues/InputEventQueueWestonTest/0.ButtonEvent (351 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.AxisEvent
[       OK ] EventQueues/InputEventQueueWestonTest/0.AxisEvent (328 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.KeyEvent
[       OK ] EventQueues/InputEventQueueWestonTest/0.KeyEvent (340 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.RepeatAfter1000Ms
[       OK ] EventQueues/InputEventQueueWestonTest/0.RepeatAfter1000Ms (1442 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.NoRepeatAfterRelease
[       OK ] EventQueues/InputEventQueueWestonTest/0.NoRepeatAfterRelease (2543 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/0.Modifiers
[       OK ] EventQueues/InputEventQueueWestonTest/0.Modifiers (354 ms)
[----------] 8 tests from EventQueues/InputEventQueueWestonTest/0 (6028 ms total)

[----------] 8 tests from EventQueues/InputEventQueueWestonTest/1, where TypeParam = xbmc::wayland::version_11::EventQueueStrategy
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.Construction
[       OK ] EventQueues/InputEventQueueWestonTest/1.Construction (343 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.MotionEvent
[       OK ] EventQueues/InputEventQueueWestonTest/1.MotionEvent (353 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.ButtonEvent
[       OK ] EventQueues/InputEventQueueWestonTest/1.ButtonEvent (361 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.AxisEvent
[       OK ] EventQueues/InputEventQueueWestonTest/1.AxisEvent (367 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.KeyEvent
[       OK ] EventQueues/InputEventQueueWestonTest/1.KeyEvent (367 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.RepeatAfter1000Ms
[       OK ] EventQueues/InputEventQueueWestonTest/1.RepeatAfter1000Ms (1450 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.NoRepeatAfterRelease
[       OK ] EventQueues/InputEventQueueWestonTest/1.NoRepeatAfterRelease (2551 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/1.Modifiers
[       OK ] EventQueues/InputEventQueueWestonTest/1.Modifiers (371 ms)
[----------] 8 tests from EventQueues/InputEventQueueWestonTest/1 (6165 ms total)

[----------] 8 tests from EventQueues/InputEventQueueWestonTest/2, where TypeParam = xbmc::wayland::version_12::EventQueueStrategy
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.Construction
[       OK ] EventQueues/InputEventQueueWestonTest/2.Construction (350 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.MotionEvent
[       OK ] EventQueues/InputEventQueueWestonTest/2.MotionEvent (350 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.ButtonEvent
[       OK ] EventQueues/InputEventQueueWestonTest/2.ButtonEvent (356 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.AxisEvent
[       OK ] EventQueues/InputEventQueueWestonTest/2.AxisEvent (343 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.KeyEvent
[       OK ] EventQueues/InputEventQueueWestonTest/2.KeyEvent (353 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.RepeatAfter1000Ms
[       OK ] EventQueues/InputEventQueueWestonTest/2.RepeatAfter1000Ms (1444 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.NoRepeatAfterRelease
[       OK ] EventQueues/InputEventQueueWestonTest/2.NoRepeatAfterRelease (2581 ms)
[ RUN      ] EventQueues/InputEventQueueWestonTest/2.Modifiers
[       OK ] EventQueues/InputEventQueueWestonTest/2.Modifiers (354 ms)
[----------] 8 tests from EventQueues/InputEventQueueWestonTest/2 (6131 ms total)

[----------] 1 test from TestTextureCache
[ RUN      ] TestTextureCache.GetWrappedImageURL
[       OK ] TestTextureCache.GetWrappedImageURL (1 ms)
[----------] 1 test from TestTextureCache (1 ms total)

[----------] 6 tests from ThreeButtonMouse/WaylandPointerProcessorButtons
[ RUN      ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonPress/0
[       OK ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonPress/0 (0 ms)
[ RUN      ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonPress/1
[       OK ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonPress/1 (0 ms)
[ RUN      ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonPress/2
[       OK ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonPress/2 (0 ms)
[ RUN      ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonRelease/0
[       OK ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonRelease/0 (0 ms)
[ RUN      ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonRelease/1
[       OK ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonRelease/1 (0 ms)
[ RUN      ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonRelease/2
[       OK ] ThreeButtonMouse/WaylandPointerProcessorButtons.ButtonRelease/2 (0 ms)
[----------] 6 tests from ThreeButtonMouse/WaylandPointerProcessorButtons (1 ms total)

[----------] 2 tests from VerticalScrollWheel/WaylandPointerProcessorAxisButtons
[ RUN      ] VerticalScrollWheel/WaylandPointerProcessorAxisButtons.Axis/0
[       OK ] VerticalScrollWheel/WaylandPointerProcessorAxisButtons.Axis/0 (0 ms)
[ RUN      ] VerticalScrollWheel/WaylandPointerProcessorAxisButtons.Axis/1
[       OK ] VerticalScrollWheel/WaylandPointerProcessorAxisButtons.Axis/1 (0 ms)
[----------] 2 tests from VerticalScrollWheel/WaylandPointerProcessorAxisButtons (0 ms total)

[----------] Global test environment tear-down
[==========] 501 tests from 81 test cases ran. (33847 ms total)
[  PASSED  ] 501 tests.

The only thing I'm not really sure about is this:

ifeq (@USE_WAYLAND@,1)
SRCS = StubCursorManager.cpp \
       StubEventListener.cpp \
       TestEGLNativeTypeWayland.cpp \
       TestWaylandInputUnit.cpp \
       TestXBMCWaylandInputAcceptance.cpp \
       TmpEnv.cpp \
       WestonProcess.cpp \
       WestonTest.cpp \
       XBMCWayland.cpp

If USE_WAYLAND is not 1, then that entire makefile will probably parse to nothing. I have no idea if that works in automake, and I'm not able to verify it because non-wayland builds are failing due to a missing dependency (which I know I have, just autoconf insists that I don't). Can someone else test the non-wayland build before merge?

@smspillaz

Current series: quick fixup to not include things at all in EGLNativeTypeWayland if we're not building with wayland support.

@theuni
Team Kodi member

fribidi? That's what I'm seeing here. Nothing obvious, it'll have to wait 'til morning I'm afraid.

I'll merge once that's straightened out.

@wsnipex
Team Kodi member

non wayland build test:
jenkins build this please

@theuni
Team Kodi member

@smspillaz See http://jenkins.xbmc.org/job/XBMC-Android-ARM/709/console. Still needs a fixup.

As for configure, that was a subtle one indeed. Looks like your early use of (recursive) pkg-config confuses configure. I'm not sure what changed, it was working fine before...

Either way:
PKG_PROG_PKG_CONFIG

Add that after the other AC_PROG's. It ensures that PKG_CONFIG is set before trying to use it.

@smspillaz

Autotools are awesome .

I'll fix up those build problems and re-push now.

smspillaz and others added some commits
@smspillaz smspillaz Added initial support for displaying on Wayland compositors.
SDL and X11 builds are disabled when using the --enable-wayland
switch.

EGLNativeTypeWayland is an implementation of EGLNativeType which
connects to a running wayland compositor if possible and starts
rendering in a new surface.

WinEventsWayland polls the wayland display for new events and updates
the main surface.

The wayland client libraries are loaded dynamically and their functions
should not be used directly. Instead, IDllWaylandClient should be injected
into any objects that need to call functions in those libraries. Because
the autogenerated protocol functions are inline in the header files
and not available to be looked up, the protocol needs to be used directly.

Some of the helpers there are:

 1. wayland::protocol::CreateWaylandObject -> creates a wl_proxy casted
    to the result type with a specific wl_interface as looked up in
    the client library.
 2. wayland::protocol::CallMethodOnWaylandObject -> calls wl_proxy_marshal
    with on the proxy with the specified opcode and arguments
 3. wayland::protocol::AddListenerOnWaylandObject -> adds a wl_listener
    to the wl_proxy
 4. wayland::protocol::DestroyWaylandObject -> calls wl_proxy_destroy
    on the proxy.

There may be some cases where additional constructor or destructor functions
might need to be called before or after CreateWaylandObject and
DestroyWaylandObject. Developers should consult the autogenerated
wayland-*-protocol.h headers to determine the expected call order.

XBMCSurface and XBMCConnection wrap most of the wayland connection
and surface creation / destruction and provide outputs for getting
the current resolution and EGL surface.

There is currently no support for keyboard input, mouse input or
multiple monitors.
9f5d939
@smspillaz smspillaz Added support for multiple outputs and go fullscreen by default.
Created new object xbmc::wayland::Output to wrap wl_output. Gather
all the available modes and report thoses in ProbeResolutions. Resize
the window in SetNativeResolution and set a new opaque region for it.

Remove all outputs on DestroyNativeDisplay()
11e46cc
@smspillaz smspillaz Added basic input framework.
Added xw::Seat to wrap wl_seat and WaylandInput to be the central
control object for keyboard and mouse input.

EventListener is a pure virtual class that WaylandInput delegates
to. EventDispatch implements EventListener and forwards input
and focus events on to XBMC.

Let WinEventsWayland manage the wl_seat * from EGLNativeTypeWayland
once it appears
dd4332c
@smspillaz smspillaz Added support for pointer events and hide the system pointer.
Created classes xbmc::wayland::Pointer to wrap wl_pointer and
xbmc::PointerProcessor implementing xbmc::wayland::PointerListener
which contains the logic for converting wayland button and pointer
events into xbmc events.

Made xbmc::wayland::Seat wait for a pointer to appear and initialize
a pointer in WaylandInput.

Call wl_pointer_set_cursor as soon as the pointer enters our surface
as it is undefined before that.
3c5e295
@smspillaz smspillaz Listen for a new wl_keyboard from wl_seat_listener and create an
XKBKeymap implementing wayland::Keymap. This class keeps track
of the keyboard state and MUST be updated every time a modifier or
a key is pressed (eg, every time we get an event from the protocol).

KeyboardProcessor implements the logic of converting XKB keysyms to
XBMC keysyms. It also changes the focus state of the window and
delivers key events to the XBMC event subsystem.

TimeoutManager and WaylandEventLoop are just a simple abstraction for
adding timeouts to the poll () / wl_display_dispatch () mainloop, in
place so that we can implement key repeat
df42779
@smspillaz smspillaz Read or dispatch events in a separate thread.
MessagePump() should not be a blocking operation

Because wl_display_read_events was only introduced in wayland 1.2, we need
to support two methods of making MessagePump() nonblocking.

version_11::EventQueueStrategy dispatches the whole event queue and gathers
the resulting XBMC_Events or other messages wrapped up into Action functors
in its reader thread. It then dispatches these to XBMC in the main thread.

version_12::EventQueueStrategy simply reads the wayland connection fd and
then flushes the output buffer and dispatches any read events in the
main thread.

In either version, the wayland listeners may be running in a separate thread.

As such, there is no guaruntee that it is safe to mutate the state of
objects in the xbmc::wayland namespace, at least until
version_11::EventQueueStrategy can be dropped.
XBMCConnection::WaitForSynchronize() should also only be called from
the main thread and not the dispatch thread as it is responsible for
setting synchronized == true
8d6c6b4
Cory Fields [aml] add macro for optional export resolving 22c2fec
@smspillaz smspillaz Optionally resolve wl_display_read_events and wl_display_prepare_read 7b2cc7e
@smspillaz smspillaz Add wayland-specific workaround for an intel driver bug.
Add EGL_QUIRK_DONT_TRUST_SURFACE_SIZE. The intel driver in Ubuntu Raring is
broken and returns a surface size of -1, -1. This is only temporary.
dbd62d2
@smspillaz smspillaz Initial wayland test framework
Secondary Author: Cory Fields

wayland: Fixup test building

- Build tests in the test dir, not the main make.
- Guard objects and code appropriately
- Remove support for all but weston += 1.0.99. pkg-config and versioning were
  not implemented before that anyway.
0bcbf58
@smspillaz smspillaz Lazy-bind global interfaces.
Make all global-interfaces lazy-binding. This means that we store
the result of any incoming wl_registry.global event and then actually
process it later when we call wl_registry.bind after trying to
access the global object for the first time.
419fb89
@smspillaz smspillaz Add wayland object listeners.
We will need direct access to some wayland objects in testing,
some of which are only available to the client itself. Add some
hooks to the client classes to advertise via a singleton via
any other interested code that some wayland object became available.

Test that we received the xbmc_wayland object after connection and
sync.
4f20fb6
@smspillaz smspillaz Add tests that depend on xbmc_wayland c23c3fb
@smspillaz smspillaz Split WinEventsWayland.cpp into separate files and refactor.
Rename WaylandInput to InputFactory and WaylandEventLoop to Loop.
Put each of them in the appropriate namespace. WaylandEventLoop
now delegates event queue callbacks to an injected EventListener
so as to decouple it from the rest of XBMC.
357d7e0
@smspillaz smspillaz Added input acceptance tests a191b27
@smspillaz smspillaz Add unit tests for PointerProcessor a7a3835
@smspillaz smspillaz Give xbmc::wayland::Keyboard the responsibility of managing the keymap.
The fact that we recieve the keymap as a string in shared memory is
really a wayland-specific implementation detail and not an abstraction
suitable for KeyboardProcessor. All KeyboardProcessor needs to care
about is receiving a keymap of some sort.
f4e6e58
@smspillaz smspillaz Do a reverse lookup on the keymap instead of hardcoding keys 902a0ff
@smspillaz smspillaz Add key repeat tests 403fae4
@smspillaz smspillaz Split up TestEGLNativeTypeWayland.cpp into separate translation units.
Where we don't generate the xbmc_wayland test extension, those tests
depending on it are disabled
96102bf
@smspillaz

New patch set: Fixed some minor build errors.

@MartijnKaijser
Team Kodi member

jenkins build this please

@theuni
Team Kodi member

Linux and android now looking good. Pulling if jenkins gives the all-clear.

@MartijnKaijser MartijnKaijser merged commit 9c9fdb3 into xbmc:master

1 check passed

Details default Merged build #337 succeeded in 1 hr 29 min
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Oct 11, 2013
  1. @smspillaz

    Added initial support for displaying on Wayland compositors.

    smspillaz committed
    SDL and X11 builds are disabled when using the --enable-wayland
    switch.
    
    EGLNativeTypeWayland is an implementation of EGLNativeType which
    connects to a running wayland compositor if possible and starts
    rendering in a new surface.
    
    WinEventsWayland polls the wayland display for new events and updates
    the main surface.
    
    The wayland client libraries are loaded dynamically and their functions
    should not be used directly. Instead, IDllWaylandClient should be injected
    into any objects that need to call functions in those libraries. Because
    the autogenerated protocol functions are inline in the header files
    and not available to be looked up, the protocol needs to be used directly.
    
    Some of the helpers there are:
    
     1. wayland::protocol::CreateWaylandObject -> creates a wl_proxy casted
        to the result type with a specific wl_interface as looked up in
        the client library.
     2. wayland::protocol::CallMethodOnWaylandObject -> calls wl_proxy_marshal
        with on the proxy with the specified opcode and arguments
     3. wayland::protocol::AddListenerOnWaylandObject -> adds a wl_listener
        to the wl_proxy
     4. wayland::protocol::DestroyWaylandObject -> calls wl_proxy_destroy
        on the proxy.
    
    There may be some cases where additional constructor or destructor functions
    might need to be called before or after CreateWaylandObject and
    DestroyWaylandObject. Developers should consult the autogenerated
    wayland-*-protocol.h headers to determine the expected call order.
    
    XBMCSurface and XBMCConnection wrap most of the wayland connection
    and surface creation / destruction and provide outputs for getting
    the current resolution and EGL surface.
    
    There is currently no support for keyboard input, mouse input or
    multiple monitors.
  2. @smspillaz

    Added support for multiple outputs and go fullscreen by default.

    smspillaz committed
    Created new object xbmc::wayland::Output to wrap wl_output. Gather
    all the available modes and report thoses in ProbeResolutions. Resize
    the window in SetNativeResolution and set a new opaque region for it.
    
    Remove all outputs on DestroyNativeDisplay()
  3. @smspillaz

    Added basic input framework.

    smspillaz committed
    Added xw::Seat to wrap wl_seat and WaylandInput to be the central
    control object for keyboard and mouse input.
    
    EventListener is a pure virtual class that WaylandInput delegates
    to. EventDispatch implements EventListener and forwards input
    and focus events on to XBMC.
    
    Let WinEventsWayland manage the wl_seat * from EGLNativeTypeWayland
    once it appears
  4. @smspillaz

    Added support for pointer events and hide the system pointer.

    smspillaz committed
    Created classes xbmc::wayland::Pointer to wrap wl_pointer and
    xbmc::PointerProcessor implementing xbmc::wayland::PointerListener
    which contains the logic for converting wayland button and pointer
    events into xbmc events.
    
    Made xbmc::wayland::Seat wait for a pointer to appear and initialize
    a pointer in WaylandInput.
    
    Call wl_pointer_set_cursor as soon as the pointer enters our surface
    as it is undefined before that.
  5. @smspillaz

    Listen for a new wl_keyboard from wl_seat_listener and create an

    smspillaz committed
    XKBKeymap implementing wayland::Keymap. This class keeps track
    of the keyboard state and MUST be updated every time a modifier or
    a key is pressed (eg, every time we get an event from the protocol).
    
    KeyboardProcessor implements the logic of converting XKB keysyms to
    XBMC keysyms. It also changes the focus state of the window and
    delivers key events to the XBMC event subsystem.
    
    TimeoutManager and WaylandEventLoop are just a simple abstraction for
    adding timeouts to the poll () / wl_display_dispatch () mainloop, in
    place so that we can implement key repeat
  6. @smspillaz

    Read or dispatch events in a separate thread.

    smspillaz committed
    MessagePump() should not be a blocking operation
    
    Because wl_display_read_events was only introduced in wayland 1.2, we need
    to support two methods of making MessagePump() nonblocking.
    
    version_11::EventQueueStrategy dispatches the whole event queue and gathers
    the resulting XBMC_Events or other messages wrapped up into Action functors
    in its reader thread. It then dispatches these to XBMC in the main thread.
    
    version_12::EventQueueStrategy simply reads the wayland connection fd and
    then flushes the output buffer and dispatches any read events in the
    main thread.
    
    In either version, the wayland listeners may be running in a separate thread.
    
    As such, there is no guaruntee that it is safe to mutate the state of
    objects in the xbmc::wayland namespace, at least until
    version_11::EventQueueStrategy can be dropped.
    XBMCConnection::WaitForSynchronize() should also only be called from
    the main thread and not the dispatch thread as it is responsible for
    setting synchronized == true
  7. @smspillaz

    [aml] add macro for optional export resolving

    Cory Fields committed with smspillaz
  8. @smspillaz
  9. @smspillaz

    Add wayland-specific workaround for an intel driver bug.

    smspillaz committed
    Add EGL_QUIRK_DONT_TRUST_SURFACE_SIZE. The intel driver in Ubuntu Raring is
    broken and returns a surface size of -1, -1. This is only temporary.
  10. @smspillaz

    Initial wayland test framework

    smspillaz committed
    Secondary Author: Cory Fields
    
    wayland: Fixup test building
    
    - Build tests in the test dir, not the main make.
    - Guard objects and code appropriately
    - Remove support for all but weston += 1.0.99. pkg-config and versioning were
      not implemented before that anyway.
  11. @smspillaz

    Lazy-bind global interfaces.

    smspillaz committed
    Make all global-interfaces lazy-binding. This means that we store
    the result of any incoming wl_registry.global event and then actually
    process it later when we call wl_registry.bind after trying to
    access the global object for the first time.
  12. @smspillaz

    Add wayland object listeners.

    smspillaz committed
    We will need direct access to some wayland objects in testing,
    some of which are only available to the client itself. Add some
    hooks to the client classes to advertise via a singleton via
    any other interested code that some wayland object became available.
    
    Test that we received the xbmc_wayland object after connection and
    sync.
  13. @smspillaz
  14. @smspillaz

    Split WinEventsWayland.cpp into separate files and refactor.

    smspillaz committed
    Rename WaylandInput to InputFactory and WaylandEventLoop to Loop.
    Put each of them in the appropriate namespace. WaylandEventLoop
    now delegates event queue callbacks to an injected EventListener
    so as to decouple it from the rest of XBMC.
  15. @smspillaz

    Added input acceptance tests

    smspillaz committed
  16. @smspillaz
  17. @smspillaz

    Give xbmc::wayland::Keyboard the responsibility of managing the keymap.

    smspillaz committed
    The fact that we recieve the keymap as a string in shared memory is
    really a wayland-specific implementation detail and not an abstraction
    suitable for KeyboardProcessor. All KeyboardProcessor needs to care
    about is receiving a keymap of some sort.
  18. @smspillaz
  19. @smspillaz

    Add key repeat tests

    smspillaz committed
  20. @smspillaz

    Split up TestEGLNativeTypeWayland.cpp into separate translation units.

    smspillaz committed
    Where we don't generate the xbmc_wayland test extension, those tests
    depending on it are disabled
Something went wrong with that request. Please try again.