mutter:wip/kms-connector-add-remove

Last commit made on 2019-09-03
Get this branch:
git clone -b wip/kms-connector-add-remove https://git.launchpad.net/mutter

Branch merges

Branch information

Name:
wip/kms-connector-add-remove
Repository:
lp:mutter

Recent commits

9582f7b... by Jonas Ådahl

monitor-manager/kms: Get hotplug events from MetaKms

This makes it clearer that MetaMonitorManagerKms keeps updated as
MetaKms updates its state.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/743

5fa38f4... by Jonas Ådahl

kms/impl-device: Add and remove connectors on hot plug

Connectors may disappear and appear on hot plugs, e.g. when a docking
station is connected, so when processing a hot plug event, make sure we
remove connectors that are now gone, and add new ones that has appeared
since last time.

Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/728

https://gitlab.gnome.org/GNOME/mutter/merge_requests/743

0ae31a4... by Jonas Ådahl

kms: Add assert to check that the main thread is blocked on impl task

This is so that we can have code in impl tasks that pokes at the main
context objects.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/743

14c706e... by Daniel van Vugt

clutter: Introduce geometric picking

Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.

However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.

Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.

The picking routines are still tied to painting.

When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.

CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:

  | | Intel | Nvidia |
  | ------: | --------: | -----: |
  | Moving the mouse: |
  | Before | 10% | 10% |
  | After | 6% | 6% |
  | Moving a window: |
  | Before | 23% | 81% |
  | After | 19% | 40% |

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
        https://gitlab.gnome.org/GNOME/mutter/issues/691

Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
                          https://gitlab.gnome.org/GNOME/mutter/issues/590,
                          https://gitlab.gnome.org/GNOME/mutter/issues/700

v2: Fix code style issues
    Simplify quadrilateral checks
    Remove the 0.5f hack
    Differentiate axis-aligned rectangles

https://gitlab.gnome.org/GNOME/mutter/merge_requests/189

a70823d... by Daniel van Vugt

clutter/point: Add ClutterPoint quarilateral testing API

Add a function to check whether a point is inside a quadrilateral
by checking the cross product of vectors with the quadrilateral
points, and the point being checked.

If the passed quadrilateral is zero-sized, no point is ever reported
to be inside it.

This will be used by the next commit when comparing the transformed
actor vertices.

[feaneron: add a commit message and remove unecessary code]

https://gitlab.gnome.org/GNOME/mutter/merge_requests/189

fdda8ad... by =?utf-8?q?R=C3=A9mi_Bernon?= <email address hidden>

x11: Add window test before accessing reparents_pending field

https://gitlab.gnome.org/GNOME/mutter/merge_requests/768

8f242f8... by =?utf-8?q?R=C3=A9mi_Bernon?= <email address hidden>

core: Fix multiple reparent requests handling

If window decoration is modified within a short period of time, mutter
sometimes starts processing the second request before the first
UnmapNotify event has been received. In this situation, it considers
that the window is not mapped and does not expect another UnmapNotify /
MapNotify event sequence to happen.

This adds a separate counter to keep track of the pending reparents. The
input focus is then restored when MapNotify event is received iff all
the expected pending ReparentNotify events have been received.

Signed-off-by: Rémi Bernon <email address hidden>

https://gitlab.gnome.org/GNOME/mutter/merge_requests/657

36a14e6... by Mart Raudsepp <email address hidden>

build: Raise libXi minimum dependency for required deadlock fixes

Older than 1.7.4 have deadlock bugs, see
https://bugzilla.gnome.org/show_bug.cgi?id=738944

6ed5d2e... by Daniel van Vugt

cogl: Remove GLX "threaded swap wait" used on Nvidia

Threaded swap wait was added for using together with the Nvidia GLX
driver due to the lack of anything equivalent to the INTEL_swap_event
GLX extension. The purpose was to avoid inhibiting the invocation of
idle callbacks when constantly rendering, as the combination of
throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
source having higher priority than the default idle callback sources
meant they would never be invoked.

This was solved in gbz#779039 by introducing a thread that took care of
the vsync waiting, pushing frame completion events to the main thread
meaning the main thread could go idle while waiting to draw the next
frame instead of blocking on glxSwapBuffers().

As of https://gitlab.gnome.org/GNOME/mutter/merge_requests/363, the
main thread will instead use prediction to estimate when the next frame
should be drawn. A side effect of this is that even without
INTEL_swap_event, we would not block as much, or at all, on
glxSwapBuffers(), as at the time it is called, we have likely already
hit the vblank, or will hit it soon.

After having introduced the swap waiting thread, it was observed that
the Nvidia driver used a considerable amount of CPU waiting for the
vblank, effectively wasting CPU time. The need to call glFinish() was
also problematic as it would wait for the frame to finish, before
continuing. Due to this, remove the threaded swap wait, and rely only on
the frame clock not scheduling frames too early.

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
Related: https://gitlab.gnome.org/GNOME/mutter/issues/700

[jadahl: Rewrote commit message]

https://gitlab.gnome.org/GNOME/mutter/merge_requests/602

d4eb222... by Jonas Ådahl

later: Add tracing

https://gitlab.gnome.org/GNOME/mutter/merge_requests/757