Allow to upload the CbCr plane of an NV12 image into a GL texture.
Signed-off-by: Julien Isorce <jisorce@oblong.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
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 <ofourdan@redhat.com>
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 <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
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 <ofourdan@redhat.com>
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 <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107314
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
With a patch to mesa to expose rgb565 pbuffers even on a server with
only depth 24 and 32 visuals, fixes
dEQP-EGL.functional.render.single_context.gles2.rgb565_pbuffer. Those
pbuffers (or at least something renderable with 565) are required by
the current CTS for GLES3, and having the server support DRI3 on those
pixmaps means that we can avoid having a different path for EGL
pbuffers compared to pixmaps.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
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 <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add internal.h to SOURCES, omitted from 126c1cfa
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This prevents multiple scroll events happening for wayland compositors
which send axis values other than 10. For example, libinput will
typically return 15 for each scroll wheel step, and if a wayland
compositor sends those to xwayland without normalising them, 2 scroll
wheel steps will end up as 3 xorg scroll events. By listening for the
discrete_axis event, this will now correctly send only 2 xorg scroll
events.
The wayland protocol gurantees that there will always be an axis event
following an axis_discrete event. However, it does not gurantee that
other events (including other axis_discrete+axis pairs) will not happen
in between them. So we must keep a list of outstanding axis_discrete
events.
Signed-off-by: Scott Anderson <scott@anderso.nz>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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: Jim Qu <Jim.Qu@amd.com>
Reviewed-by: Alex Goins <agoins@nvidia.com>
Dependencies are ported from the automake build.
v2: Make it a tristate defaulting to 'auto'. Use pkg-config for libaudit.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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 <agoins@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The client ID is only needed for XRes, and autotools build ignores the
--clientids= arg if xres is disabled. We haven't made a meson option
for disabling tracking client ids (is it actually worth a build
option?), so just make this depend on xres.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes us match the featureset of autotools, and also fixes the
non-Linux default value to match.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is silly to have optional based on detection of the protocol
headers, particularly now that we have a single protocol header repo
to install.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Not sure what if anything calls XSetDeviceModifierMapping() but this would've
failed all the time. check_modmap_change() returns Success but we were
treating it like a boolean. Fix this.
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
I don't have a BSD to test on, but this should do the same as what
autotools did.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have pm_noop.c being built most of the time for the
no-OS-PM case, so just switch to always using it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
CONFIG_UDEV and CONFIG_UDEV_KMS are the actual defines that are used
in the C code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The SCM_RIGHTS flag seems to be the thing that xtrans depends on, and
meson makes the check easy without needing a build option.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is already included in ephyr (the only kdrive server left)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of having every video driver loop over any pending leases to
free them during CloseScreen, do this up in the DIX layer by
terminating leases when a leased CRTC or Output is destroyed and
(just to make sure), also terminating leases in RRCloseScreen. The
latter should "never" get invoked as any lease should be associated
with a resource which was destroyed.
This is required as by the time the driver's CloseScreen function is
invoked, we've already freed all of the DIX randr structures and no
longer have any way to reference the leases
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
Cc: Thomas Hellstrom <thellstrom@vmware.com>
The recent rewrite of modesetting driver broke the 24bpp support.
As typically found on cirrus KMS, it leads to a blank screen, spewing
the error like:
failed to add fb -22
(EE) modeset(0): failed to set mode: Invalid argument
The culript is that the wrong bpp value of the front buffer is passed
to drmModeAddFB(). Fix it by replacing with the back buffer bpp,
drmmode->kbpp.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor_fds_from_pixmap() will bail out early if DRI3 is not enabled,
unfortunately Xwayland's glamor code would not set it as enabled which
would lead to blank pixmaps when using texture from pixmap.
Make sure to mark DRI3 as enabled from glamor_egl_screen_init() in
Xwayland.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107287
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The logical size is the size of the output in the global compositor
space. The mode width/height should be scaled as in the logical
size, but shouldn't be transformed. Thus we need to rotate back
the logical size to be able to use it as the mode width/height.
This fixes issues with pointer input on transformed outputs.
Signed-Off-By: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Control flow is:
PanoramiXMaybeAddDepth() allocates an array size 240 (pDepth->numVisuals)
PanoramiXMaybeAddVisual() finds up to 270 matches (pScreen->numVisuals)
and writes those into the previously allocated array.
This caused invalid reads/writes followed by eventually a double-free abort.
Reproduced with xorg-integration-tests server test
XineramaTest.ScreenCrossing/* (and a bunch of others).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
When setting DefaultDepth to 16 in the Screen section, the current
code requests a 32 bpp framebuffer, however the X-Server seems to
assumes 16 bpp.
Fixes commit 21217d0216 ("modesetting: Implement 32->24 bpp
conversion in shadow update")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Currently our meson.build just makes the assumption that the libc is
going to provide RPC functions. This doesn't actually seem to be the
case on Fedora, which causes compilation to fail unexpectedly:
../../Projects/xserver/os/rpcauth.c:47:10: fatal error: rpc/rpc.h: No such file or directory
#include <rpc/rpc.h>
^~~~~~~~~~~
compilation terminated.
So, in the event that we can't use libtirpc ensure that we actually
check whether or not the libc provides rpc/rpc.h. If it doesn't, raise
an error.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
If we're using atomic modesetting, then we're also using universal
planes, and so the lease we create needs to include the plane.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We don't want universal_planes unless we're using atomic APIs for
modesetting, and the kernel already enables universal_planes
automatically when atomic is enabled.
If we enable universal_planes when we're not using atomic, then we
won't have selected a plane for each crtc, and this will break lease
creation which requires planes for each output when universal_planes
is enabled.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The DIX crtc and output structures are freed when their resources are
destroyed, which happens before CloseScreen is called. As a result, we
know these pointers are invalid and referencing them during any of the
remaining CloseScreen sequence will be bad.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: thellstrom@vmware.com
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
paths returned by get_option('foodir') are potentially relative to prefix
Noticed when comparing manpages generated by a meson build with those
generated by an autotools build
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This lets an application open a suitable DRM device and pass the file
descriptor to the mode setting driver through an X server command line
option, '-masterfd'.
There's a companion application, xlease, which creates a DRM master by
leasing an output from another X server. That is available at
git clone git://people.freedesktop.org/~keithp/xlease
v2:
Always print usage, but note that it can't be used if
setuid/gid
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
KMS drivers are not required to support GEM. In particular, vmwgfx
doesn't support flink and handles and names are identical.
Getting a bo name should really be part of a lower level API, if needed,
but in the mean time work around this by setting the name identical to
the handle if GEM isn't supported.
This fixes modesetting driver dri2 on vmwgfx.
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
