Some DRM drivers have added a consistent set of properties that
allow compensating for the overscan that some TVs do, without the
user being able to disable.
There is copy&pasted code in set_scroll_button, which is apparently
wrong, because it is trying to set scroll method instead of the scroll
button...
https://bugzilla.gnome.org/show_bug.cgi?id=747967
Since 8769b3d55, the checks performed on which update_* function was
called for each device got quite more lax, leading to failed asserts
on code that assumed the previous behavior.
Change update_[mouse|touchpad|trackball]_* to bail out early if the
device received has not the right type, and remove the asserts.
https://bugzilla.gnome.org/show_bug.cgi?id=747886
This seems nicer/tidier than the current X11 (center on the span of all
monitors) or native (so close to the activities corner it's hard not
to trigger it) platform behaviors.
This code also takes over the native-specific pointer warping that
happens when the pointer was over a removed output.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
This function returns the monitor_info index corresponding to the given
coordinates, or -1 if none is found at that point. The native backend
has been changed in places where it could make use of this function.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
clutter currently never emits activated or deactivated signals on
the stage object when using the EGL backend. Since the stage never
gets activated, accessibility tools, like orca, don't work.
This commit makes mutter take on the responsibility, by tracking
when the stage gains/loses focus, and then synthesizing stage
CLUTTER_STAGE_STATE_ACTIVATED state events.
A limitation of this approach is that clutter's own notion of
the stage activeness won't reflect mutter's notion of the
stage activeness. This isn't a problem, in practice, and can
be addressed in the medium-term after making changes to
clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=746670
The enums are swapped currently, because for edge scroll is enabled two finger
scroll and similary for two finger scroll is enabled edge scroll, what is
apparently wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=746870
On startup, the cursor is kept hidden if there's any touchscreen available.
If the device that was last interacted is removed, we check on available
pointing devices though, so we don't possibly hide the pointer if there are
further mice/touchpads/etc.
Devices being added don't update cursor visibility, we wait for the user
interacting with those instead.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
On X11, calling this function on meta_display_handle_events() will not catch
mouse events happening over clients, so poke directly in the backend for
XI_DeviceChanged events, which mutter will get on device switches.
The code has been slightly refactored so we deal with XIEvents at a single
handle_input_event() function.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
This function can be used to trigger changes depending on the device type
that is currently emitting the events. So far, it is used to switch cursor
visibility on/off on touchscreen interaction.
A "last-device-updated" signal has also been added, in order allow hooking
other behavior changes (eg. OSK) when the last device changes.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
The initial pointer position is set by clutter. At the moment it
is the point 16x16 on the screen. But this point is not always
in the visible area on monitors (the monotors can be arranged in
many different ways).
https://bugzilla.gnome.org/show_bug.cgi?id=745752
Otherwise the pointer might be "lost" outside the visible area. Note
that the constraining code only ensures the pointer doesn't leave the
visible area but if the pointer is already outside because the rug was
pulled under it then it doesn't do anything.
https://bugzilla.gnome.org/show_bug.cgi?id=745121
DRM objects like connectors and encoders might change at any time, in
particular they might become invalid between drmModeGetResources() and
getting the actual objects in which case they'll be NULL. Be defensive
against that.
Note that, if this happens, we should get another udev event soon
which will cause us to update our state.
https://bugzilla.gnome.org/show_bug.cgi?id=745476
To make the nested compositor mode work again after "backends/native:
Calculate the output scale in here", set the scale when creating the
dummy output.
https://bugzilla.gnome.org/show_bug.cgi?id=745401
This just exposes the type and the singleton getter necessary to make
it available to introspection. We'll expose more functionality as it
becomes needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743745
When running as a dispay server pointer barriers are a server side
feature and requires no client interaction of any sort. This patch
implements pointer barriers that can be used when running as a display
server on the native backend. Running as a display server using the X11
backend is currently not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
For each device that can be mapped (touchscreens, tablets), the output
will be fetched from settings and matched with the currently connected
ones. If a match is found, the device matrix will be found out from the
output configuration and set on the device.
This is also updated both individually for newly connected devices, and
collectively on output configuration changes.
https://bugzilla.gnome.org/show_bug.cgi?id=739397
This goes through modifying XI2 device properties, either common ones (eg.
set on every device) or those specific to the libinput X11 driver. Keyboard
repeat/rate are set through core and XKB APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=739397
This object internally keeps track of the relevant input configuration,
and goes through its vmethods in order to apply the configuration on the
backend-specific devices.
So far, only mouse/touchpad settings are actually attached to GSettings
changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked
yet.
One caveat is that meta_input_settings_create() may return NULL if the
backend does not own the windowing system (wayland nested on X11 being
the one case), and thus device settings can't be changed freely.
https://bugzilla.gnome.org/show_bug.cgi?id=739397
This patch removes the X11 specific code from MetaBarrier and creates an
abstraction layer MetaBarrierImpl. The existing X11 implementation is
moved to a new GObject MetaBarrierImplX11 implementing the abstract
interface MetaBarrierImpl which is instantiated by MetaBarrier when
supported.
While at it, move it to backends/ and properly name the files.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
EDID parsing has been refactored to a common meta_output_parse_edid()
function, which ensures the extracted information is the same on both KMS
and X11 backend, so it can be used consistently on eg. settings values.
https://bugzilla.gnome.org/show_bug.cgi?id=742882
This reverts commit 47e339b46e. The
approach that was used to reduce the amount of work we do on RR events
to the necessary minimum is flawed. It assumes that, when the first
event we see where the retrieved XRRScreenResources.timestamp is
bigger than the previous, we already have all the data we need to
rebuild our view of the world.
That isn't true however, because the X server sends
RRScreenChangeNotify events for every step of the configuration
change, i.e. it lacks an atomic reconfiguration API. In particular, if
the X screen size is one of the changes, when we rebuild our state and
emit monitors-changed, the X screen size might still be the previous
one and since we stop updating ourselves until another reconfiguration
happens (noticed by looking at XRRScreenResources.timestamp) we end up
with the wrong idea of the X screen size.
https://bugzilla.gnome.org/show_bug.cgi?id=738630
This optimization breaks our use of XRRScreenResources' timestamps to
detect hotplugs in case one of the outputs is disconnected and the
remaining ones don't need any mode, position or transform adjustments.
In that scenario, when applying the new configuration, we resize the X
screen but never call XRRSetCrtcConfig() and since XRRSetScreenSize()
doesn't take a timestamp and the X server doesn't update its last set
timestamp, when we next get a RRScreenChangeNotify and update
ourselves, XRRScreenResources.timestamp will still be smaller than
XRRScreenResources.configTimestamp which makes us think we're seeing a
new hotplug. We just don't enter an endless loop because the screen
size that we keep applying is always the same and the X server
short-circuits and stops sending us RRScreenChangeNotifys.
Always calling XRRSetCrtcConfig() ensures that the last set timestamp
will be bigger than configTimestamp in the next event and thus making
us trigger the monitors-changed signal properly.
Note that the X server already does basically the same checks that
we're removing here, so doing this shouldn't be a significant
efficiency loss. See
http://cgit.freedesktop.org/xorg/xserver/tree/randr/rrcrtc.c?h=server-1.16-branch#n539
It doesn't make sense to load cursor textures that we might not ever
use. Since the code here also uses CoglTexture2D, and cursors tend
to be NPOT textures, then we won't crash users of cards without
NPOT support. At least until they open the magnifier. :)
Refactor make_default_config() to always sanity-check the configuration to
ensure that it fits within the framebuffer. Previously, this was only done
for the default linear configuration.
In recent versions of the QXL driver, it may set "suggested X|Y" connector
properties. These properties are used to indicate the position at which
multiple displays should be aligned. If all outputs have a suggested position,
the displays are arranged according to these positions, otherwise we fall back
to the default configuration.
At the moment, we trust that the driver has chosen sane values for the
suggested position.
When the output device has hotplug_mode_update (e.g. the qxl driver used in
vms), the displays can be dynamically resized, so the current display
configuration does not often match a stored configuration. When a new
monitor is added, make_default_config() tries to create a new display
configuration by choosing a stored configuration with N-1 monitors, and then
adding a new monitor to the end of the layout. Because the stored config
doesn't match the current outputs, apply_configuration() will routinely
fail, leaving the additional display unconfigured. In this case, it's more
useful to just fall back to creating a new default configuration from
scratch so that all outputs get configured to their preferred mode.
Move logic for creating different types of configurations into separate
functions. This keeps things a bit cleaner and allows us to add alternate
configuration types more easily.
When a laptop's lid is closed we try to build and apply a temporary
configuration that disables the laptop's display if we have other
outputs.
This isn't enough though, we must also check if at least one of these
other outputs is enabled otherwise we'll try to resize the screen to
0x0 which (rightfully) hits an assertion.
https://bugzilla.gnome.org/show_bug.cgi?id=739450
It turns out that this was wrong because MetaWindow->monitor points to
the old monitor infos and they are needed to position windows in the
new configuration which happens in a monitors-changed handler.
This reverts commit e1704acda4.
The code in MetaMonitorConfig was really complex and was trying to do
way too much, using multiple different variables to determine where
things were stored, and trying to do fancy tricks to transfer
ownership.
Add a refcounting system to help simplify this, and clean up the logic.
Simply along the way, this fixes multiple bugs in the monitor config
logic, most notably bug #734889, which was my original goal to fix.
The X server sends several RRScreenChangeNotify events in a burst when
something happens which, currently, causes us to rebuild our view of
the world as many times and notify the upper layers about it which
causes a lot of bogus repeated work like rebuilding background actors.
We can avoid this extra work by looking at the timestamp in the
XRRScreenResources struct which is updated when an X client (including
us!) last changed something and comparing it with the previous
timestamp.
https://bugzilla.gnome.org/show_bug.cgi?id=738630
meta_monitor_config_match_current() only matches the number of outputs
and if the output connector, vendor, product and serial match.
In the X backend, this means that we can't use it to bypass doing any
work because it won't detect cases where we actually want to update
ourselves like e.g. an output being turned off either by us or by
another X client (e.g. xrandr).
In the native backend, unlike the xrandr backend, we only get called
on real hotplug events and thus should always trigger the common
hotplug code to (possibly) apply a new mode so the check is pointless
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=738630
In randr events, configTimestamp can be considered the hotplug time,
i.e. whenever the server notices hardware changes, this value will be
updated.
Having that in mind, we can re-work the logic to make it clearer.
There are no semantic changes.
The code here was a bit messy with the addition of
hotplug_mode_update, and the comments were a bit confusing and
inaccurate. Clean it up and comment it a bit better to make the flow and
intention more clear.
We need to tell clutter's evdev backend about the desktop's key repeat
settings so that our own key bindings event processing and
gnome-shell's chrome widgets get their fake key events for continuous
key press as they expect.
Note that the wayland frontend filters out these events and thus
wayland clients do not see them as specced.
https://bugzilla.gnome.org/show_bug.cgi?id=728055
