The scale will have been set to 1 no matter what when initializing the
MetaOutput since it at the time didn't have an CRTC assigned to it.
Now, when we assign the CRTC to the output, we need to update the scale.
https://bugzilla.gnome.org/show_bug.cgi?id=769505
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
We do some things when binding to a socket fails (closing the fd,
logging, unlinking files, ...) those might affect errno in some
or other way, so it might no longer be EADDRINUSE even if we later
try to make those non fatal.
It seems better to check errno soon after the failure, and don't
rely on it in any way at a later point. All error paths in
bind_to_abstract_socket() also have early logging, which also might
help figure out better the point of failure when the socket fails
to be created.
https://bugzilla.gnome.org/show_bug.cgi?id=769578
Allocate the offscreen stage view framebuffers up front; otherwise they
may get allocated after the viewport calculated by the stage is set,
which would cause the viewport to be incorrect until recalculated.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Support changing the mouse and trackball acceleration profile. This
makes it possible to for example disable pointer acceleration by
choosing the 'flat' profile.
This adds an optional dependency on gudev. Gudev is used by the X11
backend to detect whether a device is a mouse or not. Without gudev
support, the accel profile settings has have effect for mouse devices.
Trackball still uses the "strstr" approach, since udev doesn't support
tagging devices as trackball devices yet.
https://bugzilla.gnome.org/show_bug.cgi?id=769179
Add support for setting edge-scrolling separately from two-finger
scrolling. We now have 2 separate boolean settings for those, with the
Mouse panel in gnome-control-center allowing to set only one of those at
a time, but nothing precludes both being set in the configuration.
We need to handle:
- two-finger-scrolling-enabled and edge-scrolling-enabled settings both
being set.
- those 2 settings being change out-of-order
- two-finger-scrolling being set on a device that doesn't support it
- edge-scrolling-enabled on a device that doesn't support it
And the combinations of one touchpad supporting just one of edge
scrolling and two-finger scrolling and another vice-versa.
https://bugzilla.gnome.org/show_bug.cgi?id=768245
Instead of continuing eventually crashing with a segmentation fault due
to a missing renderer, make MetaBackend an GInitable, and gracefully
handle the failure to fully create the backend with an EXIT_FAILURE.
https://bugzilla.gnome.org/show_bug.cgi?id=769036
We only use a handful of the attributes set, so lets stop pretending
that things are initialized for a reason. Eventually we should stop
using XWindowAttributes in the generic MetaWindow creation path.
https://bugzilla.gnome.org/show_bug.cgi?id=769070
If the compiler cannot figure out that the condition for setting
the dev variable is the same as the condition for accessing it,
it will complain about potential uninitialized use.
