Re: Need support to display application at (0, 0) position on Weston desktop
On Thu, 13 Jul 2023 10:29:28 -0500 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. Hi Igor, you seem to be mixing things up here. It is true that Wayland maintainers are extremely resistant to suggestions to add global coordinate based client-driven window positioning to any Wayland extension intended to be used by regular desktop applications. However, all the mentioned conditions apply together. A compositor can choose to support Wayland extensions aimed at special-purpose clients that actually know better themselves to position themselves than the compositor. Integrable desktop components fall into this category. Non-desktops have no such rules at all. Anyone is free to add any positioning protocol they need when it does not aim for generic desktop use. Whether it is a good or bad idea is another matter. In-vehicle infotainment systems have favoured this approach. There is an even less restricted case where you have a special-purpose compositor built for a very specific use case. It sounds like Huy has this case in mind. This case may not even need any custom Wayland extension and could possibly support generic applications by special window management rules inside the compositor. This makes the compositor a part of the overall application, known just from the client app_id where and how it need to be positioned. One can pick their path, but if it requires absolute window positioning dictated by clients, then it won't be usable as a regular desktop application. Thanks, pq pgpRYgM9SdK98.pgp Description: OpenPGP digital signature
Re: [PATCH] drm: support up to 128 drm devices
(cc Daniel Vetter and Pekka because this change has uAPI repercussions)
On Friday, June 30th, 2023 at 13:56, James Zhu wrote:
> From: Christian König
>
> This makes room for up to 128 DRM devices.
>
> Signed-off-by: Christian König
> Signed-off-by: James Zhu
> ---
> drivers/gpu/drm/drm_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 73b845a75d52..0d55c6f5 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -137,7 +137,7 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> r = idr_alloc(&drm_minors_idr,
> NULL,
> 64 * type,
> - 64 * (type + 1),
> + 64 * (type + 2),
The type comes from this enum:
enum drm_minor_type {
DRM_MINOR_PRIMARY,
DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
DRM_MINOR_ACCEL = 32,
};
Before this patch, 0..63 are for primary, 64..127 are for control (never
exposed by the kernel), 128..191 are for render, 2048..2112 are for accel.
After this patch, 0..127 are for primary, 64..191 are for control (never
exposed by the kernel), 128..255 are for render, 2048..2176 are for accel.
I'm worried what might happen with old user-space, especially old libdrm.
When there are a lot of primary nodes, some would get detected as control
nodes, even if they aren't. Is this fine? This would at least be confusing
for information-gathering tools like drm_info. I'm not sure about other
consequences. Do we want to forever forbid the 64..127 range instead, so
that we have the guarantee that old libdrm never sees it?
I'm also worried about someone adding a new entry to the enum after
DRM_MINOR_RENDER (DRM_MINOR_ACCEL was specifically set to 32 so that new
node types could be added before). drm_minor_alloc() would blow up in this
case, because it'd use the 192..319 range, which overlaps with render.
I think a switch with explicit ranges (and WARN when an unknown type is
passed in) would be both easier to read and less risky.
> GFP_NOWAIT);
> spin_unlock_irqrestore(&drm_minor_lock, flags);
> }
> --
> 2.34.1
Re: [PATCH] drm: support up to 128 drm devices
On Friday, July 14th, 2023 at 12:31, Simon Ser wrote: > Before this patch, 0..63 are for primary, 64..127 are for control (never > exposed by the kernel), 128..191 are for render, 2048..2112 are for accel. > After this patch, 0..127 are for primary, 64..191 are for control (never > exposed by the kernel), 128..255 are for render, 2048..2176 are for accel. Correction: reading the code, accel is handled separately. Additional find: the kernel creates sysfs control nodes because old user-space reads them to figure out whether a device is DRIVER_MODESET.
Re: Need support to display application at (0, 0) position on Weston desktop
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
