Before commit ac448bd42b the pointer,
keyboard, and touch objects were initialized when the seat was created.
Now they're initialized later, when the clutter device manager finds and
loads them.
This commit makes sure we don't try to access those objects if they
aren't initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=744640
The wayland seat event handlers get sent events that
aren't strictly interesting to them (such as events for
hardware devices the seat doesn't support and events for
virtual devices that the seat needs to ignore).
This commit makes sure all uninteresting events get ignored.
Kerbel Space Program, and perhaps some other SDL-based programs, use
a really dumb way of specifying icons, which is totally
non-standards-compliant.
The ICCCM specifies that the icon_pixmap field of WM_HINTS should be a
1-bit-deep Pixmap, but we've seen applications set it to a pixmap of the
root depth as well, so we support that.
Kerbel Space Program seems to use it with a 32-bit depth Pixmap,
signifying ARGB32 (which it is), along with a 1-bit icon_mask, which
crashes us.
Keep in mind that Pixmaps, by definition, have no Visual attached, so
we simply have to make a guess at the correct visual based on the
depth. Do that by assuming that a depth-32 visual always means ARGB32,
which is a pretty safe bet.
If a client creates an xdg_popup given a parent that is a xdg_popup that
is not the most top one in the grab chain, send the
not_the_topmost_popup error.
Also fail a client who destroys a popup that is not the top most one.
https://bugzilla.gnome.org/show_bug.cgi?id=744452
We'll want to expose popup logic outside of meta-wayland-pointer.c and
one day we'll also probably want to add touch support for popups, so
lets move it to its own file. There are no significant semantical
changes, only refactoring.
https://bugzilla.gnome.org/show_bug.cgi?id=744452
The current ordering updates the clip shape of the composite overlay
window after unredirecting the target window. This has the effect of
forcing X to clear the target window and sending an expose to the
application to repaint - causing an unsightly flash. If we update the
shape first, then unredirect, X restores the background of the root
window (sending no expose events as no one is interested) and the
background is typically NONE for the root window. Then the unredirect
paints the contents of the composite backing pixmap over top without
requiring a round trip and waiting for the client to repaint - thus no
flashing.
Fixes regression from
commit d6282716b2
Author: Jasper St. Pierre <jstpierre@mecheye.net>
Date: Fri Dec 6 17:10:44 2013 -0500
compositor: Simplify the unredirected window management code
Cc: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=743858
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
We're locked to frame sync anyway, so it doesn't make sense to try to
redraw early. In casual testing, this seems to actually make things
faster, as well.
The commit 97a69cee5a broke the caching of
the surface state when because the frame_callback_list target state was
overwritten after the content had been moved to it.
This commit fixes it by moving the frame list addition after the copy. We
also need to initialize the list since the plain copy put garbage in it.
https://bugzilla.gnome.org/show_bug.cgi?id=743678
When looking for space to place a new window, other non-minimized
windows on the same workspace should be taken into account. However
the current check does not work correctly when the placed window is
located on all workspaces, so handle that case explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=743217
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
MetaKeyCombo is about the *unresolved* keybinding, which can either be a
"keysym" (<Ctrl>F) or a "keycode" (<Ctrl>0x21). When we resolved the
keysym to a keycode, we stuffed it back in the same MetaKeyCombo, which
confused about what the "keycode" field was for. Thus, we often stomped
on the user's explicit choice if they chose a keycode binding value.
To solve this, create a separate structure, the "devirtualized key combo"
or MetaKeyDevirtCombo, which contains a resolved keycode from the
keysym, and a devirtualized modifier mask. The MetaKeyCombo is now
always a "source" value, and the MetaKeyDevirtCombo is now always what
the user chose.
This also lets us significantly clean up the overlay and ISO key binding
paths.
The reason MetaKeyCombo has a keycode value at all is *not* to store the
devirtualized keycode from the keysym, but instead to allow people that
type in "0x55" into the preference. Everything except the overlay-key
respected this. Make the overlay-key binding respect this.
Break down the beautiful core/ui abstraction barrier by inserting
a pointer to MetaWindow into a MetaUIFrame. I'm a scoundrel, I know.
We'll use this very soon to destroy meta_core_get.
Whenever we added a frame to the GHashTable, we added the frame itself
as the value, and a pointer to its storage of the frame window XID,
as the key.
When we iterated over the hash table, we actually looked up the
MetaUIFrame in the key, which might seem extraordinarily wrong, but
eagle-eyed viewers might notice that the XID is the first field in
MetaUIFrame, so the key and value are actually the same pointer.
Changing the layout of MetaUIFrame at all causes this to go haywire,
so let's not do this and simply put the MetaUIFrame in the value,
as expected.
When the frame type updates, we were doing something funky that
caused us to reset the title used for the text layout here. I can't
really think of any place that it would trigger, and in testing I
haven't hit this either, so let's just remove the fancy logic and
assert this.
With support for the old metacity theme format gone, there's no
reason to keep storing theme information in terms of the old theme
properties. Just store the padding/border information for each
element directly.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
MetaFrameStyle now only holds a MetaFrameLayout, so we can cut out
the middle man and use the layout directly. And as we are already
using a single style/layout per frame set and handle frame state
and focus by setting appropriate style flags, MetaFrameStyleSet
is pointless too - just store one MetaFrameLayout per frame type
directly in the theme.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Rest in peace you magnificent format, love-child of arcane X11 drawing
API and markup craze, you will not be missed.
We do remember however the bravery of a many men and women, who fearlessly
descended into the guts of your intrinsics and turned ugliness into beauty;
their work will still be spoken of when you will long have been forgotten.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
All geometry/drawing information is now picked up from the GTK+ theme,
so replace the remaining bits (hide_buttons + title_scale) with
hardcoded values from the default Adwaita theme and stop loading
the metacity theme altogether.
If there is a need to theme those constants again in the future,
we should make them available from GTK+ where they are available
for client-side decorations as well. They certainly don't justify
maintaining support for a complex theme format.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Few themes ever had support for those in the first place, and even
less supported them properly; in particular support in the default
theme has been broken for a while now.
With this in mind (and considering that not even the tweak tool exposes
any UI to configure them), let's (try to) remove support altogether - the
corresponding rects are still kept around, so it's easy to add back in
case we reconsider (and get the necessary artwork).
https://bugzilla.gnome.org/show_bug.cgi?id=741917
GTK+ doesn't deal with different frame types for its client-side
decorations - it just treats dialogs the same as normal windows
and ignores the odder frame types like UTILITY and MENU. That's
fine as those have largely gone out of fashion anyway, but it's a
different case for the WM - we still have to support them somehow.
For now, just apply the existing title_scale factor to the geometry
information picked up from the theme in addition to the title font.
If it turns out that there's demand for something more sophisticated,
we can still consider adding wm-only style information to the GTK+
theme.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
The frame shape is relevant in three places:
- the window decoration we draw
- the frame mask (used for the shape region)
- the frame bounds (used for clipping)
All three should match, so make sure to use the same GTK+ method for
the first two, and bring the (non-antialiased) third closer to the
other two by removing an obscure modifier from the corner radius.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
We now have everything in place to pick up geometry and drawing
information from GTK+ rather than the metacity theme, so do just
that; the metacity theme is now only used for some constants
(title_scale, hide_buttons, ...), which we will replace soon.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
We want to eventually pick up all theme information from GTK+ instead
of our own theme format; to prepare for this, add another helper method
to fill in geometry information from the GTK+ theme.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
GTK+ expresses the window state as style classes and widget state for
client-side decorations. Add a helper method to translate our own frame
state to the corresponding changes to the style context hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Sounds obvious, doesn't it?
After this change when titlebar-uses-system-font is set, the "system
font" used will not be a generic one, but match what GTK+ uses in
client-side decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
In order to pick up all theme information from GTK+, a single style
context is not enough; a style hierarchy that closely matches the widget
hierarchy by GTK+'s client-side decorations will allow this soon.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Our current use of style contexts is fairly limited - we don't
use them for much more than picking up some color information.
We will soon start to make more elaborate use of GTK style
information, but a single context will no longer be enough
to draw a frame then.
To prepare for this, add a simple ref-counted type to wrap
style information.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Rather than defining the space to the left and right of buttons, add a
simple spacing property that defines the space between buttons, which is
what GTK+ does for client-side decorations (e.g. GtkButtons in a GtkBox).
Unfortunately the value is hardcoded in GTK+; if it is exposed in the
theme in the future, we should pick it up from there, but for now we
just use the same value as GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Basically it's odd to have "button_rect" be a function with all the
foo_rect GdkRectangles around - renaming to get_button_rect() will
free the name for the generically named "rect" once buttons are the
only movable pieces in the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
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
If the app finished multiple frames before we sent _NET_WM_FRAME_DRAWN,
we could add the send_frame_messages_timer multiple times. In the rare
case that the app immediately closed the window, the older timeout
could potentially then run on the freed actor.
https://bugzilla.gnome.org/show_bug.cgi?id=738686
* Use -1 rather than 0 as a flag for pending queue entries; 0 is
a valid frame_counter value from Cogl.
* Consistently handle the fact we can have more than one pending
entry. It's app misbehavior to submit a new frame before
_NET_WM_FRAME_DRAWN is received; but we accept such frame messages,
so we can't just leak them.
* If we remove send_frame_message_timer, assign the current frame counter
to pending entries.
* To try to avoid regressing on this, when sending _NET_WM_FRAME_TIMINGS
messages, if we have stale messages, or messages with no frame drawn
time, warn and remove them from the queue rather than just accumulating.
* Improve commenting.
https://bugzilla.gnome.org/show_bug.cgi?id=738686
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. :)
Whenever the compositor takes a grab, we're supposed send leave/enter
events to the current surface, which makes sense, as the compositor
has stolen the pointer from the client.
I forget why I added the special case in the first place, but it's
likely a bug that's since been fixed.
This actually fixes a bug: it prevents the need to double-click on
X11 application titlebars when grabbing them.
Windows that set empty input shapes get n_rects of 0 when querying them
later, which makes sense, but the code that interpreted the result
translated it into a NULL input shape, which meant it was the same as
the bounding region. As such, an empty input shape would actually get
interpreted as a full input shape!
We, ourselves, set an empty input shape on tray icon windows in
gnome-shell since we would handle the picking ourselves. This meant that
we'd actually get the MetaSurfaceActorX11 when hovering over the tray
icon, instead of the ShellGTKEmbed that we capture events on and react
to.
This fixes weird tray icon behavior in gnome-shell.
The parent pick() implementation in ClutterActor only recurses if the
vfunc is untouched, which means it's up to the MetaWaylandSurface
implementation to actually recurse, just the same as if an input mask
applied.
https://bugzilla.gnome.org/show_bug.cgi?id=738890
This reverts commit ec8ed1dbb0.
1) It turns out to add a momentary flicker from the transition
between the login screen and user session
2) It actually isn't needed anymore since bug 733026
https://bugzilla.gnome.org/show_bug.cgi?id=740377
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.
WindowActors can outlive their corresponding window to animate unmap.
Unredirecting the actor does not make sense in that case, so make
sure to not request it.
https://bugzilla.gnome.org/show_bug.cgi?id=740133
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
The input region currently only gets scaled by the surface
scale while ignoring the output scale, which causes input events to not get
delivered correctly for clients on hidpi screens. So take the output scale
into account when doing so.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
This commit is wrong, it assumes that the scale only applies to the one
set by the client but its not. meta_surface_actor_wayland_scale_texture
also handles the output scale. Revert the commit to fix hidpi for wayland
clients like weston-terminal.
This reverts commit 0364ea9140.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
Since GTK+ commit 3a337156d11a86c7, save()/restore() may only be
used for subelements; in this particular case, the change broke
the backdrop state in decorations. Luckily we don't actually need
the save()/restore() pair anyway, as we only touch the context's
state and always set it explicitly.
The set/unset branches of meta_display_update_pointer_emulating_sequence()
have been split and put directly where it makes sense. The pointer emulated
sequence will be updated before processing the CLUTTER_TOUCH_BEGIN, and
after processing the CLUTTER_TOUCH_END, this way the checks on this hold
true during all the sequence lifetime.
https://bugzilla.gnome.org/show_bug.cgi?id=738411
If the actor surface has an input mask, custom picking is implemented
for the portions affected by the mask, although the child actors (most
usually subsurfaces) are left out.
https://bugzilla.gnome.org/show_bug.cgi?id=738890
Returning FALSE here gets the button release event propagated to the
client on wayland, which is unexpected after xdg_surface.move/resize()
have been called.
https://bugzilla.gnome.org/show_bug.cgi?id=738888
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.
