Skip to content
This repository has been archived by the owner. It is now read-only.
Permalink
master
Switch branches/tags
Go to file
 
 
Cannot retrieve contributors at this time
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component cc
2012-04-01 15:52:53 -0700
2015-08-13 02:03:09 -0700
2012-04-29 09:34:19 -0700
closed
usability
Fixed
mkeil@…
jeremyhu@…
Expected
2.7.2
xserver
ken@…

Problem with mouse wheel events on 2.7.2_beta4

I just upgraded to 2.7.2_beta4 from beta3 and noticed that not all mouse wheel events (Button4 and Button5) come through (Using a Logitech external three button mouse with mouse wheel - no Logitech driver installed). Downgrading to 2.7.2_beta3 fixes the problem. The mouse wheel works without problems in MacOSX native applications. I see the problem in a variety of X11 programs (e.g. trying to scroll xterm). The problem shows up also with xev. Scrolling the wheel, click by click (very slowly) will not register any ButtonPress or ButtonRelease events on Button4 or Button5. But turning the wheel fast will generate the events.


jeremyhu@… commented on Apr 1, 2012

Scrolling is now handled by smooth scrolling in DIX. The dix handles converting the scrolling into legacy button presses.

Can you be more specific about the problem? Does it seem like scrolling is not as fast as it used to be? What ratio of old/new do you think it is? It seems fine to me.


mkeil@… commented on Apr 2, 2012

