Mouse polling in the registryd is disabled by default and can't be enabled by clients. In the old registryd this was possible by calling registerGlobalEventListener.
Confirmed that mouse movement events are no longer registered.
There is an issue with the registration. Mouse events are a VERY strange thing in AT-SPI. Its obvious that at some points KeyboardEvents and MouseEvents had the same structure/format as a normal AT-SPI 'Event' with a type, major, minor detail1..ect. Keyboard events are no longer like this, presumably because more information was required. They are now packaged as a 'DeviceEvent' with a totally different structure. Unfortunately mouse movement events remained the same format as a normal at-spi event. So we are in the strange situation that different device events have different formats.
When moving over to D-Bus we have messed this situation up even further. Because normal events don't need to be consumed we have changed them to D-Bus signals. This means that mouse events don't only have a different format to keyboard events but a different registration mechanism also. This hasn't been reflected in the deviceventcontroller. Its still assuming that mouse events are 'registered' with it before it starts to poll. Unfortunately this no longer happens. All mouse events are signals, so registration takes place with the D-Bus bus and not the registry daemon. Polling never gets started.
This bug must have been introduced a long time ago when we 'fixed' the issue regarding continuous polling of mouse movement.
Always poll (BAD)
Have clients inform the registryd when they need the mouse polled.
- This involves adding new methods ("MousePollAdd", "MousePollRemove")
Clients should then call these when they register/deregister
any mouse movement events.
Created attachment 33212 [details] [review]
Add mouse poll methods
Thanks for the explanation Mark.
The attached patch adds MousePollAdd and MousePollRemove to the DeviceEventController interface.