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 and Adam Jackson's avatar Adam Jackson committed
      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=1616269
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      3f31f569
    • Lionel Landwerlin's avatar
      xwayland: fix access to invalid pointer · 53ce2ba0
      Lionel Landwerlin authored and Adam Jackson's avatar Adam Jackson committed
      
      
      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 and Adam Jackson's avatar Adam Jackson committed
      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=107508
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      75448671
    • Lionel Landwerlin's avatar
      present: fix freed pointer access · ce271535
      Lionel Landwerlin authored and Adam Jackson's avatar Adam Jackson committed
      
      
      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)
      ==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==  Address 0x1b44dc98 is 40 bytes inside a block of size 184 free'd
      ==5331==    at 0x48369EB: free (vg_replace_malloc.c:530)
      ==5331==    by 0x213B0A: present_wnmd_free_idle_vblanks (present_wnmd.c:118)
      ==5331==    by 0x213B0A: present_wnmd_flips_stop (present_wnmd.c:161)
      ==5331==    by 0x2143EF: present_wnmd_flip_notify (present_wnmd.c:192)
      ==5331==    by 0x2143EF: 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)
      ==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==  Block was alloc'd at
      ==5331==    at 0x48377D5: calloc (vg_replace_malloc.c:711)
      ==5331==    by 0x212D9F: present_vblank_create (present_vblank.c:69)
      ==5331==    by 0x214014: present_wnmd_pixmap (present_wnmd.c:610)
      ==5331==    by 0x21576C: proc_present_pixmap (present_request.c:150)
      ==5331==    by 0x27599D: Dispatch (dispatch.c:479)
      ==5331==    by 0x279945: dix_main (main.c:276)
      ==5331==    by 0x633AB16: (below main) (libc-start.c:310)
      
      v2: Still notify aborted flips (Roman)
      Signed-off-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107314
      
      Reviewed-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      Tested-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      ce271535
  3. 07 Sep, 2018 1 commit
  4. 06 Sep, 2018 1 commit
  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 and Michel Dänzer's avatar Michel Dänzer committed
      
      
      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 and Michel Dänzer's avatar Michel Dänzer committed
      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 rrCheckPixmapBounding() account for arbitrary transforms,
      but realized that the fb being large enough to accommodate arbitrary transforms
      is not a hard requirement enforced in the server. Instead, this change simply
      makes it so that rrCheckPixmapBounding() will only resize the fb to be larger
      than it already is, preventing it from stepping on prior requests to increase
      the size of the fb.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      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