Hello! On Monday 11 April 2022 15:48:48 Hans de Goede wrote: > Hi Mark, > > On 3/21/22 23:18, Mark Pearson wrote: > > > > Apologies if this is thread hijacking...but I've got a similarish > > problem on Lenovo laptops that we have on the todo list to investigate > > so wanted to jump in with a somewhat related question... > > No problem. > > > On 3/18/22 04:54, Hans de Goede wrote: > >> > >> Regardless of the method, the kernel's responsibility here is > >> to make sure the touchpad gets seen as a touchpad and after that > >> "disabling" it is a userspace problem. > >> > > > > The issue on our platforms is that if you disable the touchpad in the > > BIOS it doesn't actually disable the touchpad. It sets a flag in the EC > > registers to let the OS know the touchpad is not supposed to be enabled > > (I only just found out this is how it is supposed to work). > > Interesting. > > > I'm not 100% sure the reasons for this - I think it's to do with keeping > > the trackpoint usable (maybe). > > Yes that makes sense the trackpoint often sends its data to the touchpad > which then muxes the trackpoint data into its own datastream as special > trackpoint packets. So disabling the touchpad at the hw level would also > disable the trackpoint in these kinda setups. That is truth. And some kernel drivers are smart and try to de-mux these packets and reports trackstick events via different input device as touchpad input device. So via xinput it is possible to disable e.g. touchpad while keeping trackstick working. This disable method is of course Xserver specific and just instruct Xserver to ignore events on one input device. > > So just curious on the comment above - is there a standard way to let > > user space know to ignore the touchpad or disable it by default? > > Not yet, but we could define one. Or we could even try to see if > a patch to drop all non trackpoint data inside the kernel when the > flag is set would be accepted. > > Someone needs to write the code for this though and if we want to let > userspace know also define a userspace API. I think the all kernel > solution might be the easiest to implement, but I'm not sure if this > will be accepted by the input subsystem maintainer. There is really no standard way... > > I'm obviously being lazy here as I've been meaning to go and read code > > but I was flicking thru the mailing list and this caught my eye....and > > if there's a shortcut to the answer that would be awesome. > > > > I've no idea if this is a Lenovo specific issue or more generic - but > > this thread made me wonder if it's actually a common/standard problem? > > This is the first time I have heard about this. > > Regards, > > Hans > ... and this not first time I read about this request. In past there was request for Nokia N900 touchscreen driver and its userspace to disable receiving events on opened touchscreen input device. External tool monitored ambient light sensor and determined when phone was in pocket and when not. And it needed to instruct kernel to not send touchscreen events when phone was in pocket. IIRC at that time kernel for Nokia N900 had custom patch with custom API for enabling/disabling touchscreen. This requirement is not exactly same as yours, but have common thing: ability to enable / disable input device and report if device is disabled or not.
