<div dir="ltr"><br><div class="gmail_extra">On Wed, Dec 11, 2013 at 2:15 PM, Piņeiro <span dir="ltr"><<a href="mailto:apinheiro@igalia.com" target="_blank">apinheiro@igalia.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 12/11/2013 07:09 PM, Giulio Camuffo wrote:<br>
> Wayland doesn't have a way to inject mouse events currently. Some<br>
> protocol must be written, which would be presumably implemented as a<br>
> private protocol which only trusted clients can use, given the<br>
> security implications.<br>
<br>
</div>I was guessing about that. While reading about Wayland, I found this<br>
extension:<br>
<a href="https://github.com/01org/wayland-fits" target="_blank">https://github.com/01org/wayland-fits</a><br>
<br>
And as you can read on the description:<br>
<br>
"The first protocol is a interface for generating input events<br>
on the server-side (e.g. mouse, keyboard, touch)."<br>
<br>
<br>
What I was not sure if that would the one to go for accessibility needs,<br>
and also if implemented as a private protocol, how at-spi2 could use it.<br>
Or in other words, how declare at-spi2 as a trusted client</blockquote><div><br></div><div>A trusted client has to effectively be launched by the compositor, it cannot just be started by the user or another application in the session. It could be stored in compositor configuration that is not changeable at runtime.<br>
<br></div><div>Of course, if at-spi2 is launched as a trusted client, and then just exports the capability of the private protocol (injecting arbitrary input) over its own d-bus api, then the trust is misplaced because all apps can then inject input just by talking d-bus to at-spi2 instead of talking directly to the compositor...<br>
<br></div><div>So I think the trusted client will have to be orca itself.<br></div></div><br></div></div>