It does nothing at the moment, but can be hooked into MetaWaylandTabletPad
now. For X11, we need to trigger these for the pad events we receive from
the passive pad button grabs.
This function will be useful for the wayland implementation, because buttons
are mapped at the time of sending those through the wire.
As x11/wayland implementations differ here, this function will be useful for
the wayland implementation, as the action is handled lat
Some settings make no sense on external tablets, and others make
no sense in display/system-integrated tablets. Perform those checks
so we don't end up with possibly broken configuration.
Given that information defines largely how such devices are to be
configured, it makes sense to have that information at hand. A getter
has been also added for the places where it could be useful, although
it will require HAVE_LIBWACOM checks in callers too.
They are already effectively interchangeable so this should reduce
pointless casts.
Just like in GDK though, we need to keep the old definition for
instrospection to be able to include the struct's fields.
By creating a pending gbm/EGL surface pair, only setting it on
swap-buffers, we would draw onto a buffer on the old surface, then swap
the buffer from the new surface, causing the first frame after a
hot-plug always having no content.
This was in the past not very noticable since some non-deterministic but
frequent side effect in gnome-shell caused hot-plugging to always render
two new frames, but after "Introduce regional stage rendering", this
side effect did not occur as often, thus making it more visible.
This commit updates the current gbm/EGL surface pair before painting a
frame, so that when the frame is painted, the surface with the correct
size is used and the buffer from correct surface is swapped.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Being a listener to a signal, it is inconvenient to enforce order of
execution between different signal listeners. If there are things in
the backend that should be updated before various other signal
handlers, make sure so is done by emitting the signal after having
explicitly notified the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Call a CoglContext "cogl_context", CoglDisplay "cogl_display" and
CoglRenderer "cogl_renderer" so that they won't be confused with
ClutterContext, MetaDisplay and MetaRenderer etc.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Make the cogl vfunc functions have names that are globally
discoverable. Calling the same function in every backend the same name
causes code navigation tools to not function properly. Rename the
affected functions to closer correspond to the style mutter uses.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In preperation for having allowing drawing onto multiple onscreen
framebuffers, move the onscreen framebuffer handling to the
corresponding winsys dependent backends.
Currently the onscreen framebuffer is still accessed, but, as can seen
by the usage of "legacy" in the accessor name, it should be considered
the legacy method. Eventually only the X11 Compositing Manager backend
will make use of the legacy single onscreen framebuffer API.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Split the stage window implementations into three separate objects: one
for X11 as a compositing manager, one for X11 running as a nested
Wayland compositor, and one for running with the native backend.
The new stage window implementations are only thin shells; this is in
preparation for making the stage windows behave more differently.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
The stage resizing was placed in the generic backend, which was only
run on certain configurations (when running nested or using the native
backend). This commits makes the resizing more explicit thus more
obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
This commit completes the move of monitor logic to the monitor
mangager. The renderer now only deals with framebuffers, asking the
monitor manager to do the crtc flip tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Let MetaMonitorManagerKms manage KMS modes. This lets us pass less
state to MetaRendererNative. Instead let MetaMonitorManager tell the
monitor manager when it should set the mode and with what framebuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Absorb the CoglRendererKMS struct into MetaRendererNative. The gbm
device initialization is moved earlier so that the renderer fails to
initialize if the gbm device creation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Move the KMS interaction from cogl into mutter, where most of the other
KMS interaction already takes place. This also removes dead code which
were only excercised when non-mutter callers used the cogl KMS backend.
The cogl KMS API was updated to pass via MetaRendererNative instead of
via the different cogl objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of passing around the KMS file descriptor via clutter to cogl,
just make our own clutter backend create the cogl renderer and set the
KSM fd.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
MetaRenderer is meant to be the object responsible for rendering the
scene graph. It will contain the logic related to the cogl winsys
backend, the clutter backend, and the clutter stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Use the correct pointer types for cogl objects. This avoids warnings
when including the cogl headers doesn't result in all the cogl types
being typedefs to void.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Emit a signal so that interested parties can recreate their FBOs and
queue a full scene graph redraw to ensure we don't end up showing
graphical artifacts.
This relies on the GL driver supporting the
NV_robustness_video_memory_purge extension and cogl creating a
suitable GL context. For now we only make use of it with the X backend
since the only driver with which this is useful is NVIDIA.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
All the upper layers are prepared for multiple onscreen cursors, but
this. All MetaCursorRenderers created would poke the same internal
MetaOverlay in the stage.
This will lead to multiple cursor renderers resorting to the "SW"
rendering paths (as it can be seen with tablet support) to reuse the
same overlay, thus leading to flickering when a different
MetaCursorRenderer takes over the overlay.
Fix this by allowing per-cursor-renderer overlays, their lifetime
is attached to the cursor renderer, so is expected to be tear down
if the relevant device (eg. tablet) disappears.
