1. 01 Mar, 2018 1 commit
  2. 07 Feb, 2018 2 commits
  3. 01 Feb, 2018 1 commit
    • Carlos Garnacho's avatar
      backends/x11: Preserve XI1 XDevice throughout ClutterInputDevice lifetime · c02679f9
      Carlos Garnacho authored
      Opening and closing the device may result into XI2 grabs being cut short,
      resulting into pad buttons being rendered ineffective, and other possible
      misbehaviors. This is an XInput flaw that fell in the gap between XI1 and
      XI2, and has no easy fix. It pays us for mixing both versions, I guess...
      Work this around by keeping the XI1 XDevice attached to the
      ClutterInputDevice, this way it will live long enough that this is not
      a concern.
      Investigation of this bug was mostly carried by Peter Hutterer, I'm just
      the executing hand.
      Closes: #7
  4. 27 Jan, 2018 1 commit
  5. 23 Jan, 2018 1 commit
  6. 21 Jan, 2018 1 commit
  7. 18 Jan, 2018 1 commit
  8. 12 Jan, 2018 2 commits
  9. 09 Jan, 2018 1 commit
    • Daniel van Vugt's avatar
      wayland: Ensure wl_shell_surfaces are set reactive · 294cceae
      Daniel van Vugt authored
      Wayland clients using the wl_shell interface were never receiving mouse
      input. It meant they also couldn't be raised with a click.
      This was because the call to meta_wayland_surface_set_window for wl_shell
      surfaces did nothing while surface->window == window already. As such, it
      never called clutter_actor_set_reactive() and the wl_shell window remained
      a non-reactive actor.
      Just make sure surface->window isn't already set before calling
      meta_wayland_surface_set_window so it can actually do what it's meant to.
  10. 31 Dec, 2017 1 commit
  11. 22 Dec, 2017 1 commit
  12. 21 Dec, 2017 1 commit
  13. 20 Dec, 2017 2 commits
    • Marco Trevisan's avatar
      stage: Push framebuffer before setting up viewport · 7ef3ed0f
      Marco Trevisan authored
      When capture_view* functions are called with the paint flag set
      to TRUE, we need to setup the framebuffer, however this was
      happening after setting up the viewport, while the viewport
      needs the framebuffer to be valid when calling cogl_set_viewport.
    • Jonas Ådahl's avatar
      keybindings: Only add multiple keycodes from the same level · 827d0b3f
      Jonas Ådahl authored
      The reason why multiple keycodes could be mapped to a single keysym was
      to support having both KEY_FAVORITES and KEY_BOOKMARK map to
      XF86Favorites. However, iterating through all layout levels adding all
      key codes has severe consequences on layouts with levels that map
      things like numbers and arrow. The result is that keybindings that
      should only have been added for keycodes from the first level, are
      replaced by some unexpected keycode where the same keysym was found on
      another level.
      An example of this is the up-arrow key and l symbol. Normally you'd find
      both the up-arrow symbol and the l symbol on the first level and be done
      with it. However, on the German Neo-2 layout, layout level 4 maps the
      KEY_E to the l symbol, while layout level 4 maps KEY_E to up-arrow.
      Which ever gets to take priority is arbitrary, but for this particular
      case KEY_E incorrectly mapped to up-arrow instead of the l symbol,
      causing the keyboard shortcut Super+l, which would normally lock the
      screen, to trigger the workspace-up (Super+up-arrow) key binding.
  14. 15 Dec, 2017 1 commit
  15. 14 Dec, 2017 1 commit
  16. 11 Dec, 2017 1 commit
  17. 01 Dec, 2017 1 commit
  18. 30 Nov, 2017 2 commits
    • Jonas Ådahl's avatar
      monitor-manager: Compare keys when checking whether a config is complete · 205dc28e
      Jonas Ådahl authored
      We only counted configured monitors and whether the config was
      applicable (could be assigned), howeverwe didn't include disabled
      monitors when comparing. This could caused incorrect configurations to
      be applied when trying to use the previous configuration.
      One scenario where this happened was one a system with one laptop
      screen and one external monitor that was hot plugged some point after
      start up. When the laptop lid was closed, the 'previous configuration'
      being the configuration where only the laptop panel was enabled, passed
      'is-complete' check as the number of configured monitors were correct,
      and the configuration was applicable.
      Avoid this issue by simply comparing the configuration key of the
      previous configuration and the configuration key of the current state.
      This correctly identifies a laptop panel with the lid closed as
      inaccessible, thus doesn't incorrectly revert to the previous
    • Jonas Ådahl's avatar
      monitor-config-manager: Don't include closed laptop panel in config key · ea538537
      Jonas Ådahl authored
      When deriving the list of disabled monitors when creating new monitors
      configs, don't include the laptop panel if the lid is currently closed,
      as we consider the laptop panel nonexistent when the laptop lid is
      closed when it comes to configuration.
      The laptop panel connector(s) will either way be appropriately disabled
      anyway, as the field listing disabled monitors in the configuration do
      not affect actual CRTC/connector assignments.
  19. 29 Nov, 2017 1 commit
  20. 26 Nov, 2017 1 commit
  21. 25 Nov, 2017 1 commit
  22. 22 Nov, 2017 1 commit
  23. 17 Nov, 2017 4 commits
  24. 15 Nov, 2017 2 commits
  25. 14 Nov, 2017 1 commit
  26. 13 Nov, 2017 1 commit
  27. 11 Nov, 2017 2 commits
  28. 10 Nov, 2017 4 commits