modesetting: Fix damage tracking auto-disable code

dispatch_dirty_region was only returning -EINVAL error codes,
otherwise it would return 0. The kernel returns -ENOSYS when the
driver doesn't support damage tracking, so dispatch_dirty would never
see the error and never disable damage tracking.

Pass all errors back from dispatch_dirty_region and let dispatch_dirty
deal with them.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
modesetting: Detect whether damage tracking is needed

Call drmModeDirtyFB and check the return value to detect whether the
driver support for damage tracking is present, only initialize it in
that case.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
glamor: Call glamor_pixmap_destroy_fbo from glamor_set_pixmap_private

Calling glamor_purge_fbo directly was incorrect for large pixmaps.

Fixes use-after free with large pixmaps:

==2029== Invalid write of size 8                                                                                                                                      ~
==2029==    at 0x85F93AD: __xorg_list_del (list.h:184)
==2029==    by 0x85F93AD: xorg_list_del (list.h:204)
==2029==    by 0x85F93AD: glamor_fbo_expire (glamor_fbo.c:280)
==2029==    by 0x85F95CA: glamor_pixmap_fbo_cache_put (glamor_fbo.c:159)
==2029==    by 0x85D7AB5: glamor_destroy_textured_pixmap (glamor.c:228)
==2029==    by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029==    by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029==    by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029==    by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029==    by 0x5098F6: FreePicture (picture.c:1425)
==2029==    by 0x85E678E: glamor_composite_clipped_region (glamor_render.c:1558)
==2029==    by 0x85F763A: glamor_composite_largepixmap_region (glamor_largepixmap.c:1347)
==2029==    by 0x85E7964: _glamor_composite (glamor_render.c:1679)
==2029==    by 0x85E7A38: glamor_composite (glamor_render.c:1758)
==2029==  Address 0x1141d3c0 is 0 bytes inside a block of size 64 free'd
==2029==    at 0x4C29E90: free (vg_replace_malloc.c:473)
==2029==    by 0x85D7167: glamor_set_pixmap_private (glamor.c:570)
==2029==    by 0xC1BDDC4: radeon_glamor_destroy_pixmap (radeon_glamor.c:272)
==2029==    by 0x519D00: damageDestroyPixmap (damage.c:1473)
==2029==    by 0x4DD307: XvDestroyPixmap (xvmain.c:370)
==2029==    by 0x4DB975: ShmDestroyPixmap (shm.c:258)
==2029==    by 0x45B246: doFreeResource (resource.c:875)
==2029==    by 0x45BD5E: FreeResource (resource.c:905)
==2029==    by 0x43444B: ProcFreePixmap (dispatch.c:1422)
==2029==    by 0x43856E: Dispatch (dispatch.c:432)
==2029==    by 0x43C96F: dix_main (main.c:298)
==2029==    by 0x6CFAB44: (below main) (libc-start.c:287)

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
glamor: Make glamor_purge_fbo static

Only called from glamor_fbo.c now.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
glamor: Make sure Xvideo source image data is properly aligned

_glamor_upload_bits_to_pixmap_texture currently ignores the stride
parameter, but __glamor_upload_pixmap_to_texture uses 4-byte alignment
via glPixelStorei(GL_UNPACK_ALIGNMENT, 4).

Also fix up the stride argument passed in though, in case it starts
being used properly in the future.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87455
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fix "Back", "Forward", and other special mouse buttons in XWayland.

Currently, the indexes are off by 4 because of the scroll buttons.

Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
present: If present_queue_vblank() fails, do present_execute().

Previously, if present_queue_vblank() failed, we simply dropped the
present request on the floor, and returned an error.  This was rather
mean to clients - after presenting, they wait for a PresentComplete
event to come back.  But since the present never happens, they end up
waiting forever, and lock up in poll().

This patch falls back to present_execute if present_queue_vblank fails.
We still print a debugging message to warn when queueing fails, which
allows us to continue debugging problems, but makes Present robust
enough to not lock up people's compositing manager when vblank bugs
happen.

v2: Don't do present_queue_vblank() /and/ present_execute() (a bug that
    snuck in during last minute tidying).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
modesetting: Track the CRTC's DPMS mode.

We don't want to try to vblank synchronize to monitors which are off.

In order to handle that properly, we need to know the CRTC's DPMS mode.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
modesetting: Check DPMS mode in ms_covering_crtc().

crtc->enabled is insufficient; we should also make sure DPMS is on.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
modesetting: Include glamor.h from driver.h.

We basically want it throughout the driver.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
modesetting: Add vblank synchronization support when using Present.

modesetting hooked up vblank support for DRI2, but was missing support
for vblanks in Present.

This is mostly copy and pasted from Keith's code in the intel driver.

v2: Use ms_crtc_msc_to_kernel_msc in ms_present_queue_vblank to hook
    up the vblank_offset workaround for bogus MSC values (which the
    DRI2 code already did).

    Also simplify the ms_present_get_crtc function.  vblank.c already
    implements the functionality; we just need to convert types.

v3: Fix ms_flush_drm_events return code.  I'd copied code where 0 meant
    success into a function that returned a boolean, so the return code
    was always backwards.

    Also add DebugPresent calls in ms_present_vblank_{handler,abort}.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>