Wayland client and synthetic input
Dear subscribers of wayland-devel, As a Vim motions enthusiast, it bothers me that there are too many situations where I'm forced to use a pointer input device (e.g. a mouse) to perform an action. I looked around to see if anyone has developed a tool that would allow me to move or teleport the pointer to a specific location on the screen and perform a click action using keyboard keystrokes. I did not find it, so I decided to create it myself. I have recently started to learn the programming language Rust. I thought this would be a great opportunity to improve my Rust skills, too. As someone new to both Wayland and Rust, I dove into the Wayland documentation and related Rust crates. Thus far, I have not found any documentation on how to send synthetic input (i.e. mouse movements) to the display server as a Wayland client. According to some LLMs, synthetic input is even heavily restricted in Wayland due to security reasons, making my quest to create this tool impossible. I would like to ask for your input (no pun intended) on this. Is it true what the LLMs are saying? If so, are there alternative ways to develop such a tool? I'm looking forward to your responses. Sincerely, Zarif Atai
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
On 5/15/25 15:39, Daniel Stone wrote: > Hi, > > On Thu, 15 May 2025 at 19:02, Harry Wentland wrote: >> On 2025-05-15 13:19, Daniel Stone wrote: >>> Yeah, the Weston patches are marching on. We've still been doing a >>> little bit of cleanup and prep work in the background to land them, >>> but we also can't land them until the kernel lands. None of that work >>> is material to the uAPI though: as said previously, the uAPI looks >>> completely solid and it's something we can definitely beneficially use >>> in Weston. (Even if we do need the obvious follow-ons for >>> post-blending as well ...) >> >> We can't merge kernel uAPI without canonical userspace that uses it. >> To move forward we'll need a userspace to at least publish a branch >> that shows the use of this new uAPI. >> >> Do you have a public branch for the Weston work for this? > > Yeah, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1702 > has been around for a little while now. There are some driver bugs > that Leandro commented on, but they don't seem material to the uAPI as > such? Hello, Yes, there's nothing related to the API that is blocking us. It seemed very flexible and easy to use. The bugs that I've spotted are probably internal to AMD driver. I'd say that the Weston patches are converging nicely, we just need time to get them fully reviewed. We had a few preparation MR's to land before !1702, and now there's only one left (!1617). Thanks, Leandro > > Cheers, > Daniel
Re: Wayland client and synthetic input
You may find one of these projects helpful: https://github.com/rvaiya/warpd https://github.com/moverest/wl-kbptr https://github.com/gabcoh/keynav-wayland https://github.com/tadeokondrak/waypoint I believe all of them support the virtual-pointer protocol. Mine (waypoint) supports libei as well, but it isn't as complete or documented as some of the others. -- Tadeo On Wed, May 14, 2025, at 17:27, Zarif Atai wrote: > Dear subscribers of wayland-devel, > > As a Vim motions enthusiast, it bothers me that there are too many situations > where I'm forced to use a pointer input device (e.g. a mouse) to perform an > action. I looked around to see if anyone has developed a tool that would > allow me to move or teleport the pointer to a specific location on the screen > and perform a click action using keyboard keystrokes. I did not find it, so I > decided to create it myself. I have recently started to learn the programming > language Rust. I thought this would be a great opportunity to improve my Rust > skills, too. > > As someone new to both Wayland and Rust, I dove into the Wayland > documentation and related Rust crates. Thus far, I have not found any > documentation on how to send synthetic input (i.e. mouse movements) to the > display server as a Wayland client. According to some LLMs, synthetic input > is even heavily restricted in Wayland due to security reasons, making my > quest to create this tool impossible. > > I would like to ask for your input (no pun intended) on this. Is it true what > the LLMs are saying? If so, are there alternative ways to develop such a tool? > > I'm looking forward to your responses. > > Sincerely, > Zarif Atai
Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> new drm_colorop_type: DRM_COLOROP_3D_LUT.
>
> Signed-off-by: Alex Hung
> ---
> v8:
> - Fix typo in subject (Simon Ser)
> - Update documentation for DRM_COLOROP_3D_LUT (Simon Ser)
> - Delete empty lines (Simon Ser)
>
> v7:
> - Simplify 3D LUT by removing lut_3d_modes and related functions (Simon Ser)
>
> drivers/gpu/drm/drm_atomic.c | 6 +++
> drivers/gpu/drm/drm_atomic_uapi.c | 6 +++
> drivers/gpu/drm/drm_colorop.c | 72 +++
> include/drm/drm_colorop.h | 21 +
> include/uapi/drm/drm_mode.h | 33 ++
> 5 files changed, 138 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 0efb0ead204a..ef47a06344f3 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -806,6 +806,12 @@ static void drm_atomic_colorop_print_state(struct
> drm_printer *p,
> case DRM_COLOROP_MULTIPLIER:
> drm_printf(p, "\tmultiplier=%llu\n", state->multiplier);
> break;
> + case DRM_COLOROP_3D_LUT:
> + drm_printf(p, "\tsize=%d\n", colorop->lut_size);
> + drm_printf(p, "\tinterpolation=%s\n",
> +
> drm_get_colorop_lut3d_interpolation_name(colorop->lut3d_interpolation));
> + drm_printf(p, "\tdata blob id=%d\n", state->data ?
> state->data->base.id : 0);
> + break;
> default:
> break;
> }
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 947c18e8bf9b..d5d464b4d0f6 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -719,6 +719,10 @@ static int drm_atomic_color_set_data_property(struct
> drm_colorop *colorop,
> case DRM_COLOROP_CTM_3X4:
> size = sizeof(struct drm_color_ctm_3x4);
> break;
> + case DRM_COLOROP_3D_LUT:
> + size = colorop->lut_size * colorop->lut_size *
> colorop->lut_size *
> + sizeof(struct drm_color_lut);
> + break;
> default:
> /* should never get here */
> return -EINVAL;
> @@ -771,6 +775,8 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> *val = state->multiplier;
> } else if (property == colorop->lut_size_property) {
> *val = colorop->lut_size;
> + } else if (property == colorop->lut3d_interpolation_property) {
> + *val = colorop->lut3d_interpolation;
> } else if (property == colorop->data_property) {
> *val = (state->data) ? state->data->base.id : 0;
> } else {
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index e03706e7179b..224c6be237d2 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -67,6 +67,7 @@ static const struct drm_prop_enum_list
> drm_colorop_type_enum_list[] = {
> { DRM_COLOROP_1D_LUT, "1D LUT" },
> { DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
> { DRM_COLOROP_MULTIPLIER, "Multiplier"},
> + { DRM_COLOROP_3D_LUT, "3D LUT"},
> };
>
> static const char * const colorop_curve_1d_type_names[] = {
> @@ -82,6 +83,11 @@ static const struct drm_prop_enum_list
> drm_colorop_lut1d_interpolation_list[] =
> { DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR, "Linear" },
> };
>
> +
> +static const struct drm_prop_enum_list
> drm_colorop_lut3d_interpolation_list[] = {
> + { DRM_COLOROP_LUT3D_INTERPOLATION_TETRAHEDRAL, "Tetrahedral" },
> +};
> +
> /* Init Helpers */
>
> static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
> *colorop,
> @@ -349,6 +355,51 @@ int drm_colorop_mult_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> }
> EXPORT_SYMBOL(drm_colorop_mult_init);
>
> +int drm_colorop_3dlut_init(struct drm_device *dev, struct drm_colorop
> *colorop,
> + struct drm_plane *plane,
> + uint32_t lut_size,
> + enum drm_colorop_lut3d_interpolation_type
> interpolation,
> + bool allow_bypass)
> +{
> + struct drm_property *prop;
> + int ret;
> +
> + ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_3D_LUT,
> allow_bypass);
> + if (ret)
> + return ret;
> +
> + /* LUT size */
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE |
> DRM_MODE_PROP_ATOMIC,
> +"SIZE", 0, UINT_MAX);
> + if (!prop)
> + return -ENOMEM;
> +
> + colorop->lut_size_property = prop;
> + drm_object_attach_property(&colorop->base,
> colorop->lut_size_property, lut_size);
> +
Re: Wayland client and synthetic input
Hi Zarif, On Fri, 16 May 2025 at 11:54, Zarif Atai wrote: > Dear subscribers of wayland-devel, > > As a Vim motions enthusiast, it bothers me that there are too many > situations where I'm forced to use a pointer input device (e.g. a mouse) to > perform an action. I looked around to see if anyone has developed a tool > that would allow me to move or teleport the pointer to a specific location > on the screen and perform a click action using keyboard keystrokes. I did > not find it, so I decided to create it myself. I have recently started to > learn the programming language Rust. I thought this would be a great > opportunity to improve my Rust skills, too. > > As someone new to both Wayland and Rust, I dove into the Wayland > documentation and related Rust crates. Thus far, I have not found any > documentation on how to send synthetic input (i.e. mouse movements) to the > display server as a Wayland client. According to some LLMs, synthetic input > is even heavily restricted in Wayland due to security reasons, making my > quest to create this tool impossible. > > I would like to ask for your input (no pun intended) on this. Is it true > what the LLMs are saying? If so, are there alternative ways to develop such > a tool? > Some would argue that this does not really belong to Wayland (the protocols), yet that does not mean this is impossible, I would suggest looking into libei: https://gitlab.freedesktop.org/libinput/libei That, however, requires that the Wayland compositor supports the relevant portal API and libei itself, of course, which is the case of KDE and GNOME (and possibly others, but I do not know all of the compositors). HTH Cheers Olivier
Re: Wayland client and synthetic input
On Wed, May 14, 2025 at 11:27:50PM +, Zarif Atai wrote: > Dear subscribers of wayland-devel, > > As a Vim motions enthusiast, it bothers me that there are too many situations > where I'm forced to use a pointer input device (e.g. a mouse) to perform an > action. I looked around to see if anyone has developed a tool that would > allow me to move or teleport the pointer to a specific location on the screen > and perform a click action using keyboard keystrokes. I did not find it, so I > decided to create it myself. I have recently started to learn the programming > language Rust. I thought this would be a great opportunity to improve my Rust > skills, too. > > As someone new to both Wayland and Rust, I dove into the Wayland > documentation and related Rust crates. Thus far, I have not found any > documentation on how to send synthetic input (i.e. mouse movements) to the > display server as a Wayland client. According to some LLMs, synthetic input > is even heavily restricted in Wayland due to security reasons, making my > quest to create this tool impossible. > > I would like to ask for your input (no pun intended) on this. Is it true what > the LLMs are saying? If so, are there alternative ways to develop such a tool? While not strictly Wayland, you can inject synthetic input via libei using the remote desktop portal. It does so with sandboxing/security in mind, by being a portal. See https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html for details. Whether it works on your compositor depends on the portal backend used. Some compositors may support the virtual keyboard or virtual pointer protocols as well. See https://wayland.app/protocols/wlr-virtual-pointer-unstable-v1 and https://wayland.app/protocols/virtual-keyboard-unstable-v1. Jonas > > I'm looking forward to your responses. > > Sincerely, > Zarif Atai
