after update to xorg-server 1.16.0-6 mtrack fails to function

[dlemke01]

Hi,

After the recent (about two weeks ago) xorg update and related package updates for xf86*, xf86-input-mtrack fails to function (i.e. no mouse movement associated with trackpad touches). I can run xf86-input-synaptics with no problems. I've been troubleshooting this since the initial update and am now just spinning my wheels. I've tried reinstalling, websearching, and reading through wiki's and man pages to understand the problem, but I'm not cracking it. My system (Arch) is up to date, and I'm working off xf86-input-mtrack-git from the AUR. I'm hoping that since no one else has posted this problem, that there is a simple fix that I am overlooking. Here is output from Xorg.0.log:

37.396 LoadModule: "mtrack"
37.396 Loading /usr/lib/xorg/modules/input/mtrack_drv.so
37.403 Module mtrack: vendor="X.Org Foundation"
37.403 Using input driver 'mtrack' for 'bcm5974'
37.405 mtrack: devname: bcm5974
37.405 mtrack: devid: 5ac 252 1
37.405 mtrack: caps: left mtdata ibt
37.405 mtrack: 0: min: 0 max: 2048
37.405 mtrack: 1: min: 0 max: 2048
37.405 mtrack: 2: min: 0 max: 2048
37.405 mtrack: 3: min: 0 max: 2048
37.405 mtrack: 4: min: -16384 max: 16384
37.405 mtrack: 5: min: -4750 max: 5280
37.405 mtrack: 6: min: -150 max: 6730
37.406 mtrack: 9: min: 0 max: 65535
37.461 Using input driver 'mtrack' for 'bcm5974'
37.462 mtrack: cannot configure device
37.462 UnloadModule: "mtrack"

And here is my (barebones) mtrack.conf:

Section "InputClass"
MatchIsTouchpad "on"
Identifier "Touchpads"
Driver "mtrack"
EndSection

Any help is appreciated. :)

A bit of further info: Linux version 3.16.0-2-ARCH running on a Macbook pro 8,1.

[PetteriAimonen]

This is just a guess, but the two "Using input driver 'mtrack'" lines seem to suggest that perhaps your device is detected twice for some reason. If that is the problem, it could be possible to limit it using MatchDevicePath "/dev/input/eventX" where X is a number you might find from dmesg.

[dlemke01]

Hi Petteri,
I thought MatchIsTouchpad "on" replaced the need for MatchDevicePath. From http://ubuntuforums.org/archive/index.php/t-1730361.html
BlueDragonX: ' ...Don't use MatchDevicePath anymore, use: MatchIsTouchpad "on" '

I had tried that previously, but got tired of going through all the events in /dev/input, and I think I tested it with the right one b/c if I did cat /dev/input/event11 (I think it was 11), it showed mouse input even though the cursor did not move.

[brutasse]

I had the same problem (updated to xorg-server 1.16.0-6 on Arch, using a Macbook Air from 2012).

Turns out this is due to X now being rootless and my user didn't have the permissions to read /dev/event/input10. A simple gpasswd -a input <user> solved the issue for me.

Another solution is to use /etc/X11/Xwrapper.config to force execution as root as explained here but it's less elegant.

[dlemke01]

Thanks brutasse!

[canoon]

I've fixed this partially in #70 but it still doesn't seem to want to resume correctly after a vt switch.

[rcrath]

I am also having this problem on an up-to-date manjaro system (arch-based). Brutasse's solution did not work for me. It may contain a typo. I think it should be

gpasswd -a user input

not

gpasswd -a input user

Did not work either way. tried after a reboot too. cat /dev/input/mouse2 shows activity on trackpad successfully.

[rynbrd]

It works on xorg 1.16.0, I've been running it against that version for quite a while. This does seem to be an Arch specific issue. I'm not the Arch package maintainer and I don't have any of these systems around I'm afraid.

[rcrath]

removed all traces of earlier versions and checked out master branch, reinstalled, and this time it worked. the one extra thing I did was add another line to my Xwrapper.config file. I'll paste the whole thing in, though at this point I am not sure the extra line I put in is what fixed the problem (after a reboot just to be sure)

# from less elegant solution here
# https://github.com/BlueDragonX/xf86-input-mtrack/issues/69#issuecomment-52619907
# and 
# https://www.archlinux.org/news/xorg-server-116-is-now-available/
# man xorg.wrap
# this is the other option for this file not mentioned in comment above
# allowed_users = rootonly|console|anybody
allowed_users = anybody
# this is the fix recommended:
needs_root_rights = yes
#these are the options:
#needs_root_rights = yes|no|auto

I also added myself to the group "input" as described above, though that alone did not fix the problem.

[rcrath]

broke again after update in 3.16 kernel via manjaro, as per #83, which includes workaround.

[WhyNotHugo]

FWIW, as stated above, sudo gpasswd -a $USER input works fine, though it's just a hacky workaround.

Regrettably , I lack the expertise to improve upon #70 in order to do a proper fix. :(