1. 23 Feb, 2020 2 commits
  2. 18 Feb, 2020 5 commits
  3. 14 Feb, 2020 1 commit
  4. 12 Feb, 2020 2 commits
    • Adam Jackson's avatar
      meson: Add support for libunwind · ee9f6e20
      Adam Jackson authored
    • Zoltán Böszörményi's avatar
      Fix modesetting device matching through kmsdev device path · 42aaf372
      Zoltán Böszörményi authored and Adam Jackson's avatar Adam Jackson committed
      xf86platformProbeDev didn't check the device path, fix it.
      This is a problem when trying to set up a non-PCI device via
      explicit xorg.conf.d configuration.
      An USB DisplayLink device, being non-PCI was always set up
      as a GPU device assigned to screen 0 instead of a regular
      framebuffer, potentially having its own dedicated screen,
      despite such configuration as below. Only the relevant parts
      of the configuration are quoted, it's part of a larger context
      with an Intel chip that has 3 outputs:
      * DP1 connected to an LCD panel,
      * VGA1 connected to an external monitor,
      * HDMI1 unconnected and having no user visible connector
      Section "ServerFlags"
              Option          "AutoBindGPU" "false"
      Section "Device"
              Identifier      "Intel2"
              Driver          "intel"
              BusID           "PCI:0:2:0"
              Screen          2
              Option          "Monitor-HDMI1" "HDMI1"
              Option          "ZaphodHeads" "HDMI1"
      Section "Device"
              Identifier      "UDL"
              Driver          "modesetting"
              Option          "kmsdev" "/dev/dri/card0"
              #BusID          "usb:0:1.2:1.0"
              Option          "Monitor-DVI-I-1" "DVI-I-1"
              Option          "ShadowFB" "on"
              Option          "DoubleShadow" "on"
      Section "Screen"
              Identifier      "SCREEN2"
              Option          "AutoServerLayout" "on"
              Device          "UDL"
              GPUDevice       "Intel2"
              Monitor         "Monitor-DVI-I-1"
              SubSection      "Display"
                      Modes   "1024x768"
                      Depth   24
      Section "ServerLayout"
              Identifier      "LAYOUT"
              Option          "AutoServerLayout" "on"
              Screen          0 "SCREEN"
              Screen          1 "SCREEN1" RightOf "SCREEN"
              Screen          2 "SCREEN2" RightOf "SCREEN1"
      On the particular machine I was trying to set up an UDL device,
      I found the following structure was being used to match
      the device to a platform device while I was debugging the issue:
      xf86_platform_devices[0] == Intel, /dev/dri/card1, primary platform device
      xf86_platform_devices[1] == UDL, /dev/dri/card0
      devList[0] == "Intel0", ZaphodHeads: DP1
      devList[1] == "Intel1", ZaphodHeads: VGA1
      devList[2] == "UDL"
      devList[3] == "Intel2", ZaphodHeads: HDMI1 (intended GPU device to UDL)
      When xf86platformProbeDev() matched the UDL device, the BusID
      check failed in both cases of:
      * BusID "usb:0:1.2:1.0" was specified
      * Option "kmsdev" "/dev/dri/card0" was specified
      As a result, xf86platformProbeDev() went on to call probeSingleDevice()
      with xf86_platform_devices[0] and devList[2], resulting in the
      UDL device being set up as a GPU device assigned to the first screen
      instead of as a framebuffer on the third screen as the configuration
      Checking Option "kmsdev" in code code may be a layering violation.
      But the modesetting driver is actually part of the Xorg sources
      instead of being an external driver, so he "kmsdev" path knowledge
      may be used here.
      Signed-off-by: default avatarBöszörményi Zoltán <zboszor@pr.hu>
  5. 11 Feb, 2020 6 commits
  6. 10 Feb, 2020 2 commits
    • Michel Dänzer's avatar
      modesetting: Fix build with glamor disabled · 0cb9fa79
      Michel Dänzer authored and Michel Dänzer's avatar Michel Dänzer committed
      Fixes: cb1b1e18
       "modesetting: Indirect the glamor API through
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Pekka Paalanen's avatar
      randr: auto-bind of GPU is a config change · bfb36a58
      Pekka Paalanen authored and Michel Dänzer's avatar Michel Dänzer committed
      When a GPU is auto-bound adding more outputs to a screen, that needs to count
      as a configuration change on that screen so that a WM listening for
      RRScreenChangeNotify gets notified and handles it as a hotplug. This is
      particularly for cases where the outputs are already connected. Otherwise
      nothing might happen.
      Issue #909 describes a real world case where plugging in a DisplayLink dock
      with a monitor already connected is sometimes left inactive by GNOME. That
      issue is a race, and requires adding a sleep(5); as the first thing in
      NewGPUDeviceRequest() to reproduce reliably. With the sleep, the monitor in the
      dock will never activate automatically. Add this fix over the sleep, and the
      issue is gone.
      This fix was originally developed on a branch replicating Ubuntu 19.04 patch
      set based on xserver 1.20.4. Testing on master branch was impossible due to
      Closes: xorg/xserver#909
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
  7. 09 Feb, 2020 1 commit
  8. 05 Feb, 2020 1 commit
  9. 31 Jan, 2020 1 commit
    • Michel Dänzer's avatar
      xwayland/glamor-gbm: Add xwl_glamor_gbm_post_damage hook · 9e85aa9c
      Michel Dänzer authored and Michel Dänzer's avatar Michel Dänzer committed
      It flushes any pending drawing to the kernel, to make sure it'll be
      visible to the Wayland server.
      Without this, it was possible for the Wayland server to process surface
      commits before Xwayland got around to flushing the corresponding
      drawing, which could result in stale or even completely random window
      contents being visible.
      * Make EGL backend post_damage hook mandatory, don't check for NULL in
        xwl_glamor_post_damage. (Olivier Fourdan)
      Closes: xorg/xserver#951
      Reviewed-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
  10. 30 Jan, 2020 1 commit
  11. 29 Jan, 2020 1 commit
  12. 28 Jan, 2020 5 commits
    • Michel Dänzer's avatar
      gitlab-ci: Enable -Werror in the meson build job · b6a5389e
      Michel Dänzer authored and Peter Hutterer's avatar Peter Hutterer committed
      There are no warnings left, so let's prevent new ones from creeping
      back in.
    • Michel Dänzer's avatar
      tests/misc: Drop redundant screenInfo declaration · 794fd7e5
      Michel Dänzer authored and Peter Hutterer's avatar Peter Hutterer committed
      GCC warned about it:
      ../test/misc.c:36:19: warning: redundant redeclaration of ‘screenInfo’ [-Wredundant-decls]
         36 | extern ScreenInfo screenInfo;
            |                   ^~~~~~~~~~
      In file included from ../test/misc.c:30:
      ../include/scrnintstr.h:688:29: note: previous declaration of ‘screenInfo’ was here
        688 | extern _X_EXPORT ScreenInfo screenInfo;
            |                             ^~~~~~~~~~
    • Michel Dänzer's avatar
      Xephyr: Cast "red" to char* for xcb_aux_parse_color · 42876044
      Michel Dänzer authored and Peter Hutterer's avatar Peter Hutterer committed
      xcb_aux_parse_color takes a non-const pointer, even though it doesn't
      modify the string or take ownership of its memory.
      Avoids the following warning from GCC:
      ../hw/kdrive/ephyr/hostx.c: In function ‘hostx_init’:
      ../hw/kdrive/ephyr/hostx.c:683:30: warning: passing argument 1 of ‘xcb_aux_parse_color’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
        683 |     if (!xcb_aux_parse_color("red", &red, &green, &blue)) {
            |                              ^~~~~
      In file included from ../hw/kdrive/ephyr/hostx.c:50:
      /usr/include/xcb/xcb_aux.h:194:27: note: expected ‘char *’ but argument is of type ‘const char *’
        194 | xcb_aux_parse_color(char *color_name,
            |                     ~~~~~~^~~~~~~~~~
    • Michel Dänzer's avatar
      loader: strdup const string assigned to local variable name · 65387391
      Michel Dänzer authored and Peter Hutterer's avatar Peter Hutterer committed
      There's a free(name) at the end of the function.
      GCC warned about this:
      ../hw/xfree86/loader/loadmod.c: In function ‘LoadModule’:
      ../hw/xfree86/loader/loadmod.c:702:18: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
        702 |         m = name = "int10";
            |                  ^
    • Adam Jackson's avatar
      Revert "dri2: Don't make reference to noClientException" · e1fa3beb
      Adam Jackson authored
      It's true that the value would always be -1, if it's not zero, but it's
      usually zero is the problem. As a result we return failure from
      otherwise successful indirect GLX paths, which isn't very nice of us.
      This reverts commit 7d33ab0f.
      Fixes: xorg/xserver#211
  13. 27 Jan, 2020 2 commits
  14. 15 Jan, 2020 1 commit
  15. 14 Jan, 2020 2 commits
  16. 08 Jan, 2020 2 commits
    • Fabrice Fontaine's avatar
      hw/xfree86/common/xf86Init.c: fix build without glx · 49456e0a
      Fabrice Fontaine authored and Adam Jackson's avatar Adam Jackson committed
      Since commit d8ec33fe, an include on
      glxvndabi.h has been added to hw/xfree86/common/xf86Init.c
      However, if glx is disabled through --disable-glx and GLX headers are
      not installed in the build's environment, build fails on:
      In file included from xf86Init.c:81:
      ../../../include/glxvndabi.h:64:10: fatal error: GL/glxproto.h: No such file or directory
         64 | #include <GL/glxproto.h>
            |          ^~~~~~~~~~~~~~~
      Fix this failure by removing this include which does not seem to be
      needed (an other option would have been to keep it under an ifdef GLXEXT
       - http://autobuild.buildroot.org/results/de838a843f97673d1381a55fd4e9b07164693913
      Signed-off-by: Fabrice Fontaine's avatarFabrice Fontaine <fontaine.fabrice@gmail.com>
    • Lubomir Rintel's avatar
      glamor_egl: Reject OpenGL < 2.1 early on · 26004df6
      Lubomir Rintel authored and Adam Jackson's avatar Adam Jackson committed
      The Etnaviv driver on GC2000 reports desktop OpenGL 1.3 but also OpenGL ES 2.0.
      However, with the modesetting driver, GLES2 never gets a chance:
        [ 11233.393] Require OpenGL version 2.1 or later.
        [ 11233.393] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time.
        [ 11233.393] (EE)
        Fatal server error:
        [ 11233.395] (EE) AddScreen/ScreenInit failed for driver 0
      Let's reject old desktop GL early on, just like XWayland seems to do.
      This is perhaps a slightly bit more complicated that one would expect, since we
      need to call eglMakeCurrent() before we query the GL version.
      Signed-off-by: Lubomir Rintel's avatarLubomir Rintel <lkundrak@v3.sk>
  17. 06 Jan, 2020 5 commits