Weston qxl/spice backend
Hello Does there exist a qxl/spice backend in weston nowadays? At some point there was https://github.com/ein-shved/compositor-spice but I could not find something active/which builds these days. OpenPGP_0x20257A7131FFF28B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[PATCH] uapi/drm: Specify time constraints of DRM_MODE_ATOMIC_NONBLOCK
From: Jonas Ådahl
In order for compositors to utilize real time scheduling capabilities,
it must be ensured by the kernel that calling a drmModeAtomicCommit()
with DRM_MODE_ATOMIC_NONBLOCK does not block in a manner that makes the
realtime scheduler watchdog send a SIGKILL to the calling process.
Thus, require drmModeAtomicCommit() explicitly with passed
DRM_MODE_ATOMIC_NONBLOCK to not block in such a way, i.e. during regular
non-mode setting page flips, the kernel must not block any extensive
period of time.
While blocking for the amount of time needed to trigger SIGKILL
(usually 250 ms) already means inadequate behavior due to a large amount
of missed frames, thus stuttering, is the result, if drivers still need
to behave this way in edge cases, they should behave in away that the
calling thread can go to sleep.
Signed-off-by: Jonas Ådahl
---
Hi,
This is a follow up from the Display Next Hackfest in Coruña[1], where the
topic was discussed, and the conclusion was to try to document the
expectations of the kernel when compositors are doing non-blocking page
flips.
As can be seen, synchronous mode setting commits are not, for the time
being, meant to guarantee finishing fast enough, which is fine, but to be
able to make use of realtime scheduling, nonblocking updates must behave
in a sensible manner.
I took it so far to describe how drivers should handle situations when checking
an update can potentially take a very very long time, but if that should just
never be allowed to happen, it can be reworded. The main take away should be
that it's a kernel bug if a non-blocking commit blocks for more than a few
milliseconds.
Jonas
[1] https://events.pages.igalia.com/linuxdisplaynexthackfest/
include/uapi/drm/drm_mode.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index c082810c08a8..1953ae1a37d2 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1112,6 +1112,12 @@ struct drm_mode_destroy_dumb {
* IOCTL returns immediately instead of waiting for the changes to be applied
* in hardware. Note, the driver will still check that the update can be
* applied before retuning.
+ *
+ * The driver must not leave the calling thread in a running state for any
+ * extensive period of time to avoid the process receiving SIGKILL by the
+ * realtime scheduler. This means if checking the update needs to wait for an
+ * excessive amount of time, the running state of the calling thread must be
+ * changed accordingly while waiting.
*/
#define DRM_MODE_ATOMIC_NONBLOCK 0x0200
/**
--
2.44.0.501.g19981daefd.dirty
Re: disabling rotation for a particular display area
Hi Ivan, On Fri, Sep 20, 2024 at 05:54:27PM +0300, Ivan Drobyshevskyi wrote: > Hi all, > > Is there any way to make weston not rotate a particular window? Any > kind of ugly workaround will do. > > Larger context around it -- high resolution video on an embedded board > becomes super jerky when the display is rotated, and plays smoothly > when it's not. So one idea is to pre-rotate the video. > > Full details below: > > There's an i.MX6DL embedded board, running community flavor of Yocto > BSP (meta-freescale) with weston (8.0.0) and gstreamer 1.16. DRM > backend is used, with etnaviv driver. > > FullHD LVDS display is connected, natively in landscape mode, but must > be used in portrait mode, so it's rotated in weston.ini > (transform=270). > > Now the problem: higher resolution video (about half of FullHD, > occupying half of the screen) is very teared/jerky. > FPS by itself is not an issue, reported around 30 by fpsdisplaysink. > Now if display rotation is disabled (transform=0), video is smooth! > Video is played via gst-launch-1.0 with waylandsink. > > I've backported "rotate-method" waylandsink support, which effectively > calls wl_surface_set_buffer_transform(), among other things. > The idea was to match weston display rotation and video rotation so > that they cancel out. > The commit didn't apply cleanly, but I think I've figured it out and > ported properly. > Video is indeed rotated, but still teared/jerky, no improvement at all > (tried both CW and CCW just in case). Perhaps there's no offloading to a HW plane even with rotate-method added? Merely a speculation but between version 8 and 9 of Weston we redefined the output roation transforms as they seem to be have been inversed, and aligned them with the spec [1]. If there's not that much of a hassle, suggest trying out Weston 9 (or newer obviously), or maybe try to backport this yourself in case there's no way on updating. You should change, in your ini file, transform=270 to transform=90, and give it another go (with the same rotate-method for waylandsink). Alternatively, you can try to debug this on your own using drm-backend log scope, which you can activate by adding `--debug` cmd line option when running Weston. Then use weston-debug drm-backend and look for lines that could hint why Weston wasn't able to lift the waylandsink view into a HW plane. Probably not a lot would make sense but you can compare between a good run (with no orietnation applied) and with one that doesn't work and maybe work out the difference. Note that Weston 8 is quite old and lot of things changed even with this debug scope part. [1] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/383 > > Thanks, > Ivan signature.asc Description: PGP signature
