ELAN Touchpad floods syslog [SOLVED]

[debbiethekiwi]

Hardware Huawei Matebook13, touchpad appears to be working fine, perhaps a little sensitive, but that might be the weight of my finger
The problem is that just touching the pad can run the cpu up to 15%, and /var/log/syslog writes zillions of these lines, repeated at a whisker under 7milliseconds:

Code: Select all

Oct 27 15:17:18 debbie kernel: [ 2828.392651] i2c_hid i2c-ELAN962C:00: i2c_hid_get_input: incomplete report (14/65535)

I tried to apply the patch from https://github.com/nekr0z/linux-on-huaw ... ok-13-2019 but it failed with

Code: Select all

dh_testdir
rm -rf debian/build debian/stamps debian/lib/python/debian_linux/*.pyc debian/lib/python/debian_linux/__pycache__ $(find debian -maxdepth 1 -type d -name 'linux-*') debian/*-modules-*-di* debian/kernel-image-*-di* debian/xen-linux-system-* debian/*-tmp
dh_clean
mkdir -p debian/build
printf >debian/build/version-info 'Source: %s\nVersion: %s\n' linux 4.19.67-2a~test
md5sum --check debian/control.md5sum --status || \
	/usr/bin/make -f debian/rules debian/control-real
dh_testdir
/usr/bin/make -f debian/rules.gen source
make[1]: Entering directory '~/build/linux-4.19.67'
/usr/bin/make -f debian/rules.real source-featureset ABINAME='4.19.0-6' FEATURESET='none' SOURCEVERSION='4.19.67-2a~test' SOURCE_BASENAME='linux' UPSTREAMVERSION='4.19' VERSION='4.19'
make[2]: Entering directory '~/build/linux-4.19.67'
test -d .pc
set +e; QUILT_PC=.pc quilt unapplied --quiltrc - >/dev/null && echo 'Patch series not fully applied'; test $? -eq 1
Patch series not fully applied
make[2]: *** [debian/rules.real:146: debian/stamps/source] Error 1
make[2]: Leaving directory ~/build/linux-4.19.67'
make[1]: *** [debian/rules.gen:1137: source_none_real] Error 2
make[1]: Leaving directory '~/build/linux-4.19.67'
make: *** [debian/rules:25: source] Error 2

The machine is working, just the spurious writes to log will be a) chewing up battery, and b) wearing out SSD. Uncompressed syslog is abot 700MB per week, compressed abt 60MB. All the reports I've found on the net for the syslog msg are from people whose touchpad either doesn't work period, or has erratic function.

[Deb-fan]

Kind of a hack but this is first thing that popped into head for your situation. That being to set it so that all that garbage is simply excluded from logging to your syslog. As long as it's working fine, who needs to hear all that noise. Haven't been in that particular situation so can't advise how to proceed in any detail, just give the general idea. Finding a way to simply tell it to shut it or send the fecker to /dev/null HELL!

Btw: How's New Zealand these days ? Hope all you kiwi's are doing well.

[debbiethekiwi]

Yeah, it had occurred to me a dirty hack could stop it logging, but the bug/feature has been in and out of the kernel modules. There's backchat between the kernel devs and Dell amongst others, but mainly concerned with getting the touchpad to work properly or at all,,,

[Deb-fan]

Hmmmm, well it's what I'd likely do in such a situation. Curious have you tried other distro's, ala: Linux Mint or Ubuntu and this also affects them too ? Just one of the quirks of gnu/Linux when it comes to hardware support sometimes a person is or can be out of luck or have to resort to some hacking, duct-taping or other work arounds. In particular seems logical when discussing Debian stable. Emphasis is on stability, not latest support. Though surely many ways to address such concerns, if/as needed.

Other stuff which occurs would be trying a newer kernel perhaps, newer firmware packages if available/relevant, yada yada. As for sensitivity, would take that up with adjusting libinput or whichever you have setup to deal with the touchpad. Though of course doesn't address the logging thing. As long as it's working, the aforementioned hack would be my route of choice. Good luck ...

[Deb-fan]

Missed something rather significant in your OP Debbiethekiwi, touching the thing spikes your cpu(s)up to 15%, yikes, that would drive me nuts too. The logging hack is one thing, that above something else. Well so did a bit of googling came up with this ...

Sounds like the same deal as yours, is that what you tried to fix it with ? If not give er a go ? Edit: Oops, yep it is, might try again ? Didn't really look over what you're reporting as error message. Will have to look again real quick ... Here's the github page for the project(you already found). As mentioned above, might be mucho easier to go with a more suited distro, highly dislike advising someone who seems to have their head on straight to use something other than Debian, just saying looks like there is an easy button for that system here.

Couldn't hurt to try a newer kernel, though the one's from Debian may well lack the patch needed regardless and a hail Mary throw here would be to perhaps try out the Liquorix kernel, he may have included or left the patch out-of-box. Been forever since I've dorked with Liquorix but have played with it on Debian stable ( well #! = Crunchbang gnu/Linux, which was always based on Debian stable.)

See Cont below, or will be ... trying to think.

[Deb-fan]

Cont:

Well actually not going to be a big one, going to ask a question here. Do you have everything you need to successfully compile a kernel yourself ? You've done so before ? Noticed recently that many of the tools needed which used to be included in build-essential had gotten separated out. I do tend to generally compile my own kernel and had recently done one for a 64bit OS on my old laptop. Vaguely remember it failing, getting pissed and later found I was missing some of the junk I'd thought were in build-essential. Afterwards the compile went as expected.

Mind linking to the how-to/process you used to attempt to compile this kernel ?

Yet another edit, arghhh! You're of course getting the source from Debian ? Last one I built was upstream (kernel.org/vanilla) and you need these things installed. At least if you're editing the .config file used with "make menuconfig". Have done Debian source and upstream blahblah ... Do you have them ?

Code: Select all

apt install libelf-dev bison flex bc libssl-dev libncurses5-dev build-essential

Also see this if you haven't already, the main point am getting at is that it appears you may need the multi-touch touchpad package thingy installed. What are you using for touchpad, libinput ? "dpkg -l |grep libinput" ? Anyway, will check back, have way more questions than answers. This would be much easier if I could just dork with your system. Mind shipping your new comp to me in the states ?

[Head_on_a_Stick]

I tried to apply the patch from https://github.com/nekr0z/linux-on-huaw ... ok-13-2019 but it failed

Looks like the patch wasn't applied correctly, how exactly did you do that?

I would download the source package then apply the patch and run

Code: Select all

dpkg-source --commit
debuild -us -uc

[debbiethekiwi]

Looks like the patch wasn't applied correctly, how exactly did you do that?

I followed nekr0z instructions, or at least I hope I did. Maybe the kernel I have is too new for his patch, the joys of kernel hacking...

Curious have you tried other distro's, ala: Linux Mint

I'm breaking off a 30 year romance with Apple/Macintosh, and am looking at various distro's for something that fits my workflows and is not a hassle to run. I've used Linux Mint for some years on a spare partition on my MacBook, it was easy to get along with, but when I upgraded from 17 to 19 to look for gotchas with this new hardware, the MacBook complained, got much hotter in some of my video rendering tasks. There's threads over on the mint forums about it. On this Huawei ripping a dvd runs 10°C hotter and 20 frames/sec slower on Mint Cinnamon 19.2 vs. Debian Mate 10.1. Mint using the extra cpu cycles to warm the planet doesn't appeal to me, but Mint doesn't have the touchpad flood problem, go figure...

[Deb-fan]

Occurs to me a nice chunk of the 15% cpus spiking may be attributable to those "trillions" of errors being logged and excluding them could help alleviate your problem, like you mentioned also avoid unnecessary wear and tear, the heavier a cpu is loaded logically enough the hotter it'll be, electronics aren't real big on heat and less responsive/available to do the things you want it to be doing. Jmo it's only a dirty hack when it doesn't accomplish something productive and there's obvious better ways and options, shrugs. Definitely not ideal, I get that ... sheesh bothers someone enough, they can get a bluetooth mouse or summin.

Oops, brought back a memory, when was using window$ discovered something called a software mouse, using the arrow keys or whatever on the keyboard. The thing was actually pretty kickbutt and used it as (more)often than an actual mouse.

When it comes to LM, I started out with it, LM10 (Gnome 2.4) actually have a soft spot for the distro. Though only very briefly stayed with it. Kept dorking around in the community for years after I'd stopped running anything Mint. Though yep, think they do make a fine gnu/Nix distro regardless. However suffer from what I like to call over-configitus. So many layers upon layers of stuff running, obscures what's underneath it all. All those bells + whistles, always on. If someone doesn't use Bluetooth with their comp, they don't need it running, cups = printing same etc etc. Besides those can easily be enabled when needed and shut down when not.

Mint 10 came out-of-box at like 270mbs-ram, had it down to 120 something within a short period w/o much loss of features, actually ran much better and snappier. End of the day it's all gnu/Nix underneath, someone can make it whatever they please (learn to.) Might try some alternative kernels, real-time, low-latency/preemptive, jacked up timer interrupt freq etc etc blahblahblah, multi-media can be a horse of a diff color in terms of what kernel config are best vs jane/joe avg desktop user. A persons choice of power governor, which they can even be easily switched between on the fly. On and friggin on, yada, yada.

Don't agree with many of the stock choices distro devs/maintainers make, so I compile my own now and wuv Debian cause they give you everything someone could need to make it whatever the hades they want. On a positive note, finally got around to installing Buster, yay ! Lol ... about 30 hours later, pleased with how the thing is coming along. Still a way to go but happy to be one of the cool kids again.

No matter, can tell you're an intelligent lady, so definitely hope you stay with Debian anyway. Some real good folks in the Debian crowd.

[Head_on_a_Stick]

Looks like the patch wasn't applied correctly, how exactly did you do that?

I followed nekr0z instructions, or at least I hope I did. Maybe the kernel I have is too new for his patch, the joys of kernel hacking...

Those instructions don't work for me, that patch won't apply cleanly.

Try this patch instead.

To apply it use this method:

Code: Select all

apt source linux
wget https://gist.githubusercontent.com/Head-on-a-Stick/e270c0f94e1bb36bac29dd105902a8bb/raw/1633c1a2c4b5e87fd1012598706abb359b7529a5/elan.patch
cd linux-*
patch -p0 < ../elan.patch
dpkg-source --commit # enter patch name & message
debuild -us -uc
dpkg -i ../linux-*.deb

The patch applies cleanly for me but I haven't tried actually building the kernel.

Note that the patch is already applied to the kernel version in the buster-backports repositories.

[Deb-fan]

^Hey cool, why didntcha just say that in the 1st place man !!! Messing and glad you lent her a hand Hoas.

[debbiethekiwi]

Those instructions don't work for me, that patch won't apply cleanly.

Like I said, the joys of kernel hacking...

Note that the patch is already applied to the kernel version in the buster-backports repositories.

Code: Select all

$ uname -v
#1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)

So are you saying that the 4.19.67-2+deb10u1 in backports is patched without a change in version number? Because 5.2.0 is the only later one, and if I look at that I'm down a rabbit hole after missing i915 updates...

[Head_on_a_Stick]

So are you saying that the 4.19.67-2+deb10u1 in backports is patched without a change in version number? Because 5.2.0 is the only later one, and if I look at that I'm down a rabbit hole after missing i915 updates...

I don't understand your i915 comment but the kernel version in the buster-backports repositories is 5.2.something.

[debbiethekiwi]

1.) I tried your patch Head_on_a_Stick, it must be me I guess, even with the --verbose flag patch just sat there for 40 minutes with a blinking cursor. Too lazy to scour the logs for why, I took the 5.2.0 kernel from backports (there is a 4.19.67-2+deb10u1 in there too, same as I had) and
2.) apt moaned about my i915 components not being up to the version it wanted for the 5.2 kernel. After persuading Grub that, yes, I did want to boot 5.2, all seems fine , no flooding of the logs, no i915 complaints in the logs, stable and cool. Thank you Sir.