GNOME Bugzilla – Bug 517888
Missing events of buttons 4 and 5
Last modified: 2021-07-05 10:44:51 UTC
I'm developing an accessible application that needs to listen the mouse events. While I was writing my code I realized that the events of buttons 4 and 5 of the mouse (Scroll Wheel) aren't registered by at-spi and of course by pyatspi. I hope this can be fixed and if needed I think I can help. Thanks Greetings
I am looking at the code registryd/deviceeventcontroller.c:impl_generate_mouse_event. Button 4 and 5 are handled there. It should work. Is pyatspi the only binding you used? Add Eitan to the bug to see if he has any idea about what happens in pyatspi.
Exactly!! I saw the same file and function before registering the bug and I saw that the buttons are handled there, but the event doesn't seems to be registered and that is exactly the strange thing. :-( I added to pyatspi/constants.py/ the constants for buttons 4 and 5. (MOUSE_B4P, MOUSE_B5P) and I was able to generate an event with buttons 4 and 5, like this: pyatspi.Registry.generateMouseEvent( X, Y, pyatspi.MOUSE_B4P ) Then I added to the same file 'mouse:button:4p', 'mouse:button:4r', 'mouse:button:5p', 'mouse:button:5r' to the EVENT_TREE, but the event isn't registered yet. What I think is that maybe the buttons 4 and 5 events doesn't use the press and release state. Shaeger tested it too and the same thing happened to him. I hope this information can help. Thanks. P.S: Yes, pyatspi is the only binding I'm using.
The mouse events for buttons 4 and 5 are not making it to deviceeventcontroller.spi_dec_button_update_and_emit. I am not really sure why with my limited knowledge of this code. There does not seem to be anything unusual about button 4 and 5 events as seen through xev. Each click of my scroll wheel results in a pressed and release event. How do you build for debug? CFLAGS="-DSPI_DEBUG" during autogen did not work for me.
Do you want to debug registryd? Setting your CFLAGS as "-g -O0" should work.
I'm sorry I reply so late. It's a busy week. Can you please provide a test program for us?
It's ok, Thanks for aswering. :-D I compiled with "-g -O0" and i didn't see anything strange. The strange thing is that in the code there is a mouse 4 and 5 buttons support, but the aren't processed. With xev the buttons 4 and 5 are taken perfectly, but with a little differenc from at-spi, they doesn't genereate a press or release state, they just generate 1 event each time they are used. The app i'm using to test the buttons is a simple piece of code with a listener. ## # This is the basic example of pyatspi web site # import pyatspi reg = pyatspi.Registry desk = reg.getDesktop(0) def callback(event): print event reg.registerEventListener(callback, 'mouse:button') reg.start() I hope this helps. Thanks a lot
While doing some tests with xev i found out the state code for buttons 4 and 5, the table should be like this: pressed = 0x0 button 1 = 0x100 button 2 = 0x200 button 3 = 0x400 button 4 = 0x800 button 5 = 0x1000 I don't know the names for those states. The other thing is that i tryed to change the pointer buttons order. The normal order is "1 2 3 4 5" with xmodmap i changed it like this "1 4 3 2 5" and with this the scroll press will generate a button 4 event wich means a scroll up event and indeed it worked great, i started the testing listener script and pressing the scroll it got the button 4p and 4r event. To change the pointer order: xmodmap -e "pointer = 1 4 3 2 5" Maybe there's support for buttons 4 and 5 but not for their states. I hope this help
Created attachment 106811 [details] Test program as an attachment
These days I was sick at home hence couldn't handle it in time. Mouse events are handled in function spi_dec_mouse_check. But button 4 and button 5 events are not forwarded to listeners. I'm investigating the reason.
Thanks Jeff!!! I'm investigating too... If you find somethign let me know... With xev i saw that buttons 4 and 5 just have a release state not a press one, maybe that information can help.. It is important for me to fix this bug and the new one I posted [0] without this features of at-spi i wont be able to end that application like it should be. [0] http://bugzilla.gnome.org/show_bug.cgi?id=521098 Thanks again
if (display != NULL) XQueryPointer(display, DefaultRootWindow (display), &root_return, &child_return, x, y, &win_x_return, &win_y_return, &mask_return); In function spi_dec_mouse_check, registryd uses XQueryPointer to get the mouse information. But when you use mouse wheel, XQueryPointer can't get the status of the mouse. I mean, the mask_return (The last parameter) is still 0. If the event is from button 1 or 2, mas_return is not 0. This is the reason that events of button 4 and button 5 are not forwarded by registryd. But which function should I use to get the mouse state, which can catch operations of button 4 and button 5?
Created attachment 106968 [details] [review] Add's the mouse buttons 4 and 5 constants Ok i'll take a look to that.. There's another thing that could help, the file pyatspi/constants.py doesn't have the buttons 4 and 5 constants (b4p, b4r, b5p, b5r). The attachement is a patch that should add them.
Just as I have said, XQueryPointer can't get the state change when use presses button 4 or button 5. So i'm considering to intercept the mouse event in global_filter_fn. gdk_window_add_filter (NULL, global_filter_fn, controller); global_filter_fn will intercept all events to all windows in which we can deal with the mouse messages. But I found that when I pressed button 4 or 5, the event type received in global_filter_fn is 113. A strange event type. Who knows the reason?
Hey!! I'm still looking how to fix this... How did you find out that the event tyoe is 113? i mean, how are you debugging at-spi? What I think is that the mouse scrool wheel events have their own event type, wich have it's own event name or state... I don't know their names, but it seems that their code is 113 (I think). does anyone found out something else??
I use "printf" to output the event type in the filter function. Scroll events have their own event type? If this is true, I should find them somewhere. But so far, I didn't find their definitions.
I wanted to know if there were some good news!!! I can't find that event type too...I'm still trying to figure out where it is defined.
Not yet. Sorry these days I'm busy in other work. Could you try gdk_window_add_filter (NULL, global_filter_fn, controller), in global_filter_fn, could we get the correct messages of mouse? Currently I'm blocked here. Do you know who I can ask to get further help?
Are there some news about this bug? I'm still trying to figure out how can we fix it... Thanks for your help, i'm really interested in fixing it..
I asked some guys working on X about this. Seems there is no way to get the mask because the 4 and 5 events are simulated by a press and an immediate release... (In reply to comment #11) > if (display != NULL) > XQueryPointer(display, DefaultRootWindow (display), > &root_return, &child_return, > x, y, > &win_x_return, &win_y_return, &mask_return); > > In function spi_dec_mouse_check, registryd uses XQueryPointer to get the mouse > information. But when you use mouse wheel, XQueryPointer can't get the status > of > the mouse. I mean, the mask_return (The last parameter) is still 0. > > If the event is from button 1 or 2, mas_return is not 0. > > This is the reason that events of button 4 and button 5 are not forwarded by > registryd. > > But which function should I use to get the mouse state, which can catch > operations of button 4 and button 5? >
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
Moving open tickets in at-spi2' "registry" Bugzilla component to "at-spi2-core" as it has a subdir called "registryd".
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/ Thank you for your understanding and your help.