Hi XBMC community.
I've decided to participate in Google Summer of Code for XBMC this year. In previous lives, I've maintained a the window manager for Ubuntu, but now that I'm no longer working and just a student again, it'd be nice to focus on something I've kept my eye on for a while.
I'm basically going to be putting in a bunch of work to provide windowing system backends for using the linux native framebuffer directly (eg, kms/gbm) as well as wayland and possible mir. I'll be introducing some new functional tests into the codebase as well so that these window systems don't turn out to be a maintenance burden as they aren't in wide use yet.
Here's the proposal as found on google-melange:
Short description: The purpose of this project will be to create window system backends to deploy XBMC on modern linux windowing systems and provide automated tests such that the code doesn't fall into bitrot for windowing systems which might not be heavily used at the moment. Ideally, the project will allow xbmc to run natively when either: Directly on the linux framebuffer (eg, GBM / KMS), Via the wayland protocol on Weston, Via the Mir protocol on the Mir Compositor.
WHAT WILL THE PROJECT FOCUS ON
The number one goal of the project will be to deliver XBMC on top of the
Wayland protocol directly, with full support for the two mentioned human
interface devices and full support for rendering with OpenGL and OpenGL | ES.
Automated tests must be provided for each of those two sub-goals.
Once the provision of XBMC on top of Wayland is satisfied, delivery on top
of Mir and KMS / GBM will effectively be "bonus goals".
The issue of providing an alternative to window decorations where the window
system does not provide them should be discussed with the rest of
team-xbmc. It falls within the broader scope of this proposal, but is not
a direct focus.
HOW WILL THIS BE ACHIEVED
The first thing to do will be to ensure that a suitable testing framework
is in place.
Weston provides a small amount of framework for doing application level
acceptance testing.
1. The compositor has a "headless" backend which effectively has no input
or output, and runs with a "no-op" renderer which does not require OpenGL.
2. Weston has a loadable "weston-test" module, whose protocol allows
clients using the protocol to ask weston to:
a. move surfaces
b. move the pointer
c. send button events
d. activate surfaces
e. send keys
3. This test module currently requries the x11 backend, though some simple
experimentation has shown that it should be a fairly straightforward
matter to allow it to run without any dependency on a running window
system, which means that it can be run on a continouous integration
server.
4. The test module and protocol is currently not exported to outside
applications, but perhaps this may change upstream. In the alternative,
we can ship our own version of the test module and load it directly
at runtime given weston's support for modules
5. XBMC currently uses Google Test as its xUnit framework. It should be
straightforward to integrate the two - all that need be done is to
create a test environment that launches weston with the test module
loaded in on a particular socket, and then to provide a test fixture
with convenience functions to communicate over weston's test protocol.
This would be similar to xorg-gtest which I've worked a lot with in the past.
Ideally, we should test functionality at two levels:
1. The code which translates wayland protocol callbacks (for example
wl_keyboard's "key" callback, which is called whenever a new key
is pressed or released) into XBMC events (for example XBMC_KEYDOWN)
needs to be built in a separate static library to the rest of the
project. We should test that sending events through the test
protocol to the application results in a correct interpretation of
the event in XBMC. This can be a largely table-driven matter.
2. XBMC itself can be run against the testing weston display server and
certain events can be sent in order to trigger certain behaviours
within the application. This is the second preferred level of testing,
but will be more fragile depending on any upcoming design or user
interface changes.
In terms of the actual implementation, we will need to implement three things:
1. A "CEGLNativeTypeWayland" inheriting from CEGLNativeType.
a. Initialize will be responsbile for calling
wl_display_connect and setting up the global-interface handler
to handle any interfaces that the protocol supports
b. CreateNativeDisplay will be responsbile for fetching the EGLDisplay
from eglGetDisplay
c. CreateNativeWindow will be responsbile for calling
wl_compositor_create_surface and creating a wl_buffer
compatible buffer for that surface with wl_egl_window_create
and attaching with with wl_surface_attach. It will store the
wl_egl_window in the area where it can be queried by
GetNativeWindow
2. A "CWinEventsWayland" inheriting from CWinEvents.
a. Implements MessagePump () which calls wl_display_dispatch_pending,
wl_display_flush (), poll () on the fd and then wl_display_dispatch_pending ()
once again.
i. Note: this exact order is necessary. Synchronous requests
such as those implicitly done in eglSwapBuffers in mesa
will cause the output buffer to be flushed and new events
to accumulate in the input buffer. Those must be processed
before sleeping as they may result in behaviour that causes
events we need to send to the compositor in order for it to
wake us up later to be sent.
b. Is the main area for the surface, pointer and keyboard listeners,
translating the incoming callbacks into xbmc events as appropriate.
One current unknown with this implementation is that currently there is no
way to get the native display type from the window system in the window events
class. In other cases it has been assumed that the window events in the
underlying windowing system is presented in terms of an implicit global context.
3. Backends will need to be dynamically loaded. In that sense, the current X11, RasPI, Android and IOS backends will need to become separate libraries and have their own vTable and entry points.
a. One issue that needs to be worked out here is how we're going to handle
the relationship between input backends and windowing backends. Some
windowing backends may require the same input backend, others may
require unique ones. This might be solvable by just having windowing ->
input dependencies, or just linking in the input backends to the windowing
backends.
BENEFITS
This project will secure the success of XBMC on future desktop and mobile linux
platforms in years to come and forms part of the strategy of being a multi-platform
application.
For embedded users, being able to run XBMC directly on the framebuffer presents a
new opportunity to provide a bare-bones XBMC experience. Likewise, running on top
of the wayland protocol effectively also provides a lightweight setup that does not
require a desktop environment to be running underneath.
REQUIREMENTS
1. Being able to build and run git xbmc, git weston and bzr mir (should mir
be included as part of the goals)
2. Understanding of EGL and basic understanding of OpenGL.
3. Understanding of test-driven-development and "correct" C++
MENTORS
1. TheUni
I've decided to participate in Google Summer of Code for XBMC this year. In previous lives, I've maintained a the window manager for Ubuntu, but now that I'm no longer working and just a student again, it'd be nice to focus on something I've kept my eye on for a while.
I'm basically going to be putting in a bunch of work to provide windowing system backends for using the linux native framebuffer directly (eg, kms/gbm) as well as wayland and possible mir. I'll be introducing some new functional tests into the codebase as well so that these window systems don't turn out to be a maintenance burden as they aren't in wide use yet.
Here's the proposal as found on google-melange:
Short description: The purpose of this project will be to create window system backends to deploy XBMC on modern linux windowing systems and provide automated tests such that the code doesn't fall into bitrot for windowing systems which might not be heavily used at the moment. Ideally, the project will allow xbmc to run natively when either: Directly on the linux framebuffer (eg, GBM / KMS), Via the wayland protocol on Weston, Via the Mir protocol on the Mir Compositor.
WHAT WILL THE PROJECT FOCUS ON
The number one goal of the project will be to deliver XBMC on top of the
Wayland protocol directly, with full support for the two mentioned human
interface devices and full support for rendering with OpenGL and OpenGL | ES.
Automated tests must be provided for each of those two sub-goals.
Once the provision of XBMC on top of Wayland is satisfied, delivery on top
of Mir and KMS / GBM will effectively be "bonus goals".
The issue of providing an alternative to window decorations where the window
system does not provide them should be discussed with the rest of
team-xbmc. It falls within the broader scope of this proposal, but is not
a direct focus.
HOW WILL THIS BE ACHIEVED
The first thing to do will be to ensure that a suitable testing framework
is in place.
Weston provides a small amount of framework for doing application level
acceptance testing.
1. The compositor has a "headless" backend which effectively has no input
or output, and runs with a "no-op" renderer which does not require OpenGL.
2. Weston has a loadable "weston-test" module, whose protocol allows
clients using the protocol to ask weston to:
a. move surfaces
b. move the pointer
c. send button events
d. activate surfaces
e. send keys
3. This test module currently requries the x11 backend, though some simple
experimentation has shown that it should be a fairly straightforward
matter to allow it to run without any dependency on a running window
system, which means that it can be run on a continouous integration
server.
4. The test module and protocol is currently not exported to outside
applications, but perhaps this may change upstream. In the alternative,
we can ship our own version of the test module and load it directly
at runtime given weston's support for modules
5. XBMC currently uses Google Test as its xUnit framework. It should be
straightforward to integrate the two - all that need be done is to
create a test environment that launches weston with the test module
loaded in on a particular socket, and then to provide a test fixture
with convenience functions to communicate over weston's test protocol.
This would be similar to xorg-gtest which I've worked a lot with in the past.
Ideally, we should test functionality at two levels:
1. The code which translates wayland protocol callbacks (for example
wl_keyboard's "key" callback, which is called whenever a new key
is pressed or released) into XBMC events (for example XBMC_KEYDOWN)
needs to be built in a separate static library to the rest of the
project. We should test that sending events through the test
protocol to the application results in a correct interpretation of
the event in XBMC. This can be a largely table-driven matter.
2. XBMC itself can be run against the testing weston display server and
certain events can be sent in order to trigger certain behaviours
within the application. This is the second preferred level of testing,
but will be more fragile depending on any upcoming design or user
interface changes.
In terms of the actual implementation, we will need to implement three things:
1. A "CEGLNativeTypeWayland" inheriting from CEGLNativeType.
a. Initialize will be responsbile for calling
wl_display_connect and setting up the global-interface handler
to handle any interfaces that the protocol supports
b. CreateNativeDisplay will be responsbile for fetching the EGLDisplay
from eglGetDisplay
c. CreateNativeWindow will be responsbile for calling
wl_compositor_create_surface and creating a wl_buffer
compatible buffer for that surface with wl_egl_window_create
and attaching with with wl_surface_attach. It will store the
wl_egl_window in the area where it can be queried by
GetNativeWindow
2. A "CWinEventsWayland" inheriting from CWinEvents.
a. Implements MessagePump () which calls wl_display_dispatch_pending,
wl_display_flush (), poll () on the fd and then wl_display_dispatch_pending ()
once again.
i. Note: this exact order is necessary. Synchronous requests
such as those implicitly done in eglSwapBuffers in mesa
will cause the output buffer to be flushed and new events
to accumulate in the input buffer. Those must be processed
before sleeping as they may result in behaviour that causes
events we need to send to the compositor in order for it to
wake us up later to be sent.
b. Is the main area for the surface, pointer and keyboard listeners,
translating the incoming callbacks into xbmc events as appropriate.
One current unknown with this implementation is that currently there is no
way to get the native display type from the window system in the window events
class. In other cases it has been assumed that the window events in the
underlying windowing system is presented in terms of an implicit global context.
3. Backends will need to be dynamically loaded. In that sense, the current X11, RasPI, Android and IOS backends will need to become separate libraries and have their own vTable and entry points.
a. One issue that needs to be worked out here is how we're going to handle
the relationship between input backends and windowing backends. Some
windowing backends may require the same input backend, others may
require unique ones. This might be solvable by just having windowing ->
input dependencies, or just linking in the input backends to the windowing
backends.
BENEFITS
This project will secure the success of XBMC on future desktop and mobile linux
platforms in years to come and forms part of the strategy of being a multi-platform
application.
For embedded users, being able to run XBMC directly on the framebuffer presents a
new opportunity to provide a bare-bones XBMC experience. Likewise, running on top
of the wayland protocol effectively also provides a lightweight setup that does not
require a desktop environment to be running underneath.
REQUIREMENTS
1. Being able to build and run git xbmc, git weston and bzr mir (should mir
be included as part of the goals)
2. Understanding of EGL and basic understanding of OpenGL.
3. Understanding of test-driven-development and "correct" C++
MENTORS
1. TheUni
