2

Some Background

While I realize that my question is related to my original post over on Ask Ubuntu, it was never answered there, and I'm really hoping to refocus my question here (as it's really no longer a Ubuntu specific question), so...

The Issue

From that original question, I'm running Ubuntu 22.10 on a Lenovo ThinkPad T15 Gen2, and my goal was to disable the touchscreen, as I don't use it and I just keep bumping it accidentally, causing problems. So, I wanted to just disable the touchscreen entirely.

While I ultimately did figure out how to solve my issue, what's still concerning me is that I ended up with multiple possible solutions, which is something of a "shotgun approach" to resolving this issue.

I could:

sudo modprobe -r hid_generic
  AND
sudo modprobe -r hid-multitouch

Or I could:

sudo modprobe -r i2c-hid-acpi
  OR
sudo modprobe -r intel_lpss_pci

Or even disable a driver:

GRUB_CMDLINE_LINUX_DEFAULT="splash initcall_blacklist=dw_i2c_init_driver"

Sure, any of these solutions seem to work, but I don't know which is the most appropriate (and/or most efficient) solution.

My Question

So... my question isn't so much about disabling the touchscreen (that's resolved) as it is about how to know how to identify the best solution. Or put differently...

What's the best approach for determining/troubleshooting specific module functionality with a high degree of understanding?

Since troubleshooting this issue, I'm starting to think the only way to really identify the most appropriate solution would be to track down the source code for every kernel module, and step through them and fully understand their functionality (and side effects). But that seems to be overkill, and I wonder if there's a much better way?

Thanks

richbl
  • 121
  • 3
  • Did you think about deactivating ”the touch of your screen“ in your BIOS/UEFI? – Nepumuk Mar 25 '23 at 16:01
  • @Nepumuk, that was my first thought, but no such option exists in firmware to do this. – richbl Mar 25 '23 at 20:22
  • 1
    blacklisting it with grub is probably the most "efficient", it prevents the module loading at all. the other method unloads it after it has been loaded. but it probably makes no significant difference either way, use whichever method is *easier* or most *convenient* for you. ease and convenience are more important than a few milliseconds (at most!) at boot time. – cas Mar 26 '23 at 02:09
  • @cas, I guess my question is **how** to determine which module to ultimately blacklist. In my case, it was a brute force effort: walk all of the loaded kernel modules, disable them, and see what happens. And as it turns out, there were several different "solutions." I was hoping there'd be a more "logical" approach. Let me know if I need to tweak my question to better underscore this. Thanks much. – richbl Mar 26 '23 at 03:00
  • 1
    Unless you already know exactly which driver(s) to disable, the only real substitute for trial-and-error AND reading docs + source code is to ask other people (hopefully finding someone who has already done the trial and error for your specific case, or has enough general knowledge/experience to either figure it out or extrapolate from their existing knowledge to your case). Some combination of Knowledge, Experience, and willingness/ability to Research & Experiment will always be required. This is true for pretty much everything, not just Linux. It is the path to expertise in any field. – cas Mar 26 '23 at 03:18
  • @cas, **this is good feedback**, as it confirms my observation/experience that there may not be any definitive resource for kernel module information that I somehow overlooked. While reading through source code isn't not fun (I code for a living, so I'm quite used to it), I had thought (hoped?) that there was something perhaps a bit less granular out in the ether somewhere. BTW, if you want to move this to an answer, I'm good to close out this question. Thanks again. – richbl Mar 26 '23 at 03:41
  • I don't think it's good enough or specific enough to be an answer. It's just generic autodidact opinion / philosophy. – cas Mar 26 '23 at 03:53

0 Answers0