On 07/12/16 07:28, chry...@web.de wrote: > Howdy, > > Sorry i have no concrete solution for that. But i found a good blog that > gives a talk about privileged access to wayland. Maybe there is someuseful > information: > > http://www.mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
I just skimmed it a little, and seems interesting, thanks for sharing. Will read it when I get the time to do it properly. > > LibWSM looks like a try to implement that stuff. Maybe its a good point to > start. But the last commits are over 6 month old. > > Maybe the guy that implement global hotkey management in gnome have similar > problems and you could give a talk to them? By "global hotkey" do you mean gnome keyboard shortcuts like these? https://wiki.gnome.org/Design/OS/KeyboardShortcuts AFAIR, it is handled by gnome-shell, independently of wayland spec. > > Cheers chrys Cheers, and thanks for the link. > > > Am Mo. Dez. 5 12:31:19 2016 GMT+0100 schrieb Alejandro Piñeiro: >> On 05/12/16 00:43, Luke Yelavich wrote: >>> Hey folks. >>> I am working on accessibility for Unity 8. One thing that we need to solve >>> is >>> input event capture/processing for Orca. Whilst things work well enough >>> with >>> Qt via its X QPA plugin, the Mir QPA plugin does not do any form of >>> keyboard >>> snooping, therefore when using Orca with Qt apps under Mir, Orca's commands >>> cannot be used. I am pretty sure the same applies for Wayland as well. >> Yes, the same applies for Wayland. It is one of our oldest TODOs. We >> even had some email threads about the topic on wayland-dev some years >> ago, without too much success. The thing is that they are open to >> discuss it, but they didn't give too much hints about how to implement >> it, and we should be the ones doing it. >> >> FWIW, the issue is not only about snoop input events, but also about >> synthesize input events. >> >>> I know >>> in the case of Qt's Mir support, the developers do not want to add any form >>> of keyboard snooping such as is present in Gtk/Clutter/Qt via its X QPA >>> plugin. >> Depending on who you ask, that also happens on gtk, but even on X11. >> Fortunately, after our insistence, whey kept it on X11. Future on >> Wayland is uncertain. >> >>> I'm wondering whether anybody has done any work to spec out a cross desktop >>> solution for this problem. My understanding is that any solution would not >>> involve working on Wayland/Mir directly, since the compositor/shell is the >>> arbitor of all things input. Instead any solution would be implemented in >>> the >>> compositor/shell, so mutter, KWin, and the unity 8 shell. >> Yes, the first step, as far as I remember the chats, would be solving it >> first on the compositor. For Wayland-GNOME, would be gnome-shell. >> >>> Without having tried to spec something out myself, I don't think it would >>> be >>> that complex, probably something over DBus that allows an assistive >>> technology such as Orca to register its interest to process input events >>> with >>> the shell, at which point it is notified again via DBus when an input event >>> needs processing, and signals the shell appropriately. >> About exposing it through DBUS, at-spi already provides the API. On the >> ancient times, it was implemented using the X extension XEvIE. When that >> become unsupported, it was reimplemented with a combination of snooping >> and event polling. >> >> On a ideal world, we would like to reuse the existing at-spi API so Orca >> and any other AT could use it, reimplementing it with "something" >> available on Wayland. >> >>> I guess this si >>> something that would need amending an atspi spec somewhere, or would this >>> be >>> more along the lines of XDG? >> As I mentioned, at-spi already includes the client API (obviously, >> perhaps it could be improved). What it is missing is the Wayland/Mir >> part, that as you mention, it is more a XDG thing. The more promising >> thing (the "something" I mentioned before) I found is this: >> https://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/ >> >> It is promising because although the presentation point accessibility as >> one of the main affected, it mentions that affects other use-cases, >> meaning that we could get more traction. >> >> Unfourtunately I didn't have time to take a deep look to this proposal. >> I don't know about their current state either. >> >> Finally, other place to take a look to are screen on keyboards. They >> face similar problems, and I bet that there are Mir-based platforms with >> some kind of screen on keyboard (Ubuntu Touch?) >> >> Thanks for the interest, and good luck >> >> [1] http://www.freedesktop.org/wiki/Software/XEvIE >> >> >> >> _______________________________________________ >> gnome-accessibility-devel mailing list >> gnome-accessibility-devel@gnome.org >> https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >> _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
