This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
Install include files in
$prefix/include/mutter-$apiversion/[clutter,cogl,...,meta]/, and
datafiles in /usr/share/mutter-$apiversion/.... We still would conflict
e.g. given that our gettext name is "mutter", and how keybindings are
installed, but it's a step in the right direction.
This allows input methods to inject key events with specific keyval/keycode,
those events will be flagged with CLUTTER_EVENT_FLAG_INPUT_METHOD so they
won't be processed by the IM again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/531
If the user maps eg. Alt+F2 to a pad button, the MetaInputSettings will
send the full Alt press, F2 press, F2 release, Alt release sequence.
However the keycode corresponding to Alt is found in level 1, so the
Shift modifier gets unintendedly latched in addition to the Alt key
press/release pair.
We could probably improve keycode lookup heuristics so level=0 (and
no modifier latching) is preferred, but we can do without it altogether
for modifier keys.
If an effect is active and it overrides the paint volume, we should
always recompute the paint volume when requested and not use the
cache, since the paint volume override can change from call to
call depending on what phase of painting we are in. For instance,
if we are part way through painting effects and request the
paint volume, the paint volume should only go up to the current
effect, but in a later call to compute repaint regions, the
paint volume needs to expand to accomadate the effect.
This still involves a lot of recomputation in the case of effects -
in a later clutter version it would be worth adding an API to
allow effects to explicitly recompute and return a new the paint
volume up to the current effect as opposed to recomputing
the cached one.
Previously we were checking l->data != NULL || (l->data != NULL &&
l->data != priv->current_effect). This would continue the loop even
if l->data == priv->current_effect, since l->data != NULL, which was
not the intention of that loop.
We also don't need to check that l->data != NULL before checking if
it does not match the current_effect, since we already checked
that current_effect was non-NULL before entering the loop.
Some tablets have a noticable pointer jump on tip down/up, causing unintended
lines during drawing. Likewise, a button event may have an axis update that we
currently ignore. libinput provides tablet axis events only if no other state
changes, the client must instead get the current axis data from the tip/button
event. So let's do this, process the event axis data during tip/button as
well.
A libinput recording to reproduce is the 'dots.yml' in
https://gitlab.freedesktop.org/libinput/libinput/issues/128Fixes#289
Unfortunately XKeysymToKeycode() falls short in that it coalesces keysyms
into keycodes pertaining to the first level (i.e. lowercase). Add a
ClutterKeymapX11 method (much alike its GdkKeymap counterpart) to look up
all matches for the given keysym.
Two other helper methods have been added so the virtual device can fetch
the current keyboard group, and latch modifiers for key emission. Combining
all this, the virtual device is now able to handle keycodes in further
levels.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/135
A just focused ClutterInputFocus must set itself up correctly on
all situations. Refactor this into a function, so it can be used
for the case where a ClutterText gets editable while focused.
`ClutterText` painting for editable single_line_mode actors like `StEntry`
is always clipped by:
`cogl_framebuffer_push_rectangle_clip (fb, 0, 0, alloc_width, alloc_height)`
So it's difficult to get the rectangle wrong. However in cases where the
target framebuffer has changed (`cogl_push_framebuffer`) such as when
updating `ClutterOffscreenEffect` we had the wrong old value of `fb`. And
so would be clipping the wrong framebuffer, effectively not clipping at all.
Sending button events to a ClutterVirtualInputDevice, the API expects
button codes to be of the internal clutter type. The evdev
implementation incorrectly assumed it was already prepared evdev event
codes, which was not the case. Fix the evdev implementation to translate
from the internal representation to evdev before passing it along to
ClutterSeatEvdev.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/190
Children added to a parent after that parent (or its ancestors)
have already been cloned now inherit the clone branch depth of
the parent. Otherwise `clutter_actor_is_in_clone_paint` on the child
could return FALSE when it should have been returning TRUE.
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
`modelview` is uninitialized and the `apply` function just multiplies it.
What we really want is to initialize `modelview` so replace `apply` with
`get`.
Who knows what bugs this may have caused...
Treat the main seat as other seats, so we don't have to handle it differently
in specific places. This was already the case before when a real device
was plugged before the startup, but not applied when hotplugging a device.
When no input devices are available on startup the device manager might be fast
enough to be constructed so that no default stage is set yet, and thus when
main seat virtual devices are created they won't have a proper stage set.
If then we plug a real device, the events that an input manager could generate
won't be associated to any stage and thus won't be processed.
We need then ensure that when we update the stage for the device manager we
(un)associate it also to the main seat devices.
In devices such as ARM boards there could be no input devices connected on
startup, leading to a crash when we try to process artificial events that
could be queued (as gnome-shell does when syncing pointer).
Those events still should refer to a device and, in case we don't have one
provided by libinput we should still return the core devices defined in the
main seat.
The fix is twofold. On one hand, it makes sense not to relate IM (nor
any other) generated events to a HW device. On the other hand, if we
are unfortunate that an IM event is in flight when we are switching
to another TTY, it may arrive at a time when the source device is no
longer existent.
Mark CAPS lock as a modifier (as it should) so that when using XKB
options to change the default behaviour of CAPS lock, the new assigned
key can by used as a sticky key as well.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/112
Input method can inject key events, which leads to multiple reported key
press/release events for a single user action.
Ignore those events as this confuses keyboard accessibility.
And make the ClutterText-level properties independent from the input
focus, as those properties can be set anytime, not just when the
ClutterText actor is focused.
https://gitlab.gnome.org/GNOME/mutter/issues/66Closes: #66
We can save an unnecessary relayout if the required size to fully draw the text
is equal to the currently allocated size after the underlying text buffer or
attributes that only affect the PangoLayout have changed.
Actor keybindings were dispatched in an earlier return path, which means
the IM doesn't get to see certain key events. Flip the order around so the
IM has an opportunity to handle all keypresses.
https://gitlab.gnome.org/GNOME/mutter/issues/65Closes: #65
IF two touch devices have colliding touch point IDs they'd interfere on
the seat. To avoid this, always allocate a seat wide slot for each
device wide slot, but don't use device slots directly in the seat.
Checking correct state is responsibility of the ClutterInputFocus user, and
it is indeed possible to get a focused ClutterText while its
ClutterInputFocus didn't get itself focused (eg. lack of IM).
https://gitlab.gnome.org/GNOME/mutter/issues/36Closes: #36
BTN_STYLUS3 is defined by the Linux 4.15 kernel and is sent when the
third button on a stylus is pressed. At the moment, only Wacom's "Pro
Pen 3D" has three stylus buttons. Pressing this button triggers a button
8 event to be sent under X11, so we use the same mapping here.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
clutter_set_viewport always operates on the draw fb, but
mutter sometimes has an offscreen fb it uses instead.
This commit uses the non-deprecated, clutter_framebuffer_set_viewport
function, which takes an explicit fb argument.
Closes: https://gitlab.gnome.org/GNOME/mutter/merge_requests/2
This function returns TRUE if there is any preedit going on. This method
will be useful in gnome-shell where similar checks are performed on
StIMText actors.
ClutterInputFocus is an abstract object to be subclassed by UI actors and
the wayland interface and represents the user of an input method. It
represents the current focus of the input method, so all emitted signals
and public API hooks are expected to be called when the input method is
currently interfacing with the input focus.
ClutterInputMethod is an abstract class (to be implemented in the upper
layers) that represents the input method itself. Besides focus management
itself, all public API calls that would be called by the subclasses are
delivered through the current input focus.
Libinput shall report those as having slot=-1, which gets mistakenly
translated into the special "NULL" ClutterEventSequence. Making those
events get a non-NULL sequence will make single touch devices work.
https://bugzilla.gnome.org/show_bug.cgi?id=792005
We might receive touch events for unknown touch points, for example
when starting mutter while touching the screen (resulting in no
touch-down event ever being received). Avoid crashing when this happens
by just dropping these events on the floor.
https://bugzilla.gnome.org/show_bug.cgi?id=791371
When capture_view* functions are called with the paint flag set
to TRUE, we need to setup the framebuffer, however this was
happening after setting up the viewport, while the viewport
needs the framebuffer to be valid when calling cogl_set_viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=791809
On VT switch, the xkb state layout index is lost and reset to the first
group, so if the first layout is not the last one being used, the xkb
state used in both meta-wayland-keyboard.c and clutter/evdev will be
desynchronized with the keyboard source indicator in the gnome-shell UI.
Save the effective layout chosen along with the seat so it can be
restored when reclaiming devices.
Use the saved layout index from the clutter/evdev's seat to restore the
layout in meta-wayland-keyboard, so that switching VT doesn't reset the
layout and causes further discrepancies with the layout indicator in the
gnome-shell UI.
https://bugzilla.gnome.org/show_bug.cgi?id=791383
Adds a set of convenient functions that can be shared between x11 input
device backends (namely core-x11 and xi2) to control XKB accessibility
features.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Implementing keyboard accessibility in clutter means we need to be able
to notify higher layers of possible modifier masks or setting changes
(as some keyboard accessibility can be disabled or enabled by keyboard).
For this purpose, add two new signals:
ClutterDeviceManager::kbd-a11y-mods-state-changed
ClutterDeviceManager::kbd-a11y-flags-changed
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Use a set of bitwise enum flags to set different keyboard accessibility
features and the necessary vfunc hooks in clutter input device so that
keyboard preferences can be passed to different input device
implementations.
The idea is to be able to configure either the clutter own
implementation of keyboard accessibility for evdev, or eventually
configure AccessX from the X11 clutter input device using the same
mechanism.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
On X11, when AccessX is enabled, all X11 clients benefit from the
AccessX features, including gnome-shell/mutter, meaning that special
keys like the overview or other shortcuts are also affected.
To achieve the same in Wayland, we need to implement the same features
in clutter main rather than the Wayland backend, so that all depending
code within the compositor but also Wayland clients (which rely on the
compositor to get keyboard events) similarly benefit from the
accessibility features.
Add hooks to the clutter main loop to be able to implement such
features.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
We'll need a way to trigger a bell from within clutter for keyboard
accessibility features, add the necessary hooks to be able to call a
backend bell-notify method.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
The capture_into() function wrote out of bounds when capturing from a
non-origin view (not positioned at (0,0)). At the time of
implementation, this API was used to capture pixels across views into a
single data buffer, but the way it's used, and the way views may work
now, makes this impossible to do properly.
So remove the ability to capture into a pre-allocated buffer from
multiple views, and complain if the passed rectantgle overlapps with
multiple views. This removes the broken offset calculation all
together, fixing the bug motivating this change.
https://bugzilla.gnome.org/show_bug.cgi?id=787715
The reverted commit seems to cause
https://bugzilla.gnome.org/show_bug.cgi?id=787240 for some reason. Lets
be safe and revert it for now, as the code freeze is just around the
corner.
This partly (it doesn't reintroduce a whitespace issue) reverts commit
dbc63430d8.
Add API similar to clutter_stage_capture() but that draws into
externally allocated memory. It is assumed that the pixel format is
ARGB32, and the memory is structured in a way that the width of the
passed rectangle is identical to the stride divided by 4.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
If CLUTTER_CURRENT_TIME is passed, let the backend find an appropriate
time stamp representing the current time in the clock that is used by
that backend.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
When suspending (i.e. VT switching away, the GDM gnome-shell instance
gets hidden, or changing user), destroy the onscreen and offscreen
monitor framebuffers. When resuming, the stage views and framebuffers
will be recreated anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=786299
Message was poking stage_x11, which doesn't exist in this context.
Just print the Window that is receiving the event, the event will be
emitted into the only existing stage anyway.
Adds basic support for the "wheel" event from the Wayland tablet protocol.
Ideally we would accumulate the angle and report a wheel event with an
appropriate value for "clicks". We can get away with a much cruder method
for the time being, however, since no Wacom tablet puck actually provides
a smooth scrollwheel. Checking whether the angle in CLUTTER_INPUT_AXIS_WHEEL
exceeds a nominally-small threshold is sufficient to determine that the
wheel has advanced by at least one physical click.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
These events will be useful on gnome-shell UI, so translate the
4-5 button events with exotic axes to those. Also use the
XI_Motion event received when first touching those to reset
the ring/strip state, so we don't receive spurious direction
changes in the upper layers.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
When fractional scaling is used, damage and paint clip region is tracked
in stage coordinate space using integers might end up missing some
pixels when the border ends up on half pixels. Change the damage
tracking and clip regions to be in buffer coordinates so we can align
damage on physical pixel borders.
However, just using rounding up to the next physical pixel results in
glitches. To avoid this, extend the damage by one logical pixel in all
directions, but still (scissor) clip the drawing to the non-extended
region, as otherwise drawing the damaged regions will result in
incorrect pixels on the right and bottom edges of the clip region. It is
possible that there are better ways to do this, which can be explored in
the future.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
We always hit non-fractional floats here because the stage views are
always made so that they are aligned on integer positions with integer
sizes, but there is no reason to go float -> int -> float when
calculating the viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Make clutter_stage_capture() work if views are scaled. This needs
adaptations on the using side to deal with the cairo surface device
scale that is used to communicate the scale used when capturing.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To support fractional scaling, change the stage view scale to be a
float instead of an int. Also change the places where it is retrieved
and used when scaling things.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Previously gnome-shell listened on the Xft Xsettings via GTK+s
GtkSettings to get the font DPI setting. The Xsetting might not
be what we want, and we should not rely on Xsettings when we don't need
to, so lets manage it ourself.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
These should be set one, but just set the master to be the slave
pad device. We are passively grabbing the pad device, so this is
consistent with active grabs on slave devices. Besides, pads are
paired to the VCP, which is not really truthful.
Fixes inoffensive warnings when trying to check whether motion
throttling applies for these events.
https://bugzilla.gnome.org/show_bug.cgi?id=784881
When building against a glib-genmarshal from GLib 2.54 we can use the
`--prototypes` command line argument to generate the prototypes for the
marshallers in the C source, and avoid a missing-prototypes compiler
warning.
Since commit 5cb5baa7d4, we skip transitions when updating an
actor's scale/position to the existing value. As a result, we
don't get change notification on those properties either - given
that the properties did not actually change, that behavior seems
fine, so just modify the test to not expect a notify signal for
unchanged properties.
Commit 0fd9e38175 fixed setting the out parameter for the x coordinate
when using the X11 backend, but broke compilation when the backend is
not available ...
Really fix the issue by running the X11-specific code when the X11
backend is available and in use, and display the one-time warning
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=781902
GLib now generates the prototypes for the generated marshallers, so it's
not necessary to include the header any more.
This fixes a build failure in GNOME Continuous with GLib master, caused
by -Werror=redundant-decls.
Due to an accidental swap of an else statement and a preprocessor #else,
the output x coordinate is currently only set when not using the X11
windowing system, whoops.
https://bugzilla.gnome.org/show_bug.cgi?id=781902
Window scaling is a clutter feature used to enable automatic scaling of
stage windows when running under as an application in windowing system.
Clutter in mutter does not support running as a stand-alone application
toolkit, so lets remove this unused feature.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit adds the ability to set a scale on a scale view. This will
cause the content in the stage view to be painted with the given scale,
while still keeping the configured layout on the stage. In effect, for
a stage view with scale 'n', this means the framebuffer of a given stage
will 'n' times larger, keeping the same size on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Clutter's evdev input backend has no support for setting double
click timeout set by gnome-settings-daemon. This results in
touchpad click events timing out on wayland, because the
default timeout value wasn't enough.
This patch moves timeout setting to mutter and removes X11
backend specific setting from clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=771576
This will be used to invert the transform in the nested mode, making it
possible to test offscreen texture based transform using the nested
backend.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
In order to minimize the amount of breakage, while at the same time
making it easier to make backward incompatible changes needed to
continue turning libmutter into a capable Wayland compositor, make the
libmutter and friends (libmutter-clutter, libmutter-cogl*) parallel
installable by adding a version number to the name. This changes
various filenames, for example what previously was libmutter.so is now
libmutter-0.so (assuming the version for now is 0), and
libmutter-clutter-1.0.so is now libmutter-clutter-0.so. The pkg-config
filenames and GObject introspection has been renamed to reflect this as
well.
This enables a downstream compositor rely on a specific version of the
libmutter API, while gracefully handling API/ABI changes by having to
update to the new version at their own pace.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
When != 0, this property will express the W:H ratio of the desired
output area (be it one monitor or the span of all monitors). At
the time of translating coordinates, coordinates will be skewed so
that the input area of the tablet is a rectangle of the given ratio.
Events happening in the input areas that fall outside the output
aspect ratio will be clamped to the nearest coordinate in the rect.
If the ratio is 0, the whole input area of the tablet will be used
and no coordinate skewing will happen.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
And transform absolute events using this matrix. This property is
akin to the "Coordinate Transformation Matrix" property in X11,
and will be used to map tablets/touchscreens to outputs, favoured
over the libinput matrix which is meant for calibration.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
Clutter assumed seat0 which is most usually, but not always correct.
Add an evdev-backend specific function to allow passing the seat
that will be used for ClutterDeviceManager construction, which we
already obtain in MetaLauncher.
https://bugzilla.gnome.org/show_bug.cgi?id=778092
Since both the libinput event source and the key repeat timer have the
same priority, the order in which both handlers are called is
arbitrary if both sources are ready on the same poll return. This
means that sometimes we generate key repeats when there's already a
real key event queued on libinput that would cancel the repeat timer
if only it was processed before.
One solution would be lowering the repeat timer source priority a
notch lower than the libinput source but that would mean that a steady
stream of events from libinput (e.g. pointer device motion) would
prevent any key repeats to happen.
Instead, we can fix this problem by trying to dispatch libinput from
the key repeat timer and checking if the timer source has been
destroyed before generating more key repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
Commit 9214d5029c changed the notify*
API to use microseconds and we already have a microsecond time source
here so we can use the timestamp directly without losing resolution at
this layer.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
This is implemented using Wacom-driver specific properties at
the moment, until libinput becomes the fallback driver handling
tablet and pad management.
Whenever a tool becomes in proximity, a new ClutterInputDeviceToolXI2
will be created (if it wasn't created previously) for the given
serial number. This tool will be set in all events send from the
device.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Stylus configuration (stylus buttons, pressure) was handled
at the very high level, doing the button and pressure translations
right before sending these to wayland clients.
However, it makes more sense to store these settings into the
ClutterInputDeviceTool itself, and have clutter apply the config
at the lower level so 1) the settings actually apply desktop-wide,
not just in clients and 2) X11 and wayland may share similar
configuration paths. The settings are now just applied whenever
the tool enters proximity, in reaction to
ClutterDeviceManager::tool-changed.
This commit moves all handling of these two settings to
the clutter level, and removes the wayland-specific paths
https://bugzilla.gnome.org/show_bug.cgi?id=773779
We do so whenever a tool enters or leaves proximity. We now also
ensure that last_tool is NULL after it leaves proximity, although
the CLUTTER_PROXIMITY_OUT event itself should still contain tool
information.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
We most notably handle button events (acquired through a passive grab on
all device buttons) which are translated to CLUTTER_PAD_BUTTON* events,
so there is generic handling of pad actions on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Commit 5fbb479301 was wrong too. What we
really want to do here is getting view relative coordinates given the
view's and the rectangle's global coordinates so we need to subtract
the view's origin from the rectangle's.
https://bugzilla.gnome.org/show_bug.cgi?id=771502
Commit a4fb7ef5a3 dropped translations of our internal cogl/clutter
forks, which broke the local-based text direction support. Instead
of bringing back translations just for this purpose, we can re-use
GTK's translations which use the same technique.
https://bugzilla.gnome.org/show_bug.cgi?id=771549
Now with the existance of offscreen view framebuffers the buffer age
damage regions are only valid if the view in question doesn't doesn't
have an intermediate offscreen. So, for views that doesn't have buffer
age, return the dirty pixel (0,0).
https://bugzilla.gnome.org/show_bug.cgi?id=770672
When blitting an offscreen onto an onscreen, the whole offscreen should
always be drawn on the whole onscreen. Thus, don't try to convert
between coordinate spaces, just draw the whole offscreen on the whole
onscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=770672
Clutter discards any motion event if next event happens to also be a
motion event. This is problematic when the motion event carries
relative motion deltas, since the information about them is completely
lost.
Until we have moved away made the stage stop discarding motion events,
lets work around the issue by compressing them, effectively adding
multiple relative motion deltas together, would one be discarded.
https://bugzilla.gnome.org/show_bug.cgi?id=771049
The rectangle passed to capture_view() is in stage coordinate space;
thus, to translate to framebuffer coordinate space, the origin need to
be translated by the view layout position.
This fixes capturing views not at position (0, 0).
https://bugzilla.gnome.org/show_bug.cgi?id=770127
Absolute pointer events used the X coordinate as both X and Y. This
caused the pointer cursor to be moved incorrectly for absolute pointer
devices, commonly used in virtual machines.
https://bugzilla.gnome.org/show_bug.cgi?id=770557
"Blit" the result on the framebuffer after each view is painted.
This of course only applies if there is an offscreen buffer to
perform any blitting. Otherwise the onscreen framebuffer is rendered
to directly and this step is not necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The offscreen is given through the ::back-buffer property, the ClutterStageView
will set up the the CoglPipeline used to render it back to the "onscreen"
framebuffer.
The pipeline can be altered through the setup_pipeline() vfunc, so ClutterStageView
implementations can alter the default behavior of blitting from offscreen to
onscreen with no transformations.
All getters of "the framebuffer" that were expecting to get an onscreen have
been updated to call the right clutter_stage_view_get_onscreen() function.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
Various clutter test directly use cogl symbols, so they should be linked
against mutter-cogl as well.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769636
This is somewhat gross at the moment, because we're after all mimicking
real keyboard events, we can only lookup keycodes that are available
in the current map, and the control of levels is rather limited.
Eventually, we want to implement the text_input protocol, handle these
events separately to MetaWaylandKeyboard, so event->key.keyval is
is guaranteed to be the final result. Until then, this is the farthest
we can get.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
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.
