When creating a cursor with GBM_BO_USE_CURSOR{_64x64} and a dimension of 64 by 64 pixel the operation succeeds and the returned stride size is always 256. When drawing the cursor buffer and displaying on screen graphical artifacts appear. Instead of 128 bytes a stride size of 512 seems to be correct on Kaveri systems. For this particular scenario there is a workaround: query 'an arbitrary but valid cursor buffer size' with DRM_CAP_CURSOR_WIDTH DRM_CAP_CURSOR_HEIGHT. Still gbm_bo_get_stride should not return a wrong stride size.
You need to pass the dimensions queried from DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT instead of hardcoding 64. As of CIK, Radeon hardware only supports 256x256 hardware cursors.
(In reply to Michel Dänzer from comment #1) > You need to pass the dimensions queried from DRM_CAP_CURSOR_WIDTH and > DRM_CAP_CURSOR_HEIGHT instead of hardcoding 64. As of CIK, Radeon hardware > only supports 256x256 hardware cursors. Yes, but since buffer creation with a smaller size does not fail, gbm_bo_get_stride should return the right size.
(In reply to Andreas Pokorny from comment #2) > Yes, but since buffer creation with a smaller size does not fail, > gbm_bo_get_stride should return the right size. It returns the stride of the allocated buffer. The problem is that the buffer size doesn't match the hardware cursor size in the first place. Returning a different stride can't change that.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.