Bug 483669 - xpdf change to allow more mouse buttons is incomplete
xpdf change to allow more mouse buttons is incomplete
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xpdf (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-02 16:37 EST by Michal Jaegermann
Modified: 2009-03-05 13:01 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-05 13:01:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
missing change to recognize in xpdf up to nine buttons (778 bytes, patch)
2009-02-02 16:37 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2009-02-02 16:37:11 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):
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 13:01:00 EST
This is fixed in the latest xpdf updates for all branches.

Note You need to log in before you can comment on or make changes to this bug.