There is no scrolling at all, when i do it very slowly, e.g. one notch (my old mouse's wheel is not free moving) per second. Using the touchpad of my macbook, it works even if moving the two fingers very slowly, but not with my external mice (logitech + microsoft).

Do you see button 4/5 press/release events in dev, when scrolling very slowly (one notch at a time)?


mkeil@… commented on Apr 2, 2012

sorry, meant "xev" not "dev" in last sentence.


mkeil@… commented on Apr 2, 2012

just saw your comment in the mailing list about another input problem and trying out "xinput --test-xi2". That gives some interesting info. Doing that, the wheel scrolling of my mice is seen as "RawMotion/Motion" events, the valuator 0 is for "1-notch-scrolling": 0.1. Which increases when i scroll faster. And once i hit 0.5 or above button presses/releases are registered. That also seems to work accumulative but time dependant. so doing 5 notches slowly (but not glacial) on my scroll wheel will generate on button press/release event, but doing 2 notches fast, can generate a lot of button presses/releases. I somewhat understand the logic behind that now, but i think every turn of the mouse wheel needs to generate mouse presse/release event, even if that means that it is imposing a minimum speed.


danny.bloemendaal@… commented on Apr 4, 2012

Replying to mkeil@…:

I see the problem in a variety of X11 programs (e.g. trying to scroll xterm). The problem shows up also with xev. Scrolling the wheel, click by click (very slowly) will not register any ButtonPress or ButtonRelease events on Button4 or Button5. But turning the wheel fast will generate the events.

I am experiencing exactly the same problem here. Very annoying.


jeremyhu@… commented on Apr 4, 2012

  • Status changed from new to assigned
  • Priority changed from Not Set to Expected
  • Milestone set to 2.7.2

Replying to mkeil@…:

Do you see button 4/5 press/release events in xev, when scrolling very slowly (one notch at a time)?

When using an old (non-smooth, "clicky") wheel mouse, I do see scrolling events. They are at 0.1 per click when done slowly but more when done quickly. This is the raw data that we are getting from AppKit about how much you have scrolled. If you scroll very slowly, you will get a button press after 10 clicks because you will have accumulated 1.0 scroll.

In the older code, we would always send at least one button press rather than waiting to accumulate 1.0 worth of motion, so you previously saw 10 clicks (one for each 0.1) whereas now you see just 1 click (when you reach 1.0).

http://cgit.freedesktop.org/xorg/xserver/commit/?id=31646d8fa9524adca1d7bc2cd2db90d47c2eb96e

So the problem is that the newer code is actually more correct, but you seem to prefer the older code because that is what you're used to... =/ I'll have to think about what to do here...


jeremyhu@… commented on Apr 4, 2012

Replying to mkeil@…:

i think every turn of the mouse wheel needs to generate mouse presse/release event, even if that means that it is imposing a minimum speed.

I agree, but the problem is that we don't have that kind of information coming in to XQuartz. We don't know what the real underlying hardware is. AppKit just tells us "you scrolled by 0.1" and we pass that along to Xi as "hey, we scrolled 0.1" ... this approach really removes "us" from the equation and passes the AppKit value straight to Xi clients. Unfortunately, many X11 applications haven't been updated to support smooth scrolling, so they still rely on those archaic button presses.

Perhaps I'll try a sqrt() of the valuator if the valuator is < 1.0 ... you still wouldn't get a click on every button, but it would be better... how do you feel about that?


mkeil@… commented on Apr 4, 2012

Replying to jeremyhu@…:

So the problem is that the newer code is actually more correct, but you seem to prefer the older code because that is what you're used to... =/ I'll have to think about what to do here...

I agree with you from the developers point of view. But from a user perspective you have the conundrum of supporting old hardware. It is just that the new behavior is "different" and currently very unique. I just had a look around various OSes, Windows, Linux, Solaris, MacOSX. All of them scroll with each notch of an old mouse wheel. So you would create a precedent here. Personally i would be happy, if there is a preference to set, where one specifies that one uses an old notched scroll wheel, which switches then to the old behavior.


jeremyhu@… commented on Apr 4, 2012

Replying to mkeil@…:

I agree with you from the developers point of view. But from a user perspective you have the conundrum of supporting old hardware. It is just that the new behavior is "different" and currently very unique. I just had a look around various OSes, Windows, Linux, Solaris, MacOSX. All of them scroll with each notch of an old mouse wheel.

You did not try Linux with a recent enough xorg-server and evdev driver. If you did, I believe you'd see the exact same behavior as in XQuartz. I'm not saying it's correct, but it is consistent. Additionally, I don't think Solaris would support smooth scrolling because I don't think the mouse driver has been updated to support it yet.

So you would create a precedent here. Personally i would be happy, if there is a preference to set, where one specifies that one uses an old notched scroll wheel, which switches then to the old behavior.

There's not going to be a preference to enable the old way because the old way did not allow smooth scrolling in applications that supported it. The problem here is in trying to support old applications with old hardware using an API that doesn't expose the intricacies of the hardware.

Like I said, the best I am willing to do is "bump" the amount scrolled if it is < 1.0, so we should focus our discussion on what exactly is the best way to do this.


mkeil@… commented on Apr 4, 2012

Well, none of the Linux distributions used by our customers are yet anywhere near that recent server. Our customer base is quit conservative. Our application needs to basically run on most computer platforms of the last 10 years. If we can not code up a workaround for traditional mice wheels, that will anger our customers tremendously and could lead us to dropping support for the Mac and Linux.

How would one fix up the application code anyway? How does one get an xevent for such partial scrolling of the mouse wheel? Xev does not give me anything. So how can i get to the 0.1 value with X11?

I think bumping the amount if it is < 1.0 is not a solution. The heart problem will persist. A user expects feedback, whenever he moves the wheel (especially when it is notched). If he does not get any movement he will think the mouse is broken (my first reaction) or the application does not work correctly.


jeremyhu@… commented on Apr 4, 2012

Replying to mkeil@…:

Well, none of the Linux distributions used by our customers are yet anywhere near that recent server. Our customer base is quit conservative. Our application needs to basically run on most computer platforms of the last 10 years. If we can not code up a workaround for traditional mice wheels, that will anger our customers tremendously and could lead us to dropping support for the Mac and Linux.

As I mentioned, I will be making the legacy support "better", but I am not sure how I will be doing that. The raw values from AppKit will go through "some" transformation, and I need to figure out what makes the most sense.

How would one fix up the application code anyway? How does one get an xevent for such partial scrolling of the mouse wheel? Xev does not give me anything. So how can i get to the 0.1 value with X11?

xev does not use Xi. That is why it doesn't tell you anything about the Xi events. In order to see them, you need to support Xi 2.1 in your application. See Peter's blog entry on smooth scrolling for more information:

http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html

I think bumping the amount if it is < 1.0 is not a solution.

It is what we were doing before. We previously sent ceil(value) number of button presses for each NSEvent. Now, we send one Xi scroll event of value.

The heart problem will persist. A user expects feedback, whenever he moves the wheel (especially when it is notched). If he does not get any movement he will think the mouse is broken (my first reaction) or the application does not work correctly.

Yes, the problem is in determining just what the right transformation is from the NSEvent's value to the value we want to pass along to X11.


mkeil@… commented on Apr 4, 2012

Replying to jeremyhu@…:

xev does not use Xi. That is why it doesn't tell you anything about the Xi events. In order to see them, you need to support Xi 2.1 in your application.

hmm. If one needs Xi 2.1 extension to support smooth scrolling anyway, why does this break the core protocol XButtonEvent? (We are not using the Xinput extension api).

Looking into Xi2 it looks like functions are needed which are not supplied by older Xserver's libX11. In order to have one unifying executable for the different servers, we would need to resolve these at run-time (painful...).

I think bumping the amount if it is < 1.0 is not a solution.

It is what we were doing before. We previously sent ceil(value) number of button presses for each NSEvent. Now, we send one Xi scroll event of value.

sorry, i was unclear. I think bumping from e.g. 0.1 to ~0.3 (sqrt 0.1) will not satisfy users. It certainly reduces significantly the "non-working" turns of the scroll wheel, but they are still present.

But on the other hand: I am now tainted, because i know what is happening underneath. You should do some usability testing with normal users. Get some non-X-developers, and ask them to scroll in an xterm and give you feedback.


jeremyhu@… commented on Apr 5, 2012

Replying to mkeil@…:

hmm. If one needs Xi 2.1 extension to support smooth scrolling anyway, why does this break the core protocol XButtonEvent? (We are not using the Xinput extension api).

It doesn't break XButtonEvent. You still get them, but the logic that determines when you get them has changed from being synthesized by the XQuartz DDX (at least one core button press per NSEvent) to be synthesized by the DIX (one core button press per 1.0 accumulated scrolling).

Looking into Xi2 it looks like functions are needed which are not supplied by older Xserver's libX11.

  1. libX11 doesn't belong to the Xserver

  2. This has nothing to do with libX11. It has to do with libXi. Both your libXi and the server need to support this.

In order to have one unifying executable for the different servers, we would need to resolve these at run-time (painful...).

That's not true. Even if the server doesn't support the newer protocol, you still just use what it does support. Just because your app supports Xi 2.1 doesn't mean it won't run on older servers. On older servers, you just need to fall back on the legacy button presses.


mkeil@… commented on Apr 5, 2012

Replying to jeremyhu@…:

It doesn't break XButtonEvent. You still get them, but the logic that determines when you get them has changed from being synthesized by the XQuartz DDX (at least one core button press per NSEvent) to be synthesized by the DIX (one core button press per 1.0 accumulated scrolling).

You are right from the technical point of view, but not the user experience view: Older applications using XButtonEvent to get the mouse wheel events look broken if a mouse with traditional mouse wheel is used.

Looking into Xi2 it looks like functions are needed which are not supplied by older Xserver's libX11.

  1. libX11 doesn't belong to the Server

  2. This has nothing to do with libX11. It has to do with libXi. Both your libXi and the server need to support this.

In order to have one unifying executable for the different servers, we would need to resolve these at run-time (painful...).

That's not true. Even if the server doesn't support the newer protocol, you still just use what it does support. Just because your app supports Xi 2.1 doesn't mean it won't run on older servers. On older servers, you just need to fall back on the legacy button presses.

Hmm... libXi... We did not use that before; we would need to pull that in. I just queried it on two different Macs. One with 2.7.2beta3 supplies e.g. XIQueryVersion, the one from Snow Leopard Apple X11 does not. So i still need to resolve the function pointers for the new Xi stuff on runtime with something like dlsym, and potentially do some more trickery with the include files, since our build server for the Mac is 10.5. Then some trickery that the executable inhales the library from XQuartz (/opt/X11/lib) instead of standard X11 (/usr/X11/lib) when XQuartz is available and otherwise fallback onto the default library. Hmm... that is not a tiny order.

Are there any plans to update the legacy applications, like xterm, which come with X11? Or do users have jus to come to terms that the mouse wheel in these applications now behave differently?


mkeil@… commented on Apr 5, 2012

Replying to jeremyhu@…:

http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html

I read another time over the blog entry... I now understand your reasoning, and see that you can not do much here. I, personally, disagree with Peter's assessment of the potential side effects:

"Clients that implement smooth-scrolling may act on information less than one increment. Permanent up/down movement of values less than one increment may then cause smooth scrolling events but no legacy events. I don't think this is an issue, users usually trigger the scrolling axis until they see the effect on-screen. The worst-case scenario here is that scrolling in one client requires more finger movement than in another client. "

I have seen to much users which "expect" immediate visible action once the mouse is moved (or wheel is scrolled). And they mostly also expect one mouse wheel notch to equal one scroll unit (often set to one line in an editor). But since not much can be done, we just have to brace ourselves and try to survive, once our users find out.


jeremyhu@… commented on Apr 5, 2012

Replying to mkeil@…:

Hmm... libXi... We did not use that before; we would need to pull that in. I just queried it on two different Macs. One with 2.7.2beta3 supplies e.g. XIQueryVersion, the one from Snow Leopard Apple X11 does not. So i still need to resolve the function pointers for the new Xi stuff on runtime with something like dlsym, and potentially do some more trickery with the include files, since our build server for the Mac is 10.5. Then some trickery that the executable inhales the library from XQuartz (/opt/X11/lib) instead of standard X11 (/usr/X11/lib) when XQuartz is available and otherwise fallback onto the default library. Hmm... that is not a tiny order.

There's a much simpler solution. You can just supply your own X11 libraries in your application (or at minimum, your own libXi)

Are there any plans to update the legacy applications, like xterm, which come with X11? Or do users have jus to come to terms that the mouse wheel in these applications now behave differently?

xterm is not maintained by X.org. You would need to talk to its maintainer, Thomas Dickey, about that.


ichou@… commented on Apr 6, 2012

This behavior is a mixed blessing. I have 2 different mice that I use regularly. An old Logitech clicky type mouse that is permanently plugged into a dock at my desk, and an Apple Magic Mouse when I'm on the road. The new behavior makes using the Magic Mouse much nicer, as the scrolling feels much more intuitive rather than feeling "out of control" as it used to be. The Logitech mouse is nice because what they lacked in precision, they provided through the "clicks".

If it were possible to adjust the "sensitivity" by simply cranking up the scroll speed in my System Preferences, I would just do that as a workaround, but even with the scroll speed set to maximum, it still takes 2 clicks to register anything on the Logitech mouse.

If there's no way for XQuartz to detect which kind of mouse I have connected, is it possible to add a checkbox in the Preferences for "Old scroll wheel sensitivity behavior"? With the pervasiveness of old Logitech click-style scroll wheel mice, I think this change would affect a lot of people.


jeremyhu@… commented on Apr 7, 2012

Replying to ichou@…:

This behavior is a mixed blessing. I have 2 different mice that I use regularly. An old Logitech clicky type mouse that is permanently plugged into a dock at my desk, and an Apple Magic Mouse when I'm on the road. The new behavior makes using the Magic Mouse much nicer, as the scrolling feels much more intuitive rather than feeling "out of control" as it used to be. The Logitech mouse is nice because what they lacked in precision, they provided through the "clicks".

If it were possible to adjust the "sensitivity" by simply cranking up the scroll speed in my System Preferences, I would just do that as a workaround, but even with the scroll speed set to maximum, it still takes 2 clicks to register anything on the Logitech mouse.

If there's no way for XQuartz to detect which kind of mouse I have connected, is it possible to add a checkbox in the Preferences for "Old scroll wheel sensitivity behavior"? With the pervasiveness of old Logitech click-style scroll wheel mice, I think this change would affect a lot of people.

There is no way that I'm bringing back the same codepath, but as I mentioned earlier, there will be a solution. I may consider a preference which allows the old behavior, but not the old codepath.


ken@… commented on Apr 16, 2012

If I may make a suggestion: the first scroll event after a period of, say, a quarter of a second, should send a scroll value of at least magnitude 1.0 to DIX. If the NSEvent value was less than 1.0, then it should also establish a "deficit" recorded internally. Subsequent events coming faster than a quarter of a second apart should apply to that deficit until it's wiped out and then start sending values to DIX again.

A change in scroll direction should act as though the half second period had elapsed. That is, the first event in the new direction should immediately send at least magnitude 1.0 to DIX.


ken@… commented on Apr 16, 2012

  • Cc ken@… added

jeremyhu@… commented on Apr 16, 2012

Yes, that will help legacy usage (ie, listeners of the button press scrolling), but it will be worse for the smooth scrolling, so I don't want that to be the default.

That is a good idea as al alternative method (ie: it's probably better than the ceil(scroll_value) approach that we used to use).


ken@… commented on Apr 16, 2012

Replying to ken@…:

A change in scroll direction should act as though the half second period had elapsed. That is, the first event in the new direction should immediately send at least magnitude 1.0 to DIX.

Actually, I amend that. A change in scroll direction within the quarter-second period should zero out the deficit and deliver its value to DIX immediately. It should not boost that to 1.0 for the first such event.

On another subject, you may be familiar with the new NSEvent method -hasPreciseScrollingDeltas. You can't use that and maintain 10.6 compatibility. However, the same information has been available from Core Graphics prior to 10.7. In particular, CGEventGetIntegerValueField([anNSEvent CGEvent], kCGScrollWheelEventIsContinuous).

You can use that information to somewhat alleviate this issue (although it's still not completely right). For a non-continuous scroll event, like from a clicky scroll wheel, you should multiply the scroll value by the "line height". Some applications have their own notion of the line height. However, there's also one inherent to Core Graphics: CGEventSourceGetPixelsPerLine(). You can get the source for a CGEvent using CGEventCreateSourceFromEvent().


jeremyhu@… commented on Apr 16, 2012

Yeah, I'd like to avoid relying on anything newer than SL, even conditionally. The source is currently amess with #ifdef foo to support pre-dispatch Leopard and Tiger at a source level, and SL is a good min-req even if newer functionality looks appealing.

I did know about hasPreciseScrollingDeltas, but I didn't know about kCGScrollWheelEventIsContinuous. Thanks for that.


jeremyhu@… commented on Apr 19, 2012

patch


jeremyhu@… commented on Apr 19, 2012

Ok, here's a patch that seems to behave well.


jeremyhu@… commented on Apr 27, 2012

2.7.1_rc1 includes this change. Please let me know how it feels to you.


jeremyhu@… commented on Apr 29, 2012

  • Status changed from assigned to closed
  • Resolution changed from to fixed

http://cgit.freedesktop.org/xorg/xserver/commit/?id=662d41acdde1dcb9774fbe4054e251c708acaffe

I haven't heard any complaints about the new behavior, so closing.


mkeil@… commented on Apr 29, 2012

Works for me with a clicky wheel mouse. Nice work! Thanks!