(In reply to comment #0)

In the meantime, I scraped the web and found old man pages evdev(4), which entailed the following additions to the xorg.conf:

  Option "evBits"  "+1-2"
  Option "keyBits" "~272-287"
  Option "relBits" "~0-2 ~6 ~8"

Remember in the last episode there was an unnamed neighbor telling the trackman worked "everything normal" on his window$ machine, and the reaction to this change proves that the linux kernel driver actually sends something sensible which xf86-evdev propably doesn't pick apart properly.

Now evtest.c sometimes reports wheel events, but not reliably:

Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc404 version 0x110
Input device name: "Logitech Trackball"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 272 (LeftBtn)
    Event code 273 (RightBtn)
    Event code 274 (MiddleBtn)
  Event type 2 (Relative)
    Event code 0 (X)
    Event code 1 (Y)
    Event code 8 (Wheel)
  Event type 4 (Misc)
    Event code 4 (ScanCode)
Testing ... (interrupt to exit)
Event: time 1237743309.762421, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1237743309.762434, -------------- Report Sync ------------
Event: time 1237743312.274421, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1237743312.274434, -------------- Report Sync ------------
Event: time 1237743313.554419, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1237743313.554432, -------------- Report Sync ------------
...

This is when scrolling the wheel down, the up-motion isn't detected, and other than this output, the wheel doesn't do anything anymore.  I had tried live-CDs of chrunchbang and knoppix (two linux distributions), and in both of them the scroll-wheel would "ruckle" a little bit just one time before turning mute again, but I thought this to be statistical noise or hinting at a hardware issue.  Now I think we have evidence of needing either clever, undocumented configuration tricks or a real, but small evdev bug.

Another resource on the web hints to check
"cat/proc/bus/input/devices", which tells us:

I: Bus=0003 Vendor=046d Product=c404 Version=0110
N: Name="Logitech Trackball"
P: Phys=usb-0000:00:02.0-2/input0
S: Sysfs=/class/input/input4
U: Uniq=
H: Handlers=mouse1 event4 
B: EV=17
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=103
B: MSC=10

whereas the old "mechanical", worn out PS/2 mouse describes as:

I: Bus=0011 Vendor=0002 Product=0005 Version=0051
N: Name="ImPS/2 Logitech Wheel Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input6
U: Uniq=
H: Handlers=mouse2 event6 
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=103

Does this tell a knowledgable person which numbers should be entered into the various "Option *bits" of the xorg.conf?  I simply cannot figure it out, even with usr/include/linux/input.h and evtest.c.  I take it the numbers above are hex and xorg options need decimal ints, but how do I shift/mask them into shape?

Regards, clemens

(In reply to comment #0)
> I wonder why the is no "ZAxisMapping" option for evdev pointers.  The bogus
> "YAxisMapping" from the log is reported always, but it has no effect and cannot
> be overridden.


The option ZAxisMapping isn't supported because it is pointless. Clients expect wheels to be buttons 4/5 (vert) and 6/7 (horiz) anyway, so remapping them is a corner use-case that can be done at runtime if needed. This option existed in the mouse driver because that driver pre-dates scroll wheels.

YAxisMapping is the button mapping for horizontal motion in wheel __emulation__ mode.



>   Option "Protocol" "auto"

Option "Protocol" is not supported, you can remove it.

>   Option "CorePointer"

That's the default anyway these days.

> In the meantime, I scraped the web and found old man pages evdev(4), which
> entailed the following additions to the xorg.conf:
> 
>   Option "evBits"  "+1-2"
>   Option "keyBits" "~272-287"
>   Option "relBits" "~0-2 ~6 ~8"

these options aren't supported anymore, so don't worry about them.
 
> Now evtest.c sometimes reports wheel events, but not reliably:

sorry, there is nothing we can do in the driver. you need to file this as a kernel bug. evtest.c uses the same data as xf86-input-evdev, so if evtest can't see wheel events, neither can our driver.

> Input driver version is 1.0.0
> Input device ID: bus 0x3 vendor 0x46d product 0xc404 version 0x110
> Input device name: "Logitech Trackball"
> Supported events:
>   Event type 0 (Sync)
>   Event type 1 (Key)
>     Event code 272 (LeftBtn)
>     Event code 273 (RightBtn)
>     Event code 274 (MiddleBtn)
>   Event type 2 (Relative)
>     Event code 0 (X)
>     Event code 1 (Y)
>     Event code 8 (Wheel)
>   Event type 4 (Misc)
>     Event code 4 (ScanCode)

the mouse reports the correct capabilities, as I said above if wheel events are reported unreliably, then this is a kernel issue.

> Does this tell a knowledgable person which numbers should be entered into the
> various "Option *bits" of the xorg.conf?  I simply cannot figure it out, even
> with usr/include/linux/input.h and evtest.c.  I take it the numbers above are
> hex and xorg options need decimal ints, but how do I shift/mask them into
> shape?

the bits aren't your problem. in fact, evtest tests these bits and prints out the configuration (LeftBtn, RightBtn, MiddleBtn, etc.). 
KEY=70000 0 0 0 0 0 0 0 0 is 0x70000 << (32 * 8), you can then binary AND this with 1 shifted by the constants defined in linux/input.h (e.g. number & (1 << BTN_LEFT) is non-zero if BTN_LEFT is provided).