mutter:wip/nielsdg/add-yuv-support

Last commit made on 2019-06-24
Get this branch:
git clone -b wip/nielsdg/add-yuv-support https://git.launchpad.net/mutter

Branch merges

Branch information

Name:
wip/nielsdg/add-yuv-support
Repository:
lp:mutter

Recent commits

1fd5e9b... by Niels De Graef <email address hidden>

WIP

940a485... by Niels De Graef <email address hidden>

WIP

784b175... by Niels De Graef <email address hidden>

wayland: Support complex (YUV) pixel formats

In the previous commits, we added the possibility to use pixel formats
which are complex (YUV-based and/or multi-planar) inside Cogl. Use this
new feature by assuming we get a CoglMultiPlaneTexture, rather than a
"simple" CoglTexture.

To easily test whether this works, one can use GStreamer pipelines
(you'll need gst-plugins-bad for this to work):

For normal BGRA (this should already work before this commit):

```
$ gst-launch-1.0 videotestsrc ! "video/x-raw" ! waylandsink
```

For NV12 (a popular video format):

```
$ gst-launch-1.0 videotestsrc ! "video/x-raw,format=NV12" ! waylandsink
```

For YUV 4:2:2 (another video format):

```
$ gst-launch-1.0 videotestsrc ! "video/x-raw,format=Y42B" ! waylandsink
```

You can also replace with other video sinks, like `vaapisink`.

`glimagesink` also works, but for some reason seems to unconditionally
convert to RGBA before submitting a texture (so it doesn't do a lot
really).

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=705514

f8747a2... by Niels De Graef <email address hidden>

cogl: Add CoglMultiPlaneTexture for complex formats

Mutter always assumed that any texture it got was
representable by a `CoglTexture`, which does not have this kind of
concept. This also has the useful feature that each `CoglTexture`
corresponds to a single layer in a `CoglPipeline`.

To deal with this, we introduce a new object: a `CoglMultiPlaneTexture`
consists of multiple `CoglTexture`s, each representing a plane in the
texture we got. It also provides knows when to use a
CoglPixelFormatConversion.

8911151... by Niels De Graef <email address hidden>

cogl: Add non-RGBA pixel formats

Up until now, we didn't support any YUV pixel formats. This was for
several reasons: first, we draw onto an RGBA framebuffer, so any
YUV-based color format needs to be converted to RGBA using a shader.

Next, some more complex pixel format have extra properties that we have
not had to deal with right now: they can be located on multiple "planes"
(which means components are not combined in a single texture or memory
block). Some pixel formats also have a notion of "subsampling", where
one does not save a component for each and every pixel, but rather for
every other pixel (possibly in both the horizontal and vertical sense).

To deal with this, we introduce a new type as well:
`CoglPixelFormatConversion` provides a wrapper for the necessary shaders
(which in Cogl are represented by `CoglSnippet`s).

990b0ef... by Niels De Graef <email address hidden>

WIP: Add a COGL_TEXTURE_COMPONENTS_R

ce64339... by Niels De Graef <email address hidden>

cogl: Replace G_8 with R_8 pixel format

Cogl doesn't use `COGL_PIXEL_FORMAT_G_8` anywhere, and it has differing
implementations depending on the driver (Mesa averages it out over the
diferent components, while NVIDIA stores it in the R component).

Furthermore, by having this new pixel format, we can use this for
single-component uploads, which will be useful when dealing with
non-trivial textures (such as YUV-based textures).

e14613e... by Marco Trevisan (Treviño)

window: Warn if try to focus unmanaging windows

https://gitlab.gnome.org/GNOME/mutter/merge_requests/307

f71151a... by Marco Trevisan (Treviño)

window-x11: Focus the default window with delay while waiting for take-focus

When requesting to a take-focus window to acquire the input, the client may or
may not respond with a SetInputFocus (this doesn't happen for no-input gtk
windows in fact [to be fixed there too]), in such case we were unsetting the
focus while waiting the reply.

In case the client won't respond, we wait for a small delay (set to 250 ms) for
the take-focus window to grab the input focus before setting it to the default
window.

Added a test for this behavior and for the case in which a window takes the
focus meanwhile we're waiting to focus the default window.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/307

6022b23... by Marco Trevisan (Treviño)

test-runner: Add 'dispatch' command

This will only wait for events to be dispatched and processed by the server
without waiting for client processing.

Reuse the code for the wait command too.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/307