| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By the looks of it, commit 95e9fa10ef was taping over an Intel DRI bug
that would make it return post-swizzling pixel data on glReadPixels().
There's been reports over time of that commit resulting in wrong colors
on other drivers, and lately Mesa >17.3 started showing the same symptoms
on Intel.
But texture swizzling works by changing parameters before fragment shaders
and reading pixels from an already drawn FBO/texture doesn't involve those.
This should thus use pixel_format_to_gl_with_target(), which will result in
correctly requesting the same pixel format than the underlying texture,
while still considering it BGRA for the upper layers in the swizzling case.
https://gitlab.gnome.org/GNOME/mutter/issues/72
Closes: #72
|
| | |
|
| | |
|
| |
|
|
| |
As "suggested" by gcc and -Werror. Introduced by commit cb40049ec.
|
| |
|
|
|
|
|
|
|
|
| |
This state tracks hardware devices' state, thus shouldn't be triggered by
events that were emulated/forwarded by the IM. Those may include modifiers
and would result in xkb_state being doubly set, and possibly stuck.
https://gitlab.gnome.org/GNOME/mutter/issues/74
Closes: #74
|
| |
|
|
|
|
|
|
|
|
| |
Actor keybindings were dispatched in an earlier return path, which means
the IM doesn't get to see certain key events. Flip the order around so the
IM has an opportunity to handle all keypresses.
https://gitlab.gnome.org/GNOME/mutter/issues/65
Closes: #65
|
| | |
|
| |
|
|
| |
Update NEWS.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Commit d714a94d9 added support for stable xdg-shell surfaces while
preserving old unstable zxdg-shell v6 ones, but committed a mistake
in checking for both in the xdg_exporter.export error condition
paths. We want to check that the surface is neither of both.
https://gitlab.gnome.org/GNOME/mutter/issues/63
Closes: #63
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Raising and lowering windows in tandem without a proper grouping
mechanism ended up being more annoying than functional.
This reverts commit e76a0f564c1e07e32fe857d0f8e5b723c3bbe57d.
|
| | |
|
| | |
|
| |
|
|
| |
Update NEWS.
|
| |
|
|
|
|
|
|
|
| |
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
|
| |
|
|
|
|
| |
If there was no matching config, fail to find the first one.
https://gitlab.gnome.org/GNOME/mutter/issues/2
|
| |
|
|
|
|
| |
It just picked the first config, so name it accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/2
|
| |
|
|
|
|
|
|
| |
So we can trigger actions for the right mode.
https://gitlab.gnome.org/GNOME/mutter/issues/48
Closes: #48
|
| |
|
|
|
|
|
|
|
| |
Use libwacom to be able to find out modes, groups and button roles on
pad devices.
https://gitlab.gnome.org/GNOME/mutter/issues/48
Closes: #48
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When painting the titlebar, button icons that aren't available in the
desired size need to be scaled. However the current code inverses the
scale factor, with the result that the adjusted icons are much worse
than the original icons, whoops.
This went unnoticed for a long time given that most icons are availa-
ble in the desired 16x16 size, and the most likely exceptions - window
icons - are not shown by default.
https://gitlab.gnome.org/GNOME/mutter/issues/23
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(cherry picked from commit 543d031a55164e8f4cd5bb0e906fbef4cca0cf90)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Instead of bailing out when a seemingly random file is missing, require
the version of wayland-protocols that includes the source to create that
built file.
Introduced in d714a94
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In order to let applications gracefully handle version mismatches, add
a version property to the APIs. Also add a warning on the APIs that
these are not meant for public consumption.
|
| |
|
|
|
| |
This is so that application will not try to send touch events when
touch is not supported.
|
| | |
|
| |
|
|
|
|
| |
If the coordinates was for a stream not at the stage position (0, 0),
they'd be incorrect. Fix this by correctly translating the coordinates
according to the stream position.
|
| |
|
|
| |
Will be used to translate stream local coordinates to stage coordinates.
|
| |
|
|
|
| |
Will be needed by the remote desktop session to translate stream local
input coordinates.
|
| |
|
|
| |
Relative pointer motions are assumed to be pre-accelerated.
|
| | |
|
| |
|
|
|
| |
Keyboard keycode events will act as a physical keyboard thus depend on
the active keyboard layout.
|
| |
|
|
| |
Just call the corresponding clutter API once for each step.
|
| |
|
|
|
| |
The check was inverted; allowed axis are 0 and 1, not the other way
around.
|
| |
|
|
|
| |
This is needed so that mutter can let applications using the remote
desktop API to know whether touch screens are supported.
|
| |
|
|
|
| |
As the other virtual input event delivery mechanisms, this also uses
the XTEST protocol.
|
| |
|
|
|
| |
So far only implemented on the evdev backend,as X11 doesn't support touch
devices nor smooth scrolling via XTEST.
|
| |
|
|
|
|
| |
IF two touch devices have colliding touch point IDs they'd interfere on
the seat. To avoid this, always allocate a seat wide slot for each
device wide slot, but don't use device slots directly in the seat.
|
