Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set
On Tue, 11 Jul 2023 10:57:57 +0200 Daniel Vetter wrote: > On Fri, Jul 07, 2023 at 07:40:59PM -0300, André Almeida wrote: > > From: Pekka Paalanen > > > > Specify how the atomic state is maintained between userspace and > > kernel, plus the special case for async flips. > > > > Signed-off-by: Pekka Paalanen > > Signed-off-by: André Almeida > > --- > > v4: total rework by Pekka > > --- > > Documentation/gpu/drm-uapi.rst | 41 ++ > > 1 file changed, 41 insertions(+) > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > > index 65fb3036a580..6a1662c08901 100644 > > --- a/Documentation/gpu/drm-uapi.rst > > +++ b/Documentation/gpu/drm-uapi.rst > > @@ -486,3 +486,44 @@ and the CRTC index is its position in this array. > > > > .. kernel-doc:: include/uapi/drm/drm_mode.h > > :internal: > > + > > +KMS atomic state > > + > > + > > +An atomic commit can change multiple KMS properties in an atomic fashion, > > +without ever applying intermediate or partial state changes. Either the > > whole > > +commit succeeds or fails, and it will never be applied partially. This is > > the > > +fundamental improvement of the atomic API over the older non-atomic API > > which is > > +referred to as the "legacy API". Applying intermediate state could > > unexpectedly > > +fail, cause visible glitches, or delay reaching the final state. > > + > > +An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which > > means the > > +complete state change is validated but not applied. Userspace should use > > this > > +flag to validate any state change before asking to apply it. If validation > > fails > > +for any reason, userspace should attempt to fall back to another, perhaps > > +simpler, final state. This allows userspace to probe for various > > configurations > > +without causing visible glitches on screen and without the need to undo a > > +probing change. > > + > > +The changes recorded in an atomic commit apply on top the current KMS > > state in > > +the kernel. Hence, the complete new KMS state is the complete old KMS > > state with > > +the committed property settings done on top. The kernel will automatically > > avoid > > +no-operation changes, so it is safe and even expected for userspace to send > > +redundant property settings. No-operation changes do not count towards > > actually > > +needed changes, e.g. setting MODE_ID to a different blob with identical > > +contents as the current KMS state shall not be a modeset on its own. > > Small clarification: The kernel indeed tries very hard to make redundant > changes a no-op, and I think we should consider any issues here bugs. But > it still has to check, which means it needs to acquire the right locks and > put in the right (cross-crtc) synchronization points, and due to > implmentation challenges it's very hard to try to avoid that in all cases. > So adding redundant changes especially across crtc (and their connected > planes/connectors) might result in some oversynchronization issues, and > userspace should therefore avoid them if feasible. > > With some sentences added to clarify this: > > Reviewed-by: Daniel Vetter After talking on IRC yesterday, we realized that the no-op rule is nowhere near as generic as I have believed. Roughly: https://oftc.irclog.whitequark.org/dri-devel/2023-07-12#1689152446-1689157291; Thanks, pq > > + > > +A "modeset" is a change in KMS state that might enable, disable, or > > temporarily > > +disrupt the emitted video signal, possibly causing visible glitches on > > screen. A > > +modeset may also take considerably more time to complete than other kinds > > of > > +changes, and the video sink might also need time to adapt to the new signal > > +properties. Therefore a modeset must be explicitly allowed with the flag > > +DRM_MODE_ATOMIC_ALLOW_MODESET. This in combination with > > +DRM_MODE_ATOMIC_TEST_ONLY allows userspace to determine if a state change > > is > > +likely to cause visible disruption on screen and avoid such changes when > > end > > +users do not expect them. > > + > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is allowed to > > +effectively change only the FB_ID property on any planes. No-operation > > changes > > +are ignored as always. Changing any other property will cause the commit > > to be > > +rejected. > > -- > > 2.41.0 > > > pgpYHziFByeuR.pgp Description: OpenPGP digital signature
Re: Need support to display application at (0, 0) position on Weston desktop
On Wed, 12 Jul 2023 21:38:06 +0700 huy nguyen wrote: > Hi all, > > I have a Linux system based on weston wayland. I run MPV player and expect > it displays a video window at (0,0) position on the screen (top left corner > of the display). I already use x11egl backend option to MPV to support a > fixed position to application but the video window of MPV is displayed at > an offset (X offset, Y offset) from (0,0) position as shown by the picture > below: > > [image: IMG_6944.jpg] > > Can we have a support from weston wayland to position (0,0) to application > running on Xwayland backend? Hi, I think the gap you see is the window decorations. Weston's X11 Window Manager (XWM) and demo clients have a fairly wide margin around window decorations. So the window actually is at (0, 0) already, and the gap is really just the decorations. Maybe you can tell mpv to tell XWM to not decorate the window at all, or maybe you can make the position slightly negative to close the gap. However, if this is a not general use desktop, and kiosk-shell does not fit, the I'm afraid the only reliable way to get exactly the window management behaviour you want overall is to fork and modify Weston's desktop-shell plugin. I mean, maybe you would also like the video window to stay on top regardless of where the user is touching/clicking. Composing an application from multiple independent programs like video players necessarily requires the window manager to be part of the application. As window managers are built into Wayland compositors, you have to change the compositor. In Weston case that happens by loading a different "shell" plugin. Usually if you want an application to embed a video player, you do that with video playing libraries inside the application, and not by adding an external video player which then requires careful window management. Thanks, pq pgpOWpECV0DC1.pgp Description: OpenPGP digital signature
Re: Need support to display application at (0, 0) position on Weston desktop
Hi, On Wed, Jul 12, 2023 at 10:24:22PM +0700, huy nguyen wrote: […] > In my application, I want to overlay an MPV video window on another > application so that users can view both video content and other application > static content so that a fullscreen MPV is not suitable. > Is it possible to adjust the initial position of MPV video window at (0,0) > on the weston desktop (I already hide the weston top bar). I would recommend to use libmpv instead of mpv, which lets you render inside of your application wherever you want, without forcing you through X11. You would typically have a GL or Vulkan widget in your UI which you paint into using libmpv. > > Best regards, > Huy […] -- Link Mauve
Re: Need support to display application at (0, 0) position on Weston desktop
Hi Pekka, Thank you for your helpful feedback. I understand all your points and will take a look to provide a custom logic to weston desktop to support my use-cases. Best regards, Huy On Thu, Jul 13, 2023 at 5:07 PM Pekka Paalanen wrote: > On Wed, 12 Jul 2023 21:38:06 +0700 > huy nguyen wrote: > > > Hi all, > > > > I have a Linux system based on weston wayland. I run MPV player and > expect > > it displays a video window at (0,0) position on the screen (top left > corner > > of the display). I already use x11egl backend option to MPV to support a > > fixed position to application but the video window of MPV is displayed at > > an offset (X offset, Y offset) from (0,0) position as shown by the > picture > > below: > > > > [image: IMG_6944.jpg] > > > > Can we have a support from weston wayland to position (0,0) to > application > > running on Xwayland backend? > > Hi, > > I think the gap you see is the window decorations. Weston's X11 Window > Manager (XWM) and demo clients have a fairly wide margin around window > decorations. So the window actually is at (0, 0) already, and the gap > is really just the decorations. > > Maybe you can tell mpv to tell XWM to not decorate the window at all, > or maybe you can make the position slightly negative to close the gap. > > However, if this is a not general use desktop, and kiosk-shell does not > fit, the I'm afraid the only reliable way to get exactly the window > management behaviour you want overall is to fork and modify Weston's > desktop-shell plugin. I mean, maybe you would also like the video > window to stay on top regardless of where the user is touching/clicking. > > Composing an application from multiple independent programs like video > players necessarily requires the window manager to be part of the > application. As window managers are built into Wayland compositors, you > have to change the compositor. In Weston case that happens by loading > a different "shell" plugin. > > Usually if you want an application to embed a video player, you do that > with video playing libraries inside the application, and not by adding > an external video player which then requires careful window management. > > > Thanks, > pq >
Re: Need support to display application at (0, 0) position on Weston desktop
Hi Igor, I do not have a full context about Wayland protocol vs X11 legacy faults to understand the reason why the Wayland devs do not support absolute position decided by client applications. Fortunately, I can modify the weston desktop shell to provide that support to my particular use-case with my local build so that I can live with that until an official support from Wayland in the future. Best regards, Huy On Thu, Jul 13, 2023 at 10:29 PM Igor Korot wrote: > Hi, > I believe with any Wayland stuff you will fail to use absolute positioning. > > you absolutely have to use X11 and forget about Wayland.. > > The Wayland devs are NOT CONVINCED enough to support absolute > positioning and will just tell you to use X11. > > THank you. > > On Thu, Jul 13, 2023 at 9:55 AM huy nguyen > wrote: > > > > Hi Pekka, > > > > Thank you for your helpful feedback. > > I understand all your points and will take a look to provide a custom > logic to weston desktop to support my use-cases. > > > > Best regards, > > Huy > > > > On Thu, Jul 13, 2023 at 5:07 PM Pekka Paalanen > wrote: > >> > >> On Wed, 12 Jul 2023 21:38:06 +0700 > >> huy nguyen wrote: > >> > >> > Hi all, > >> > > >> > I have a Linux system based on weston wayland. I run MPV player and > expect > >> > it displays a video window at (0,0) position on the screen (top left > corner > >> > of the display). I already use x11egl backend option to MPV to > support a > >> > fixed position to application but the video window of MPV is > displayed at > >> > an offset (X offset, Y offset) from (0,0) position as shown by the > picture > >> > below: > >> > > >> > [image: IMG_6944.jpg] > >> > > >> > Can we have a support from weston wayland to position (0,0) to > application > >> > running on Xwayland backend? > >> > >> Hi, > >> > >> I think the gap you see is the window decorations. Weston's X11 Window > >> Manager (XWM) and demo clients have a fairly wide margin around window > >> decorations. So the window actually is at (0, 0) already, and the gap > >> is really just the decorations. > >> > >> Maybe you can tell mpv to tell XWM to not decorate the window at all, > >> or maybe you can make the position slightly negative to close the gap. > >> > >> However, if this is a not general use desktop, and kiosk-shell does not > >> fit, the I'm afraid the only reliable way to get exactly the window > >> management behaviour you want overall is to fork and modify Weston's > >> desktop-shell plugin. I mean, maybe you would also like the video > >> window to stay on top regardless of where the user is touching/clicking. > >> > >> Composing an application from multiple independent programs like video > >> players necessarily requires the window manager to be part of the > >> application. As window managers are built into Wayland compositors, you > >> have to change the compositor. In Weston case that happens by loading > >> a different "shell" plugin. > >> > >> Usually if you want an application to embed a video player, you do that > >> with video playing libraries inside the application, and not by adding > >> an external video player which then requires careful window management. > >> > >> > >> Thanks, > >> pq >
