1. 05 Jan, 2015 1 commit
  2. 04 Jan, 2015 1 commit
    • Peter Hutterer's avatar
      xfree86: rename Xorg.bin to Xorg · de89c6b8
      Peter Hutterer authored
      If the suid wrapper is enabled, /usr/bin/Xorg is just a shell script that
      execs either /usr/libexec/Xorg.bin directly or the Xorg.wrap binary which then
      execve's /usr/libexec/Xorg.bin.
      
      Either way, we end up with Xorg.bin, which is problematic for two reasons:
      * ps shows the command as Xorg.bin
      * _COMM and _EXE in systemd's journal will both show Xorg.bin as well
      
      There's not much we can do about the path, but having the actual command stay
      as Xorg means better compatibility to existing scripts. And, the reason for
      this path: the command
         journalctl _COMM=Xorg
      works universally, regardless of whether the wrapper is used or not.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Acked-by: default avatarHans de Goede <hdegoede@redhat.com>
      de89c6b8
  3. 02 Jan, 2015 1 commit
  4. 01 Jan, 2015 1 commit
  5. 25 Dec, 2014 7 commits
  6. 20 Dec, 2014 2 commits
  7. 18 Dec, 2014 1 commit
    • Keith Packard's avatar
      modesetting: [v2] Don't re-enable the cursor when loading the image · 5a541bd5
      Keith Packard authored
      Hidden cursors also have their image updated; re-enabling the cursor
      each time the image is set will cause it to re-appear.
      
       * Unifies the code that was in  drmmode_load_cursor_argb and
        drm_mode_show_cursor and moves it to a new drmmode_set_cursor
      
       * Add a new boolean, 'cursor_up', to the per-crtc
         private data to track whether the cursor should be displayed.
      
       * Call drmmode_set_cursor from drm_mode_show_cursor and, if
         the cursor should be displayed, from drm_mode_load_cursor_argb.
      
      v2: Call drmModeSetCursor2 when loading a new cursor image if the
          cursor should be displayed.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      5a541bd5
  8. 11 Dec, 2014 8 commits
  9. 09 Dec, 2014 2 commits
  10. 08 Dec, 2014 4 commits
  11. 12 Nov, 2014 3 commits
  12. 09 Nov, 2014 5 commits
    • Colin Harrison's avatar
      hw/xwin: Don't allocate one wchar_t too much for unicode text placed on the Windows clipboard · 5920433c
      Colin Harrison authored
      The count of wchar_t returned by MultiByteToWideChar() includes the terminating
      null character, so don't add one to it.
      
      Also, reduce the scope of various length variables
      Signed-off-by: default avatarColin Harrison <colin.harrison@virgin.net>
      Reviewed-by: Jon Turney's avatarJon TURNEY <jon.turney@dronecode.org.uk>
      5920433c
    • Jon Turney's avatar
      hw/xwin: Fix hang on shutdown when we own the clipboard. · d172cd63
      Jon Turney authored
      If we are the clipboard owner when we are shutdown, we recieve a
      WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
      available to other applications.  Unfortunately, this is far too late to do
      anything useful with, as the server is waiting for the clipboard thread to exit,
      and so can't process requests to convert clipboard contents.
      
      Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
      WM_RENDERALLFORMATS has ever worked usefully, in any case).
      
      (To make this work, I guess we would need to rearrange the way shutdown works
      completely: first synchronously stop the clipboard, then stop the X server)
      
      We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
      clipboard formats have changed (as ones which haven't been rendered are now
      removed), but the clipboard owner is now the system, not us, which we have to
      arrange to ignore.
      Signed-off-by: Jon Turney's avatarJon TURNEY <jon.turney@dronecode.org.uk>
      Reviewed-by: default avatarColin Harrison <colin.harrison@virgin.net>
      d172cd63
    • Jon Turney's avatar
      hw/xwin: Fix clipboard thread restart · 94d433c8
      Jon Turney authored
      It seems that the clipboard thread restart mechanism has been broken for a
      while, which can be demonstrated using XDMCP with KDM (e.g. to a Kubutunu 12.04
      host)
      
      KDM kills all attached clients, including the clipboard integration client,
      which restarts, but then exits on WM_QUIT.
      
      Using PostQuitMessage() in WM_DESTROY is unhelpful, as we may not actually be
      quitting the thread, if we just destroyed the window because the clipboard
      thread is about to retry, because he WM_QUIT message sticks around, and is
      noticed the next time we look at the window message queue and confuses us into
      thinking we need to quit.
      
      Sending a WM_DESTROY is apparently never correct anyhow, see [1]
      
      So:
      
      1/ Use DestroyWindow() to destroy the clipboard messaging window when cleaning
      up for retry or exit in winClipboardProc (the clipboard thread main proc)
      
      2/ Send a special WM_WM_QUIT message in winClipboardWindowDestroy() from the X
      server thread when the X server is resetting.
      
      3/ When processing that WM_WM_QUIT message in the clipboard thread, cause the
      clipboard window to PostQuitMessage(), which causes the clipboard thread to
      exit.
      
      [1] http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspxSigned-off-by: Jon Turney's avatarJon TURNEY <jon.turney@dronecode.org.uk>
      Reviewed-by: default avatarColin Harrison <colin.harrison@virgin.net>
      94d433c8
    • Jon Turney's avatar
      hw/xwin: Improve reliability of clipboard X->Windows pastes · b4a08e64
      Jon Turney authored
      Sometimes, particularly with large clipboard pastes to Windows, we could end up
      waiting for the timeout to expire, rather than pasting the data.
      
      Various changes to improve reliability:
      
      1. Use XFlush() not XSync() in winProcessXEventsTimeout().
      
      It makes no sense to ensure we have received replies to outstanding requests if
      we are going to wait for them using select()
      
      2. Add XFlush() to winClipboardProc()
      
      Make sure we have sent any requests before we wait using select()
      
      3. Don't use FD_ISSET() to check which fd is ready
      
      This looks like a Cygwin select() bug in that it sometimes returns 0 with an
      empty fd set before the timeout expires, but a fd appears to be ready.
      
      Add select() return value to debug output when we are warning that this has
      happened.
      
      4. Drain event queues before entering select()
      
      Unconditionally drain event queues before entering select().  This seems to be
      the recommended way of writing select() and X event processing loops.
      
      winClipboardFlushXEvents() checks using XPending(), and
      winClipboardFlushWindowsMessageQueue() checks using PeekMessage() so this is
      safe against blocking, but means that may not need to enter select() at all
      sometimes.
      Signed-off-by: Jon Turney's avatarJon TURNEY <jon.turney@dronecode.org.uk>
      Reviewed-by: default avatarColin Harrison <colin.harrison@virgin.net>
      b4a08e64
    • Jon Turney's avatar
      hw/xwin: Add controls for enabling/disabling monitoring of PRIMARY selection · c03f9e23
      Jon Turney authored
      xwinclip: Add -noprimary option
      Xwin: Add -primary and -noprimary options and tray-menu control
      
      v2:
      Use Bool type for fPrimarySelection
      Add -noprimary to usage message
      Fix indentation in hw/xwin/winwndproc.c
      Signed-off-by: Jon Turney's avatarJon TURNEY <jon.turney@dronecode.org.uk>
      Reviewed-by: default avatarColin Harrison <colin.harrison@virgin.net>
      c03f9e23
  13. 06 Nov, 2014 4 commits