Hello, I’m having the exactly same problem as our friend @ThiagoTnt in the following link:
Any movement (literally any movement) you try in the touchpad is translated as an inverted Y axis cursor movement, at the same time, inverted scroll. Clicking and moving goes a little bit to the right.
I had to use xinput disable 11 so I could click with the usb mouse, otherwise its click wouldn’t work.
I’ve seen people with similar problems in a few others distros, they solved using synaptics or mtrack driver, but as we can’t install any drivers into Endless, I just couldn’t. I downloaded GCC and gnome.Sdk mode, tried to compile xf86-input-mtrack driver from Debian, but it won’t find Xorg package while in Sandbox mode.
It would be very interesting if Endless had a root mode where you could have some real permissions, probably I could solve the problem and posted here the resolution. This read-only limitation is very good for end users which will use the computer, but for me, as a linux heavy user, configuring and trying to introduce the first linux distro to a friend of mine which has this Macbook, it turned into something very hard to get done…
I just thought in the end of the day: “Wow… everything could be resolved with just a sudo apt install. If I could only test this, and see it working, it would help other people to with the same problem and at the same time help the OS dev team with this specific bug.”
The output from eos-diagnostics tool is attached as asked.
Hi,
unfortunately in most cases it’s not easily possible to simply grab some sources and compile it for native execution inside EOS. There are some exceptions, like statically linked applications.
As for Xorg Drivers it’s not possible, because of:
Xorg searches it’s drivers under /usr/lib/xorg/modules, which is part of the read-only mounted OSTree controlled filesystem.
In some other cases where (1) does not matter, you can, however compile for EOS, even if it’s tricky: You need to compile with the Flatpak SDK of your choice and compile all dependencies in the correct version for yourself. Then you can use the resulting binary on EOS natively. But as stated, it’s tricky and not portable - as soon as EOS gets updated, chances are that the binary no longer works. I did this some time ago to have some parts of GVFS available before they were included by default.
Generally, it’s IMHO a good thing not only for beginning Linux users, but for every audience in general to have a read-only system, even if this makes some things harder to impossible. From a security and maintenance view, you get a very robust system which doesn’t make much problems when deployed in the wild.
Ok! I was doing some tests with Manjaro Usb Stick, it uses bcm5974 kernel driver for the touchpad, it works perfectly.
This driver is also available on EOS and it is loaded, since I can see it in lsmod | grep bcm.
I did some tests and if I run sudo modprobe -r bcm5974, touchpad continues enabled.
I added a custom /etc/X11/xorg.conf.d/40-libinput.conf trying to set the driver as bcm5974. After rebooting, I still get libinput running xinput --list-props 11 as the driver, as if my conf file is not being loaded.
Is there any chance that this file in /etc/X11/xorg.conf.d is not being loaded?
Thanks for making the effort to check Manjaro. Indeed our real interest here is to make such hardware work out-of-the-box and knowing that it is working fine elsewhere gives us a good base to figure this out.
Your last comment has mixed up kernel drivers (bcm5974) with X config and X drivers (where there is no such driver named bcm5974, and it would be unusual to have anything other than libinput used regardless of the backing kernel driver) - a bit confusing I know!
What specific observation did you make on Manjaro that tells you that bcm5974 is used? Let’s go deeper into that…
Can you please post, from Endless: sudo cat /sys/kernel/debug/usb/devices
And from Manjaro: sudo cat /sys/kernel/debug/usb/devices dmesg
And the X logs if you can find them (might be in the journal e.g. journalctl -b)