search

hugegreenbug / xf86-input-cmt

X11 ChromiumOS touchpad driver ported to Linux
BSD 3-Clause "New" or "Revised" License
82 stars 15 forks source link

cmt module does not load when X is started using 'startx' #5

Open joebonrichie opened 9 years ago

joebonrichie commented 9 years ago

This is an issue for Arch users who install the 'xf86-input-cmt-xorg' driver in the AUR if they start X manually using 'startx' the module does not load. This is an non-issue for people who use a display manager which loads the module.

When using 'startx' other input drivers such as synaptics load as they should.

The Arch wiki tells me that evdev will act as a hotplug for input drivers https://wiki.archlinux.org/index.php/xorg#Input_devices This may be a problem on Ubuntu as well as Arch I believe the problem is because we are using libevdevc. I will try using the module with linux libevdev and see if it works.

Any help or info that will help me resolve the issue would be appreciated.

joebonrichie commented 9 years ago

To replicate switch to tty2 and run startx. Unity did not like this however with my testing on ubuntu.

hugegreenbug commented 9 years ago

I will look into it. Thanks.

Hugh

On Tue, Mar 17, 2015 at 7:43 AM, Joey Riches notifications@github.com wrote:

To replicate switch to tty2 and run startx. Unity did not like this however with my testing on ubuntu.

— Reply to this email directly or view it on GitHub https://github.com/hugegreenbug/xf86-input-cmt/issues/5#issuecomment-82357966 .

joebonrichie commented 9 years ago

Quick update, also an issue on gdm 3.16 (wayland) when loading a X session but not a wayland session.

hugegreenbug commented 9 years ago

Sorry for the late reply. I'm on Ubuntu 14.04 and the mouse driver did work correctly with startx. I tried it with the latest version and the older version. When you tested on Ubuntu, did you use my packages?

ghost commented 9 years ago

After doing all manner of things (including trying the latest kernel [4.0] RC), I decided to try and look into this bug. After reading the Xorg log through the systemd journal I came across a couple of lines indicating Xorg's inability to load the driver, most importantly:

[...] /usr/lib/gdm-x-session[493] (**) cmt: Cypress APA Trackpad (cyapa): Opening Device: "/dev/input/event12"
[...] /usr/lib/gdm-x-session[493] (**) cmt: Cypress APA Trackpad (cyapa): Cannot Open: "/dev/input/event12"

This seemed like a permission problem to me, as all other Xorg messages related to finding and loading modules (especially in regards to /dev/input/event) worked correctly.

After doing a little research, I came across a few articles regarding Xorg and input devices with something to the effect that the group input controls permissions in regards to whether Xorg can see and access input devices due to the same group being listed as owning everything in /dev/input/ (specifically all of the event devices).

So putting 2 and 2 together, I decided to test the theory that perhaps GDM did not have the correct permissions. As such, I added the group input to the user gdm with:

sudo usermod -a -G input gdm

After this, I rebooted and voila! The touchpad was now working correctly at the login screen! However, as soon as I logged in the touchpad did not work again. After re-reading the Xorg log, the touchpad did indeed load the cmt module correctly, but errored out once I was logged in. So I decided to do the same thing with my own user account, in this case thomas:

sudo usermod -a -G input thomas

After another reboot and login the cmt driver was now working correctly for everything!

After this ,I did a little bit more investigating to see exactly why Xorg was acting this way by running ps aux | grep Xorg. From the looks of things, Xorg is actually running as two separate processes, one under the user gdm and one under my own user thomas. My guess is this why there are two seperate tty's running at any given time when GDM is started: one for GDM itself and one for the user currently logged in. (One can verify this by simply switching to the first tty once logged into GNOME and then back to the next, the second tty in my case.)

_TL;DR:_ There seems to be a permissions problem in regards to GDM being able to access the touchpad in the corresponding event file in /dev/input/. To alleviate this for the time being simply run (as root):

usermod -a -G input gdm
usermod -a -G input <user>

Where <user> is the username you are trying to use when logging into GNOME. After this, reboot, and the touchpad should be working as expected.

joebonrichie commented 9 years ago

Awesome thanks templrivanho, can confirm its working with Gnome/GDM 3.16 Additionally, I disabled GDM and used 'startx' to execute the gnome-session and the touchpad worked! Not sure if it was your fix, or recent packages libevdev/gnome arch updates that solved it.

update: It appears I didn't need to run: usermod -a -G input gdm I tested gnome-session and mate-session with gdm 3.16 and 'startx' @templrivanho can you confirm whether you need to run 'usermod -a -G input gdm' or not? If you need that command to make touchpad work with gdm can you check if 'libinput' is installed?

ghost commented 9 years ago

Yes libinput was already installed and I also installed xf86-input-libinput to make sure whether or not the input group was needed to be added to gdm. Unfortunately for me, removing the input group did indeed make the touchpad unresponsive to gdm but after using the keyboard to login, the touchpad was working for my user.

This was on a fully up-to-date Arch install.