1. 17 Jun, 2016 8 commits
  2. 15 Jun, 2016 1 commit
  3. 13 Jun, 2016 3 commits
  4. 10 Jun, 2016 2 commits
  5. 08 Jun, 2016 12 commits
  6. 07 Jun, 2016 1 commit
  7. 03 Jun, 2016 4 commits
  8. 02 Jun, 2016 1 commit
  9. 01 Jun, 2016 3 commits
    • Keith Packard's avatar
      dix: Don't update current time in the middle of input event processing · 7c77c42f
      Keith Packard authored
      In patch 137ac094
      , Adam moved an
      expensive call to UpdateCurrentTime out of the main dispatch
      loop. That's a good change as the original fix from Chase was a bit
      expensive. However, it breaks grab processing and so a couple of the
      calls to UpdateCurrenTime need to be removed.
      Input event processing can generate a stream of events; a button press
      that activates a grab will send a press followed by a sequence of
      enter/leave events. All of these should have the same time stamp on
      the wire as they occur at the 'same' time.
      More importantly, the grab time recorded in the device is pulled from
      currentTime after all of the events are delivered, so if currentTime
      doesn't match the time in the device event, then future grab
      modifications will fail as the time marked in the device will be
      'later' than the grab time known to the client (which is defined as
      the timestamp from the activating input event).
      A bit of history here -- it used to be that currentTime was driven
      *entirely* by input events; those timestamps didn't even have to be
      related to the system time in any way. Then we started doing ICCCM
      stuff and people got confused when PropertyNotify events would have
      the same timestamp even when delivered minutes apart because no input
      events were delivered.
      We added code in the server to go update the time, but only if no
      input events were pending (so that the clock "wouldn't" go
      backwards). The only places where this is necessary is in request
      processing which may generate an event with a timestamp, and there
      only at the very top of the request processing code so that the whole
      request would be processed at the 'same time', just like events.
      cc: Chase Douglas <chase.douglas@canonical.com>
      cc: Peter Hutterer <peter.hutterer@who-t.net>
      cc: Adam Jackson <ajax@redhat.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Tested-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      Acked-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Keith Packard's avatar
      os: Initialize NotifyFds earlier in startup · ce654633
      Keith Packard authored
      If the server calls AbortServer during the first-time initialization
      (which can happen if you start the server on an already using
      DISPLAY), then the dbus code will shut down and call the notify fd
      interface. If the notify fd list hasn't been initialized, the server
      will crash.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Keith Packard's avatar
      os: Lock input while messing with input device list · f0756793
      Keith Packard authored
      The list of input devices may be changed by hotplugging while the
      server is active, and those changes may come from either the main
      thread or the input thread. That means the list of input devices needs
      to be protected by a mutex.
      This prevents input drivers from receiving I/O ready callbacks after
      removing a device.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  10. 30 May, 2016 5 commits