[External] : Re: Automated testing with XTEST wired to the libEI

Alexander Zvegintsev alexander.zvegintsev at oracle.com
Mon Mar 17 23:32:57 UTC 2025


Hi Olivier,

thank you for the reply

> Remote desktop has now support for persistent sessions [1] [2] , but 
> using it might be tricky for Xwayland for a variety of reasons.
>
> First, it would need to be supported in liboeffis [3] as this is what 
> Xwayland uses, but then it would also need a way to store the token to 
> restore the session later, and Xwayland doesn't save any data nor has 
> any configuration file.

Do I understand correctly that there is no restore token functionality 
available for plain XTestFake* calls, and you suggest not using the 
XTEST and using one of the following for mouse/keyboard control?

  * org.freedesktop.portal.RemoteDesktop.ConnectToEIS and use libei
    sendercontext
  * org.freedesktop.portal.RemoteDesktop.NotifyPointerMotionAbsolute /
    NotifyPointerButton /NotifyPointerAxisDiscrete /
    NotifyKeyboardKeycode / etc

I quickly tried the latter and it seems to work fine on OEL 10 as expected.


Thanks,
Alexander.

On 3/14/25 17:57, Olivier Fourdan wrote:
> Hi Alexander,
>
>
> On Fri, Mar 14, 2025 at 4:24 PM Alexander Zvegintsev 
> <alexander.zvegintsev at oracle.com> wrote:
>
>     I have a question related to XTEST wired to the libEI.
>
>     There is a user confirmation for remote interaction
>     <https://bugs.openjdk.org/secure/attachment/113761/confirmation.png>
>     on the XTestFake* calls, but once granted it does not persist
>     across reboots or may timeout after a certain period of time of
>     inactivity.
>
>     This basically blocks the automated testing on OEL 10.
>
>
>     Is there a way to make this confirmation persistent?
>
>
> Remote desktop has now support for persistent sessions [1] [2] , but 
> using it might be tricky for Xwayland for a variety of reasons.
>
> First, it would need to be supported in liboeffis [3] as this is what 
> Xwayland uses, but then it would also need a way to store the token to 
> restore the session later, and Xwayland doesn't save any data nor has 
> any configuration file.
>
>     Or is there a way to disable this connection between XTEST and
>     libEI? (as a temporary solution, so that the XTestFake* calls only
>     affect the Xwayland without user prompt)
>
>
> Xwayland itself does not enable it by default and has a command line 
> option to explicitly enable the EI portal support (-enable-ei-portal) 
> but with Xwayland rootless, Xwayland is started by the Wayland 
> compositor automatically and GNOME Shell / mutter does not offer a way 
> to customize the command line so there is no way to disable it in the 
> default Xwayland rootless case.
>
> GNOME Shell mutter has options to disable selected X11 extensions so 
> it is possible to disable XTEST support entirely, but that would break 
> your tests completely.
>
> Easiest would be to add a way in mutter to optionally disable 
> „-enable-ei-portal“ when it starts Xwayland, but that's a bit of a 
> hack, not sure it would be acceptable for mutter, but we can try.
>
> Cheers
> Olivier
>
>
> [1] https://github.com/flatpak/xdg-desktop-portal/issues/850 
> <https://urldefense.com/v3/__https://github.com/flatpak/xdg-desktop-portal/issues/850__;!!ACWV5N9M2RV99hQ!IW3eBARlVJ5C165UfiNGqJN_zPrEg1_pUiy-Q_MXcM66P-HKJbyqw1DM-ZkfnU_GcgCx7c-LvVDoZpwtnMMh3WupopI$>
> [2] https://github.com/flatpak/xdg-desktop-portal/pull/1004 
> <https://urldefense.com/v3/__https://github.com/flatpak/xdg-desktop-portal/pull/1004__;!!ACWV5N9M2RV99hQ!IW3eBARlVJ5C165UfiNGqJN_zPrEg1_pUiy-Q_MXcM66P-HKJbyqw1DM-ZkfnU_GcgCx7c-LvVDoZpwtnMMhsgcwpeE$>
> [3] 
> https://libinput.pages.freedesktop.org/libei/api/index.html#sec-oeffis 
> <https://urldefense.com/v3/__https://libinput.pages.freedesktop.org/libei/api/index.html*sec-oeffis__;Iw!!ACWV5N9M2RV99hQ!IW3eBARlVJ5C165UfiNGqJN_zPrEg1_pUiy-Q_MXcM66P-HKJbyqw1DM-ZkfnU_GcgCx7c-LvVDoZpwtnMMhR3MOb-8$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/wakefield-dev/attachments/20250318/299c418c/attachment.htm>


More information about the wakefield-dev mailing list