after update to xorg-server 1.16.0-6 mtrack fails to function about xf86-input-mtrack HOT 10 OPEN

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.

from xf86-input-mtrack.

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.

from xf86-input-mtrack.

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.

from xf86-input-mtrack.

Thanks brutasse!

from xf86-input-mtrack.

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

from xf86-input-mtrack.

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.

from xf86-input-mtrack.

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.

from xf86-input-mtrack.

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.

from xf86-input-mtrack.

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

from xf86-input-mtrack.

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. :(

from xf86-input-mtrack.