The Clutter X11 backend can't drop CLUTTER_PEN_DEVICE and
CLUTTER_ERASER_DEVICE in favor of CLUTTER_TABLET_DEVICE without
losing information (as the driver will create one device for each).
So make MetaInputSettings cater for both sets of device types.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Its only purpose was caching settings applying to an stylus/tool, this
is now handled through ClutterInputDeviceTool evdev specific API, or
X device properties, so is not needed anymore.
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
Enabling edge scrolling before disabling two finger would result in
edge scrolling not actually being enabled because two finger is still
enabled at the time and we bail out.
This patch moves this logic to common code for both the native and X
backends and fixes it by ensuring that both settings are never set at
the same time and still re-checking if edge scrolling should be
enabled after two finger scrolling gets disabled.
We also simplify the code by not checking for supported/available
settings since the underlying devices will just reject those values
and there isn't anything we can do about it here. It's the UI's job to
only show supported/available settings to users.
https://bugzilla.gnome.org/show_bug.cgi?id=771744
Checking for supported methods isn't needed since libinput will just
error out and do nothing itself if a requested method isn't supported
and, in fact, this logic was preventing the enum values 0 from being
set.
https://bugzilla.gnome.org/show_bug.cgi?id=771744
commit e2bfaf0751 does this:
g_hash_table_insert (cards,
g_udev_device_get_name (parent_device),
g_steal_pointer (&parent_device));
The problem is the g_steal_pointer call may happen before the
g_udev_device_get_name call leading to a crash.
This commit does the get_name call on an earlier line
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Right now we accept any character device that matches the glob card*.
That's fine, but we can be a little more specific by checking that
the devtype is what we expect.
This commit does that.
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Despite g_udev_client_new taking a list of subsystems, it doesn't
implicitly filter results to those subsystems.
This commit explicitly adds a subsystem match to make sure sound cards
don't end up in the resulting list of video cards.
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Using the view's MetaMonitorInfo to find all the crtcs which should be
configured to display a given onscreen doesn't work unfortunately. The
association runs only the other way around, i.e. we need to go through
each crtc and find the ones corresponding to our monitor info.
https://bugzilla.gnome.org/show_bug.cgi?id=773115
If this isn't initialized and an idle watch gets instanced before
meta_idle_monitor_native_reset_idletime() gets called, that idle watch
would get triggered as soon as we hit the main loop.
This was causing gnome-session to go into idle mode at session start
thus making gnome-shell lock the screen.
In the past this bug was being masked by either logind emiting
session active signals or a stray input event making it through at
startup.
https://bugzilla.gnome.org/show_bug.cgi?id=772839
Going through the global mode pool and then checking if the mode is
available for a given output is pointless work since we can look at
the output's available modes directly.
This implicitly changes how we choose the default mode since, instead
of relying on the sort order of the global modes array, we now rely on
the sort order of the output modes array. Still not ideal, but at
least it makes more sense since the global array is essentially
unsorted.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
This isn't technically needed and, in fact, makes us default to
interlaced modes in some cases which isn't desirable.
Note that X doesn't account for these flags either for its mode
refresh rates.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
As the m format specifier doesn't consume any arguments, the number
of varargs currently doesn't match the number of specifiers; the
failed transform may be relevant, so include it in the message
instead of removing the excess argument.
backends/meta-input-settings.c:1245:27: error: format '%lx' expects
argument of type 'long unsigned int', but argument 3 has type 'guint64
{aka long long unsigned int}' [-Werror=format=]
Those will be unseen by g-s-d/g-c-c, so no settings will be written on
disk for those. Still, look up an ID correctly in this case instead of
crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=771628
This is needed to make the wayland backend react to configuration
changes until gnome-control-center is updated to use the
gsettings-desktop-schemas settings.
https://bugzilla.gnome.org/show_bug.cgi?id=771315
Some output devices only advertise their preferred mode even though
they're able to display others too. This means we can include some
common modes in each output's supported list.
This is particularly important for mirroring, since we can only mirror
outputs which are using the same resolution.
https://bugzilla.gnome.org/show_bug.cgi?id=744544
This signal allows interested parties to be notified of a new cursor
frame being painted regardless of whether it's being painted by the
backend directly or if it's a software rendered cursor frame handled
by clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=749913
Instead of hiding stage views enablement behind MUTTER_STAGE_VIEWS=1,
default to enable it, while making it possible to disable using
MUTTER_STAGE_VIEWS=0 instead.
https://bugzilla.gnome.org/show_bug.cgi?id=770366
Switch to the output naming logic used by the X server's modesetting
driver which, in particular, uses drmModeConnector's connector_type_id
instead of connector_id.
The kernel generates new connector_id's every time there are changes
which means we can't identify the same monitor on the same connector
after an hardware hotplug. Switching to connector_type_id fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=770338
We can only honor this properly in the MUTTER_STAGE_VIEWS=1 case. When using
the legacy view, software implemented transforms are only exposed if there is
only one output, as we can only transform the entire stage there.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The texture is only created if the view is transformed at the software level,
otherwise the texture is NULL, and rendering happens on the onscreen.
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
The call to _cogl_framebuffer_winsys_update_size() results in no-op here,
as the framebuffer has already the right size when rebuilding the views.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
Those will need a separate treatment from the modes that we eventually
support through "software", so split those into a separate enum so we
can can do the right thing when applying the configuration.
Also, add a helper function that returns the transform that the software
fallbacks should perform, which should be "normal" if the rotation is
already handled via hw.
The function applying the configuration has been modified to always set
a HW rotation mode (even if normal), when we come to support SW rotation
modes, we'll be relying on a normal transformation, so it will be
necessary to have mixed HW/SW managed transforms.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
As whether edge scrolling is enabled depends on whether two-finger
scrolling is disabled, make sure to update two-finger scrolling first.
Note that this only fixes the problem on startup. Changing the
settings in GSettings directly might cause an inconsistent state, but
the main UI for this setting, gnome-control-center, makes sure to
update two-finger scrolling before edge scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=769276
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
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
