1. 20 Dec, 2017 1 commit
  2. 12 Oct, 2017 1 commit
  3. 04 Oct, 2017 2 commits
  4. 25 Sep, 2017 1 commit
    • Adam Jackson's avatar
      xfree86: Silence a new glibc warning · c5320244
      Adam Jackson authored
      glibc would like to stop declaring major()/minor() macros in
      <sys/types.h> because that header gets included absolutely everywhere
      and unix device major/minor is perhaps usually not what's expected. Fair
      enough. If one includes <sys/sysmacros.h> as well then glibc knows we
      meant it and doesn't warn, so do that if it exists.
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      (cherry picked from commit d732c365)
      c5320244
  5. 15 Mar, 2017 1 commit
  6. 10 Mar, 2017 1 commit
  7. 02 Mar, 2017 4 commits
  8. 01 Mar, 2017 1 commit
  9. 28 Feb, 2017 2 commits
  10. 23 Feb, 2017 1 commit
  11. 11 Jan, 2017 1 commit
  12. 15 Nov, 2016 1 commit
  13. 28 Oct, 2016 1 commit
  14. 26 Oct, 2016 1 commit
  15. 05 Oct, 2016 5 commits
  16. 28 Sep, 2016 1 commit
  17. 23 Sep, 2016 1 commit
  18. 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
  19. 19 Sep, 2016 1 commit
  20. 16 Sep, 2016 1 commit
  21. 15 Sep, 2016 1 commit
    • Jon Turney's avatar
      Add Windows-DRI extension · f5f4d32a
      Jon Turney authored
      If windowsdriproto headers are available, build a Windows-DRI extension,
      which supports requests to enable local clients to directly render GL to a
      Windows drawable:
      
      - a query to check if WGL is being used on a screen
      - a query to map a fbconfigID to a native pixelformatindex
      - a query to map a drawable to a native handle
      
      Windows-DRI can only be useful if we are using WGL, so make an note if WGL
      is active on a screen.
      
      Make validGlxDrawable() public
      
      Adjust glxWinSetPixelFormat() so it doesn't require a context, just a
      screen and config.
      
      That enables factoring out the deferred drawable creation code as
      glxWinDeferredCreateDrawable()
      
      Enhance glxWinDeferredCreateDrawable(), so that pixmaps are placed into a
      file mapping, so they exist in memory which can be shared with the direct
      rendering process.
      
      Currently, this file mapping is accessed by a name generated from the XID.
      This will not be unique across multiple server instances. It would perhaps
      be better, although more complicated, to use an anonymous file mapping, and
      then duplicate the handle for the direct rendering process.
      
      Use glxWinDeferredCreateDrawable() to ensure the native handle exists for
      the Windows-DRI query to map a drawable to native handle.
      
      v2:
      Various printf format warning fixes
      
      v3:
      Fix format warnings on x86
      Move some uninteresting windows-dri output to debug log level
      
      v4:
      check for windowsdriproto when  --enable-windowsdri
      use windowsdriproto_CFLAGS
      Signed-off-by: Jon Turney's avatarJon Turney <jon.turney@dronecode.org.uk>
      Reviewed-by: default avatarColin Harrison <colin.harrison@virgin.net>
      f5f4d32a
  22. 13 Sep, 2016 1 commit
  23. 13 Aug, 2016 1 commit
  24. 21 Jul, 2016 1 commit
  25. 19 Jul, 2016 1 commit
  26. 18 Jul, 2016 1 commit
  27. 30 Jun, 2016 1 commit
    • Adam Jackson's avatar
      configure: Tell AC_REPLACE_FUNCS where to find replacements · 3762edde
      Adam Jackson authored
      Fixes weird link errors of the form:
      
            CCLD     Xvfb
          ../../Xext/.libs/libXext.a(xvmc.o): In function `xf86XvMCRegisterDRInfo':
          /home/ajax/git/xserver/Xext/xvmc.c:828: undefined reference to `strlcpy'
          /home/ajax/git/xserver/Xext/xvmc.c:829: undefined reference to `strlcpy'
          ../../os/os.O: In function `siHostnameAddrMatch':
          /home/ajax/git/xserver/os/access.c:1821: undefined reference to `strlcpy'
          ../../os/os.O: In function `AuthAudit':
          /home/ajax/git/xserver/os/connection.c:555: undefined reference to `strlcpy'
          /home/ajax/git/xserver/os/connection.c:574: undefined reference to `strlcpy'
          ../../os/os.O:/home/ajax/git/xserver/os/log.c:972: more undefined references to `strlcpy' follow
          collect2: error: ld returned 1 exit status
          Makefile:688: recipe for target 'Xvfb' failed
          make[3]: *** [Xvfb] Error 1
          Makefile:749: recipe for target 'all-recursive' failed
          make[2]: *** [all-recursive] Error 1
          Makefile:608: recipe for target 'all-recursive' failed
          make[1]: *** [all-recursive] Error 1
          Makefile:776: recipe for target 'all-recursive' failed
          make: *** [all-recursive] Error 1
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      3762edde
  28. 08 Jun, 2016 1 commit
    • Peter Hutterer's avatar
      Allow compile-time selection of a fallback input driver · c69bd15e
      Peter Hutterer authored
      A new --with-fallback-input-driver=foo option allows selecting a
      fallback driver for the server if the driver configured for the device
      is not found.  Note that this only applies when the device has a driver
      assigned and that module fails to load, devices without a driver are
      ignored as usual.
      
      This avoids the situation where a configuration assigns e.g. the
      synaptics driver but that driver is not available on the system,
      resulting in a dead device. A fallback driver can at least provides some
      functionality.
      
      This becomes more important as we move towards making other driver true
      leaf nodes that can be installed/uninstalled as requested. Specifically,
      wacom and synaptics, a config that assigns either driver should be
      viable even when the driver itself is not (yet) installed on the system.
      
      It is up to the distributions to make sure that the fallback driver is
      always installed. The fallback driver can be disabled with
      --without-fallback-input-driver and is disabled by default on non-Linux
      systems because we don't have generic drivers on those platforms.
      Default driver on Linux is libinput, evdev is the only other serious
      candidate here.
      
      Sample log output:
      [  3274.421] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event4)
      [  3274.421] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad weird driver"
      [  3274.421] (II) LoadModule: "banana"
      [  3274.422] (WW) Warning, couldn't open module banana
      [  3274.422] (II) UnloadModule: "banana"
      [  3274.422] (II) Unloading banana
      [  3274.422] (EE) Failed to load module "banana" (module does not exist, 0)
      [  3274.422] (EE) No input driver matching `banana'
      [  3274.422] (II) Falling back to input driver `libinput'
      .. server proceeds to assign libinput, init the device, world peace and rainbows
      everywhere, truly what a sight. Shame about the banana though.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      c69bd15e
  29. 30 May, 2016 1 commit
    • Jonas Ådahl's avatar
      xwayland: Use the CLOCK_MONOTONIC clock · a779fda2
      Jonas Ådahl authored
      By default the X server will try CLOCK_MONOTONIC_COARSE before
      CLOCK_MONOTONIC, while A Wayland compositor may only support getting
      their timestamps from the CLOCK_MONOTONIC clock. This causes various
      issues since it may happen that a timestamp from CLOCK_MONOTONIC
      retrieved before a sending an X request will still be "later" than the
      timestamp the X server than gets after receiving the request, due to the
      fact that CLOCK_MONOTONIC_COARSE has a lower resolution.
      
      To avoid these issues, make Xwayland always use CLOCK_MONOTONIC, so
      that it becomes possible for Wayland compositor only supporting
      CLOCK_MONOTONIC and X server to use the same clock.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Tested-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      a779fda2
  30. 26 May, 2016 2 commits
    • Keith Packard's avatar
      Create a threaded mechanism for input [v7] · 30ac7567
      Keith Packard authored
      The current SIGIO signal handler method, used at generation of input events,
      has a bunch of oddities. This patch introduces an alternative way using a
      thread, which is used to select() all input device file descriptors.
      
      A mutex was used to control the access to input structures by the main and input
      threads. Two pipes to emit alert events (such hotplug ones) and guarantee the
      proper communication between them was also used.
      Co-authored-by: default avatarFernando Carrijo <fcarrijo@freedesktop.org>
      Signed-off-by: default avatarTiago Vignatti <tiago.vignatti@nokia.com>
      
      v2: Fix non-Xorg link. Enable where supported by default.
      
          This also splits out the actual enabling of input threads to
          DDX-specific patches which follow
      
      v3: Make the input lock recursive
      
      v4: Use regular RECURSIVE_MUTEXes instead of rolling our own
          Respect the --disable-input-thread configuration option by
          providing stubs that expose the same API/ABI.
      
          Respond to style comments from Peter Hutterer.
      
      v5: use __func__ in inputthread debug and error mesages.
      
          Respond to style comments from Peter Hutterer.
      
      v6: use AX_PTHREAD instead of inlining pthread tests.
      
          Suggested by Emil Velikov <emil.l.velikov@gmail.com>
      
      v7: Use pthread_sigmask instead of sigprocmask when using threads
      
          Suggested by Adam Jackson <ajax@redhat.com>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      30ac7567
    • Keith Packard's avatar
      Remove SIGIO support for input [v5] · 6a5a4e60
      Keith Packard authored
      This removes all of the SIGIO handling support used for input
      throughout the X server, preparing the way for using threads for input
      handling instead.
      
      Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
      to stub functions input_lock/input_unlock so that we don't lose this
      information.
      
      xfree86 SIGIO support is reworked to use internal versions of
      OsBlockSIGIO and OsReleaseSIGIO.
      
      v2: Don't change locking order (Peter Hutterer)
      v3: Comment weird && FALSE in xf86Helper.c
          Leave errno save/restore in xf86ReadInput
          Squash with stub adding patch (Peter Hutterer)
      v4: Leave UseSIGIO config parameter so that
          existing config files don't break (Peter Hutterer)
      v5: Split a couple of independent patch bits out
          of kinput.c (Peter Hutterer)
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6a5a4e60