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
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.
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.
