1. 06 Jul, 2018 5 commits
  2. 18 Dec, 2017 1 commit
    • Olivier Fourdan's avatar
      xwayland: add _XWAYLAND_MAY_GRAB_KEYBOARD property · 5f132f39
      Olivier Fourdan authored
      Add a new client message "_XWAYLAND_MAY_GRAB_KEYBOARD" that X11 clients
      can use to tell mutter this is a well behaving X11 client so it may
      grant the keyboard grabs when requested.
      
      An X11 client wishing to be granted Xwayland grabs by gnome-shell/mutter
      must send a ClientMessage to the root window with:
      
       - message_type set to "_XWAYLAND_MAY_GRAB_KEYBOARD"
       - window set to the xid of the window on which the grab is to be issued
       - data.l[0] to a non-zero value
      
      Note: Sending this client message when running a plain native X11
      environment would have no effect.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783342
      5f132f39
  3. 25 Jan, 2017 1 commit
  4. 15 Nov, 2016 1 commit
  5. 23 Jul, 2016 1 commit
  6. 10 Mar, 2016 1 commit
  7. 19 Feb, 2016 1 commit
    • Carlos Garnacho's avatar
      core: Refactor startup notification into a separate object · 56beedf9
      Carlos Garnacho authored
      This is kind of in a middle ground at the moment. Even though it
      handles sequences not coming from libsn, they're added nowhere at
      the moment, we'll rely on the app launch context being in the x11
      side at the moment.
      
      Also, even though we do create internal sequence objects, we keep
      exposing SnStartupSequences to make gnome-shell happy, we could
      consider making this object "public" (and the sequence objects with
      it), things stay private at the moment.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=762268
      56beedf9
  8. 15 Oct, 2015 1 commit
  9. 15 May, 2015 1 commit
    • Carlos Garnacho's avatar
      wayland: Add X11/wayland selection interoperation · 4fc1811c
      Carlos Garnacho authored
      This piece of code hooks in both wl_data_device and the relevant X
      selection events, an X11 Window is set up so it can act as the clipboard
      owner when any wayland client owns the selection, reacting to
      SelectionRequest events, and returning the data from the wayland client
      FD to any X11 requestor through X properties.
      
      In the opposite direction, SelectionNotify messages are received,
      which results in the property contents being converted then written
      into the wayland requestor's FD.
      
      This code also takes care of the handling incremental transfers through
      the INCR property type, reading/writing data chunk by chunk.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=738312
      4fc1811c
  10. 18 Jan, 2015 2 commits
  11. 29 Dec, 2014 3 commits
  12. 17 Sep, 2014 4 commits
    • Jasper St. Pierre's avatar
      events: Only process Enter/Leave events when in the normal route · c8cc4344
      Jasper St. Pierre authored
      This prevents issues from happening when processing Enter/Leave events
      while in another kind of grab op like a Wayland popup or resizing a
      window.
      
      This can't ever really happen except outside of a race condition,
      with the X server, since we won't ever pass input events to the
      X server in any of these cases, but it can't hurt to be more correct
      about what the intended operation is.
      c8cc4344
    • Jasper St. Pierre's avatar
      events: Ignore normal FocusIn events on the root window · ae292c85
      Jasper St. Pierre authored
      GTK+ focuses its own windows with RevertToParent, which means that when
      a GTK+ CSD window is destroyed, the X server will set the focus back to
      the root window. The event stream that we is an UnmapNotify followed by
      a FocusOut event. Our own UnmapNotify-handling code unmanages the window
      and forcibly changes the focus to the next default window in the stack.
      
      Since UnmapNotify events don't come with timestamps, we query for one,
      and set the window focus using that.
      
      But there's *still* a FocusOut event in the stack, with an older
      timestamp and serial than our own focusing. We see this, throw it out
      since it's older than the most recent focus, but then our own code that
      notices the root has been focused kicks in and tries to focus the
      default window... using a timestamp older than our most recent focusing.
      
      meta_display_sanity_check_timestamps notices this, and (rightly so)
      puts a warning in our face, telling something is awry.
      
      Only let our workarounds kick in when the event is new enough, otherwise
      our code will get confused over old events.
      
      This stops the:
      
      Window manager warning: last_focus_time (367917173) is greater than comparison timestamp (367917170).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
      
      warning spam when closing a CSD window.
      ae292c85
    • Jasper St. Pierre's avatar
      events: Remove our workarounds for broken libXi versions · 35dd1e64
      Jasper St. Pierre authored
      We now depend on a recent enough libXi that fixes broken locking in
      XIGrabTouchBegin, so we don't need to carry this around anymore.
      35dd1e64
    • Jasper St. Pierre's avatar
      events: Fix a typo preventing the None detection from working properly · be85ead2
      Jasper St. Pierre authored
      XINotifyDetailNone is a value for detail, not for mode.
      be85ead2
  13. 12 Sep, 2014 2 commits
  14. 04 Sep, 2014 1 commit
  15. 14 Aug, 2014 3 commits
  16. 07 Aug, 2014 1 commit
  17. 13 Jul, 2014 1 commit
    • Jasper St. Pierre's avatar
      events: Return early if we close the display · 46361c3e
      Jasper St. Pierre authored
      This is so we won't poke into the MetaDisplay, which is invalid memory,
      and crash. This can sometimes work right now because GSlice might not
      deallocate the object immediately, but it's still not a fun thing to do.
      46361c3e
  18. 11 Jun, 2014 1 commit
  19. 29 May, 2014 2 commits
  20. 19 May, 2014 1 commit
  21. 09 May, 2014 2 commits
  22. 08 May, 2014 4 commits