Skip to content
  1. Mar 01, 2018
  2. Feb 07, 2018
  3. Feb 01, 2018
    • 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.
      
      #7
      
      Closes: #7
      c02679f9
  4. Jan 27, 2018
  5. Jan 23, 2018
  6. Jan 21, 2018
  7. Jan 18, 2018
  8. Jan 12, 2018
  9. Jan 09, 2018
    • Daniel van Vugt's avatar
      wayland: Ensure wl_shell_surfaces are set reactive · 294cceae
      Daniel van Vugt authored and Marco Trevisan's avatar Marco Trevisan committed
      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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=790309
      294cceae
  10. Dec 31, 2017
  11. Dec 22, 2017
  12. Dec 21, 2017
  13. Dec 20, 2017
    • 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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=791809
      7ef3ed0f
    • 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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=789300
      827d0b3f
  14. Dec 15, 2017
  15. Dec 14, 2017
  16. Dec 11, 2017
  17. Dec 01, 2017
  18. Nov 30, 2017
    • 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
      configuration.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=788915
      205dc28e
    • 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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=788915
      ea538537
  19. Nov 29, 2017
  20. Nov 26, 2017
  21. Nov 25, 2017
  22. Nov 22, 2017
  23. Nov 17, 2017
  24. Nov 15, 2017
  25. Nov 14, 2017
  26. Nov 13, 2017
  27. Nov 11, 2017
  28. Nov 10, 2017