Conversation
In the XCB events the mouse buttons start at index 1, while for WPE we need to use 0-based indexing: buttons [left, middle, right] are [1, 2, 3] in X11, [0, 1, 2] in WPE.
Handle the first five pointer buttons by checking their exact button codes. Their values are used directly to avoid the need for <linux/input-event-codes.h> to be present at build time.
aperezdc
force-pushed
the
aperezdc/button-event-fixes
branch
from
0666394 to
1ff8267
Compare
|
Interestingly, having the correct values for the |
|
Are you certain wpe_input_pointer_event::button uses the zero-based MouseEvent button spec? This seems contrary to my experiences which suggest it is one-based. Digging through wpe-source reveals createWebMouseEvent() which uses a simplistic hard-coded 1=left, 2=right, 3=middle, all others ignored. Note that wpe_input_pointer_event::modifiers does correspond to the W3C spec with the correct bitmask values. Can also confirm right-click (value == 2) messing up subsequent input. Had assumed it was related to using DRM (so no way to render a context-menu), but seems more fundamental. Tried lots fo work around it, but without luck. Input-field double-clicking and text selection also fail to work. This may be related to wpe button handling in that the "clickCount" field is always 0/1. That suggests the calling code is supposed to identify a double-click, but there is no way to actually do so. |
2 participants
Fix the X11 and Wayland plug-ins to pass the correct pointer button indices in
wpe_input_pointer_event::button. The WPE values are based on the MouseEvent.button spec, and:1, so they need conversion to be0-based.BTN_*values from the<linux/input-event-codes.h>header.This PR fixes them accordingly.