1. 11 Sep, 2018 5 commits
  2. 10 Sep, 2018 6 commits
    • Adam Jackson's avatar
    • Adam Jackson's avatar
      modesetting: Lie less in the man page · 0dc2c419
      Adam Jackson authored
      We don't support 8bpp, and we do have acceleration.
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      0dc2c419
    • Olivier Fourdan's avatar
      xwayland: Remove xwl_present_window from privates on cleanup · 3f31f569
      Olivier Fourdan authored
      Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()`
      before the common `DestroyWindow()`.
      
      But then `DestroyWindow()` calls `present_destroy_window()` which will
      possibly end up in `xwl_present_abort_vblank()` which will try to access
      data that was previously freed by `xwl_present_cleanup()`:
      
        Invalid read of size 8
           at 0x434184: xwl_present_abort_vblank (xwayland-present.c:378)
           by 0x53785B: present_wnmd_abort_vblank (present_wnmd.c:651)
           by 0x53695A: present_free_window_vblank (present_screen.c:87)
           by 0x53695A: present_destroy_window (present_screen.c:152)
           by 0x42A90D: xwl_destroy_window (xwayland.c:653)
           by 0x584298: compDestroyWindow (compwindow.c:613)
           by 0x53CEE3: damageDestroyWindow (damage.c:1570)
           by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326)
           by 0x46F7F6: FreeWindowResources (window.c:1031)
           by 0x472847: DeleteWindow (window.c:1099)
           by 0x46B54C: doFreeResource (resource.c:880)
           by 0x46C706: FreeClientResources (resource.c:1146)
           by 0x446ADE: CloseDownClient (dispatch.c:3473)
         Address 0x182abde0 is 80 bytes inside a block of size 112 free'd
           at 0x4C2FDAC: free (vg_replace_malloc.c:530)
           by 0x42A937: xwl_destroy_window (xwayland.c:647)
           by 0x584298: compDestroyWindow (compwindow.c:613)
           by 0x53CEE3: damageDestroyWindow (damage.c:1570)
           by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326)
           by 0x46F7F6: FreeWindowResources (window.c:1031)
           by 0x472847: DeleteWindow (window.c:1099)
           by 0x46B54C: doFreeResource (resource.c:880)
           by 0x46C706: FreeClientResources (resource.c:1146)
           by 0x446ADE: CloseDownClient (dispatch.c:3473)
           by 0x446DA5: ProcKillClient (dispatch.c:3279)
           by 0x4476AF: Dispatch (dispatch.c:479)
         Block was alloc'd at
           at 0x4C30B06: calloc (vg_replace_malloc.c:711)
           by 0x433F46: xwl_present_window_get_priv (xwayland-present.c:54)
           by 0x434228: xwl_present_get_crtc (xwayland-present.c:302)
           by 0x539728: proc_present_query_capabilities (present_request.c:227)
           by 0x4476AF: Dispatch (dispatch.c:479)
           by 0x44B5B5: dix_main (main.c:276)
           by 0x75F611A: (below main) (libc-start.c:308)
      
      This is because `xwl_present_cleanup()` frees the memory but does not
      remove it from the window's privates, and `xwl_present_abort_vblank()`
      will still find it and hence try to access that freed memory...
      
      Remove `xwl_present_window` from window's privates on cleanup so that no
      other function can find and reuse that data once it's freed.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      3f31f569
    • Lionel Landwerlin's avatar
      xwayland: fix access to invalid pointer · 53ce2ba0
      Lionel Landwerlin authored
      xwl_output->randr_crtc is used in the update_screen_size() function :
      
      ==5331== Invalid read of size 4
      ==5331==    at 0x15263D: update_screen_size (xwayland-output.c:190)
      ==5331==    by 0x152C48: xwl_output_remove (xwayland-output.c:413)
      ==5331==    by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x14BCCA: xwl_read_events (xwayland.c:814)
      ==5331==    by 0x2AC0D0: ospoll_wait (ospoll.c:651)
      ==5331==    by 0x2A5322: WaitForSomething (WaitFor.c:208)
      ==5331==    by 0x27574B: Dispatch (dispatch.c:421)
      ==5331==    by 0x279945: dix_main (main.c:276)
      ==5331==  Address 0x1aacb5f4 is 36 bytes inside a block of size 154 free'd
      ==5331==    at 0x48369EB: free (vg_replace_malloc.c:530)
      ==5331==    by 0x1F8AE8: RROutputDestroyResource (rroutput.c:421)
      ==5331==    by 0x29A2AC: doFreeResource (resource.c:880)
      ==5331==    by 0x29AE5B: FreeResource (resource.c:910)
      ==5331==    by 0x152BE0: xwl_output_remove (xwayland-output.c:408)
      ==5331==    by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x14BCCA: xwl_read_events (xwayland.c:814)
      ==5331==    by 0x2AC0D0: ospoll_wait (ospoll.c:651)
      ==5331==  Block was alloc'd at
      ==5331==    at 0x48357BF: malloc (vg_replace_malloc.c:299)
      ==5331==    by 0x1F93E0: RROutputCreate (rroutput.c:83)
      ==5331==    by 0x152A75: xwl_output_create (xwayland-output.c:361)
      ==5331==    by 0x14BE59: registry_global (xwayland.c:764)
      ==5331==    by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x14BCCA: xwl_read_events (xwayland.c:814)
      ==5331==    by 0x2AC0D0: ospoll_wait (ospoll.c:651)
      ==5331==    by 0x2A5322: WaitForSomething (WaitFor.c:208)
      Signed-off-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      53ce2ba0
    • Olivier Fourdan's avatar
      glx: check for indirect context in CreateContextAttribsARB() · 75448671
      Olivier Fourdan authored
      Commit 99f0365b "Add a command line argument for disabling indirect GLX"
      added a test to check if indirect context are enabled in
      `DoCreateContext()` but `__glXDisp_CreateContextAttribsARB()` doesn't
      use `DoCreateContext()` and doesn't check if indirect context is
      enabled.
      
      As a result, clients can still manage to create indirect contexts using
      `glXCreateContextAttribsARB()` even if indirect contexts are disabled,
      which can possibly crash Xservers such as Xwayland or Xephyr when the
      context is destroyed.
      
      To avoid the issue, check for `enableIndirectGLX` in
      `__glXDisp_CreateContextAttribsARB()` as well.
      
      Fixes: 99f0365b "Add a command line argument for disabling indirect GLX"
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107508Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      75448671
    • Lionel Landwerlin's avatar
      present: fix freed pointer access · ce271535
      Lionel Landwerlin authored
      When a vblank has been marked as aborted, it's going to be free in the
      flip_notify function when stopped. We can't notify it after it's
      stopped because the pointer is invalid.
      
      Valgrind backtrace:
      
      ==5331== Invalid read of size 8
      ==5331==    at 0x212B4D: present_vblank_notify (present_vblank.c:34)
      ==5331==    by 0x21439B: present_wnmd_flip_notify (present_wnmd.c:194)
      ==5331==    by 0x21439B: present_wnmd_event_notify (present_wnmd.c:228)
      ==5331==    by 0x156216: xwl_present_sync_callback (xwayland-present.c:282)
      ==5331==    by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
      ==5331==    by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5331==    by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
      ==5...
      ce271535
  3. 07 Sep, 2018 1 commit
  4. 06 Sep, 2018 1 commit
    • Lyude Paul's avatar
      meson: Fix building with -Ddga=false · b84e7f1c
      Lyude Paul authored
      We forget to assign a value to xf86dgaproto_dep if -Ddga=false, which
      causes the meson build to fail:
      
      meson.build:448:0: ERROR:  Unknown variable "xf86dgaproto_dep".
      
      A full log can be found at /home/lyudess/build/xserver/meson-logs/meson-log.txt
      FAILED: build.ninja
      
      So, just set it to an empty dependency to fix that.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      b84e7f1c
  5. 30 Aug, 2018 2 commits
  6. 29 Aug, 2018 1 commit
    • Jim Qu's avatar
      modesetting: code refactor for PRIME sync · f79e5368
      Jim Qu authored
      The X will be crashed on the system with other DDX driver,
      such as amdgpu.
      
      show the log like:
      
      randr: falling back to unsynchronized pixmap sharing
      (EE)
      (EE) Backtrace:
      (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e)
      (EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9)
      (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390)
      (EE)
      (EE) Segmentation fault at address 0x0
      (EE)
      
      The issue is that modesetting as the master, and amdgpu as the slave.
      Thus, when the master attempts to access pSlavePixPriv in ms_dirty_update(),
      problems result due to the fact that it's accessing AMD's 'ppriv' using the
      modesetting structure definition.
      
      Apart from fixing crash issue, the patch fix other issue in master interface
      in which driver should refer to master pixmap.
      Signed-off-by: default avatarJim Qu <Jim.Qu@amd.com>
      Reviewed-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      f79e5368
  7. 28 Aug, 2018 1 commit
  8. 24 Aug, 2018 1 commit
    • Alex Goins's avatar
      randr: rrCheckPixmapBounding should only increase screen size · a90f3372
      Alex Goins authored
      The purpose of rrCheckPixmapBounding() is to make sure that the fb is large
      enough to accommodate the region scanned out by a GPU screen. Currently, however,
      it will actually shrink the fb if it's larger than it needs to be.
      
      This is a problem when combining PRIME output slaving with arbitrary transforms
      with xrandr.
      
      Although arbitrary transforms are not supposed to constrain the size of the fb
      (https://lists.freedesktop.org/archives/xorg-devel/2018-January/055563.html),
      xrandr will use RRSetScreenSize to resize the desktop to accommodate scaling
      transforms, e.g. scaling a 1920x1080 display to 3840x2160 will result in a
      desktop size of 3840x2160.
      
      In the case of PRIME, rrCheckPixmapBounding() will be called after
      RRSetScreenSize() and it will resize the fb back down to what it would be
      without the scaling transform, e.g. 1920x1080. This represents divergence in
      behavior between PRIME and non-PRIME outputs.
      
      I had originally made rrCheckPixmapB...
      a90f3372
  9. 09 Aug, 2018 10 commits
  10. 08 Aug, 2018 1 commit
  11. 02 Aug, 2018 7 commits
  12. 25 Jul, 2018 3 commits
  13. 19 Jul, 2018 1 commit