You’re right, I did indeed skip over the FHS documentation, but I’ve now saved it and will make my way through it.
I am getting the following message when I run
sudo cat /sys/bus/i2c/drivers/i2c_hid/bind
Results in:
cat: /sys/bus/i2c/drivers/i2c_hid/bind: Permission denied
with similar results for the other place. I originally ran without sudo and got the exact same result with both files.
Weird.
Let’s check the directory tree if you even have that device, so what’s the output of:
sudo tree /sys/bus/i2c/drivers/i2c_hid/
Please?
The results are:
/sys/bus/i2c/drivers/i2c_hid
├── bind
├── module -> ../../../../module/i2c_hid
├── uevent
└── unbind
1 directory, 3 files
and here’s the same command for elants_i2c:
/sys/bus/i2c/drivers/elants_i2c
├── bind
├── i2c-ELAN0001:00 -> ../../../../devices/platform/AMDI0010:01/i2c-1/i2c-ELAN0001:00
├── module -> ../../../../module/elants_i2c
├── uevent
└── unbind
2 directories, 3 filesThat looks good too!
Did you do a chmod on /sys/?
If not:
ls --all -l --classify --human-readable /sys/bus/i2c/drivers/i2c_hid/bind
please?
Here is the result:
--w------- 1 root root 4.0K Apr 28 11:07 /sys/bus/i2c/drivers/i2c_hid/bind
and the other file:
--w------- 1 root root 4.0K Apr 28 11:08 /sys/bus/i2c/drivers/elants_i2c/bind
Write only! So forget what I told you about the cat: you cannot read these
OK, so to change the parameters,
Add
i2c-ELAN0001:00to the following locations:/sys/bus/i2c/drivers/elants_i2c/unbind
/sys/bus/i2c/drivers/i2c_hid/bind
do a:
sudo -s #this will make you "root"
echo "i2c-ELAN0001:00" | tee --append > /sys/bus/i2c/drivers/elants_i2c/unbind
echo "i2c-ELAN0001:00" | tee --append > /sys/bus/i2c/drivers/i2c_hid/bind
Breaking this down:
echo "i2c-ELAN0001:00"
just “prints” the string “i2c-ELAN0001:00” to STDOUT (standard output)
|
“pipes” this into the following command
tee reads the string “i2c-ELAN0001:00” from STDIN through the pipe and --appends it to the files you want!
Et voilà.
Hello,
unfortunately, this is still giving me the following:
zsh: /sys/bus/i2c/drivers/elants_i2c/unbind: Permission denied
Try again using bash as that’s what I’m on? (Never used zsh, so know nothing about its syntax)
Thank you for your time and patience.
Bash is outputting the same Permission denied message. I did a clean install just in case (i hadn’t yet transferred any of my files over so it was a piece of cake), and all the commands from this thread output the exact same. I used the minimal install of the manjaro gnome version, so perhaps there’s something in the full install that I’m missing?
Worked like a charm! Thank you so much for your help.
Sorry about all the time it took, but although I’m an old fart wise now, I remember being young and stupid not so wise and you’re on your way to become old and wise now…
P.S. I’ve edited my answer to include the “Become root” now so the next person that has the same problem as you can just jump to the solution without all the tutorials! 
Thanks. I’m sorry to say that this story doesn’t have a happy ending, as the changes did not hold through a shutdown. Powered my laptop up after running some errands and the touchpad is unresponsive again. Should I repeat the fix?
I don’t have your hardware, so can’t vouch for the solution you followed: I just helped you translate TechnoBabble to Human…
However you can convert all commands to a script and then make that script execute every time at boot through a SystemD service. (As SystemD services run as root, forget about the sudo -s stuff)
Google DDG on how to create a ZSH script as you know I’m on BASH, so can’t really help you with that…
probably …
but maybe you just forgot the “blacklist” step of the procedure?
otherwise, if it doesn’t work after the repeat of the steps and then a reboot
to make it “stick” I guess this could help:
In that Arch Wiki there is a link at the end of the section re the touchpad:
it says:
Tip: https://bugzilla.kernel.org/show_bug.cgi?id=207759
right above it, comments 17 and 19 to that bug report are mentioned
If you go there, there are all the commands listed
as well as a ready made systemd service script, ready made to copy and paste and use
(so it appears - obviously I can’t test that)
comment #17
HTH
Ah, of course. I forgot that this was but the first step of the procedure.
So the two remaining steps are:
First, load the
h2c_hidkernel module.
After that, all that’s left is to blacklistelants_i2c.
Since I don’t have a touchscreen, it doesn’t look like I will have to worry about the script fix, though it’s helpful to know it’s there. Could you help me through these last two steps? For the first step:
modprobe i2c_hid
Then, blacklisting seems to be a multistep process. From here, Create a .conf file inside /etc/modprobe.d/ and append a line for each module you want to blacklist, using the blacklist keyword. should be taken care of via:
echo "blacklist elants_i2c" > /etc/modprobe.d/touchpad-fix.conf
Then, it says to
Remember to add that .conf file to the
FILESarray in/etc/mkinitcpio.confif you do not have themodconfhook in yourHOOKSarray (e.g. you have deviated from the default configuration), and once you have blacklisted the modules regenerate the initramfs, and reboot afterwards.
and it’s this that I’ve again hit a wall of understanding with. Here’s a less for that file on my machine:
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES=(piix ide_disk reiserfs)
MODULES=""
# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image. This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way. This is useful for config files.
FILES=""
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No raid, lvm2, or encrypted root is needed.
# HOOKS=(base)
#
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS=(base udev autodetect block filesystems)
#
## This setup will generate a 'full' image which supports most systems.
## No autodetection is done.
# HOOKS=(base udev block filesystems)
#
## This setup assembles a pata mdadm array with an encrypted root FS.
## Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
# HOOKS=(base udev block mdadm encrypt filesystems)
#
## This setup loads an lvm2 volume group on a usb device.
# HOOKS=(base udev block lvm2 filesystems)
#
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr, fsck and shutdown hooks.
HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems fsck"
# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
#COMPRESSION="zstd"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()
Thank you in advance!
Where in that Arch Wiki does it say that?
It should not be necessary anyway - because the “modconf” hook is there already, if you did not remove it yourself.
Verify that the file actually exists and contains what it should contain, what you put in it:
cat /etc/modprobe.d/touchpad-fix.conf
It’s in the middle of that second paragraph under #Blacklisting.
Excellent, thanks!
its’s not in here - the Arch Wiki “guide”
… but it seems unnecessary anyway …
I had clicked over to the archwiki article on kernel modules.
https://wiki.archlinux.org/index.php/Kernel_module#Blacklisting
and I’ve rebooted the computer and the fix has taken hold! woo!