Re: what we need from X (was Re: Wayland)

[Alan Coopersmith <alan coopersmith oracle com>]

On 05/ 8/12 05:10 AM, Piñeiro wrote:
> Hi Alan, thanks for your mail, and sorry for the delay in my answer, I
> have been doing some research.

And I've been at a conference this week, so was delayed responding myself.

I hope you don't mind that I've taken the liberty of cc'ing the X.Org
development list so the developers working on the input handling in X
(and even some of the ones working on the input handling in Wayland)
can see and respond to these issues.

> On 05/07/2012 04:22 PM, Alan Coopersmith wrote:
>> On 05/ 7/12 03:35 AM, Piñeiro wrote:
>>> One of the current problems big problems is related to key events. In a
>>> short, as XEvIE is dead, we can't track key events directly from X
>>> server, so we are doing a key snooping on the application, and
>>> forwarding it via DBUS. This is not really performant, can have some
>>> collateral effects, and is the only remaining thing that makes X not
>>> really transparent to ATK.
>> BTW, from the X.Org developer point of view, one of the reasons we let
>> XEvIE die was because it didn't seem like anyone required it, or even
>> really noticed that it had been broken for a couple releases before the
>> removal.   If there are requirements from X or Wayland that are going
>> unmet, step 1 is letting the developers of those systems know.
>>
> 
> Well, I was not here when XEvIE was born or was let to die, so probably
> the info that I have is incomplete. As I was told, XEvIE was not let die
> because nobody required it, but because was maintainerless. In fact,
> Daniel Stone mentioned that was somewhat broken since day 1 (see his
> comment at the end of my post here [2]). Googling a little, I found this
> interesting mail [3] (also written by you). And it seems that main
> consumer of XEvIE was gok (in fact, AFAIK, just one app could use XEvIE
> at the same time, so at-spi was being used as a kind of wrapper).

I think the two went hand in hand - it wasn't being maintained because it
wasn't seen as generally needed.  Like GNOME, X.Org development is done
either by employees of corporations meeting their corporate needs (in X's
case, mostly OS/distro vendors or graphics/input device vendors) or
volunteers working on the parts that personally interest them or meet
their needs.   And as noted in the mail of mine from 2010, there was
some thought that the more general solutions in later Xinput releases
could be used instead of the special purpose solution in XEvIE.

> Register to global key events on ATK based on server-side key snooping
> was added since the beginning at 2001. XEvIE support on at-spi was added
> on 2003, and mainly to be used by gok. So I assume (please see my
> previous "probably the info that I have is incomplete", correct me if
> I'm wrong), that the problem was that XEvIE was hard to maintain (or at
> least not really maintained), and the main functionality required was
> provided by key snooping on ATK (as Orca was well maintained, gok was
> deprecated, and Caribou seems to no require it (yet)). So taking into
> account the low amount of resources of the accessibility team, the
> conclusion is that live without XEvIE was, not fine, but assumable.
> 
> Having said so, I think that we need something like XEvIE. Not the
> package, but the functionality, or part of it. As I'm not an X expert, I
> can't tell if what X provides now is enough. So after take a look to
> what we have on at-spi2-core:
>   * In order to implement atspi_register_device_event_listener:
>     * Listen Mouse movement events: calling XQueryPointer on a idle call
> (this sounds somewhat hacky and intrusive)
>   * In order to implement atspi_generate_mouse_event
>     * Generate Mouse events with  XTestFakeRelativeMotionEvent,
> XTestFakeButtonEvent, etc
>   * In order to implement atspi_register_keystroke_listener:
>     * key snooping on the server side (ATK or Qt)
>   * In order to implement atspi_generate_keyboard_event:
>     * Generate key event with XTestFakeKeyEvent
> 
> Additionally, in this research I found that right now
> atspi_register_device_event_listener only works with mouse events
> (improve documentation required). As part of the implementation of this
> listener I found a process to get and filter events (on event-source.c)
> based on XPending, XNextEvent and XFilterEvent. So I'm not sure if this
> could be applied to also listen to key events.
> 
> At this moment the priority is getting rid of the server-side
> (application-side) key snooping in order to forward key events. So Alan
> (or anyone reading), do you think that this could be achievable with X
> but without XEviE (Daniel Stone seems to discourage that on my post
> comment [2])?
> 
> PD: Having said so, X event management in at-spi (and AFAIS in general)
> is somewhat messy. For example, as at-spi2 started as a C&P of at-spi
> there are still code related with XEviE in spite that since the
> beginning was said that it should be removed [5]
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=649559#c2
> [2]
> http://blogs.igalia.com/apinheiro/2012/01/19/atkat-spi2-hackfest-2012-day-1/
> [3]
> http://mail.opensolaris.org/pipermail/accessibility-discuss/2010-April/000185.html
> [4] https://live.gnome.org/Gok
> [5]
> http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atk/at-spi/at-spi_on_d-bus

Unfortunately, I'm not deeply enough involved in the input side to know what
the answers are here - I'm just trying to provide a catalyst to get the right
people talking to each other.  Hopefully the input guys on xorg-devel can
provide some answers, or consider what changes need to be made to Xinput (or
Wayland input) to better meet the needs of accessibility helpers/frameworks.
Thank you for providing such detailed information for them to consider.

-- 
	-Alan Coopersmith-              alan coopersmith oracle com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc