[SOLVED] inconsistent scroll direction

bbbart · 2016-03-14 10:21:00

Hi,

Since a few days, I can't pinpoint when it started exactly, I have to deal with inconsistent scroll directions across different applications. Extremely annoying!

I have switched to so called `natural scrolling' a long time ago with this simple xmodmap trick:

pointer = 1 2 3 5 4 7 6 8 9 10 11 12 13 14 15 16

This used to work perfectly everywhere.

Now, a couple of applications seem to ignore this setting (how exactly, is beyond me). Two examples of misbehaving applications are Chromium (49.0.2623.87-1) and Viber (4.2.2.6-14). Most other applications are still fine.

Viber is using Qt and Chromium GTK. But then again, Gimp is also using GTK and still adheres to my reverse scrolling setting in xmodmap. So I don't think the problem lies with specific toolkit settings.

Strangely enough, if I undo the mentioned xmodmap setting, Viber and Chromium don't change their scroll direction, so it seems they are completely ignoring this. In other applications, the scrolling direction is set back to the classic way.

Where else can it be? As far as I understand the layered architecture of X, this should be impossible. So I'm sure my understanding is flawed somewhere. :-)

Thanks for thinking along with me!

Last edited by bbbart (2016-04-01 20:10:40)

Steinberg2010 · 2016-03-15 23:16:40

Same here: https://bbs.archlinux.org/viewtopic.php?id=210180

I noticed this morning that my web browser (opera) has reversed scroll direction for my touchpad, but all other apps works as normal. Confusingly my trackpoint has not reversed.

Any help much appreciated!

~S

bbbart · 2016-03-16 22:58:21

I can confirm that on my system Opera (36.0.2130.32-1) is also misbehaving, just like Viber and Chromium.

Steinberg2010 · 2016-03-17 23:03:18

I guess it's just us then... I have no idea what's causing this, but it's really annoying!
Most of my applications seem to be fine!

~S

bbbart · 2016-03-18 14:36:36

Steinberg,

do you have the same problem with Chromium, LibreOffice and Viber like in Opera? or is it simply Opera misbehaving for you?

Steinberg2010 · 2016-03-18 20:29:28

It's just opera that I'm aware of - LibreOffice is fine, I don't have Chromium or Viber installed.

~S

bbbart · 2016-03-21 12:40:14

hm, okay. then I believe we are experiencing a different problem. :-/

V1del · 2016-03-21 14:53:13

Which input backend do you use? you might want to try to uninstall libinput and use evdev/synaptics only, which should honor more of the X specifics. The reason GIMP still works is because it uses GTK2 which doesn't have support for libinput, QT(5) does and Chromium's Aura (not GTK, it can mimick the GTK style, doesn't use it directly though) does as well and you might have libinput installed which has its own configuration. Xorg log might not hurt either.

Steinberg2010 · 2016-03-23 00:00:02

Well I'm noticing it in the acroread print dialog and also it applies to my external trackball too (not just the synaptic touchpad).

~S

Steinberg2010 · 2016-03-23 20:34:02

Hi bbbart,

This may not help you but I fixed my problem. After doing some digging I discovered I had an entry "pointer: x x x x x " in ~/.Xmodmap, and also entries in /etc/X11/xorg.conf.d/.

I realised that they were probably conflicting with each other and so I went on a cleansing of the files and I fixed mine by condensing everything into 50-synaptics.conf

~S

bbbart · 2016-04-01 20:00:05

Thanks Steinberg. It's not related to my problem however. I do have the pointer setting in .Xmodmap, but not in my xorg.conf.

V1del, thanks for your input here. I do have libinput installed and I'm using evdev. Might be they are conflicting? I'm digging into this now. Can't just deinstall libinput however, since it's required by qt5-base and clutter. I checked some other programs that are in the dependency tree of libinput, and they also seem to be misbehaving, so I guess we're on the right track here.

Thanks a lot for the pointer, checking it out now!

bbbart · 2016-04-01 20:15:38

it's solved (kind of)!

indeed, libinput and evdev fighting was the problem.

solved by removing the pointer setting in .xmodmap and enabling Natural Scrolling for my mouse with xinput. this enabled natural scrolling in every application.

only problem now is that my touchpad (bcm5974) doesn't have the Natural Scrolling property available, so without the xmodmap setting now it now behaves in legacy mode. let's see what we can do about that.

thanks again V1del!

bbbart · 2016-04-01 20:27:37

I worked around it by inverting the values for the Scrolling Distance property.

all set now! at least, if xinput consistently assigns the same id to the same input devices... :-)

Arch Linux

#1 2016-03-14 10:21:00

[SOLVED] inconsistent scroll direction

#2 2016-03-15 23:16:40

Re: [SOLVED] inconsistent scroll direction

#3 2016-03-16 22:58:21

Re: [SOLVED] inconsistent scroll direction

#4 2016-03-17 23:03:18

Re: [SOLVED] inconsistent scroll direction

#5 2016-03-18 14:36:36

Re: [SOLVED] inconsistent scroll direction

#6 2016-03-18 20:29:28

Re: [SOLVED] inconsistent scroll direction

#7 2016-03-21 12:40:14

Re: [SOLVED] inconsistent scroll direction

#8 2016-03-21 14:53:13

Re: [SOLVED] inconsistent scroll direction

#9 2016-03-23 00:00:02

Re: [SOLVED] inconsistent scroll direction

#10 2016-03-23 20:34:02

Re: [SOLVED] inconsistent scroll direction

#11 2016-04-01 20:00:05

Re: [SOLVED] inconsistent scroll direction

#12 2016-04-01 20:15:38

Re: [SOLVED] inconsistent scroll direction

#13 2016-04-01 20:27:37

Re: [SOLVED] inconsistent scroll direction

Board footer