1. 27 Jan, 2020 2 commits
  2. 15 Jan, 2020 1 commit
  3. 14 Jan, 2020 2 commits
  4. 08 Jan, 2020 2 commits
    • Fabrice Fontaine's avatar
      hw/xfree86/common/xf86Init.c: fix build without glx · 49456e0a
      Fabrice Fontaine authored
      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/de838a843f97673d1381a55fd4e9b07164693913Signed-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
      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
  5. 06 Jan, 2020 6 commits
  6. 03 Jan, 2020 1 commit
    • Aaron Plattner's avatar
      modesetting: Check whether RandR was initialized before calling rrGetScrPriv · 4226c6d0
      Aaron Plattner authored
      Calling rrGetScrPriv when RandR isn't initialized causes an assertion
      failure that aborts the server:
      
       Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.
      
       Thread 1 "Xorg" received signal SIGABRT, Aborted.
       0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
       (gdb) bt
       #0  0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
       #1  0x00007ffff7892897 in abort () from /usr/lib/libc.so.6
       #2  0x00007ffff7892767 in __assert_fail_base.cold () from /usr/lib/libc.so.6
       #3  0x00007ffff78a1526 in __assert_fail () from /usr/lib/libc.so.6
       #4  0x00007ffff7fb57c1 in dixGetPrivateAddr (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:121
       #5  0x00007ffff7fb5822 in dixGetPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:136
       #6  0x00007ffff7fb586a in dixLookupPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:166
       #7  0x00007ffff7fb8445 in CreateScreenResources (pScreen=0x555555ab1790) at ../hw/xfree86/drivers/modesetting/driver.c:1335
       #8  0x000055555576c5e4 in xf86CrtcCreateScreenResources (screen=0x555555ab1790) at ../hw/xfree86/modes/xf86Crtc.c:744
       #9  0x00005555555d8bb6 in dix_main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/main.c:214
       #10 0x00005555557a4f0b in main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/stubmain.c:34
      
      This can happen, for example, if the server is configured with Xinerama
      and there is more than one X screen:
      
       Section "ServerLayout"
         Identifier "crash"
         Screen 0 "modesetting"
         Screen 1 "dummy" RightOf "modesetting"
         Option "Xinerama"
       EndSection
      
       Section "Device"
         Identifier "modesetting"
         Driver "modesetting"
       EndSection
      
       Section "Screen"
         Identifier "modesetting"
         Device "modesetting"
       EndSection
      
       Section "Device"
         Identifier "dummy"
         Driver "dummy"
       EndSection
      
       Section "Screen"
         Identifier "dummy"
         Device "dummy"
       EndSection
      
      The problem does not reproduce if there is only one X screen because of
      this code in xf86RandR12Init:
      
       #ifdef PANORAMIX
           /* XXX disable RandR when using Xinerama */
           if (!noPanoramiXExtension) {
               if (xf86NumScreens == 1)
                   noPanoramiXExtension = TRUE;
               else
                   return TRUE;
           }
       #endif
      
      Fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before
      calling rrGetScrPriv. This is similar to what the xf86-video-amdgpu
      driver does:
      https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/blob/fd66f5c0bea2b7c22a47bfd5eb1f22d32d166d9c/src/amdgpu_kms.c#L388Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      4226c6d0
  7. 23 Dec, 2019 3 commits
  8. 20 Dec, 2019 16 commits
  9. 19 Dec, 2019 1 commit
    • Michel Dänzer's avatar
      xwayland: Create duplicate TrueColor GLXFBConfigs for Composite · 846e81ec
      Michel Dänzer authored
      Similar to what is done in Xorg. Not doing this prevented apps from
      using GLX with a Composite visual, e.g. Firefox WebRender or Chromium.
      
      v2:
      * Fix inverted direct_color test, fixes Chromium as well.
      * Drop Composite extension guards, since other Xwayland code calls
        compRedirectWindow/compUnredirectWindow unconditionally anyway.
      
      Closes: xorg/xserver#921
      Fixes: 84692415 "xwayland: Add EGL-backed GLX provider"
      Reviewed-by: Adam Jackson <ajax@redhat.com> # v1
      846e81ec
  10. 17 Dec, 2019 3 commits
  11. 13 Dec, 2019 3 commits