We are handling two cases here: the active flip or the pending flip.
For the pending flip (event->pending == TRUE), we called
xwl_present_release_pixmap.
For the active flip (event->pending == FALSE), we called
xwl_present_release_event. However, xwl_present_flip_notify_vblank
already unhooked event->vblank.event_queue. So this was effectively the
same as calling xwl_present_release_pixmap.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Use present_vblank_rec::event_queue instead.
The changes in xwl_present_execute shouldn't really be needed, since
we should never hit queue_vblank in present_execute_wait. But let's be
safe rather than sorry, plus this simplifies the code.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Can just call xwl_present_execute directly.
This allows dropping the window member from struct xwl_present_window as
well.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
We clear the vblank->pixmap field, so next time xwl_present_execute
falls through to present_execute_post.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This allows for various simplifications.
Use the pointer to the struct memory as the event ID. In contrast to
the SCMD code for Xorg (where pending DRM events cannot be cancelled),
this is safe here, because we can destroy pending Wayland callbacks. So
we can't get a callback with a stale pointer to freed memory.
Remove xwl_present_window::release_list in favour of
present_vblank_rec::window_list.
Remove xwl_present_event::xwl_present_window in favour of
present_vblank_rec::window.
xwl_present_free_event is never called for a NULL pointer anymore, no
need to check.
v2:
* Restore DestroyWindow wrapping order to make sure
present_destroy_window doesn't call xwl_present_abort_vblank.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
We can call xwl_present_free_event unconditionally from
xwl_present_abort_vblank, since the sync_callback is already destroyed
in xwl_present_cleanup.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Mainly into xwl_present_check_flip, and call that from
present_wnmd_check_flip_window.
No need for them to be separate anymore.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This will allow eliminating indirections and making the Xwayland Present
code more efficient and easier to follow.
While this technically changes the Xorg video driver ABI, I don't know
of any drivers using the dropped present_wnmd_* symbols, and I doubt a
Xorg driver could make use of them as is anyway.
(As a bonus, Xorg no longer links any Xwayland specific Present code)
v2:
* Wrap DestroyWindow before initializing Present, so that
present_destroy_window runs before xwl_present_cleanup. Avoids crash
due to present_destroy_window calling xwl_present_* functions when
xwl_present_window was already freed. (Olivier Fourdan)
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Not sure why we'd need to abandon a pending stream for a pixmap just
because it's no longer a window pixmap. Let's try not to.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This makes sure RandR events are sent to interested clients as needed.
This was happening implicitly in some cases, but not in others, e.g. if
the root window size didn't change.
If this were to call RRTellChanged more often than necessary in some
cases, that should be harmless, as it only sends events if something
has actually changed since last time.
Should fix https://bugzilla.redhat.com/show_bug.cgi?id=1979892 .
v2:
* Call RRTellChanged at the very end of update_screen_size, just in
case.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This can happen if RRTellChanged is called during initialization.
Continuing in that case makes no sense conceptually:
* Any event sent over the wire requires a corresponding window.
* No root window probably means there can't be any clients which could
receive the events.
In practice, it would result in a crash down the road due to
dereferencing the NULL ScreenRec::root pointer.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This enables a number of the GLSL 1.30 paths on GPUs that have
EXT_gpu_shader4 but don't have GLSL 1.30 exposed.
(Intel gen4/5 mainly)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Meson does not like comparing things of different types which is a
problem when reading back values of feature flags as they may contain
either false (bool) or 1 (string).
Since there is a strong reason why we use false when the feature does
not exist, we work around this issue by always converting the returned
value to int via to_int().
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1190
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
If you say FixesQueryVersion twice we remember whatever the second
version number was. With just libXfixes this isn't an issue because the
request is hidden in extension setup, but libxcb-xfixes doesn't do that
for you, which means the second one can _lower_ the requested fixes
version, disabling requests that the client thought it had enabled.
Paper over this by allowing the version number to be raised but not
lowered. Also go ahead and delete the minor version number from the
client state since xfixes doesn't have minor versions (yet, anyway).
To avoid an EGL stream in the wrong state, if the window pixmap changed
before the stream was connected, we would still keep the pending stream
but mark it as invalid. Once the callback is received, the pending would
be simply discarded.
But all of this is actually to avoid a bug in egl-wayland, there should
not be any problem with Xwayland destroying an EGL stream while the
compositor is still using it.
With that bug now fixed in egl-wayland 1.1.7, we can safely drop all
that logic from Xwayland EGLstream backend.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1189
If the pixmap does not actually change in set_window_pixmap(), there is
no need to invalidate the pending stream, if there's one.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When building xserver with slibtool (https://dev.midipix.org/cross/slibtool)
the build will fail.
/usr/bin/ld: cannot find -ldmxconfig
This is because xserver creates libdmxconfig.a internally and then links with
the linker flag -ldmxconfig. However according to automake documentation the
-lfoo linker flags should only be used for external dependencies and all
internal libraries should be linked with the libtool archive file (.la) or
the static archive (.a) when the former is not available.
GNU libtool is far more permissive and happens to silently obscure this issue
while slibtool fails because it instead sees '-L./.libs -ldmxconfig'.
On at least Lenovo Thinkpad E585 udev does not have ID_PATH property for
the drm node (see
https://gitlab.freedesktop.org/xorg/xserver/-/issues/993). While this is
likely udev bug, this causes the device to be not recognized as
attribs->busid is NULL, which causes platform_find_pci_info to be not
called and corresponding xf86_platform_devices[i]->pdev to be NULL.
At this moment pdev being NULL will cause a crash, but this is a
different bug.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/993
Fixes: 0816e8fc linux: Make platform device probe less fragile
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Stop assuming that a failure to link always means that the file indeed
exists. In case of other failure (e.g., permissions), the user would get an
inconsistent "Can't read lock file" message.
Signed-off-by: Olivier Certner <olce.freedesktop@certner.fr>
