1. 10 Aug, 2019 1 commit
    • Matt Turner's avatar
      dix: Assert noPanoramiXExtension is false in PanoramiX code · 61aa40ae
      Matt Turner authored
      When compiling with link time optimization, GCC thinks it's discovered
      undefined behavior:
      
      events.c: In function 'XineramaConfineCursorToWindow':
      events.c:609:13: warning: iteration 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations]
      events.c:609:11: note: within this loop
      events.c:605:49: warning: array subscript -1 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
      events.c:606:31: warning: array subscript -1 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
      events.c:610:39: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
      events.c:617:38: warning: array subscript -2 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
      events.c:619:35: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
      
      This results from
      
          i = PanoramiXNumScreens - 1;
      
          RegionCopy(&pSprite->Reg1, &pSprite->windows[i]->borderSize);
          off_x = screenInfo.screens[i]->x;
          off_y = screenInfo.screens[i]->y;
      
      where GCC believes that PanoramiXNumScreens might be 0. Unfortunately
      GCC is just smart enough to be an annoyance because this case is not
      actually possible: XineramaConfineCursorToWindow() is only called when
      noPanoramiXExtension is false, and if noPanoramiXExtension is false then
      PanoramiXNumScreens must be >1 (see PanoramiXExtensionInit()).
      
      So, add an assert(!noPanoramiXExtension), which to my surprise provides
      GCC with information even in release builds and lets GCC understand that
      the code is not doing anything that is undefined behavior.
      
      I chose this solution instead of the proposed assert(i >= 0) because the
      same pattern occurs in CheckVirtualMotion() but is inside an
      'if (!noPanoramiXExtension)' and does not generate any warnings.
      
      Fixes: xorg/xserver#590
      
      Signed-off-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      61aa40ae
  2. 19 Nov, 2018 1 commit
    • Samuel Thibault's avatar
      dix: do not send focus event when grab actually does not change · 364d6498
      Samuel Thibault authored
      c67f2eac
      
       ("dix: always send focus event on grab change") made dix
      always sent events when it's a NotifyGrab or NotifyUngrab, even if
      from == to, because 'from' can just come from a previous XSetInputFocus
      call.
      
      However, when an application calls XGrabKeyboard several times on
      the same window, we are now sending spurious FocusOut+FocusIn with
      NotifyGrab, even if the grab does not actually change. This makes screen
      readers for blind people spuriously emit activity events which disturb
      screen reading workflow when e.g. switching between menus.
      
      This commit avoids calling DoFocusEvents in that precise case, i.e. when
      oldWin is a previous grab and the new grab is the same window.
      Signed-off-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      364d6498
  3. 12 Nov, 2018 1 commit
  4. 19 Jun, 2017 1 commit
    • Michal Srb's avatar
      dix: Disallow GenericEvent in SendEvent request. · 215f8949
      Michal Srb authored
      
      
      The SendEvent request holds xEvent which is exactly 32 bytes long, no more,
      no less. Both ProcSendEvent and SProcSendEvent verify that the received data
      exactly match the request size. However nothing stops the client from passing
      in event with xEvent::type = GenericEvent and any value of
      xGenericEvent::length.
      
      In the case of ProcSendEvent, the event will be eventually passed to
      WriteEventsToClient which will see that it is Generic event and copy the
      arbitrary length from the receive buffer (and possibly past it) and send it to
      the other client. This allows clients to copy unitialized heap memory out of X
      server or to crash it.
      
      In case of SProcSendEvent, it will attempt to swap the incoming event by
      calling a swapping function from the EventSwapVector array. The swapped event
      is written to target buffer, which in this case is local xEvent variable. The
      xEvent variable is 32 bytes long, but the swapping functions for GenericEvents
      expect that the target buffer has size matching the size of the source
      GenericEvent. This allows clients to cause stack buffer overflows.
      Signed-off-by: default avatarMichal Srb <msrb@suse.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      215f8949
  5. 07 Jun, 2017 1 commit
  6. 19 Sep, 2016 2 commits
  7. 02 Sep, 2016 1 commit
  8. 01 Jun, 2016 1 commit
    • 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>
      7c77c42f
  9. 04 May, 2016 1 commit
    • Adam Jackson's avatar
      dix: Push UpdateCurrentTimeIf down out of the main loop · 137ac094
      Adam Jackson authored
      This was added in:
      
          commit 312910b4
      
      
          Author: Chase Douglas <chase.douglas@canonical.com>
          Date:   Wed Apr 18 11:15:40 2012 -0700
      
              Update currentTime in dispatch loop
      
      Unfortunately this is equivalent to calling GetTimeInMillis() once per
      request. In the absolute best case (as on Linux) you're only hitting the
      vDSO; on other platforms that's a syscall. Either way it puts a pretty
      hard ceiling on request throughput.
      
      Instead, push the call down to the requests that need it; basically,
      grab processing and event generation.
      
      Cc: Chase Douglas <chase.douglas@canonical.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      137ac094
  10. 11 May, 2015 1 commit
  11. 21 Apr, 2015 1 commit
  12. 11 Feb, 2015 1 commit
    • Alan Coopersmith's avatar
      Get rid of const warnings in XSERVER_INPUT_EVENT dtrace probe calls · 9e002dfc
      Alan Coopersmith authored
      
      
      Use typedefs to work around dtrace dropping const qualifiers from probe
      arguments when generating Xserver-dtrace.h.   Add new probes.h header to
      avoid having to replicate these typedefs in every file with dtrace probes.
      
      Gets rid of these warnings from gcc 4.8:
       getevents.c:1096:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' discards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1096:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1651:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1651:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1791:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1791:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1921:9:
        warning: passing argument 6 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
       getevents.c:1921:9:
        warning: passing argument 7 of '__dtrace_Xserver___input__event' disards
        'const' qualifier from pointer target type [enabled by default]
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      9e002dfc
  13. 05 Jun, 2014 1 commit
  14. 29 Apr, 2014 1 commit
  15. 01 Apr, 2014 1 commit
    • Keith Packard's avatar
      Make XYToWindow a screen function · 73698d41
      Keith Packard authored
      
      
      This allows DDXen to override the window picking to account for
      native windows not seen by the X server.  The bulk of the picking logic
      is exposed as a new helper function, miSpriteTrace().  This function
      completes the sprite trace filled out by the caller, and can be set up
      to start the search from a given toplevel window.
      
      v2: Leave existing XYToWindow API in place for API compatibility
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Kristian H. Kristensen's avatarKristian Høgsberg <krh@bitplanet.net>
      73698d41
  16. 12 Jan, 2014 2 commits
  17. 09 Jan, 2014 2 commits
  18. 11 Dec, 2013 1 commit
  19. 18 Oct, 2013 2 commits
  20. 14 Oct, 2013 3 commits
  21. 30 Aug, 2013 2 commits
  22. 17 Jul, 2013 1 commit
    • Peter Hutterer's avatar
      dix: UpdateTouchesForGrab must only free the listener grab if it is non-NULL · 0e3be0b2
      Peter Hutterer authored
      
      
      If a client calls XIGrabDevice in response to a ButtonPress event (regular
      event selection), the device will have a grab, but listener->grab is NULL.
      
      Check for that, to avoid logspam.
      
      [ 26293.863] (EE) BUG: triggered 'if (!pGrab)'
      [ 26293.863] (EE) BUG: grabs.c:256 in FreeGrab()
      [ 26293.863] (EE)
      [ 26293.863] (EE) Backtrace:
      [ 26293.864] (EE) 0: /usr/bin/Xorg (FreeGrab+0x54) [0x45d3fc]
      [ 26293.864] (EE) 1: /usr/bin/Xorg (UpdateTouchesForGrab+0x135) [0x447d4e]
      [ 26293.864] (EE) 2: /usr/bin/Xorg (ActivatePointerGrab+0x1ba) [0x447f3d]
      [ 26293.864] (EE) 3: /usr/bin/Xorg (GrabDevice+0x3e6) [0x4503bc]
      [ 26293.864] (EE) 4: /usr/bin/Xorg (ProcXIGrabDevice+0x1f9) [0x5981b1]
      [ 26293.865] (EE) 5: /usr/bin/Xorg (ProcIDispatch+0x78) [0x58aa17]
      [ 26293.865] (EE) 6: /usr/bin/Xorg (Dispatch+0x30d) [0x43347e]
      [ 26293.865] (EE) 7: /usr/bin/Xorg (main+0x61d) [0x498175]
      [ 26293.865] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3df5621b75]
      [ 26293.865] (EE) 9: /usr/bin/Xorg (_start+0x29) [0x423a19]
      [ 26293.866] (EE) 10: ? (?+0x29) [0x29]
      [ 26293.866] (EE)
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      0e3be0b2
  23. 10 Jul, 2013 1 commit
  24. 15 May, 2013 2 commits
    • Peter Hutterer's avatar
      Abstract cursor refcounting · 9a5ad653
      Peter Hutterer authored
      
      
      Too many callers relied on the refcnt being handled correctly. Use a simple
      wrapper to handle that case.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      9a5ad653
    • Peter Hutterer's avatar
      dix: fix cursor refcounting · 48170210
      Peter Hutterer authored
      
      
      The cursor is referenced during CopyGrab(), thus doesn't need to be handled
      manually anymore. It does need to be refcounted for temp grabs though.
      
      The oldGrab handling in ProcGrabPointer is a leftover from the cursor in the
      grab being refcounted, but the grab itself being a static struct in the
      DeviceIntRec. Now that all grabs are copied, this lead to a double-free of
      the cursor (Reproduced in Thunderbird, dragging an email twice (or more
      often) causes a crash).
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      48170210
  25. 10 May, 2013 6 commits
  26. 25 Mar, 2013 1 commit
  27. 08 Feb, 2013 1 commit