Bug 483669

Summary: xpdf change to allow more mouse buttons is incomplete
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: xpdfAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-05 18:01:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
missing change to recognize in xpdf up to nine buttons none

Description Michal Jaegermann 2009-02-02 21:37:11 UTC
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):
xpdf-3.02-7.fc10

Additional info:

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
ateWheelTimeout: 200
....

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
led.
(WW) Disabling Keyboard0
(WW) Disabling Mouse0

so remapping would have to be done for a device "evdev" and not "mouse".

Comment 1 Tom "spot" Callaway 2009-03-05 18:01:00 UTC
This is fixed in the latest xpdf updates for all branches.