Skip to content

GitLab

Switch branch/tag
  1. 23 Feb, 2020 2 commits
  3. 18 Feb, 2020 5 commits
  5. 14 Feb, 2020 1 commit
  7. 12 Feb, 2020 2 commits
    • Adam Jackson's avatar
      meson: Add support for libunwind · ee9f6e20
      Adam Jackson authored
      ee9f6e20
    • 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"
EndSection

...

Section "Device"
        Identifier      "Intel2"
        Driver          "intel"
        BusID           "PCI:0:2:0"
        Screen          2
        Option          "Monitor-HDMI1" "HDMI1"
        Option          "ZaphodHeads" "HDMI1"
EndSection

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"
EndSection

...

Section "Screen"
        Identifier      "SCREEN2"
        Option          "AutoServerLayout" "on"
        Device          "UDL"
        GPUDevice       "Intel2"
        Monitor         "Monitor-DVI-I-1"
        SubSection      "Display"
                Modes   "1024x768"
                Depth   24
        EndSubSection
EndSection

Section "ServerLayout"
        Identifier      "LAYOUT"
        Option          "AutoServerLayout" "on"
        Screen          0 "SCREEN"
        Screen          1 "SCREEN1" RightOf "SCREEN"
        Screen          2 "SCREEN2" RightOf "SCREEN1"
EndSection

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
specified.

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>
      42aaf372
  9. 11 Feb, 2020 6 commits
  11. 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
                     LoaderSymbol"
Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      0cb9fa79
    • 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
xorg/xserver#910.

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>
      bfb36a58
  13. 09 Feb, 2020 1 commit
  15. 05 Feb, 2020 1 commit
  17. 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.

v2:
* 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>
      9e85aa9c
  19. 30 Jan, 2020 1 commit
  21. 29 Jan, 2020 1 commit
  23. 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.
      b6a5389e
    • 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;
      |                             ^~~~~~~~~~
      794fd7e5
    • 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,
      |                     ~~~~~~^~~~~~~~~~
      42876044
    • 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";
      |                  ^
      65387391
    • 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
      e1fa3beb
  25. 27 Jan, 2020 2 commits
  27. 15 Jan, 2020 1 commit
  29. 14 Jan, 2020 2 commits
  31. 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
block)

Fixes:
 - http://autobuild.buildroot.org/results/de838a843f97673d1381a55fd4e9b07164693913

Signed-off-by: Fabrice Fontaine's avatarFabrice Fontaine <fontaine.fabrice@gmail.com>
      49456e0a
    • 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>
      26004df6
  33. 06 Jan, 2020 5 commits