1. 16 Jan, 2019 1 commit
  2. 15 Jan, 2019 2 commits
  3. 08 Jan, 2019 1 commit
    • Keith Packard's avatar
      composite: 0.5. Window scaling and events · 106cc9bc
      Keith Packard authored
      
      
      Output scaling:
      
       * Changes to mivaltree to reset window clip to owner window size
         instead of server window size when compositing
      
       * Allocate owner window size pixmap for composite pixmap
      
       * Paint scaled image for automatic compositing
      
       * Report owner window size in events to the window owner.
      
       * Scale exposure damage in compSetRedirectBorderClip from
         current size to owner size to make sure the correct parts of
         the window are repainted.
      
      Input scaling:
      
       * Change miSpriteTrace to scale cursor coordinates when transiting an
         owner-sized window. Do all computations in double to handle
         multiple such transitions without losing bits
      
       * Add ScaleRootCoordinate in events.c. This function takes a window
         and a root x/y and walks up the tree scaling each time there is an
         owner size set.
      
       * Use ScaleRootCoordinate in FixUpEventFromWindow.
      
       * Wrap event delivery in DeliverEvent in new
         SaveEventRootCoord/RestoreEventRootCoord functions so that
         different windows receiving the same event will all receive the
         correct coordinates.
      
      Composite events:
      
       * Deliver CompositePixmapNotify events from compSetPixmapVisitWindow
         so that applications will be notified each time the pixmap changes.
      
       * Deliver CompositeOwnerWindowSizeNotify events when owner window
         size is set.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      106cc9bc
  4. 10 Oct, 2017 1 commit
  5. 12 May, 2017 1 commit
  6. 26 Apr, 2017 1 commit
  7. 11 Jan, 2017 1 commit
  8. 15 Nov, 2016 1 commit
  9. 28 Sep, 2016 1 commit
  10. 22 Sep, 2016 1 commit
    • Jeremy Huddleston Sequoia's avatar
      dix: Silence TSan warnings when checking for pending input · 2740dc19
      Jeremy Huddleston Sequoia authored
      
      
      V2: Moves InputCheckPending() into dix.h
      
      Bumps required version of xproto to 7.0.30
      
      ==================
      WARNING: ThreadSanitizer: data race (pid=4943)
        Read of size 4 at 0x00010c4e3854 by thread T8:
          #0 WaitForSomething WaitFor.c:237 (X11.bin+0x00010049216c)
          #1 Dispatch dispatch.c:413 (X11.bin+0x000100352ed9)
          #2 dix_main main.c:287 (X11.bin+0x00010036e894)
          #3 server_thread quartzStartup.c:66 (X11.bin+0x000100039e63)
      
        Previous write of size 4 at 0x00010c4e3854 by thread T12 (mutexes: write M856, write M1976):
          #0 mieqEnqueue mieq.c:263 (X11.bin+0x000100448d14)
          #1 DarwinSendDDXEvent darwinEvents.c:641 (X11.bin+0x000100033613)
          #2 DarwinProcessFDAdditionQueue_thread darwinEvents.c:338 (X11.bin+0x000100032039)
      
        Location is global 'miEventQueue' at 0x00010c4e3850 (X11.bin+0x0001005ab854)
      
        Mutex M856 (0x00010c4c8c80) created at:
          #0 pthread_mutex_lock <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x0000000321fe)
          #1 DarwinListenOnOpenFD darwinEvents.c:300 (X11.bin+0x000100031607)
          #2 socket_handoff bundle-main.c:288 (X11.bin+0x000100002b40)
          #3 __do_request_fd_handoff_socket_block_invoke bundle-main.c:379 (X11.bin+0x0001000029ba)
          #4 __tsan::invoke_and_release_block(void*) <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x00000005d97b)
          #5 _dispatch_client_callout <null>:33 (libdispatch.dylib+0x0000000020ef)
      
        Mutex M1976 (0x00010c4e3d68) created at:
          #0 pthread_mutex_init <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x0000000253c3)
          #1 input_lock inputthread.c:103 (X11.bin+0x00010049fd10)
          #2 TimerSet WaitFor.c:343 (X11.bin+0x0001004926c2)
          #3 RootlessQueueRedisplay rootlessScreen.c:594 (X11.bin+0x000100065d7f)
          #4 RootlessInstallColormap rootlessScreen.c:514 (X11.bin+0x000100069f1a)
          #5 miSpriteInstallColormap misprite.c:562 (X11.bin+0x000100467095)
          #6 miCreateDefColormap micmap.c:270 (X11.bin+0x000100440399)
          #7 DarwinScreenInit darwin.c:285 (X11.bin+0x0001000303bb)
          #8 AddScreen dispatch.c:3908 (X11.bin+0x00010036c417)
          #9 InitOutput darwin.c:671 (X11.bin+0x00010002fdeb)
          #10 dix_main main.c:197 (X11.bin+0x00010036e228)
          #11 server_thread quartzStartup.c:66 (X11.bin+0x000100039e63)
      
        Thread T8 (tid=4198779, running) created by main thread at:
          #0 pthread_create <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x000000024490)
          #1 create_thread quartzStartup.c:78 (X11.bin+0x000100039dad)
          #2 QuartzInitServer quartzStartup.c:95 (X11.bin+0x000100039c16)
          #3 X11ApplicationMain X11Application.m:1238 (X11.bin+0x00010001cde4)
          #4 X11ControllerMain X11Controller.m:984 (X11.bin+0x00010002a642)
          #5 server_main quartzStartup.c:136 (X11.bin+0x00010003a03b)
          #6 do_start_x11_server bundle-main.c:436 (X11.bin+0x000100002eb5)
          #7 _Xstart_x11_server mach_startupServer.c:189 (X11.bin+0x000100004e99)
          #8 mach_startup_server mach_startupServer.c:399 (X11.bin+0x000100005734)
          #9 mach_msg_server mach_msg.c:563 (libsystem_kernel.dylib+0x000000012186)
          #10 start <null>:29 (libdyld.dylib+0x000000005254)
      
        Thread T12 (tid=4198797, running) created by thread T8 at:
          #0 pthread_create <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x000000024490)
          #1 create_thread darwinEvents.c:121 (X11.bin+0x000100031ecf)
          #2 DarwinEQInit darwinEvents.c:365 (X11.bin+0x000100031860)
          #3 InitInput darwin.c:571 (X11.bin+0x00010002ea09)
          #4 dix_main main.c:261 (X11.bin+0x00010036e7ce)
          #5 server_thread quartzStartup.c:66 (X11.bin+0x000100039e63)
      
      SUMMARY: ThreadSanitizer: data race WaitFor.c:237 in WaitForSomething
      ==================
      ==================
      WARNING: ThreadSanitizer: data race (pid=22841)
        Write of size 4 at 0x000105bbd864 by main thread (mutexes: write M1945):
          #0 mieqEnqueue mieq.c:263 (X11.bin+0x000100448cf4)
          #1 DarwinSendDDXEvent darwinEvents.c:642 (X11.bin+0x000100033693)
          #2 -[X11Controller set_window_menu:] X11Controller.m:275 (X11.bin+0x0001000222fd)
          #3 -[X11Application set_window_menu:] X11Application.m:486 (X11.bin+0x000100018b44)
          #4 -[X11Application handleMachMessage:] X11Application.m:177 (X11.bin+0x000100016678)
          #5 __NSFireMachPort <null>:69 (Foundation+0x00000009b62b)
          #6 X11ControllerMain X11Controller.m:984 (X11.bin+0x00010002a5f2)
          #7 server_main quartzStartup.c:136 (X11.bin+0x000100039ffb)
          #8 do_start_x11_server bundle-main.c:436 (X11.bin+0x000100002e65)
          #9 _Xstart_x11_server mach_startupServer.c:189 (X11.bin+0x000100004e49)
          #10 mach_startup_server mach_startupServer.c:399 (X11.bin+0x0001000056e4)
          #11 mach_msg_server mach_msg.c:563 (libsystem_kernel.dylib+0x000000012186)
          #12 start <null>:29 (libdyld.dylib+0x000000005254)
      
        Previous read of size 4 at 0x000105bbd864 by thread T7:
          #0 Dispatch dispatch.c:434 (X11.bin+0x000100352fc8)
          #1 dix_main main.c:287 (X11.bin+0x00010036e874)
          #2 server_thread quartzStartup.c:66 (X11.bin+0x000100039e23)
      
        Location is global 'miEventQueue' at 0x000105bbd860 (X11.bin+0x0001005ab864)
      
        Mutex M1945 (0x000105bbdd78) created at:
          #0 pthread_mutex_init <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x0000000253c3)
          #1 input_lock inputthread.c:103 (X11.bin+0x00010049fd10)
          #2 TimerSet WaitFor.c:348 (X11.bin+0x0001004926c2)
          #3 RootlessQueueRedisplay rootlessScreen.c:594 (X11.bin+0x000100065d3f)
          #4 RootlessInstallColormap rootlessScreen.c:514 (X11.bin+0x000100069eda)
          #5 miSpriteInstallColormap misprite.c:562 (X11.bin+0x000100467075)
          #6 miCreateDefColormap micmap.c:270 (X11.bin+0x000100440379)
          #7 DarwinScreenInit darwin.c:285 (X11.bin+0x00010003036b)
          #8 AddScreen dispatch.c:3914 (X11.bin+0x00010036c3f7)
          #9 InitOutput darwin.c:671 (X11.bin+0x00010002fd9b)
          #10 dix_main main.c:197 (X11.bin+0x00010036e208)
          #11 server_thread quartzStartup.c:66 (X11.bin+0x000100039e23)
      
        Thread T7 (tid=4257217, running) created by main thread at:
          #0 pthread_create <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x000000024490)
          #1 create_thread quartzStartup.c:78 (X11.bin+0x000100039d6d)
          #2 QuartzInitServer quartzStartup.c:95 (X11.bin+0x000100039bd6)
          #3 X11ApplicationMain X11Application.m:1238 (X11.bin+0x00010001cd94)
          #4 X11ControllerMain X11Controller.m:984 (X11.bin+0x00010002a5f2)
          #5 server_main quartzStartup.c:136 (X11.bin+0x000100039ffb)
          #6 do_start_x11_server bundle-main.c:436 (X11.bin+0x000100002e65)
          #7 _Xstart_x11_server mach_startupServer.c:189 (X11.bin+0x000100004e49)
          #8 mach_startup_server mach_startupServer.c:399 (X11.bin+0x0001000056e4)
          #9 mach_msg_server mach_msg.c:563 (libsystem_kernel.dylib+0x000000012186)
          #10 start <null>:29 (libdyld.dylib+0x000000005254)
      
      SUMMARY: ThreadSanitizer: data race mieq.c:263 in mieqEnqueue
      ==================
      Signed-off-by: Jeremy Huddleston Sequoia's avatarJeremy Huddleston Sequoia <jeremyhu@apple.com>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      2740dc19
  11. 16 Sep, 2016 1 commit
  12. 13 Sep, 2016 1 commit
  13. 21 Jul, 2016 2 commits
  14. 18 Jul, 2016 3 commits
  15. 17 Jun, 2016 1 commit
    • Hans de Goede's avatar
      xrandrprovider: Do not use separate lists for unbound / source / offload slaves · 5c7af02b
      Hans de Goede authored
      
      
      A single provider can be both a offload and source slave at the same time,
      the use of seperate lists breaks in this case e.g. :
      
      xrandr --listproviders
      Providers: number : 2
      Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting
      Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 0 name:modesetting
      
      xrandr --setprovideroutputsource 1 0x7b
      xrandr --listproviders
      Providers: number : 2
      Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:modesetting
      Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 1 name:modesetting
      
      xrandr --setprovideroffloadsink 1 0x7b
      xrandr --listproviders
      Providers: number : 3
      Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:modesetting
      Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
      Provider 2: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
      
      Not good. The problem is that the provider with id 0x46 now is on both
      the output_slave_list and the offload_slave_list of the master screen.
      
      This commit fixes this by unifying all 3 lists into a single slaves list.
      
      Note that this does change the struct _Screen definition, so this is an ABI
      break. I do not expect any of the drivers to actually use the removed / changed
      fields so a recompile should suffice.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      5c7af02b
  16. 10 Jun, 2016 1 commit
    • Adam Jackson's avatar
      xace: Remove the audit hooks and tune dispatch · 6cb34816
      Adam Jackson authored
      
      
      There are no in-tree consumers of the audit hooks, and they are in any
      case redundant with the dtrace dispatch hooks. Neither is there any
      in-tree user of the core request dispatch hook. The extension hook is
      only used for non-default security cases, but in the absence of LTO we
      always have to take the function call into XaceHookDispatch to find out
      that there's no callback registered.
      
      Cc: Eamon Walsh <ewalsh@tycho.nsa.gov>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      6cb34816
  17. 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
  18. 01 Dec, 2015 1 commit
  19. 24 Aug, 2015 1 commit
    • Olivier Fourdan's avatar
      configurable maximum number of clients · d206c240
      Olivier Fourdan authored
      
      
      Make the maximum number of clients user configurable, either from the command
      line or from xorg.conf
      
      This patch works by using the MAXCLIENTS (raised to 512) as the maximum
      allowed number of clients, but allowing the actual limit to be set by the
      user to a lower value (keeping the default of 256).
      
      There is a limit size of 29 bits to be used to store both the client ID and
      the X resources ID, so by reducing the number of clients allowed to connect to
      the X server, the user can increase the number of X resources per client or
      vice-versa.
      
      Parts of this patch are based on a similar patch from Adam Jackson
      <ajax@redhat.com>
      
      This now requires at least xproto 7.0.28
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      d206c240
  20. 08 Jul, 2015 1 commit
  21. 21 Apr, 2015 2 commits
  22. 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
  23. 04 Jan, 2015 1 commit
  24. 09 Dec, 2014 1 commit
  25. 12 Nov, 2014 1 commit
  26. 09 Oct, 2014 1 commit
  27. 29 Jul, 2014 1 commit
  28. 05 Feb, 2014 1 commit
  29. 23 Jan, 2014 1 commit
  30. 12 Jan, 2014 2 commits
  31. 09 Dec, 2013 1 commit
    • Adam Jackson's avatar
      smartsched: Tweak the default scheduler intervals · b61ccd5d
      Adam Jackson authored
      
      
      A default timeslice of 20ms means a pathological client can ruin up to
      two frames per scheduler tick.  And a fifth of a second is just insane.
      
      Pick two different numbers out of the hat.  A 5ms slice means you can
      probably keep up with two or three abusive clients, and letting it burst
      to 15ms should give you about all the timeslice you need for a
      fullscreen game (that's doing server-side rendering for some reason).
      
      If you're running on a system with a 10ms granularity on SIGALRM, then
      this effectively changes the intervals to 10ms and 30ms.  Which is still
      better, just not as better.
      
      I suspect this is about as good as we can do without actually going
      preemptive, which is an entire other nightmare.
      Reviewed-by: Julien Cristau's avatarJulien Cristau <jcristau@debian.org>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      b61ccd5d
  32. 10 Sep, 2013 1 commit
  33. 05 Sep, 2013 1 commit
  34. 10 May, 2013 1 commit