GSoC project ideas
Updated 806 Days AgoPublic

Students: here are some potential ideas for projects. Talk to a mentor about these (or your own) ideas if you plan to apply. You will be expected to follow the application instructions. Potential mentors can help you get started. If you have your own idea, please talk to potential mentors on IRC.

Mentors: please use this format to add new ideas:

= Project title =
**Possible mentors:**
**Relevant links:** 

This list is ordered first by having enough possible mentors, then very roughly by importance to upstream.

Let Weston's Wayland-backend use Presentation extension

Possible mentors: @pq @giucam

Prerequisites: git, C

Relevant links: T45

When Weston runs nested on Wayland, it currently fakes all timings based on frame callbacks. This is quite inaccurate.

Implement support for host compositor's Presentation extension, and use it to drive the Presentation events towards clients.

Is this task too small?
What else could you do that is related?

  • support the wl_surface property buffer_scale according to output_scale
  • support more of the input protocols
  • (be careful to keep your project scope in control and do not take more you can chew)

How could this be tested automatically, nested on Weston/headless?

Harden libwayland-client against misuse

Possible mentors: @pq, @jadahl

Prerequisites: git, C

Relevant links: T50

There are a lot of sanity checks that could be added. With checks, one also needs tests to ensure the checks work.

This could even be a candidate for test-driven development.

Wayland protocol backward-compatibility checking tool

Possible mentors: @pq, @jadahl

Prerequisites: git, C and/or Python, XML

Relevant links: T3357

Do all possible mechanical checks to ensure updates to protocol XML files do not break the protocol.

Bonus points for figuring out a way to run this automatically on old vs. new XML file revision when committing or some 'make check' + git magic.

Weston output management enhancements (taken by Armin Krezović)

Possible mentors: @pq @giucam @sardemff7

Prerequisites: git, C

Relevant links:

Two ideas in either order or both:

  • fix weston to work with zero outputs
    • at startup, outputs hotplugged later
    • at runtime, all outputs hot-unplugged
    • in particular, survive a single output unplug+plug in a way a user would expect
  • make Weston output layout configurable in weston.ini
    • no configuration protocol or anything like that
    • no GUI
    • just weston.ini, by output names
    • cope with only some outputs from weston.ini being present
    • cope with hotplug/unplug

A shattered Weston demo client

Possible mentors: @pq, @jadahl

Prerequisites: git, C, basic OpenGL

Relevant links:

Write a demo client that shatters its window into sub-surfaces:

  • the idea is to simulate a window larger than any texturing or rendering limits
  • sub-surface / tile max size e.g. 256x256 (arbitrary, in reality it would come from min(max_texture_size, max_render_size))
  • when window resized, dynamically adjust number of tiles as needed
  • rendered with GL
  • synchronized sub-surfaces, no threads

Add Weston DRM/Pixman support for multiple KMS devices

Possible mentors: @pq

Prerequisites: git, C

Relevant links:

Add support to Weston to open several KMS devices and the ability to use outputs from all of them.

To sidestep the problem of buffer sharing between different GPU devices, restrict to Pixman-renderer: DRM dumb buffers and no composite-bypass make it simple to operate.

This work probably best started after the Weston atomic conversion patches from Daniel Stone have landed.

Stop using cairo-egl in Weston demo apps

Possible mentors: @pq, @sardemff7 (backup)

Prerequisites: git, C, basic OpenGL

Relevant links:

Rewrite parts of the toytoolkit such, that window.[ch] do not depend on GL, GLESv2, EGL, cairo-gl, cairo-glesv2 nor cairo-egl.

Weston's Wayland backend already uses some shared code to draw window decorations and then gl-renderer puts those up in GL-textures and blits them into the composite as needed. Reusing the shared code and using gl-renderer as an example, implement an optional static library that GL demo apps can link to for getting window decorations.

The idea is that if an app links only to, no GL or EGL libraries will be linked or needed. This is the normal software rendered (Cairo) case. If an app wants to use GL, it still links, but links also the new static library for the decorations, and marks the window as not needing a Cairo surface. We want to limit all Cairo operations to software rendering and wl_shm buffers.

As OpenGL and GL ES are conflicting, we need two flavours of the new static library, one for each GL. It is acceptable to not actually build the convenience library, but refer to the source files in each demo app build rules.

Currently Cairo's build configuration dictates whether we can build OpenGL or GL ES demos; we cannot build both at the same time. If Cairo is built with neither, we can use neither either, except for the simple-* demos which do not use Cairo at all. Therefore we want to stop using cairo-egl, cairo-gl and cairo-glesv2 completely.

The major benefits of this work are:

  • We stop using cairo-egl, -gl, -glesv2 which are all experimental.
  • When building Weston demos, it does not matter how Cairo was built.
  • We can always build all Weston demos, whether they use OpenGL, GL ES or neither.
  • We can remove the --with-cairo configure option and avoid users making mistakes with it.

Weston test suite

Possible mentors: @pq

Prerequisites: git, C

Relevant links:

Jon Cruz has been developing a new Weston test suite framework. If he happens to get the infrastructure in place in time, the student could port old tests to the new suite.

Whether the new framework gets up or not, the student could implement new tests nevertheless, in the old framework if necessary. Some ideas are linked from the bug report.

Coordination will be needed with Bryce Harrington, Jon Cruz, Dawid Gajownik, and maybe Derek Foreman on who will attack which items and what patches are already in the works.

Lift GL_MAX_TEXTURE_SIZE limitations from Weston's GL-renderer

Possible mentors: @pq

Prerequisites: git, C, basic OpenGL

Relevant links:

Restricted to wl_shm buffers;

When a wl_shm buffer is larger than the maximum texture size in GL, Weston currently just fails to show it. Instead, have GL-renderer create several textures for the one surface, and render them, avoiding the texture size limitation.


  • Is this feature useful in reality?
  • Will not help gfx-accelerated clients, which will just need some way to simply avoid creating too large surfaces - client-side tiling for huge windows would be possible using sub-surfaces though.

Other graphics related projects

X.Org also offers other graphics related projects and can take on Wayland projects which do not come under our scope. Check out their GSoC ideas page for more information.

Last Author
sardemff7, giucam, jadahl and 2 others