Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Actually with the move to new hal-configuration this option seems very important for me, too.
I have a Lenovo SL300 notebook which has an ALPS Touchpad (properly handled by Synaptics driver) plus an additional TrackPoint. With older X-Versions this one is handled by mouse driver using the merged mouse-device, so that scrolling by EmulateWheel with middle-mouse button works.
Now with evdev the TrackPoint and the Touchpad are handled seperately, but the hardware is splitted like this:
Touchpad + Touchpad-Buttons + TrackPoint Buttons -> event0
TrackPoint -> event1

event0 will get handled by synaptics driver automatically and all cool features like scrolling at side areas of the pad work fine. event1 will be handled by evdev which is generally ok, but scrolling with EmulateWheel will never work, because even if it is enabled through a hal-policy it never sees any button presses, because they happen on event0 which is handled by synaptics driver.

So to be able to use fully functional Touchpad with synaptics driver+ fully functional TrackPoint with evdev and EmulateWheel it would be necessary to have support for reacting on "external" button events.

I haven't checked the source yet, so I don't know how problematic an implementation of this would be? - Maybe a dev could give a statement.

Regards,
Julian

> --- Comment #2 from Julian Scheel <julian@jusst.de>  2008-11-12 02:25:27 PST ---
> Actually with the move to new hal-configuration this option seems very
> important for me, too.
> I have a Lenovo SL300 notebook which has an ALPS Touchpad (properly handled by
> Synaptics driver) plus an additional TrackPoint. With older X-Versions this one
> is handled by mouse driver using the merged mouse-device, so that scrolling by
> EmulateWheel with middle-mouse button works.
> Now with evdev the TrackPoint and the Touchpad are handled seperately, but the
> hardware is splitted like this:
> Touchpad + Touchpad-Buttons + TrackPoint Buttons -> event0
> TrackPoint -> event1

isn't that more a sign that the kernel driver needs fixing?
hacking around this issue in the X driver is just a bad idea.

(In reply to comment #3)
> isn't that more a sign that the kernel driver needs fixing?
> hacking around this issue in the X driver is just a bad idea.
> 

No, I don't think this is a driver problem. It's more a hardware problem. As the Stick buttons are simply wired (in hardware) to the touchpad they appear in the event-device of the touchpad. This obviously can't be detected by the driver. So imho the only proper workaround would be an option in evdev driver to allow reacting on other input devices buttons. Beside working around this specific problem it would just allow more flexible use of EmulateWheel in general...

Regards,
Julian

I have disassembled one of the Ultranav keyboards. The wiring looks like this:
(fixed-width font required!)

   TRACKPOINT ---> AMPLIFIER ---->------- SYNAPTICS  ------->---- USB/PS2
   STICK                          /-->--- CONTROLLER
                                 /         |    |
   TRACKPOINT ------->----------/          |    |
   BUTTONS                                 |    |
                                           |    |
   TOUCHPAD ---------->--------------------+    |
                                                |
                                                |
   TOUCHPAD ----------->------------------------+
   BUTTONS
   

(In reply to comment #5)
> I have disassembled one of the Ultranav keyboards. The wiring looks like this:
> (fixed-width font required!)
> 
>    TRACKPOINT ---> AMPLIFIER ---->------- SYNAPTICS  ------->---- USB/PS2
>    STICK                          /-->--- CONTROLLER
>                                  /         |    |
>    TRACKPOINT ------->----------/          |    |
>    BUTTONS                                 |    |
>                                            |    |
>    TOUCHPAD ---------->--------------------+    |
>                                                 |
>                                                 |
>    TOUCHPAD ----------->------------------------+
>    BUTTONS
> 
> 

Is this from a input combination which shows the problem I described? - Looking at this it is probably some kind of setting in the Synaptics Controller I guess? Probably we can't change that, so really we would have to work around this somehow...

Problem being that the evdev instances don't really know about each other and I'm not overly keen on replicating what we had in evdev 1.1, where evdev managed the devices instead of the X server.

I'd still prefer to fix this somewhere in the kernel, rather than in the driver.

Re #7, I think the correct place to fix it is actually in the X server (neither the driver, nor the kernel). I'd prefer a modification of "SendCoreEvents", similar to the way that in xorg.conf, multiple mice can be independently configured, and then, after all the independent processing, button clicks and cursor movements are aggregated.

This bug needs to cover 2 separate cases:

 - the specific weirdness with synaptic devices, such that the trackpoint buttons get into the wrong event queue (because of how the hardware is wired up).

 - the general case, where one might want to aggregate buttons and movements from entirely different mice. This is most useful when one is doing hardware hacking (i.e. getting out the soldering iron, and trying to make the device do something it was never really intended to do by the manufacturer).

> --- Comment #8 from Richard Neill <xorg@richardneill.org>  2008-11-26 06:51:32 PST ---
> Re #7, I think the correct place to fix it is actually in the X server (neither
> the driver, nor the kernel). I'd prefer a modification of "SendCoreEvents",
> similar to the way that in xorg.conf, multiple mice can be independently
> configured, and then, after all the independent processing, button clicks and
> cursor movements are aggregated.

This is pretty much done in the server since MPX was merged. The problem with
this bug is that wheel emulation is a driver feature, not a server one.

So, are there any approaches to work around this now?
Or would maybe some user-space emulation of EmulateWheel be the way to go?

I have a maybe more common scenario to justify this RFE.

I have an iBook G4 of a generation prior to those equipped with a Synaptics trackpad. I have Macintosh mouse button emulation enabled and working fine.

Thus, I have my ADB mouse with one button and no wheel and X/Y axes, and an emulated buttons two and three, with no axis. They appear as two different devices.

I'd like to be able to use button 2 on the emulated device to trigger the wheel emulation on the trackpad and use its axes as the wheel.

Hopes this justifies the RFE to have EmulateWheel span several devices a bit further (;

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

(In reply to Adam Jackson from comment #12)
> Mass closure: This bug has been untouched for more than six years, and is not
> obviously still valid. Please reopen this bug or file a new report if you
> continue to experience issues with current releases.

Hi Adam. Yes, this is still a valid RFE, and yes, it would still be a really nice feature (albeit niche) to have. Thanks - Richard

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-mouse/issues/1.