Red Hat Bugzilla – Bug 483669
xpdf change to allow more mouse buttons is incomplete
Last modified: 2009-03-05 13:01:00 EST
Created attachment 330678 [details]
missing change to recognize in xpdf up to nine buttons
Description of problem:
Bummer! This is actually my fault. When in the past submitting changes to bump a number of xpdf-usable mouse buttons to 9 I forgot about XPDFViewer.cc not to ignore those additional buttons. Here it is.
Version-Release number of selected component (if applicable):
I have here a wireless mouse which is identified as:
(II) Logitech USB Receiver: Found 16 mouse buttons
(II) Logitech USB Receiver: Found x and y relative axes
(II) Logitech USB Receiver: Configuring as mouse
(**) Logitech USB Receiver: YAxisMapping: buttons 4 and 5
(**) Logitech USB Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, Emul
I am not sure about 16 but beyond "normal" buttons, and withouth any remappings, its wheel gives buttons 4, 5, 6 and 7 (the last two as side wheel motions), there are two "back" and "forward" buttons as 8 and 9 and also "zoom-in" and "zoom-out" buttons 13 and 14. That is what I can find in xev reports.
Withouth any remapping one can at least put in /etc/xpdfrc lines like
bind mousePress8 any prevPage
bind mousePress9 any nextPage
which is really nice when in a full screen mode during a presentation and not necessarily close to a machine. With this additional patch that just works.
Making buttons above 9 "xpdf-usable" would be possible but it would need deeper intervention into GlobalParams.cc to do something similar like what is done for parsing xpdfKeyCodeF"X" presses.
Remapping mouse buttons when by default /etc/X11/xorg.conf is absent becomes slitghtly hairy and besides now one gets this in logs:
(WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disab
(WW) Disabling Keyboard0
(WW) Disabling Mouse0
so remapping would have to be done for a device "evdev" and not "mouse".
This is fixed in the latest xpdf updates for all branches.