Horizontal scroll direction is reversed

[dhardy]

Before the last system update, touchpad scrolling of the map worked perfectly. After the update (Wesnoth 1.13.10), horizontal scrolling works in the wrong direction (vertical scrolling is still correct). It's weird having only one axis reversed. I don't see any config for this.

[sevu]

I recall this happening to me too.

[Vultraz]

When I swipe left, the map goes to the right. Is that not the previous behavior?

[dhardy]

It's not the previous behaviour I had. Now the map moves down when I swipe down (same direction) but left when I swipe right. It's pretty odd. (I never did get why we needed to reverse touchpad scrolling directions just because touchscreens work differently; one is a "scrolling" method the other is "drag a point".)

[Vultraz]

That’s a good analogy, I guess. Now we just neee to decide which scrolling method to commit to.

[dhardy]

Well, either stick to the old standard (and tweak your touchpad if you want different in all your apps) or add an option. Because all my other apps scroll in the same direction as I swipe.

[AI0867]

Apple decided to make touchpads on macOS work the same as touchscreens on iOS at some point, and microsoft followed suit in windows 8 (even with scrollwheels I believe). Some linux software also does this, KDE (at least the versions I've run) does not.

It's all rather annoying.

[dhardy]

I know, I just assumed the only sane way to implement the switch would be by swapping touchpad scroll output. (Although even that is not sane — queue scroll down to zoom in on maps interpreting wheel events the usual way.) Ugh, what a can of worms.

[vgaming]

// Linux XFCE environment defines scrolling as "scroll down = more text on bottom gets revealed = viewport goes down", but there is an option to reverse scrolling behavior, called "Reverse scroll direction". This option is the approach that seems sane. It's not app-level, it's system-level.

I would be very happy if wesnoth would behave same as all others programs on my OS/environment. So that I could also reverse the behavior on all apps simultaneously by a single click (if I'd want to).

[GregoryLundberg]

I don't know if it's such a good idea querying the DM for options unless it's explicitly an option supported by all DMs on Windows, macOS and every flavor of Linux out there.

[vgaming]

@GregoryLundberg agree. So, I'd make it OS-specific. It seems that Windows has a single dominating DE/whatever, same goes for Mac. Linux has all kinds of DE-s, but the majority of them uses traditional scrolling, not "touch-style".

[dhardy]

You would have thought there'd be a freedesktop standard for this kind of thing, but I can't find one.

[dhardy]

Actually, there's a section in the X protocol (search "scrolling"). Presumably there's some equivalent for Wayland too, but can't find it.

[jyrkive]

Looks like this was caused by commit cfa2df1.

[vgaming]

@dhardy well, the point is to ignore the setting, even if it can be found on Xorg configuration files etc. We want wesnoth to behave like all other apps, we don't want hardcode that "scorll down" = "map goes down".
So, if we just use the standard Linux scroll direction, we will always scroll in the same direction as the user would inside e.g. a browser. Even if the user inverts this in his Xorg configuration.

[Vultraz]

What is this "standard Linux scroll direction" you speak of?

[GregoryLundberg]

I read it as "what my system does" and "the same as Windows" since I don't see any difference.

When I roll the mouse wheel to scroll down a web page the line I'm reading moves up my screen.

When I roll the mouse wheel the same direction on Wesnoth, the unit moves up my screen.

My touch system is restricted to mouse emulation since I'm using Windows Remote Desktop.

Connected to my Linux system, when I touch the bottom of the window and move down a bit, the unit on my screen moves up. Same as when I move the mouse a bit off the bottom edge.

My Windows 7, 8.1 and 10 systems don't seem to understand touch. Maybe something with my setup but I don't care to look right now.

I would expect, if I an click-dragging the map, or touch-dragging, that the map follows the mouse pointer or my finger.

When it comes to the arrow keys, however, I would expect the system scroll to be honored. That is, if I have it set to move the line on my web page down when I press the down arrow, I would expect the unit on my screen to move down. Similarly, if I have it set (as "normal") to move the line on my web page up when I press the down arrow, I would expect the unit on my screen to move up as well.

If I can reconfigure the mouse wheel to reverse direction, I would expect Wesnoth to follow suit, as my text editor or web browser would.

[vgaming]

@Vultraz yes, I mean the same behavior as you get when you scroll a long list. Wesnoth unit/savegame list, for example.

[vgaming]

BTW, note on Xorg settings. I did some tests now.

It seems that, when you enable this setting, applications actually receive an inverted scroll action itself. So if you scroll down your mouse wheel, applications get "scoll up" event. If you scroll your wheel up, applications get "scoll down" event. Also, this is input-specific. So you can invert your mouse, but leave touchpad as is, for example.

Note on tests:

• I didn't want to hack into Xorg settings directly, so I used my XFCE settings to enable the setting instead.
• I observed the events using xev command.

[dhardy]

FYI Windows 8 and recent versions of GNOME both switch scrolling direction (scroll UP to make text go up). Not 100% sure how this happens but I would guess by remapping events (both Xorg conf and xinput allow "mouse button" scroll events to be remapped). IIUC older versions of Windows didn't have uniform support for horizontal scrolling so that may be why the patch @jyrkive mentioned switched only the x direction? Seems a special case though; I imagine most platforms will not want this.

I strongly suspect that regardless of which behaviour you want (objects on map follow fingers when scrolling or move away), on most platforms [with horiz and vert scrolling] the current code will be wrong (inconsistent between x and y directions). But maybe more testers are needed...

[sevu]

The game is unplayable with a touchpad, I mark this as a blocker.
Some information:

• I use libinput as touchpad driver. Not evdev or synaptic.
• Scrolling up scolls up.
• Scrolling left scrolls right.

Does anybody on Linux not have a different behavior for horizontal and vertical with the touchpad?

[ancestral]

The game is honoring the scrolling setting in System Preferences. If you have the check box “content tracks finger movement” the game follows that. How do you scroll a page in Safari? It’s the same behavior.

If we undo this, then this breaks for people who have the natural scrolling turned off, which will be even more frustrating for the other half of people who turned the setting off.

So the only fix for this is overriding this preference… which I think we can do. I’ll see if I can find make a patch to check the systemwide scroll setting.

[ancestral]

BTW, I’m pretty sure this change in behavior happened with the move to SDL2.

[ancestral]

@vgaming So when you move your cursor to the edge of the map, you expect the game should move in that direction. This doesn’t apply to web browsers. You don’t scroll by moving the cursor to the edge of the window.

[vgaming]

@ancestral this part I do understand. What I cannot understand, is how it relates to scroll events. These are different types of movement on my touchpad, the cursor doesn't even change position while scrolling, it stays in the center.

[ancestral]

I guess it all comes down to personal preference. And history on how Wesnoth has traditionally worked.

My question is, for Linux users, is there actually a system setting for scrolling direction?

[vgaming]

@ancestral yes. But the trick is -- it doesn't really change scrolling direction for e.g. "scroll down" event. Instead, it makes your physical mouse scrolling generate inverted scroll event.

In other words, if you re-configure this setting, you will make the same physical gesture, but get an inverted scrolling event. Apps do not know about it (normally).

[ancestral]

My apologies. After looking at cfa2df… maybe I was wrong. I could have sworn it was in an #ifdef. My mistake, I was thinking of another report.

So Linux is different?

Please see the issue: #1754

[vgaming]

@ancestral I don't know if Linux is different because I don't use any other OS. On Linux, when you scoll up, viewport goes up. That is expected behavior. Now, when you scoll left, viewport goes right. This is broken.

[ancestral]

Okay, so is it easier to #ifdef for Linux, or #ifdef for Mac and Windows? Not sure about other platforms…

[jyrkive]

IIRC, last time I tested this on Windows, panning direction was correct (meaning that the X axis reversal is Linux specific).

[sevu]

Wesnoth also runs on a variety of other unix systems.

[vgaming]

If there are 2 systems that are known to behave in one way, and an unknown number of other systems that probably behave in another way, I'd chose ifdef-ing the two known systems.

[ancestral]

I had one person with a Linux machine confirm this works. That being said, if you notice the issue persists, please re-open the issue. Thanks.

[vgaming]

@ancestral confirming the fix works. Thanks!