Evcodes don't cut it when we have something already specifying the
character to be printed, despite the current group/level. This API
allows some more control on the intended output.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
libinput does it for us, but only for physical devices. When we add
virtual devices to the same seat, we need to track button press count
ourself.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
Virtual input devices aim to enable injecting input events as if they
came from hardware events. This is useful for things such as remote
controlling, for example via a remote desktop session.
The API so far only consists of stumps.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
Depending on clutter_input_device_get_mapping(), or whether the current
tool is either cursor or lens (those don't make any sense in absolute
mode), relative motions will be reported.
This function call only applies to tablets, and thus will error
out unless it's called with CLUTTER_TABLET_DEVICEs. This will
allow setting absolute/relative mapping on those on the fly, as
this is optional.
This will only be practical for pads (and maybe generic buttonsets in
the future?), we just need to know the number as the events will also
contain a number as the identificator.
Those map closely what we get from libinput. Button events have
been made its own separate struct, its semantics fall somewhere
in between of ClutterButtonEvent and ClutterKeyEvent, so is better
emitted as its own set.
Currently the setter doesn't take ownership of the value, but dispose()
will unref it (and thus release someone else's reference). Fix this by
taking ownership of the property value in the setter.
There's no need for a cast for printing an object's type or address,
so we can remove variables that are unused when not building with
CLUTTER_ENABLE_DEBUG.
Mutter (and libmutter users) are the only users of this version of
cogl, and will more or less only use the cogl-1.0, cogl-2.0 and cogl
experimental API variants, and having the possibility of having
different API versions of the same API depending on what file includes
it is error prone and confusing. Lets just remove the possibility of
having different versions of the same API.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
We bypass our build configuration to fetch API from a version which
isn't the one we actually use. Stop bypassing and just admit that the
1.0 API is still there, but still deprecated.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
We didn't include clutter-build-config.h, meaning we included a
different API of cogl than the rest of clutter. This API contains the
function cogl_sqrti which was the only thing used. Lets include the
build config file and stop depending on the API that is no longer
exposed to us.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
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
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
Instead of assuming there is a single onscreen framebuffer, use the
helper functions for setting the frame callback and getting the frame
counter.
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
