1. 15 Feb, 2021 10 commits
    • Olivier Certner's avatar
      os: Lock file: No link phase, never unlink foreign lock, hardening of abnormal situations · 81bc7da3
      Olivier Certner authored
      
      
      Calling unlink(2) on a file we do not own is fundamentally racy on UNIX
      systems, so remove such calls, renouncing to break stale locks from inside, and
      just give the best possible reporting to the user.
      
      Simplify the code by replacing the two-phase procedure, with creation of a
      temporary lock file and then the use of link(2) to put it in place, with direct
      exclusive creation of the lock file (more details below).
      
      Also, limit retries to 3 on the whole, instead of 3+3, with only 1s between
      each retry instead of 2, limiting the whole process length to ~3s. Retries are
      now here only for waiting for a potential existing server to shut down and to
      possibly give better reporting of what's going on to the user.
      
      ***
      
      First creating a temporary file with open(2) with flags O_CREAT | O_EXCL and
      then moving it atomically in place with link(2) has only a single advantage: To
      ensure that any lock file that is in place has the right content (here,
      length). This allows to detect more types of stale lock files (i.e., ones that
      don't have the expected length). However, the only use of such an information
      was to unlink(2) such a file, and unlink(2) is inherently racy (in bad
      circumstances, it can destroy a legitimate lock file established by another
      server). Once unlink(2) calls on foreign locks are removed, this advantage is
      no more, and the code can be simplified by removing the link(2) phase
      altogether.
      Signed-off-by: default avatarOlivier Certner <olce.freedesktop@certner.fr>
      81bc7da3
    • Olivier Certner's avatar
      os: Properly report failure to link lock file · 3627d3ed
      Olivier Certner authored
      
      
      Stop assuming that a failure to link always means that the file indeed
      exists. In case of other failure (e.g., permissions), the user would get an
      inconsistent "Can't read lock file" message.
      Signed-off-by: default avatarOlivier Certner <olce.freedesktop@certner.fr>
      3627d3ed
    • Olivier Fourdan's avatar
      xwayland: Use relative device for buttons/axis · a4095162
      Olivier Fourdan authored
      
      
      We are using the relative pointer for motion events, but buttons and
      axis events still go through the absolute pointer device.
      
      That means additional DeviceChanged events that could be avoided if the
      buttons and axis events were coming from the same device as motion
      events.
      
      Route those events to the relative pointer if available so that motion,
      buttons and axis events come from the same device (most of the time).
      Suggested-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Related: xorg/xserver#1130
      a4095162
    • Olivier Fourdan's avatar
      xwayland: Add wheel axis to relative pointer · 1abab61d
      Olivier Fourdan authored
      
      
      The relative pointer only has 2 axis, if we want to route the mouse
      wheel events to that device, we need to add the axis definition, similar
      to what is done for the absolute pointer.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Related: xorg/xserver#1130
      1abab61d
    • Olivier Fourdan's avatar
      xwayland: Split dispatch_pointer_motion_event · 71817928
      Olivier Fourdan authored
      
      
      This is a cleanup patch, no functional change.
      
      Split the function dispatch_pointer_motion_event() into three separate
      simpler functions, relative motion with a warp emulator, relative motion
      and absolute motion.
      
      This makes the code a lot easier to read for me, rather than having
      everything in a single function with nested if/else conditions.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      71817928
    • Olivier Fourdan's avatar
      xwayland: Use relative values for raw events · c5c5322a
      Olivier Fourdan authored
      
      
      Xwayland supports relative motion events from the Wayland compositor via
      the relative-pointer protocol, and converts those to the absolute range
      in device units for raw events.
      
      Some X11 clients however wrongly assume relative values in the axis
      values even for devices explicitly labeled as absolute. While this is a
      bug in the client, such applications would work fine in plain Xorg but
      not with Xwayland.
      
      To avoid that issue, use the relative values for raw events without
      conversion, so that such application continue to work in Xwayland.
      
      Thanks Peter for figuring out the root cause.
      
      v2: Don't duplicate relative and absolute events (Peter)
      v3: Use POINTER_RAWONLY (Peter)
      Suggested-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Closes: xorg/xserver#1130
      c5c5322a
    • Olivier Fourdan's avatar
      xwayland: Use a resolution of 0 for relative motion · ebdb2e26
      Olivier Fourdan authored
      
      
      That's what evdev/libinput drivers do.
      Suggested-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Related: #1130
      ebdb2e26
    • Olivier Fourdan's avatar
      dix: Add POINTER_RAWONLY flag · b5e1f136
      Olivier Fourdan authored
      
      
      This add a new flag POINTER_RAWONLY for GetPointerEvents() which does
      pretty much the opposite of POINTER_NORAW.
      
      Basically, this tells GetPointerEvents() that we only want the
      DeviceChanged events and any raw events for this motion but no actual
      motion events.
      
      This is preliminary work for Xwayland to be able to use relative motion
      events for raw events. Xwayland would use absolute events for raw
      events, but some X11 clients (wrongly) assume raw events to be always
      relative.
      
      To allow such clients to work with Xwayland, it needs to switch to
      relative raw events (if those are available from the Wayland
      compositor).
      
      However, Xwayland cannot use relative motion events for actual pointer
      location because that would cause a drift over time, the pointer being
      actually controlled by the Wayland compositor.
      
      So Xwayland needs to be able to send only relative raw events, hence
      this API.
      
      Bump the ABI_XINPUT_VERSION minor version to reflect that API addition.
      
      v2: Actually avoid sending motion events (Peter)
      v3: Keep sending raw emulated events with RAWONLY (Peter)
      Suggested-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Related: xorg/xserver#1130
      b5e1f136
    • Povilas Kanapickas's avatar
      Xi: Deliver pointer emulated touch events to grabbing client · 21312901
      Povilas Kanapickas authored and Peter Hutterer's avatar Peter Hutterer committed
      Delivery of emulated events usually happens only to the owning client.
      If there are grabs, only the grabbing client may receive these events.
      
      This logic does not work during the touch event replay in
      DeactivatePointerGrab(), as the previous grab is no longer in the
      listener queue of the touch, so the next owner gets whole emulated event
      sequence. This may trigger implicit grabs. After replay,
      DeactivatePointerGrab() will update the global grab without regard to
      this new implicit grab, which leads to issues down the line.
      
      This change is effectively the same as 35e5a76c except that the change
      is limited to only emulated pointer events. Otherwise, in the case of a
      device grab we end up not sending any touch events to clients that
      selected XI_TouchOwnership event and should get touch events before they
      get ownership of touch sequence.
      
      Fixes #7
      
      https://bugs.freedesktop.org/show_bug.cgi?id=96536
      21312901
    • Povilas Kanapickas's avatar
      Revert "Xi: Use current device active grab to deliver touch events if any" · 30e11535
      Povilas Kanapickas authored and Peter Hutterer's avatar Peter Hutterer committed
      This reverts commit 98e3db2a.
      30e11535
  2. 08 Feb, 2021 1 commit
    • Povilas Kanapickas's avatar
      dix: Send touch end to clients that do async grab without touch events · f682e056
      Povilas Kanapickas authored
      If a XI2 client started listening to touches due to a selection and then
      creates an active async grab that does not include touch events, then it
      currently won't get the touch end event which will produce inconsistent
      view of the pending touches.
      
      Note that we only need to consider touch listeners and can ignore
      pointer emulation. Under XI2 if a active grab replaces a passive
      implicit grab and the active grab does not include the button release
      event, the client won't get it either.
      f682e056
  3. 02 Feb, 2021 14 commits
  4. 29 Jan, 2021 4 commits
  5. 27 Jan, 2021 1 commit
    • Julien Cristau's avatar
      compiler.h: don't define inb/outb and friends on mips · 0148a15d
      Julien Cristau authored and Adam Jackson's avatar Adam Jackson committed
      The definition relies on IOPortBase, which is only ever set in
      hw/xfree86/os-support/bsd/arm_video.c
      
      This caused build failures on linux/mips with GCC 10, due to this
      change (from https://gcc.gnu.org/gcc-10/changes.html#c):
      
      "GCC now defaults to -fno-common. As a result, global variable accesses
      are more efficient on various targets. In C, global variables with
      multiple tentative definitions now result in linker errors. With
      -fcommon such definitions are silently merged during linking."
      
      As a result anything including compiler.h would get its own definition
      of IOPortBase and the linker would error out.
      0148a15d
  6. 22 Jan, 2021 3 commits
  7. 08 Jan, 2021 1 commit
  8. 06 Jan, 2021 1 commit
  9. 05 Jan, 2021 1 commit
    • Povilas Kanapickas's avatar
      xi: Don't deliver emulated motion when there's no owner for touch end · 3ab3083c
      Povilas Kanapickas authored and Peter Hutterer's avatar Peter Hutterer committed
      Pointer-emulated touch events should only be delivered to the client
      that owns the sequence even if it's a core client that became the
      effective owner of the sequency by selecting for pointer press and
      movement.
      
      Currently the emulated events are delivered like this already (see
      TouchResourceIsOwner() check in DeliverEmulatedMotionEvent()), except in
      the case of TouchEnd, in which case the generated motion event is still
      delivered to some client that's not necessarily the owner of the touch
      sequence.
      
      We already know whether a touch sequence that is about to emulate a
      pointer event has an owner, we just need to check that. This further
      allows to simplify DeliverEmulatedMotionEvent() as it won't ever be
      called for non-owned touch events.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=60394
      
      Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
      3ab3083c
  10. 18 Dec, 2020 2 commits
  11. 17 Dec, 2020 2 commits