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>
When support for allocating GBM BOs with modifiers was added,
glamor_fd_from_pixmap() was changed so that it would return an error if
it got a bo with modifiers set from glamor_fds_from_pixmap(). The
problem is that on systems that support BOs with modifiers,
glamor_fds_from_pixmap() will always return BOs with modifiers.
This means that glamor_fd_from_pixmap() was broken entirely, which broke
a number of other things including glamor_shareable_fd_from_pixmap(),
which meant that modesetting using multiple GPUs with the modesetting
DDX was also broken. Easy reproducer:
- Find a laptop with DRI prime that has outputs connected to the
dedicated GPU and integrated GPU
- Try to enable one display on each using the modesetting DDX
- Fail
Since there isn't a way to ask for no modifiers from
glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
function used by both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
This was left disabled in 1.20.0, it's time to start being sure it
works.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniels@collabora.com>
We were mixing stdint and CARD* types, causing compiler warnings on
32-bit. Just switch over to stdint, which is what we'd like the server
to be using long term, anyway.
Reviewed-by: Adam Jackson <ajax@redhat.com>
If dmabuf_capable is false, because the server "dmabuf_capable"
debug flag isn't set, treat it as successfull query with zero
returned formats, instead of failure.
This allows the servers cache_formats_and_modifiers() function
to cache the fact that formats are not supported during the
current server generation, instead of pointless retesting at
every invocation.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
It makes it perfectly clear that we should not be modifying them.
Should help highlight issues like the one fixed with previous commit.
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
dri3_screen_info is the user provide dispatch. Something that we do
not and should not change.
When using the _ptr typecast + const the compiler barfs at us
(rightfully so), so use the _rec one.
[Silence a new const mismatch warning too - ajax]
Fixes: 5631382988 ("dri3: Add DRI3 extension")
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Add a fd_from_pixmap (singular) hook to go with fds_from_pixmap, which
will ensure that the pixmap is allocated without modifiers and is thus
exportable to non-modifier-aware clients.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If we try to allocate with particular modifiers but it fails, try to
fall back to non-modifier allocations.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If we need a pixmap's storage to be exported to a context in which we
aren't aware of modifiers, reallocate the buffer again without
modifiers.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Rather than calling make_exportable from the get_bo entrypoint, make
sure that someone has already explicitly requested the pixmap be
exportable.
This is technically an ABI break in that it changes observable
behaviour, but no driver other than modesetting has ever used get_bo.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.
This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
With the appearance of the this new Option the X Server would crash if the
option is not set.
Default dmabuf_capable to off/FALSE for now - a user without knowledge about
this option does not want to enable it until its save.
Fixes: d11d5bb80 ("glamor: Hide new DRI behind Option "Debug" "dmabuf_capable")
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
... for xfree86, at least for now. Things appear to work for Xwayland
but not yet for modesetting. Hopefully we can fix that before 1.20 but
in the meantime this makes testing both paths easier than a rebuild.
Signed-off-by: Adam Jackson <ajax@redhat.com>
With earlier commit the required version was bumped to 2.4.89, thus the
guards always evaluate to true.
Fixes: e4e3447603 ("Add RandR leases with modesetting driver support
[v6]")
Cc: Keith Packard <keithp@keithp.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
They're part of the 1.20 RC1 ABI, and actually used by external drivers.
Also, requiring drivers which don't support the new functionality in
DRI3 1.2 to switch to the new interfaces seems unreasonable.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Using modifier might allow the driver to use a more optimal format
(e.g. tiled/compressed). Let's try to use those if possible.
v2: Don't filter out multi-plane modifiers
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Implement function added in DRI3 v1.1.
A newest version of libepoxy (>= 1.4.4) is required as earlier
versions use a problematic version of Khronos
EXT_image_dma_buf_import_modifiers spec.
v4: Only send scanout-supported modifiers if flipping is possible
v5: Fix memory corruption in XWayland (uninitialized pointer)
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It relies on GBM >= 17.1.0 where we can import BO with multiple
planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER).
v2: Properly free fds in Xwayland
[Also add glamor_egl_ext.h to Makefile.am for distcheck's sake - ajax]
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This makes it work properly with OpenGL based desktop
compositing, as tested with EGL and GLX based compositing
under OpenGL-2/3, and also artifact free with XRender
based 2D compositing.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
[ Michel Dänzer: Adapt to glamor changes since 1.19 ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
The code that needed it was introduced with commit 7cfd9cc232 ("Add
DRI3 support to glamor") back in 2013. And was nuked a couple of years
ago with commit 51984dddfc ("glamor: Delay making pixmaps shareable
until we need to.")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
All that was left here was updating the FBO's size. However, the FBO
size was always set correctly already through
glamor_set_pixmap_texture() from whoever had attached a new BO to the
pixmap.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The function hasn't been doing anything useful since keithp's resource
freeing fixes in 2014.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
GLES2 support has been requested multiple times, and we've had this
code laying around trying to implement it. The GLES2 implementation
is not quite there yet (some pixel transfer failures), but it
shouldn't take much fixing at this point.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Those extensions don't exist. There's only surfaceless_context.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Indirect GLX uses its own context and doesn't care what glamor is
using.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Using flink is banned on render nodes, and they needlessly expose our
screen pixmap contents to any authenticated client. This also
incidentally drops the dependency on EGL_MESA_drm_image.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
I couldn't find it being used anywhere in the history of the code.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This has been associated with dri3 for now, but we need to use it
elsewhere in order to avoid flink. The extensions have been
implemented for long enough that I couldn't find when it was that we
turned them on. Oddly, we already required renderbuffer import
support, which is basically as hard to implement as texture import.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Daniel Stone <daniels@collabora.com>
We only build this code with GBM, and supporting non-GBM well would be
invasive.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The EGL version is not used anywhere in the glamor code, so it's not
interesting. And when saying that we've started using GL
acceleration, it's nice to know what GL we're actually using.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This is for glamor can support fd from DRM render node which is useful
for a render only DDX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
If the libEGL we are using has eglGetPlatformDisplayEXT, yet it still
returns NULL, then this very likely means that it does not support the
type (e.g. EGL_PLATFORM_GBM_MESA) passed in, and then returning NULL is
the right thing to do.
This avoids falling back to an eglGetDisplay() implementation which does
not understands the passed in gbm handle, treats it as a pointer to
something else completely, followed by a crash sooner or later.
Specifically this fixes using the nvidia binary driver, with nvidia's
libEGL + the modesetting driver on a secondary GPU crashing inside
glamor_egl_init() sometimes.
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
eglGetDisplay forces the implementation to guess which kind of display
it's been handed. glvnd does something different from Mesa, and in
general it's impossible for the library to get this right. Add a new
inline that gets the logic right, and works around a quirk in epoxy.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
When a GPU gets hotplugged while X is already running, glamor_egl_init()
gets called and changes the current egl context, without updating
lastGLContext, potentially causing the next glamor call on another GPU to
run in the wrong context.
This causes glamor to e.g. crash in the next glamor_create_pixmap() call
(called through the master's screen->CreatePixmap), note this is not the
only troublesome entry point I've seen other backtraces when using a
compositing window manager.
Set lastGLContext to NULL to force the next glamor_make_current() call
to set the right context.
Note that we cannot use glamor_make_current() here to replace the
eglMakeCurrent() call and update lastGLContext for us because
glamor_make_current takes a glamor_priv struct as argument and that
has not been created yet when glamor_egl_init() gets called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Current Mesa Git master checks that the EGL display actually supports
the API passed to eglBindAPI, which can only succeed after
eglInitialize.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96344
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
v1.1: use version defines.
v2: let glamor work it out itself
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
If a pixmap isn't getting exported as a dmabuf, then we don't need to
make an EGLImage/GBM bo for it. This should reduce normal pixmap
allocation overhead, and also lets the driver choose non-scanout
formats which may be much higher performance.
On Raspberry Pi, where scanout isn't usable as a texture source, this
improves x11perf -copypixwin100 from about 4300/sec to 5780/sec under
xcompmgr -a, because we no longer need to upload our x11perf window to
a tiled temporary in order to render it to the screen.
v2: Just use pixmap->usage_hint instead of a new field. Drop the
changes that started storing gbm_bos in the pixmap priv due to
lifetime issues.
v3: Fix a missing gbm_bo_destroy() on the pixmap-from-fd success path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This GBM import path was introduced in 10.2, which we already require.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
I think void * was just used to avoid needing to #include gbm.h, but
we can just forward-declare the structs and be fine.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We were rolling ioctl calls ourselves, when there's a nice interface
for it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
One less layering violation (EGL should call glamor, if anything, not
the other way around).
v2: Move glamor.c's DestroyPixmap wrapping up above the
glamor_egl_screen_init() call, since glamor.c's DestroyPixmap
needs to be the bottom of the stack (it calls fb directly and
doesn't wrap). Caught by Michel.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The DestroyPixmap chain and CloseScreen chain all do pixmap teardown
already, and calling it manually would be redundant.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
I assume this was a workaround for an old, broken, closed driver. The
driver doesn't get to throw away rendering just because the rendering
context's shared-across-processes render target is getting freed from
the local address space. If the rendering isn't to a shared render
target, then we *do* want to throw away the rendering to it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Otherwise we'll fail and/or crash as no context is bound.
Fixes: 64e6124f27 (glamor: move GL_OES_EGL_image check next to EGL_EXT_image_dma_buf_import)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92105
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Nick Sarnie <commendsarnex@gmail.com>
Reported-by: Nick Sarnie <commendsarnex@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We're using the former only as the latter is present. Thus in some cases
we might incorrectly error out if it's missing.
Namely - glamor_glx, glamor_egl without gbm, EGL_KHR_gl_texture_2D_image
or EGL_EXT_image_dma_buf_import.
Fixes 58d54ee82df(glamor: explicitly check for GL_OES_EGL_image)
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Suggested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
glamor_egl_init() was not undoing any of the init steps on init error,
add an glamor_egl_cleanup() function and use this both on error and on exit
to cleanup the various resources.
Even on a clean exit eglTerminate() was not being called, causing the fd
dup()-ed by eglInitialize() to stay open, call eglTerminate() from the new
glamor_egl_cleanup() to fix this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that it's always non-null when the pixmap is non-null, we don't
need so much of this. glamor_get_pixmap_private() itself still
accepts a NULL pixmap and returns NULL, because of glamor_render.c
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Rather than create the pixmap, this uses the file descriptor
to change an existing pixmaps backing store.
This is required for reverse prime slaves, where we create
the slave pixmap, then set the backing store.
v1.1: use local pScreen (Eric)
Reviewed-by: Eric Anholt <eric@annholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need this for doing USB offload scenarios using glamor
and modesetting driver.
unfortunately only gbm in mesa 10.6 has support for the
linear API.
v1.1: fix bad define
v2: update the configure.ac test as per amdgpu. (Michel)
set linear bos to external to avoid cache. (Eric)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just embed the large elements in the regular pixmap private and
collapse the union to a single struct.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
(Originally written by Dave Airlie; split into a separate patch by
Kenneth Graunke.)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
They are part of the ABI.
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>
When reallocating the framebuffer on screen resize, the old EGL image
was getting leaked. Check for an existing EGL image and free it in
this case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There's no reason to store this in the egl screen private as the
screen pixmap will always hold a reference to it anyways.
Signed-off-by: Keith Packard <keithp@keithp.com>
Revewied-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There were three paths that called eglDestroyImageKHR:
* The front buffer
* The intel driver's flip buffer
* pixmaps under DRI3
This patch unifies the second two by having glamor_destroy_pixmap
always destroy any associaged EGL image. This allows us to stop
storing the back_pixmap pointer in glamor as that was only used to
make sure that buffer was freed at server reset time.
v2: check for valid pixmap_priv before using it in
glamor_egl_destroy_pixmap_image
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
A few files in the server are including xorg-server.h, which is only
for use by Xorg server drivers. This fixes those errors and then adds
a check to make sure it doesn't happen again.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Now that we have the DIX global state for the current context, we
don't need to track nesting to try to reduce MakeCurrent overhead.
v2: Fix a mistaken replacement of a put_context with make_current in
glamor_fill_spans_gl() (caught by keithp).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
This matches the Xephyr behavior. Now that we know when to reset the
context in the presence of GLX, we don't need to try to keep our stuff
from being smashed by GLX.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This gets us some more context changes that are needed to make sure
the two sides render to the right drawables and manipulate the right
objects.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xwayland will eventually need the current client in dri3_open. Simply
changing that API is not an option though as other drivers that
implement DRI3 will not have a matching function signature and will
crash when called.
Add a new dri3_open_client function pointer and bump
DRI3_SCREEN_INFO_VERSION so that drivers can be aware of the new
function which will be used in preference to the old function when
available.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anhole <eric@anholt.net>
By passing the client pointer to the dri3_open implementation, we allow
the clients to implement the open callback asynchronously. If the
client ignore count is positive after returning from dri3_open, we
assume that authentication is in progress and doesn't send the reply.
The code to send the reply is moved into a helper function, which the
implementation can call upon receiving its authenticaion reply.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Just like for a caller of glamor_dri3_fd_from_pixmap(), otherwise the
consumer of that named buffer has no idea what GL chose for the
stride.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The flag is already being set at glamor_egl_screen_init() time, so no
need for the driver to separately call this. That said, leave the
function around to keep the ABI compatibility.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
There's no reason to hide EGL from the rest of glamor, now that we
have epoxy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The render-nodes case is untested.
v2: Add a flag for wayland to suppress the native DRI3 support.
Wayland isn't running as a master itself, so it can't do the auth
on its own and has to ask the compositor to do it for us. Dropped
XXX about randr provider -- the conclusion from discussion with
keithp was that if the driver's dri3_open for a provider on a
different screen, that's a core dri3 bug.
v3: Don't put quite so much under GLAMOR_NO_DRI3, and add a comment
explaining what this is about.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There was confusion over whether they should have egl in the name, and
they had DRI3 in the name even though they're useful to have without
DRI3.
v2: Just rename glamor_name_from_pixmap for now -- I'd accidentally
conflict-resolved in adding new parameters from a later commit.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There's nothing dependent on the presence of DRI3 code in the server
for this, but it does rely on GBM.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The GLX side just gets the context from the current state. That's
also something I want to do for EGL, so that the making a context is
separate from initializing glamor, but I think I need the modesetting
driver in the server before I think about hacking on that more.
The previous code was rather incestuous, along with pulling in xf86
dependencies to our dix code. The new code just initializes itself
from the current state.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Libepoxy hides all the GL versus GLES2 dispatch handling for us, with
higher performance.
v2: Squash in the later patch to drop the later of two repeated
glamor_get_dispatch()es instead (caught by keithp)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
v2: Also edit the one in glamor_egl.c (by anholt)
v3: Also edit the one in glamor_eglmodule.c (by anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
We only needed this because glx was directly bashing glapi tables.
Since that's not the case anymore, we should just MakeCurrent like a
real GL app.
v2: Hand-resolve against rebase onto newer server (by anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This is a warning, but a real problem can occur on some system.
Reported-by: Fabio Pedretti <fabio.ped@libero.it>
Reviewed-by: Axel Davy <davyaxel@free.fr>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This implements some DRI3 helpers to help the DDXs using
glamor to support DRI3.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There is one compilation error ,cast int to pointer, when built without
libgbm, reported by Gaetan Nadon.
And some error checking after memory allocation, reported by Seth Arnold.
There are still some similar issues in the largepixmap implementation.
They are relatively more complicate due to the heavy usage of RegionXXX
APIs which may allocate implicitly. Will fix them in the future.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Tested-by: Gaetan Nadon <memsize@videotron.ca>
This implements glamor_egl_create_textured_pixmap_from_gbm_bo,
which is similar to glamor_egl_create_textured_pixmap, except
it takes a gbm_bo as argument.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fixes crashes when glamor is used for a GPU screen with xserver 1.13 or
newer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57200#c17
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
After increase to gcc4.7, it reports more warnings, now
fix them.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Tested-by: Junyan He<junyan.he@linux.intel.com>
Current Mesa Git only advertises the former instead of the latter.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As xorg 1.13 change the scrn interaces and remove those
global arrays. Some API change cause we can't build. Now
fix it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We miss the strict warning flags for a long time, now add it back.
This commit also fixed most of the warnings after enable the strict
flags.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Thomas Hellstrom
Lyude Paul
Adam Jackson
Eric Anholt
Mario Kleiner
Emil Velikov
Daniel Stone
Tobias Klausmann
Michel Dänzer
Louis-Francis Ratté-Boulianne
Hawking Zhang
Qiang Yu
Hans De Goede
Dave Airlie
Emil Velikov
Jason Ekstrand
Dave Airlie
Jonathan Gray
Keith Packard
Kristian Høgsberg
Gaetan Nadon
Axel Davy
Zhigang Gong
Zhigang Gong