I have found that it is a kernel bug relating to “hid_rmi”
“I have the same issue on my Dell 9Q33 (similar innards to 9333). After bisecting, the issue does indeed appear after the introduction of hid_rmi. It seems that the f54 probe has a race condition that corrupts a future read, and when the probing tries to read the next function’s data, it gets a garbled mess.”
I’m attaching a hacky patch as a workaround while I look into the root cause, can you try it on a 9333?
I looked on http://kernel.ubuntu.com/~kernel-ppa...11-rc1/CHANGES and found
“HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4”
“HID: rmi: Handle all Synaptics touchpads using hid-rmi”
Perhaps this is what caused this bug to occur for hid_rmi? https://lkml.org/lkml/2017/3/28/1234
Kernel 4.10 recognises touchpad as DLL0651:00 06CB:2985 and am able to use right-click using the physical button.
Kernel 4.11 recognises touchpad as Synaptics s3203 but the right click button does not physically work.
I had the same issue on Opensuse tumbleweed when they updated their
kernel and same on Ubuntu 17.04 linux 4.11, (I even posted on their forum https://ubuntuforums.org/showthread.php?t=2361882
I don’t have enough permission to upload any .txt files (I have them linked on ubuntu’s forum)
I posted the same message on Ubuntu’s forum, pabilities. (The numbers represent kernel version)
The issue is not Antergos-related. It is present not only in many Arch-based distros, but also n native Arch. It hurts Mate and Plasma here. Cinnamon and Gnome3 are not affected by the issue.
The workaround in brief: install dbus-x11 package from AUR with:
yaourt -S dbus-x11
After that dolphin and systemsettings5 will work with kdesu in Plasma, caja will work with gksu in Mate.
The workaround is not nice. Why?
it installs an AUR package. For the sake of stability, it’s better to avoid to install anything from AUR. Especially packages like dbus, which act at a system level.
dbus-x11 is in conflict with core/dbus package, which must be removed to install dbus-x11. Replacing a core package with another from AUR is a madness.
The workaround is difficult to apply. Why?
dbus-x11 is signed with the 4DE8FF2A63C7CC90 key, which is not in any keyring I use: archlinux-keyring, antergos-keyring, apricity-keyring. Simply speaking, yaourt may refuse to install the package because of unknown public key. If this is the case, just ask - I’ll explain how to add this key to trustdb.
Antergos has another Plasma-specific diffculty. While AUR packages install without a problem in other Antergos flavors, some of them refuse to install in Plasma - apparently because of docbook* -related problems. In this case I build an AUR package in Mate | Cinnamon | Gnome3, and then install it in Plasma. You should be able to build an AUR package in one DE and install it in another. If in need, I’ll explain how to do that.
The workaround is dirty. Why?
it replaces a system package from [core] with another from AUR
it installs a package signed with not quite normal public key
The workaround works. Why?
- because everything is possible in Arch :)
I’ll try to attach the ready-to-use dbus-x11 package, built by yaourt from AUR, here. Not sure whether the forum’s software will allow to upload a binary package in a public place:
- dbus-x11 package
If you can download the package, then forget about yaourt-related nightmare described above, and simply install the package with:
sudo pacman -U <path-to-downloaded-package>
Accept dbus package removal during dbus-x11 install.
Thank you for the explanation and guide, I’ll give this a try later tonight.
This is from a clean Kde install yesterday (Dolphin Version 16.08.1)
$ sudo dolphin = “Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)”
kdesu dolphin = no messages but dolphin still does not open
Kate works with sudo and kdesu
I have Antergos and Windows 10 installed on the same machine and have setup with efi (Dell 3542)
When I shutdown the Gnome 3 logs out and when the machine shutsdown the HDD turns off but the screen is still on with cgroup : option or name mismatch, new: 0x0"", old: 0x4 “systemd”
sudo systemctl --failed brings me “0 loaded units listed. Pass --all to see loaded but inactive units, too.”
[Picture of shutdown screen where it hangs at] http://imgur.com/nwjrsBR
I tried sudo shutdown -h now but that also hangs
my partitons are as follows.
/dev/sda1 Recovery (windows 10)
/dev/sda2 EFI (windows 10)
/dev/sda3 Microsoft Reserved
/dev/sda4 Windows 10 NTFS
/dev/sda5 EFI (Antergos)
/dev/sda6 ext4 (Antergos)
I tried including my logs and uploading but the logs are at 12mb.
Which important ones can I paste?