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
