Re: Wayland/weston, Qt and RDP connection...
On Wed, Jan 18, 2023 at 12:12:43PM +, Matti Ristimäki wrote: > Hi, Hi, > > > > Thanks for the reply! > > > > Of course in our embedded system the CPX Control Panel(Qt) works normally > via (HDMI) without any problems. And when it is running, it uses > WAYLAND_DISPLAY=wayland-0 and DRM back-end. > > > > > > Question: > > > > One shall never start the "second" Weston if screen sharing is desired, only > the screen-share plugin in the "first" Weston can do that. > > > > For some reason, the rdp-backend is not started even if the screen-share.so' > module is loaded? > > I’m just missing some RDP related configuration in the weston.ini…? You need at least weston 10, for that start-on-startup to work. Otherwise you'll have to perform Mod+Alt+s on the keyboard to start screen sharing. > > > > > > Here is two test using CPX Control Panel(Qt) and weston-simple-egl. > > > > --- > > --- > > > > > > Testing with CPX Control Panel(Qt) > > > > --- > > > > root@sm2s-imx8mp:~# ls -la /run/user/0/ > > total 48 > > drwx-- 3 root root 140 Jan 18 10:57 . > > drwxr-xr-x 3 root root60 Jan 18 10:09 .. > > srw-rw-rw- 1 root root 0 Jan 18 10:09 bus > > drwxr-xr-x 4 root root 120 Jan 18 10:09 systemd > > srwxr-xr-x 1 root root 0 Jan 18 10:57 wayland-0 > > -rw-r- 1 root root 0 Jan 18 10:46 wayland-0.lock > > -rw-r--r-- 1 root root 45744 Jan 18 10:57 weston.log > > > > --- > > > > root@sm2s-imx8mp:/opt/cpx# systemctl status cpx > > ● cpx.service - Planmeca Dental Unit CPX Control Panel > > Loaded: loaded (/lib/systemd/system/cpx.service; enabled; vendor preset: > enabled) > > Active: active (running) since Wed 2023-01-18 12:28:02 CET; 11s ago > >Main PID: 1424 (cpx.sh) > > Tasks: 13 (limit: 880) > > Memory: 44.5M > > CGroup: /system.slice/cpx.service > > ├─1424 /bin/bash /opt/cpx/cpx.sh > > └─1428 ./cpx --rotate=0 > > > > > > --- > > > > > > root@sm2s-imx8mp:/opt/cpx# tail -f /run/user/0/weston.log > > [12:27:59.698] Output 'HDMI-A-1' enabled with head(s) HDMI-A-1 > > [12:27:59.698] Compositor capabilities: > >arbitrary surface rotation: yes > >screen capture uses y-flip: yes > >presentation clock: CLOCK_MONOTONIC, id 1 > >presentation clock resolution: 0.1 s > > [12:27:59.699] Loading module '/usr/lib/weston/kiosk-shell.so' > > [12:27:59.700] Loading module '/usr/lib/weston/screen-share.so' > > [12:27:59.700] Loading module '/usr/lib/weston/systemd-notify.so' > > [12:27:59.700] info: add 1 socket(s) provided by systemd > > > > > > --- > > > > CPX Control Panel starts normally, but the rdp-backend is not started even if > the screen-share.so' module is loaded. > > > > > > [cid:image001.png@01D92B46.ED2859D0] > > > > > > > > > > --- > > --- > > > > > > > > Testing with weston-simple-egl > > > > When starting weston-simple-egl, it runs normally as well using drm. (And > also screen-share.so is running.) > > > > --- > > > > > > root@sm2s-imx8mp:~# ls -la /run/user/0/ > > total 48 > > drwx-- 3 root root 140 Jan 18 10:57 . > > drwxr-xr-x 3 root root60 Jan 18 10:09 .. > > srw-rw-rw- 1 root root 0 Jan 18 10:09 bus > > drwxr-xr-x 4 root root 120 Jan 18 10:09 systemd > > srwxr-xr-x 1 root root 0 Jan 18 10:57 wayland-0 > > -rw-r- 1 root root 0 Jan 18 10:46 wayland-0.lock > > -rw-r--r-- 1 root root 45744 Jan 18 10:57 weston.log > > > > > > --- > > > > > > root@sm2s-imx8mp:/opt/cpx# systemctl status cpx > > ● cpx.service - Planmeca Dental Unit CPX Control Panel > > Loaded: loaded (/lib/systemd/system/cpx.ser
Re: [RFC PATCH v3 1/3] drm: Introduce solid fill property for drm plane
On 1/4/23 18:40, Jessica Zhang wrote:
> Add support for solid_fill property to drm_plane. In addition, add
> support for setting and getting the values for solid_fill.
>
> solid_fill holds data for supporting solid fill planes. The property
> accepts an RGB323232 value and the driver data is formatted as such:
>
> struct drm_solid_fill {
> u32 r;
> u32 g;
> u32 b;
> };
Rather than special-casing this would it make sense to define this
as a single pixel of a FOURCC property?
I.e., something like this:
struct drm_solid_fill_info {
u32 format; /* FOURCC value */
u64 value; /* FOURCC pixel value */
}
That removes some ambiguity how the value should be interpreted, i.e.,
it can be interpreted like a single pixel of the specified FOURCC format.
It might also make sense to let drivers advertise the supported
FOURCC formats for solid_fill planes.
Is there an implementation for this in a corresponding canonical
upstream userspace project, to satisfy [1]? If not, what is the plan
for this? If so, please point to the corresponding patches.
[1]
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
Harry
>
> To enable solid fill planes, userspace must assigned solid_fill to a
> property blob containing the following information:
>
> struct drm_solid_fill_info {
> u8 version;
> u32 r, g, b;
> };
>
> Changes in V2:
> - Changed solid_fill property to a property blob (Simon, Dmitry)
> - Added drm_solid_fill struct (Simon)
> - Added drm_solid_fill_info struct (Simon)
>
> Changes in V3:
> - Corrected typo in drm_solid_fill struct documentation
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 9
> drivers/gpu/drm/drm_atomic_uapi.c | 59 +++
> drivers/gpu/drm/drm_blend.c | 17 +++
> include/drm/drm_blend.h | 1 +
> include/drm/drm_plane.h | 43 +
> 5 files changed, 129 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index dfb57217253b..c96fd1f2ad99 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -253,6 +253,11 @@ void __drm_atomic_helper_plane_state_reset(struct
> drm_plane_state *plane_state,
> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>
> + if (plane_state->solid_fill_blob) {
> + drm_property_blob_put(plane_state->solid_fill_blob);
> + plane_state->solid_fill_blob = NULL;
> + }
> +
> if (plane->color_encoding_property) {
> if (!drm_object_property_get_default_value(&plane->base,
>
> plane->color_encoding_property,
> @@ -335,6 +340,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
> if (state->fb)
> drm_framebuffer_get(state->fb);
>
> + if (state->solid_fill_blob)
> + drm_property_blob_get(state->solid_fill_blob);
> +
> state->fence = NULL;
> state->commit = NULL;
> state->fb_damage_clips = NULL;
> @@ -384,6 +392,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
> drm_crtc_commit_put(state->commit);
>
> drm_property_blob_put(state->fb_damage_clips);
> + drm_property_blob_put(state->solid_fill_blob);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index c06d0639d552..8a1d2fb7a757 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -316,6 +316,55 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> }
> EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);
>
> +static void drm_atomic_convert_solid_fill_info(struct drm_solid_fill *out,
> + struct drm_solid_fill_info *in)
> +{
> + out->r = in->r;
> + out->g = in->g;
> + out->b = in->b;
> +}
> +
> +static int drm_atomic_set_solid_fill_prop(struct drm_plane_state *state,
> + struct drm_property_blob *blob)
> +{
> + int ret = 0;
> + int blob_version;
> +
> + if (blob == state->solid_fill_blob)
> + return 0;
> +
> + drm_property_blob_put(state->solid_fill_blob);
> + state->solid_fill_blob = NULL;
> +
> + memset(&state->solid_fill, 0, sizeof(state->solid_fill));
> +
> + if (blob) {
> + if (blob->length != sizeof(struct drm_solid_fill_info)) {
> + drm_dbg_atomic(state->plane->dev,
> + "[PLANE:%d:%s] bad solid fill blob
> length: %zu\n",
> + state->plane->base.id,
> state->plane->name,
> + blob
Re: [RFC PATCH v3 1/3] drm: Introduce solid fill property for drm plane
On 1/18/2023 10:57 AM, Harry Wentland wrote:
On 1/4/23 18:40, Jessica Zhang wrote:
Add support for solid_fill property to drm_plane. In addition, add
support for setting and getting the values for solid_fill.
solid_fill holds data for supporting solid fill planes. The property
accepts an RGB323232 value and the driver data is formatted as such:
struct drm_solid_fill {
u32 r;
u32 g;
u32 b;
};
Rather than special-casing this would it make sense to define this
as a single pixel of a FOURCC property?
I.e., something like this:
struct drm_solid_fill_info {
u32 format; /* FOURCC value */
u64 value; /* FOURCC pixel value */
}
That removes some ambiguity how the value should be interpreted, i.e.,
it can be interpreted like a single pixel of the specified FOURCC format.
It might also make sense to let drivers advertise the supported
FOURCC formats for solid_fill planes.
Hi Harry,
The initial v1 of this RFC had support for taking in a format and such,
but it was decided that just supporting RGB323232 would work too.
Here's the original thread discussing it [1], but to summarize, the work
needed to convert the solid fill color to RGB is trivial (as it's just a
single pixel of data). In addition, supporting various formats for
solid_fill would add complexity as we'd have to communicate which
formats are supported.
[1]
https://lists.freedesktop.org/archives/dri-devel/2022-November/379148.html
Is there an implementation for this in a corresponding canonical
upstream userspace project, to satisfy [1]? If not, what is the plan
for this? If so, please point to the corresponding patches.
The use case we're trying to support here is the Android HWC SOLID_FILL
hint [1], though it can also be used to address the Wayland single pixel
FB protocol [2]. I'm also planning to add an IGT test to show an example
of end to end usage.
[1]
https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/master/graphics/composer/aidl/android/hardware/graphics/composer3/Composition.aidl#52
[2]
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
Thanks,
Jessica Zhang
[1]
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
Harry
To enable solid fill planes, userspace must assigned solid_fill to a
property blob containing the following information:
struct drm_solid_fill_info {
u8 version;
u32 r, g, b;
};
Changes in V2:
- Changed solid_fill property to a property blob (Simon, Dmitry)
- Added drm_solid_fill struct (Simon)
- Added drm_solid_fill_info struct (Simon)
Changes in V3:
- Corrected typo in drm_solid_fill struct documentation
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic_state_helper.c | 9
drivers/gpu/drm/drm_atomic_uapi.c | 59 +++
drivers/gpu/drm/drm_blend.c | 17 +++
include/drm/drm_blend.h | 1 +
include/drm/drm_plane.h | 43 +
5 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index dfb57217253b..c96fd1f2ad99 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -253,6 +253,11 @@ void __drm_atomic_helper_plane_state_reset(struct
drm_plane_state *plane_state,
plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
+ if (plane_state->solid_fill_blob) {
+ drm_property_blob_put(plane_state->solid_fill_blob);
+ plane_state->solid_fill_blob = NULL;
+ }
+
if (plane->color_encoding_property) {
if (!drm_object_property_get_default_value(&plane->base,
plane->color_encoding_property,
@@ -335,6 +340,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
if (state->fb)
drm_framebuffer_get(state->fb);
+ if (state->solid_fill_blob)
+ drm_property_blob_get(state->solid_fill_blob);
+
state->fence = NULL;
state->commit = NULL;
state->fb_damage_clips = NULL;
@@ -384,6 +392,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
drm_property_blob_put(state->fb_damage_clips);
+ drm_property_blob_put(state->solid_fill_blob);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index c06d0639d552..8a1d2fb7a757 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -316,6 +316,55 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
}
EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);
+static voi
