evil0sheep / motorcar Goto Github PK

The QtWayland Compositor module is Motorcar's most significant dependency and create a number of problems for the project. Because the compositor module does not ship with Qt5, using it requires building qt from source, and because motorcar must use private apis in the compositor module in order to get the raw wayland resources it needs to instantiate the resources used by its wayland extensions, it would require building qt5 from source even if the QtWayland compositor module did ship with qt5. Building qt5 correctly is a delicate process, and rebuilding it in the event of a build problem takes multiple hours. Also if we wanted to ship a binary release of Motorcar we would need to package a custom build of qt, which would be nothing short of god awful.

This issue exists to track refactoring Motorcar to use all in-house wayland compositor code, using qt only for windowing (so we can use a normal qt build) and moving all of the qt code to being built by the example compositors (similar to the way device dependencies are handled)

Problem: I am running Arch Linux and cannot get motorcar to compile.

What I've attempted: I have followed the build instructions (using the build.sh) to no avail. In addition, I attempted to compile everything myself from scratch (as per the README); that didn't work either.

Error messages: I have come across the 3 following issues (which are probably all related):

1. Using ./build.sh, I cannot get the simple-compositor to compile. Instead, I get a bunch of undefined references to qt5 objects (even though, as far as I know, I have successfully built qt5). Here is the top of the error output:

   g++  main.cpp  -std=c++11  -I../../../../src/compositor -I../../../../src/protocol -I../../../../src/device -L../../../../lib -lmotorcar-compositor  -o simple-compositor 
   ../../../../lib/libmotorcar-compositor.so: undefined reference to `QGuiApplication::primaryScreen()@Qt_5'
   ../../../../lib/libmotorcar-compositor.so: undefined reference to `QSurfaceFormat::setDepthBufferSize(int)@Qt_5'
   

2. I can get the motorcar-demo-client to compile without error; however, when I run run-motorcar-demo-client.sh, I get the following:

   motorcar-demo-client: simple-egl.cpp:1593: int main(int, char**): Assertion `display.display' failed.
   ./run-motorcar-demo-client.sh: line 1: 15560 Aborted                 (core dumped) /home/user/motorcar/src/examples/clients/simple-egl/motorcar-demo-client
   

3. Finally, when I attempt to compile motorcar from scratch, I think that qtwayland is failing to install. In particular, during the build steps outlined in the README, the qtwayland directory seems to be empty! See below for what I mean (these instructions are copied from the motorcar README):

   $ git clone git://code.qt.io/qt/qt5.git qt5
   $ cd qt5
   $ git checkout 5.5
   $ ./init-repository --no-webkit  --module-subset=qtbase,qtjsbackend,qtdeclarative,qtwayland
   $ cd qtbase
   $ git checkout 5.5
   $ cd ../qtwayland # here, the qtwayland directory is empty
   $ git checkout 5.5 # after running this command, the qtwayland directory remains empty
   $ cd ../
   $ ./configure -prefix /opt/qt5  -debug -confirm-license -opensource -egl -opengl -no-xcb-xlib
   $ cd qtwayland # this directory is still empty!
   $ git clean -fdx
   $ ../qtbase/bin/qmake CONFIG+=wayland-compositor # this doesn't work
   $ cd ../
   $ make
   $ make install
   

As a workaround, I tried to git clone the current qtwayland repo (from the qt website) into qt5/qtwayland and follow the instructions as above. This didn't work.

What do?

PS -- I read Forrest's masters thesis. Am looking forward to tinkering on motorcar if I can get it to build.

OSVR offers fairly broad device support hidden behind input abstractions that look pretty similar to what Motorcar is using internally. If we can wrap their device abstractions in the corresponding Motorcar abstractions we should be able to gain support for a fairly large set of VR devices without needing to interface with the sdks for those devices directly.

This issue exists to track the investigation of whether this is feasible as well as the implementation thereof.

3D interfaces is much more powerful and flexible with VR, if add support for Oclus and Vive and add virtual keyboard you can get very powerful 3D interface that not one system actually have.

Currently motorcar clients (clients creating 3D windows) pack their depth buffer into their color buffer and then the compositor unpacks this pack into a depth buffer for use during depth compositing (see this slide for details). This adds an extra render pass on the client side and the compositor side, which entails rgb8<->float32 conversion per pixel per client per frame across the entire framebuffer, which is fairly expensive.

This issue tracks investigation of using a separate float32 buffer for the depth buffer (if possible)

Is a binary release for Ubuntu 12.04 or 14.04 available? I've been trying to get everything to build but have been running into a lot of different issues.

I'm building the qtwayland on Fedora and I meet some problems. Now I figured out and fixed them. Turned out there are some prerequisites are missing.

The first problem is this,

Running configuration tests...
The test for linking against libxcb and support libraries failed!
 You might need to install dependency packages, or pass -qt-xcb.
 See src/plugins/platforms/xcb/README.

The solution for this is to install xcb packages. On my fedora I executed the following command:

sudo dnf install libxcb libxcb-devel libXrender libXrender-devel xcb-util-wm xcb-util-wm-devel xcb-util xcb-util-devel xcb-util-image xcb-util-image-devel xcb-util-keysyms xcb-util-keysyms-devel

For other systems please check this thread,
http://stackoverflow.com/questions/25822875/configure-error-the-test-for-linking-against-libxcb-and-support-libraries-fai

Then the second problem appeared,

 The EGL functionality test failed; EGL is required by some QPA plugins to manage contexts & surfaces.
 You might need to modify the include and library search paths by editing
 QMAKE_INCDIR_EGL, QMAKE_LIBDIR_EGL and QMAKE_LIBS_EGL in ...motorcar/dependencies/qt5/qtbase/mkspecs/linux-g++.

For my case, the EGL headers are missing. To fix this, run
sudo dnf install mesa-libEGL-devel.

Maybe there are some other dependencies that are needed, like drivers. (For my case, I've installed the bumblebee before).

After this, there is another problem but I forgot to save the error message. It's about the dependency of wayland. For this one, the following should work

sudo dnf install wayland-devel mesa-libwayland-egl-devel

It would be better if there are some instructions about the prerequisites in the README.

Thanks,
Yisu

I don't know if you've heard, but gitorious is shutting down and all the repos are going into read_only mode. I assume the QT5 project will be hosting their git repos somewhere else from now on, and you might want to have your readme reflect that.

Right now the compositor basically blindly sends view matrices to the clients each frame and then draws whatever buffer is most recently available for that client, with no knowledge of how out of date the view matrix is for that frame or how much the client's apparent transform has changed in that time.

This issue exists to track implementing a timing mechanism for view matrices and frames. So each view matrix from the compositor will come with a timestamp, and when the client notifies the compositor that it has drawn a new frame it also notifies it of the timestamp for the view matrices it drew that frame with. Then the compositor can keep track of relative motion of the client and could do things like a per-client time warp, or just drop client content if its too out of whack. In general it would just be good information to have for improving and optimizing the depth compositing process.

Right now the Motorcar example client is a single monolithic file more than 1k lines long. The goal here is to pull all the boilerplate code into a shared library (built as part of the motorcar core, like the motorcar compositor library) and have the application only be code for application specific things (like drawing content and handling events). The shared library will expose an api similar to something like glut or glfw, but for 3D windowing.

This issue depends on breaking the qtwayland dependency as that will involve refactoring the compositor library build system to use cmake instead of qmake, and that will allow the client library build system to use cmake as well.