Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Olivier Fourdan
Hi all,

In Fedora and Red Hat Enterprise Linux, we ship a small shell script called
"xvfb-run" originating from Debian to launch an X11 client within Xvfb.

With the future removal of Xorg and all related Xservers in RHEL [1],
except Xwayland, there was a need for a replacement utility that would work
like xvfb-run, but without Xvfb :)

The idea is to run Xwayland rootful within a Wayland compositor headless as
a replacement for Xvfb. The problem though is that I didn't want to be
tight to a specific Wayland compositor and of course every Wayland
compositor uses different options to run headless.

At the same time, I was also working on improving Xwayland rootful support
([2], and identified the need for a convenient utility to run an X11 client
within its own Xwayland rootful instance (useful to run a legacy game for
example. as with [3]).

So, long story short, what started as a replacement utility for xvfb-run
ended as 3 different (yet related) utilities:

 * xwayland-run, to spawn an X11 client within its own dedicated Xwayland
rootful instance,
 * wlheadless-run to run a Wayland client on a set of supported Wayland
headless compositors,
 * xwfb-run, a combination of the two other tools above to be used as a
direct replacement for xvfb-run specifically.

Right now, it supports 4 different Wayland compositors (weston, cage,
mutter, gnome-kiosk) but adding more should just be a matter of adding a
relevant module.

So my question is, if there is any interest for such a project [4], should
this be moved to the wayland namespace in gitlab (we could even change the
name of the project), should that be added to the existing
"wayland-utility" project that we have already, or if there's no interest
it's fine to stay in my own gitlab namespace for now?

Cheers
Olivier

[1] Red Hat Enterprise Linux 10 plans for Wayland and Xorg server

[2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197
[3] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1595
[4] https://gitlab.freedesktop.org/ofourdan/xwayland-run


Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Simon Ser
On Wednesday, November 29th, 2023 at 10:10, Olivier Fourdan  
wrote:

> So my question is, if there is any interest for such a project [4], should
> this be moved to the wayland namespace in gitlab (we could even change the
> name of the project), should that be added to the existing "wayland-utility"
> project that we have already, or if there's no interest it's fine to stay in
> my own gitlab namespace for now?

I'd prefer this to be kept in your personal namespace: I'd prefer not to make
this an official Wayland project.

Simon


Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Martin Stransky

On 11/29/23 10:10, Olivier Fourdan wrote:
[...]


So my question is, if there is any interest for such a project [4], should
this be moved to the wayland namespace in gitlab (we could even change the
name of the project), should that be added to the existing
"wayland-utility" project that we have already, or if there's no interest
it's fine to stay in my own gitlab namespace for now?


Definitely needed for Firefox/Wayland testing. Thanks for providing that!


[1] Red Hat Enterprise Linux 10 plans for Wayland and Xorg server

[2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197
[3] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1595
[4] https://gitlab.freedesktop.org/ofourdan/xwayland-run



--
Martin Stransky
Software Engineer / Red Hat, Inc



Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Olivier Fourdan
Hi Simon,

On Wed, 29 Nov 2023 at 10:16, Simon Ser  wrote:

>
> I'd prefer this to be kept in your personal namespace: I'd prefer not to
> make
> this an official Wayland project.
>
>
Well, that was quick! :)

If I may, would it be possible to elaborate on the rationale behind your
opinion, is that because there is no interest at all, because of the
quality of the code, because of Python, or because it's partly about
Xwayland and X11?

I understand it may not be suitable as a project of its own within the
Wayland space, but couldn't we consider adding these to the (existing)
wayland-utils instead?

Cheers
Olivier


Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Martin Stransky

On 11/29/23 10:35, Olivier Fourdan wrote:

Hi Simon,

On Wed, 29 Nov 2023 at 10:16, Simon Ser  wrote:



I'd prefer this to be kept in your personal namespace: I'd prefer not to
make
this an official Wayland project.



Well, that was quick! :)

If I may, would it be possible to elaborate on the rationale behind your
opinion, is that because there is no interest at all, because of the
quality of the code, because of Python, or because it's partly about
Xwayland and X11?

I understand it may not be suitable as a project of its own within the
Wayland space, but couldn't we consider adding these to the (existing)
wayland-utils instead?


+1

There should be a standardized and widely used tool to test Wayland 
based applications every Wayland based project may use. There's no point 
to fragment it through personal repos.


--
Martin Stransky
Software Engineer / Red Hat, Inc



Re: registry_bind function call

2023-11-29 Thread Pekka Paalanen
On Tue, 21 Nov 2023 13:05:38 -0800
Robert Ayrapetyan  wrote:

> Hi there, I'm having difficulty locating the specific location in the
> Wayland codebase where registry_bind function is called. I'm trying to
> comprehend why, for particular globals, there is no occurrence of a
> global->bind call.

See 
https://gitlab.freedesktop.org/wayland/wayland/-/blob/1.22.0/src/wayland-server.c#L995-997
and 
https://gitlab.freedesktop.org/wayland/wayland/-/blob/1.22.0/src/wayland-server.c#L1038-1040

which will cause registry_bind() to be called by

https://gitlab.freedesktop.org/wayland/wayland/-/blob/1.22.0/src/connection.c#L1025


Thanks,
pq


pgpI5fl274ykg.pgp
Description: OpenPGP digital signature


Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Neal Gompa
On Wed, Nov 29, 2023 at 5:27 AM Olivier Fourdan  wrote:
>
> Hi all,
>
> In Fedora and Red Hat Enterprise Linux, we ship a small shell script called 
> "xvfb-run" originating from Debian to launch an X11 client within Xvfb.
>
> With the future removal of Xorg and all related Xservers in RHEL [1], except 
> Xwayland, there was a need for a replacement utility that would work like 
> xvfb-run, but without Xvfb :)
>
> The idea is to run Xwayland rootful within a Wayland compositor headless as a 
> replacement for Xvfb. The problem though is that I didn't want to be tight to 
> a specific Wayland compositor and of course every Wayland compositor uses 
> different options to run headless.
>
> At the same time, I was also working on improving Xwayland rootful support 
> ([2], and identified the need for a convenient utility to run an X11 client 
> within its own Xwayland rootful instance (useful to run a legacy game for 
> example. as with [3]).
>
> So, long story short, what started as a replacement utility for xvfb-run 
> ended as 3 different (yet related) utilities:
>
>  * xwayland-run, to spawn an X11 client within its own dedicated Xwayland 
> rootful instance,
>  * wlheadless-run to run a Wayland client on a set of supported Wayland 
> headless compositors,
>  * xwfb-run, a combination of the two other tools above to be used as a 
> direct replacement for xvfb-run specifically.
>
> Right now, it supports 4 different Wayland compositors (weston, cage, mutter, 
> gnome-kiosk) but adding more should just be a matter of adding a relevant 
> module.
>
> So my question is, if there is any interest for such a project [4], should 
> this be moved to the wayland namespace in gitlab (we could even change the 
> name of the project), should that be added to the existing "wayland-utility" 
> project that we have already, or if there's no interest it's fine to stay in 
> my own gitlab namespace for now?
>

Thank you for writing this, this is great! I would love to see this in
the wayland namespace somehow.

As an aside, it would be nice to see a collection of nice wayland
utilities to be in the wayland fdo gitlab namespace to make it easier
to discover. For example, as part of the discussion around
Wayland-only Plasma, I was surprised that people didn't know about
things like waypipe[1], which has existed for a long time. And another
recent creation, waycheck[2], is not easily discoverable either.

[1]: https://gitlab.freedesktop.org/mstoeckl/waypipe
[2]: https://gitlab.freedesktop.org/serebit/waycheck




--
真実はいつも一つ!/ Always, there's only one truth!


Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Pekka Paalanen
On Wed, 29 Nov 2023 10:10:05 +0100
Olivier Fourdan  wrote:

> Hi all,
> 
> In Fedora and Red Hat Enterprise Linux, we ship a small shell script called
> "xvfb-run" originating from Debian to launch an X11 client within Xvfb.
> 
> With the future removal of Xorg and all related Xservers in RHEL [1],
> except Xwayland, there was a need for a replacement utility that would work
> like xvfb-run, but without Xvfb :)
> 
> The idea is to run Xwayland rootful within a Wayland compositor headless as
> a replacement for Xvfb. The problem though is that I didn't want to be
> tight to a specific Wayland compositor and of course every Wayland
> compositor uses different options to run headless.
> 
> At the same time, I was also working on improving Xwayland rootful support
> ([2], and identified the need for a convenient utility to run an X11 client
> within its own Xwayland rootful instance (useful to run a legacy game for
> example. as with [3]).
> 
> So, long story short, what started as a replacement utility for xvfb-run
> ended as 3 different (yet related) utilities:
> 
>  * xwayland-run, to spawn an X11 client within its own dedicated Xwayland
> rootful instance,

Hi Olivier,

wouldn't this one be at home in the xserver repository?

>  * wlheadless-run to run a Wayland client on a set of supported Wayland
> headless compositors,

I think this would belong fine in wayland-utils except for needing
per-compositor code in it. Having tools that depend on compositor
specifics live in wayland-utils would need a consensus agreement. I
have nothing against that, but I also don't maintain wayland-utils.

Alternatively, maybe each compositor project should consider shipping a
short-cut command for a headless instance? Though that does make
xwfb-run just eat the differences instead.

>  * xwfb-run, a combination of the two other tools above to be used as a
> direct replacement for xvfb-run specifically.

xserver repository?

> Right now, it supports 4 different Wayland compositors (weston, cage,
> mutter, gnome-kiosk) but adding more should just be a matter of adding a
> relevant module.
> 
> So my question is, if there is any interest for such a project [4], should
> this be moved to the wayland namespace in gitlab (we could even change the
> name of the project), should that be added to the existing
> "wayland-utility" project that we have already, or if there's no interest
> it's fine to stay in my own gitlab namespace for now?

When I was asking to have color-and-hdr documentation repository under
any common gitlab group instead of my personal namespace, the answer
was that it should first become a true community project that won't die
as soon as I walk away from it.

Will be interesting to see how much attention your scripts gain.


Thanks,
pq

> 
> Cheers
> Olivier
> 
> [1] Red Hat Enterprise Linux 10 plans for Wayland and Xorg server
> 
> [2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197
> [3] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1595
> [4] https://gitlab.freedesktop.org/ofourdan/xwayland-run



pgpfIDBTIxVMF.pgp
Description: OpenPGP digital signature


Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Simon Ser
On Wednesday, November 29th, 2023 at 10:35, Olivier Fourdan  
wrote:

> > I'd prefer this to be kept in your personal namespace: I'd prefer not to 
> > make
> > this an official Wayland project.
> 
> Well, that was quick! :)
> 
> If I may, would it be possible to elaborate on the rationale behind your
> opinion, is that because there is no interest at all, because of the quality
> of the code, because of Python, or because it's partly about Xwayland and X11?

To me the main downside is that this project has a hardcoded list of
compositors. I don't think compositor-specific scripts are a good thing to have
upstream.

Moreover, last time I asked to make something an official Wayland project (IIRC
Waypipe) the reply was "no". I don't see why this one would be any different.


Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

2023-11-29 Thread Olivier Fourdan
Hi Pekka,

On Wed, 29 Nov 2023 at 15:02, Pekka Paalanen  wrote:

> On Wed, 29 Nov 2023 10:10:05 +0100
> Olivier Fourdan  wrote:
> >  * xwayland-run, to spawn an X11 client within its own dedicated Xwayland
> > rootful instance,
>
> wouldn't this one be at home in the xserver repository?
>

Yes, xwayland-run might be better suited in the xorg space. But the 3
utilities share the same modules in Python, so splitting them isn't
convenient.

>  * wlheadless-run to run a Wayland client on a set of supported Wayland
> > headless compositors,
>
> I think this would belong fine in wayland-utils except for needing
> per-compositor code in it. Having tools that depend on compositor
> specifics live in wayland-utils would need a consensus agreement. I
> have nothing against that, but I also don't maintain wayland-utils.
>

The whole purpose of that is precisely to hide the  differences between the
compositors, so that requires per-compositor modules.

Alternatively, maybe each compositor project should consider shipping a
> short-cut command for a headless instance? Though that does make
> xwfb-run just eat the differences instead.
>
> >  * xwfb-run, a combination of the two other tools above to be used as a
> > direct replacement for xvfb-run specifically.
>
> xserver repository?
>

Yeah, but even more than xwayland-run, wlhealess-run and xwfb-run share a
lot of the same code.

[…]
>
> When I was asking to have color-and-hdr documentation repository under
> any common gitlab group instead of my personal namespace, the answer
> was that it should first become a true community project that won't die
> as soon as I walk away from it.
>
> Will be interesting to see how much attention your scripts gain.
>

Good point indeed, I guess this can stay in my gitlab space in the meantime.

And that shouldn't stop anyone downstream from packaging it.

Cheers
Olivier


Re: [PATCH RFC v7 02/10] drm: Introduce solid fill DRM plane property

2023-11-29 Thread Dmitry Baryshkov
On Sat, 28 Oct 2023 at 01:33, Jessica Zhang  wrote:
>
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the "solid_fill" plane property containing the following information:
>
> struct drm_mode_solid_fill {
> u32 r, g, b, pad;
> };
>
> Acked-by: Harry Wentland 
> Acked-by: Sebastian Wick 
> Signed-off-by: Jessica Zhang 

Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/drm_atomic_state_helper.c |  9 
>  drivers/gpu/drm/drm_atomic_uapi.c | 26 ++
>  drivers/gpu/drm/drm_blend.c   | 30 ++
>  include/drm/drm_blend.h   |  1 +
>  include/drm/drm_plane.h   | 36 
> +++
>  include/uapi/drm/drm_mode.h   | 24 +
>  6 files changed, 126 insertions(+)



-- 
With best wishes
Dmitry


Re: [PATCH RFC v7 07/10] drm/atomic: Loosen FB atomic checks

2023-11-29 Thread Dmitry Baryshkov
On Sat, 28 Oct 2023 at 01:33, Jessica Zhang  wrote:
>
> Loosen the requirements for atomic and legacy commit so that, in cases
> where pixel_source != FB, the commit can still go through.
>
> This includes adding framebuffer NULL checks in other areas to account for
> FB being NULL when non-FB pixel sources are enabled.
>
> To disable a plane, the pixel_source must be NONE or the FB must be NULL
> if pixel_source == FB.
>
> Signed-off-by: Jessica Zhang 
> ---
>  drivers/gpu/drm/drm_atomic.c| 21 ++--
>  drivers/gpu/drm/drm_atomic_helper.c | 39 
> +
>  include/drm/drm_atomic_helper.h |  4 ++--
>  include/drm/drm_plane.h | 29 +++
>  4 files changed, 64 insertions(+), 29 deletions(-)

Reviewed-by: Dmitry Baryshkov 


-- 
With best wishes
Dmitry