1. 05 Jul, 2020 1 commit
  2. 03 Jul, 2020 2 commits
    • Olivier Fourdan's avatar
      xwayland: Use a fixed DPI value for core protocol · b0413b6e
      Olivier Fourdan authored and Michel Dänzer's avatar Michel Dänzer committed
      The way Xwayland works (like all Wayland clients), it first queries the
      Wayland registry, set up all relevant protocols and then initializes its
      own structures.
      That means Xwayland will get the Wayland outputs from the Wayland
      compositor, compute the physical size of the combined outputs and set
      the corresponding Xwayland screen properties accordingly.
      Then it creates the X11 screen using fbScreenInit() but does so by using
      a default DPI value of 96. That value is used to set the physical size
      of the X11 screen, hence overriding the value computed from the actual
      physical size provided by the Wayland compositor.
      As a result, the DPI computed by tools such as xdpyinfo will always be
      96 regardless of the actual screen size and resolution.
      However, if the Wayland outputs get reconfigured, or new outputs added,
      or existing outputs removed, Xwayland will recompute and update the
      physical size of the screen, leading to an unexpected change of DPI.
      To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can
      be set using the standard command lime option "-dpi") and compute a
      physical screen size to match that DPI setting.
      Note that only affects legacy core protocols, X11 clients can still get
      the actual physical output size as reported by the Wayland compositor
      using the RandR protocol, which also allows for the size to be 0 if the
      size is unknown or meaningless.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      Closes: xorg/xserver#731
    • SimonPilkington's avatar
      xwayland: Initialise values in xwlVidModeGetGamma() · 6748a409
      SimonPilkington authored and Michel Dänzer's avatar Michel Dänzer committed
      ProcVidModeGetGamma() relies on GetGamma() to initialise values if it
      returns TRUE. Without this, we're sending uninitialised values to
      Fixes: xorg/xserver#1040
  3. 02 Jul, 2020 1 commit
  4. 27 Jun, 2020 1 commit
  5. 25 Jun, 2020 4 commits
  6. 24 Jun, 2020 1 commit
    • Martin Weber's avatar
      hw/xfree86: Avoid cursor use after free · 7ae221ad
      Martin Weber authored and Michel Dänzer's avatar Michel Dänzer committed
      During a VT-Switch a raw pointer to the shared cursor object
      is saved which is then freed (in case of low refcount) by a call to
      xf86CursorSetCursor with argument pCurs = NullCursor.
      This leads to a dangling pointer which can follow in a use after free.
      This fix ensures that there is a shared handle saved for the VT-Switch cycle.
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
  7. 23 Jun, 2020 1 commit
  8. 19 Jun, 2020 3 commits
  9. 05 Jun, 2020 1 commit
    • Adam Jackson's avatar
      xwayland: Set the vendor name for GLX_EXT_libglvnd · fc4f2485
      Adam Jackson authored
      Without this the client library will flail around looking for a default
      provider, probably one named "indirect", and that defeats the point of
      having the EGL provider for direct context support in the first place.
      This assumes that "mesa" will work, of course, and in general it should.
      Mesa drivers will DTRT through the DRI3 setup path, and if our glamor is
      atop something non-Mesa then you should fall back to llvmpipe like 1.20.
      In the future it might be useful to differentiate the vendor here based
      on whether glamor is using gbm or streams.
      Fixes: xorg/xserver#1032
  10. 03 Jun, 2020 1 commit
  11. 27 May, 2020 3 commits
    • Jan Beich's avatar
      meson: split udev from udev_kms which requires systemd · b5b52979
      Jan Beich authored
      DragonFly and FreeBSD can use xf86-input-libinput with config/udev.
      ld: error: undefined symbol: xf86PlatformDeviceProbe
      >>> referenced by xf86platformBus.c
      >>>               xf86platformBus.c.o:(xf86platformProbe) in archive hw/xfree86/common/libxorg_common.a
      ld: error: undefined symbol: xf86PlatformDeviceCheckBusID
      >>> referenced by xf86platformBus.c
      >>>               xf86platformBus.c.o:(xf86platformProbeDev) in archive hw/xfree86/common/libxorg_common.a
      ld: error: undefined symbol: xf86PlatformReprobeDevice
      >>> referenced by xf86platformBus.c
      >>>               xf86platformBus.c.o:(xf86platformVTProbe) in archive hw/xfree86/common/libxorg_common.a
      ld: error: undefined symbol: NewGPUDeviceRequest
      >>> referenced by udev.c
      >>>               udev.c.o:(device_added) in archive config/liblibxserver_config.a
      ld: error: undefined symbol: DeleteGPUDeviceRequest
      >>> referenced by udev.c
      >>>               udev.c.o:(device_removed) in archive config/liblibxserver_config.a
    • Jan Beich's avatar
      glx: unbreak on Unix without /usr/include/drm · be731e0b
      Jan Beich authored
      In file included from ../glx/glxdri2.c:35:
      /usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
       #include <drm.h>
      In file included from ../glx/glxdriswrast.c:39:
      /usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
       #include <drm.h>
    • Jan Beich's avatar
      os: unbreak xsha1 on FreeBSD · f2cf236d
      Jan Beich authored
      ../os/xsha1.c:36:10: fatal error: 'sha1.h' file not found
       #include <sha1.h>
      ../os/xsha1.c:45:5: error: implicit declaration of function 'SHA1Init' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
      ../os/xsha1.c:54:5: error: implicit declaration of function 'SHA1Update' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
          SHA1Update(sha1_ctx, data, size);
      ../os/xsha1.c:63:5: error: implicit declaration of function 'SHA1Final' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
          SHA1Final(result, sha1_ctx);
  12. 20 May, 2020 2 commits
  13. 18 May, 2020 1 commit
  14. 13 May, 2020 1 commit
    • Carlos Garnacho's avatar
      xwayland: Improve checks for confined_to on InputOnly windows · 0777cf46
      Carlos Garnacho authored and Olivier Fourdan's avatar Olivier Fourdan committed
      In this pretty Wine/Proton specific kludge, we try to handle confining grabs
      on InputOnly windows by trying to find the InputOutput window that the pointer
      would get visually confined to.
      The grabbing window and the visible window come from different clients, so
      we used to simply resort to the pointer focus. This is troublesome though, as
      the call may happen very soon at a time that the toplevel wasn't yet mapped by
      the Wayland compositor, so the pointer focus may well be out of date soon.
      In these situations, it does seem that even though the confining grab happens
      too early to have the wayland surface mapped, the xserver view of the WindowPtr
      does already reflect the size. Use this to find out the better window to
      assign the confining grab to, one whose geometry fully contains the InputOnly
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      Reviewed-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
  15. 12 May, 2020 4 commits
  16. 11 May, 2020 1 commit
  17. 08 May, 2020 1 commit
  18. 07 May, 2020 1 commit
  19. 01 May, 2020 2 commits
  20. 30 Apr, 2020 1 commit
    • Tobias Stoeckmann's avatar
      hw/xfree86: Support ACPI without APM. · 9890e912
      Tobias Stoeckmann authored and Adam Jackson's avatar Adam Jackson committed
      On systems with ACPI but disabled APM (e.g. --disable-linux-apm)
      the code does not compile due to preprocessor directives.
      If APM is disabled, the final return statement is considered to
      be part of ACPI's last if-statement, leading to a function which
      has no final return statement at all.
      I have refactored the code so ACPI and APM are independent of each
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
  21. 27 Apr, 2020 1 commit
    • Olivier Fourdan's avatar
      xwayland: Fix infinite loop at startup · 785e5906
      Olivier Fourdan authored
      Mutter recently added headless tests, and when running those tests the
      Wayland compositor runs for a very short time.
      Xwayland is spawned by the Wayland compositor and upon startup will
      query the various Wayland protocol supported by the compositor.
      To do so, it will do a roundtrip to the Wayland server waiting for
      events it expects.
      If the Wayland compositor terminates before Xwayland has got the replies
      it expects, it will loop indefinitely calling `wl_display_roundtrip()`
      To avoid that issue, add a new `xwl_screen_roundtrip()` that checks for
      the returned value from `wl_display_roundtrip()` and fails if it is
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
  22. 15 Apr, 2020 6 commits
    • Jon Turney's avatar
      hw/xwin: Drop call to setlocale() · 2fe13a1f
      Jon Turney authored
      Since we now only work with UTF-8 (or ISO8859-1) text in the clipboard,
      we don't need to setlocale().
    • Jon Turney's avatar
      hw/xwin: Consistently use BOOL type from Xmd.h · f269e01e
      Jon Turney authored
      This avoids including Xdefs.h, which means we avoid all the issues with
      _XSERVER64 effecting how types are defined by that.
    • Jon Turney's avatar
      hw/xwin: Remove XSetAuthorization() for helper clients · 4055fed1
      Jon Turney authored
      All helper client code now uses xcb, so calling XSetAuthorization() is
      no longer needed.
      This is the last reference to libX11 from helper clients, so linking
      with x11-xcb and libX11 is no longer required.
      Also drop (unneeded?) linking with libXau.
      Also drop installing these prerequistes on AppvVeyor.
      Also move prototypes for functions in winauth.c from win.h into a new
      header, winauth.h, and include that where needed.
    • Jon Turney's avatar
      hw/xwin: xcbify clipboard integration · 9e02e023
      Jon Turney authored
      Convert clipboard integration code from libX11 to xcb
      This drops support for COMPOUND_TEXT.  Presumably some ancient
      (pre-2000) clients exist which support that, but not UTF8_STRING, but we
      don't have an example to test with. (Given the nature of the thing, the
      users of those clients probably work in CJK languages)
      Supporting COMPOUND_TEXT would also involve writing (or extracting from
      Xlib) support for the ISO 2022 encoding.
      Fix the length of text property set by a SelectionRequest
      The length of the text property is not neccessarily the same as the
      length of the clipboard text before it is d2u converted (specifically,
      if that contains any '\r\n' sequences, it will be shorter as they are
      now just '\n')
    • Jon Turney's avatar
      hw/xwin: Remove nounicodeclipboard option · f4936de7
      Jon Turney authored
      Always use CF_UNICODETEXT clipboard format.  Windows will automatically
      down-convert to CF_TEXT for clients which request that.
      This is subtly different in one way: if CF_TEXT is requested, we now
      post CF_UNICODETEXT and it is converted to CF_TEXT *in the locale of the
      requesting process*.  Previously, we would convert to CF_TEXT *in our
      locale* and post that.
      It looks like the code in the !X_HAVE_UTF8_STRING case didn't actually
      work correctly, but fortunately that has never been true...
    • Jon Turney's avatar
      hw/xwin: Remove support for pre-Vista Win32 clipboard API · 9f51dfde
      Jon Turney authored
      The original Win32 clipboard API is widely regarded as terrible, since
      it relies on clients co-operatively managing the clipboard viewer chain,
      and a single buggy client can break it for all other clients.
      The last Windows version only supporting that API was Windows XP (5.1),
      EOLed in 2014.
      (This requires MinGW-w64 w32api 6.0.0 or later for
      Add/RemoveClipboardListener correctly exported by the x86_64 user32