what's the evtest output for these buttons? we send one click event (one press, one release) for each ABS_WHEEL event, so we'd have to put some filtering logic in

Peter, here's what I get with Button4 (each single indent of of the wheel gets it's own ButtonRelease evt):

ButtonPress event, serial 31, synthetic NO, window 0xec00001,
    root 0x15a, subw 0xec00002, time 13799052, (23,37), root:(31,70),
    state 0x10, button 4, same_screen YES

EnterNotify event, serial 31, synthetic NO, window 0xec00001,
    root 0x15a, subw 0x0, time 13799052, (23,37), root:(31,70),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus YES, state 2064

KeymapNotify event, serial 31, synthetic NO, window 0x0,
    keys:  90  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ButtonRelease event, serial 31, synthetic NO, window 0xec00001,
    root 0x15a, subw 0xec00002, time 13799052, (23,37), root:(31,70),
    state 0x810, button 4, same_screen YES

LeaveNotify event, serial 31, synthetic NO, window 0xec00001,
    root 0x15a, subw 0x0, time 13799052, (23,37), root:(31,70),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

Thanks for the comment- I *did* fail to notice the matching ButtonRelease events. Here's what I get with Button6 (tilt left):


ButtonPress event, serial 34, synthetic NO, window 0xec00001,
    root 0x15a, subw 0xec00002, time 14357412, (41,27), root:(49,1041),
    state 0x10, button 6, same_screen YES

EnterNotify event, serial 34, synthetic NO, window 0xec00001,
    root 0x15a, subw 0x0, time 14357412, (41,27), root:(49,1041),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

KeymapNotify event, serial 34, synthetic NO, window 0x0,
    keys:  90  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ButtonRelease event, serial 34, synthetic NO, window 0xec00001,
    root 0x15a, subw 0xec00002, time 14357412, (41,27), root:(49,1041),
    state 0x10, button 6, same_screen YES

LeaveNotify event, serial 34, synthetic NO, window 0xec00001,
    root 0x15a, subw 0x0, time 14357412, (41,27), root:(49,1041),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

ButtonPress event, serial 34, synthetic NO, window 0xec00001,
    root 0x15a, subw 0xec00002, time 14357516, (41,27), root:(49,1041),
    state 0x10, button 6, same_screen YES

....etc....

I made another error in my initial description: following mapping, the left/right scroll buttons ARE showing as "button8 and "button9" ... they're just behaving like button6 and button7.

My map command (from comment #1) excluded button 6 and button 7 entirely. So it's all WAD, but I still think that it would be nice to make the "wheel-spin" effect avoidable. And the easiest way I can imagine would be to use the already-present mapping utilities:

Just change the loop which creates the automatic "Release/Re-Press" spin behavior, so that it executes on the basis of LOGICAL button6 and button7, rather than PHYSICAL button6 and button7.



Slightly OT: This would depend on the ability to create high-numbered logical button freely, without regard to the physical device. I've seen that back in my Release (Xorg 7.5, Mandriva) I can't execute a "set-button-map" for a logical number bigger than 13. Is this still true in Git-Current?

I'm sorry about my lack of accuracy in the initial description- Thanks for your query to have me re-check. ;)

(In reply to comment #4)
> Just change the loop which creates the automatic "Release/Re-Press" spin
> behavior, so that it executes on the basis of LOGICAL button6 and button7,
> rather than PHYSICAL button6 and button7.

the driver doesn't know about the logical button mapping. so that loop is based on "we get 5 wheel events, we send 5 button 4/5/6/7 events". the server doesn't know that it's a wheel, it just sees button 4/5/6/7 events and passes them on. the whole notion that these buttons represent wheels is by convention, not policy.

> Slightly OT: This would depend on the ability to create high-numbered logical
> button freely, without regard to the physical device. I've seen that back in my
> Release (Xorg 7.5, Mandriva) I can't execute a "set-button-map" for a logical
> number bigger than 13. Is this still true in Git-Current?

xinput set-button-map <device> 18

works.

(In reply to comment #5)
> 
> xinput set-button-map <device> 18
> works.

Thanks for your test. :) I'm still confused by one thing, though: Button-4 and Button-5 really DO have a scroll wheel, and I think that each "click" of rotation causes one set of ButtonPress - ButtonRelease events.

Button-6 and Button-7 don't have a wheel. Is all mice with such buttons built to send paired events, as hardware-emulation-of-horizontal-wheel? Or is the "convention" implemented in driver code?

if ButtonPress and (Button = Button6 || Button7) {
  loop while (physical ButtonRelease hasn't been received) {
    send ButtonPress event;
    send ButtonRelease event;
    pause some milliseconds;
  } //loop

  // cleanup, maybe
}

(In reply to comment #6)
> Button-6 and Button-7 don't have a wheel. Is all mice with such buttons built
> to send paired events, as hardware-emulation-of-horizontal-wheel? Or is the
> "convention" implemented in driver code?

driver code, see http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n600. we get a wheel event from the kernel and send out a button 4/5/6/7 press+release event instead. so for your hardware, it pretty much depends on what the event the tilt wheel send is. evtest should tell you.

Thanks for confirming my un-qualified suspicion. (I looked at both the xorg driver and the kernel "glue code", and saw no such spin-loop in place.) This seems, instead, to be a traditional implementation in hardware: Tilt-wheel mice do the loop within device microcode, so it can't be "prevented".

The "wheel speed" could be reduced (in Xorg, or within higher level Toolkits), by consuming rapid, consecutive sets of Kernel and Evdev ButtonPress / ButtonRelease events (from the kernel) and re-emitting them to user code in a smaller number. But, such "tuning" code should have a GUI, so IMO it really belongs in the land of ToolKits and DEs. That's where "wheel speed" tuning for the Button4/Button5 wheel is done now.

In fact, qt ALREADY contains a loop which "quietly eats most of the events", and it works on both the Vertical (B4/B5) and Horizontal (B6/B7) axes. But the amount of "event consumption" is hard coded, and I'm thinking that I should write a BugZilla for qt to provide Getter/Setter Methods on those values. (As you remember, KDE is my primary target for this research, so qt is the toolkit in question.) 

Definitely "Working As Designed", and the traditional behavior of such mice is not something we can change. (As found in comment 4, we can emit a different button number-- but tilting the wheel will ALWAYS result in "spinning" Press/Release Events while the button is down.)

So, do we close this in X11? (I'll try marking it "RESOLVED/NOTABUG" with this comment, even though I'm not the assignee.) It's fundamentally WAD in X11. The "bug" is only useful as a reference, if a future "X12" wants to take over the job of "wheel-speed tuning" from higher-level Toolkits.

It's up to you, we're all done here :)) And BTW, I'm really, REALLY grateful for your incredibly generous "hand-holding" of this clueless newby. Thank you!