i2c_hid i2c-DELL0831:00: i2c_hid_get_input

I get this message when i switch on my laptop 7530, I external screen, IBM mouse. every time.

I have been getting the same messages. My logs at /var/log growing very high, for the last week they are about 20 Gb. These messages are scrolling until I'm putting my finger to a touchpad when a notebook returns from suspend.

Dell 7490
Linux dell 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Also, I found this similar bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152

This is due to suspend/hibernate/hybrid sleep/suspend modes not turning-off the Dell Touchpad prior to sleep/suspend.

The default sleep mode, for Dell Inspiron 15, s2idle, is the only sleep state apparently turning-off the power to the touchpad.  Other sleep/suspend modes do not turn-off the power prior to suspend/sleep, hence this i2c_hid bug.  The touchpad device apparently cannot handle sleep/suspend states itself.

A workaround, rmmod i2c_hid and reload i2c_hid, however this puts the touchpad into a simple ps/2 mouse mode, without synaptic features.  (NOTE: the touchpad already appears to be in a ps/2 simple state after suspend/hibernate)

This bug still seems present/persistent with 2021 Dell Inspiron 15 5502 laptops, having a DLL09D9:00 i2c_hid touchpad.

I may have solved this, and I likely previously already diagnosed part of the problem with my prior comment.

Basically your operating system is putting the system into a suspend/hibernate/hybrid sleep/suspend state not supported by the i2c_hid touchpad device.  I quick workaround is to remove the driver/module prior to sleep/hibernate/hybridsleep state, then reload the module afterwords.

Following details how to permanently fix, using proper application or operating system options.

Your suspend to memory method.  On my (Dell Inspiron 5502 laptop) system, s2idle is apparently supported by the touchpad, by an already functioning touchpad after suspend.  (Brackets denote default or next state method to be used.)

$ cat /sys/power/mem_sleep

[s2idle]

Your hibernate or suspend to disk method.

$ cat /sys/power/disk

[platform] shutdown reboot suspend test_resume

Platform denotes your system manfacturer's custom ACPI suspend/hibernate method.  I chose the "platform" method within my /etc/elogind/logind.conf, and now the touchpad works after hybrid sleep.  (Likely EloginD was also trying other incompatible methods instead of platform method.)

/etc/elogind/logind.conf

AllowSuspend=yes

AllowHybridSleep=yes

SuspendMode=s2idle

HybridSleepMode=platform

--SuspendMode=

--HybridSleepMode=suspend platform shutdown

Note: SuspendMode, previously, already had only one sleep mode to try within /sys/power/mem_sleep with my system.  However, I typed in the "s2idle" explicitly, and SuspendMode option carries-over to Hibernate/Hybrid modes for elogind.

Note: HybridSleepMode previously had several different other likely incompatible options, I removed the other options, leaving only the manufacturer preferred "platform" method for my system.

I found the loginctl manual file difficult to read/follow as some sections within the loginctl manual page were not written from a perspective of somebody having a basic fundamental of computer power saving methods.  A good  example, when will hybrid take affect after the system has been in suspend for awhile?  Does Hybrid mode inherit HibernateDelaySec value/int?  Or is does Hybrid wait until almost complete battery drain before powering-off?  Lacks explaining many possible scenarios and configurations.

If you're using something other than elogind, you'll need to back-port these settings to fix the touchpad after using suspend/hibernate/hybridsleep.