<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr"><div>Hi Alexander,</div><br></div><div dir="ltr" class="gmail_attr">On Tue, Mar 18, 2025 at 9:09 AM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 18, 2025 at 12:33 AM Alexander Zvegintsev <<a href="mailto:alexander.zvegintsev@oracle.com" target="_blank">alexander.zvegintsev@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
      Do I understand correctly that there is no restore token
      functionality available for plain XTestFake* calls,</div></blockquote><div><br></div><div>More or less, what I am saying is that when using XTEST, the client which actually connects to EI is Xwayland itself, on behalf of the X11 application who "speaks" X11 only, but Xwayland doesn't support the restore tokens so the portal dialog will show up.</div><div><br></div><div>Xwayland keeps the connection to EI active for a period of time so that the portal dialog does not show up continuously for every single XTEST request however.</div><div><br></div><div>That is also a reason having restore tokens might not be desirable for Xwayland, because Xwayland acts on behalf of the X11 clients and reusing restore tokens would be like giving full unrestricted access to *any* X11 client, any time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> and you
      suggest not using the XTEST and using one of the following for
      mouse/keyboard control? <br></div></blockquote><div><br></div><div>No, I was thinking of optionally disabling the XTEST / EI connection for Xwayland  in mutter (as mutter spawns Xwayland) as a temporary workaround so that XTEST still works for X11 applications.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p></p>
    <ul>
      <li>org.freedesktop.portal.RemoteDesktop.ConnectToEIS and use
        libei sendercontext</li>
      <li>org.freedesktop.portal.RemoteDesktop.NotifyPointerMotionAbsolute
        / NotifyPointerButton /NotifyPointerAxisDiscrete /
        NotifyKeyboardKeycode / etc</li>
    </ul>
    <p>I quickly tried the latter and it seems to work fine on OEL 10 as
      expected.</p></div></blockquote><div>Right, I guess you could work around the problem like that, but that means you have specific code paths in Wakefiled even for the X11 / Xwayland case, maybe that's OK for you. ~~But that could be seen as a hack as well, abusing the RemoteDesktop API~~.</div></div></div></blockquote><div><br></div><div>Sorry, I realize what I wrote in that sentence above is plain wrong, the RemoteDesktop API is the one to use indeed, if that's something you're willing to implement in Wakefiled directly (and not rely on X11 XTEST).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Anyway, if you want to have an option in mutter to not Xwayland with EI support (the temporary workaround you mentioned), best would be to file an issue against mutter upstream [1] as usual and we can work from there.</div></div></div></blockquote><div> </div><div>Sorry again ,</div><div>Olivier</div></div></div>