Drivers Hampshire Mice & Touchpads

Mouse Touchpad Driver Download Of Hp
Mice Touchpad Settings
Drivers Hampshire Mice & Touchpads Drivers

For two years I’ve been driving myself crazy trying to figure out the source ofa driver problem on OpenBSD: interrupts never arrived for certain touchpaddevices. A couple weeks ago, I put out a public plea asking for help in caseany non-OpenBSD developers recognized the problem, but while debugging anunrelated issue over the weekend, I finally solved it.

It’s been a long journey and it’s a technical tale, but here it is.

Windows Precision

Willem Lange is a beloved New England contractor, writer and master storyteller. His weekly column, A Yankee Notebook, appears in several New England newspapers. He's a commentator or host for Vermont Public Radio and both Vermont and New Hampshire Public Television. So most touchpads are basically a mouse. Now, some of the more advanced standard touchpads provide enhanced drivers and software that allow more control and gesture-like features.

In 2015, I purchased aSamsung ATIV Book 9laptop.Its touchpad was different than most other laptops used with OpenBSD previously,and would be a model for most touchpads to come after it: aWindows Precision Touchpadconnected over I2C.

Most other laptops had a touchpad connected through the PS/2 controller along withthe keyboard, emulating the historical design of PCs havingtwo PS/2 portsfor an external mouse and keyboard.These devices from Synaptics, Elan, and ALPS each spoke aproprietary protocoland were rather bandwidth-constrained in terms of how much finger data they couldcommunicate back to the OS which became a problem when multi-touch gestures becamea thing in Windows.

For these devices, Microsoft produced itsWindows Precision Touchpad specificationand would handle the driver side of things, allowing vendors to havetouchpads that shared a common driver and worked in Windows out of the box, aswell as allow Microsoft to provide a better touchpad experience with gesturesand palm rejection (but still not be able to rival what Apple does with theBroadcom touchpadson their MacBooks).

OpenBSD Support

In 2016, I finishedwriting driversfor these touchpads which required anI2C controller driver(dwiic),a HID-over-I2C driver(ihidev),a basic I2C-HID mouse driver(ims),then a full transport-agnostic HID driver implementing theWindows Precision Touchpad spec(hidmt),and finally an I2C touchpad driver(imt)to interface between ihidev and hidmt.

Shortly after, some laptops started showing up with their keyboard connectedover I2C as well, requiring theikbddriver.In 2018, I wroteumtto support USB-connected Windows Precision devices in use on some laptoptouchscreens.

While all of this worked fairly well and somewhat modernized OpenBSD’snon-ThinkPad laptop support (many ThinkPads up until some 2019 modelsstill used a PS/2-connected touchpad and TrackPoint), there was one aspect thatdidn’t work:on Broadwell chipsets, the touchpad would not wake up after an S3 suspend/resume.

Bug-Hunting

Later in 2016, I purchased a Chromebook Pixel and gotOpenBSD running on it.The Pixel also had its touchpad and touchscreen connected over I2C,though being a Chromebook not running Windows, its touchpad did not conform tothe Windows Precision Touchpad standard which meant it needed a new driver(iatp).

The Chromebook Pixel was also a Broadwell chipset and this new driver had thesame issue: communication with it failed after an S3 resume.Two different vendors of touchpads and two different drivers, but the sameproblem.The I2C controller (dwiic) worked fine after resume, but any time it tried tocommunicate with the touchpad device, everything would just timeout.

After some months of debugging on Linux, I tracked down the fix to asingle writeto a register on the I2C controller device, found in Linux’s Intel Low PowerSubsystem (LPSS) driver for power gating.

Intel’s LPSS is used for their I2C and SPI devices used to limit power usageby quickly shutting off components when idle.The way this is implemented in Linux is kind of confusing, and even now lookingat their mainLPSS driverI can’t see where the 0x800 register comes from that OpenBSD’s driver writesto the I2C controller in order to power up the I2C slave device.That Linux driver registers a clock (clk) device and the clk frameworkhandles the register writing itself rather than calling back to a function inthe LPSS driver, which is why it took me so long to find it in 2016.

Interrupting `ihidev`

In 2017, I purchased aHuawei Matebook Xwith a Kaby Lake chipset which Intel refers to as the 100 Series.Intel’s I2C controllers on this chipset now show up as actual PCI devices, whichmeantsplitting upthe dwiic driver to handle both PCI and ACPI attachments.

The dwiic driver fetches ACPI resource information for I2C slave devices thatare connected to it, like the touchpad.That resource includes the I2C slave address and interrupt pin that it isconnected to on the IOAPIC.ihidev then attaches and uses the standard methods in the OpenBSD kernel toprogram the ioapic device to register a callback to ihidev whenever that pinreceives an interrupt.

Despite all of that being setup with the proper address and pin (which matchedwhat Linux did), the IOAPIC would never receive an interrupt on that pinand ihidev would never have its interrupt handler called when the touchpad wastouched.It was being properly powered up and would respond to I2C HID commands, andif polled after touching, there was finger data available to read.It just never generated an interrupt.

As with the S3 resume issue, I spent months trying to figure out what washappening with these missing interrupts.I attended the OpenBSDt2k17 Hackathonand spent nearly a week straight in a room full of OpenBSD developers as Itried tearing apart the Linux I2C, LPSS, IOAPIC, and ACPI code with no luck.

Mouse Touchpad Driver Download Of Hp

As I heard reports from other users and developers with Intel 100 Series machineswith the same interrupt problem, I started to assume it was specific to thesenewer chipsets.I went digging through Intel documentation and I2C implementations in other OSes(such as Coreboot and Google’s Zircon kernel) to find anything related to thisspecific hardware.

Growing weary and admitting defeat, I added anadaptive polling mechanismto ihidev so the kernel would poll the device every 200ms until there wastouch data available, then poll at 10ms until shortly after it stopped receivingnew data.This was enough to get touchpads working on these new laptops, but it was slowand wasted a bit of CPU time and battery power. Unfortunately that “temporary” polling mechanism had to be used for the next twoyears as no one could fix (or was not interested in fixing) this problem.

ACPI Node Walking

A few weeks ago, I purchased the 7th generation ThinkPad X1 Carbon.Getting OpenBSD installed and working on it has been quite a feat, as there weremultiple bugs to fix.The first showstopper was a kernel panic shortly into booting the installer dueto anAMLproblem reporting “Not Integer” when executing a particular method.

For some quick background: Linux and every other operating system other thanOpenBSD and Windows use an ACPI interpreter calledACPICAwhich is written and maintained by Intel.OpenBSD and Windows each use their own custom-developed stacks.Presumably Microsoft has many engineers available to maintain their ACPIimplementation (since they also wrote and maintain the officialACPI specficationwith Intel) and every other OS just re-imports theACPICA codefrom Intel when it’s updated.Unfortunately on OpenBSD, this means we have to fix bugs and implement newfunctionality required by the ACPI spec (now at version 6.3) when we encounterthem on new hardware.

The cause of the “Not Integer” panic on the X1 was due to some AML in an _INImethod (ironically, on its touchpad device):

When ACPI is being initialized in ACPICA or OpenBSD’s ACPI code, it walks theentireDSDTtree looking for any methods named _INI and executes them.This is how certain variables get initialized, interrupts get setup, and anythingelse the hardware vendor needs to do.

(At this point you may be thinking: maybe there’s just an _INI function thatOpenBSD is not executing that is needed to fix the touchpad interrupt problem.I checked this a long time ago and listed out all of the _INI method calls thatOpenBSD did and compared it to Linux.The results were similar enough that I didn’t investigate further.)

The ToHexString operator in that _INI function is one built-in to ACPI andis supposed to convert string or integer data into a string.The way it was implemented in OpenBSD’s AML parser11 years agowas to only accept integer arguments, and so anything passed to it that wasn’tan integer (such as the _HID string above) would cause anAML panic.After reviewing the ACPI specification, thefixwas just to allow passing other types to the ToHexString (and ToDecString)functions since the underlying OpenBSD implementations already handledconverting non-integer types.

However, while debugging that crash, I noticed something strange.The first conditional in that _INI method checks against OSYS, which is aglobal variable that most DSDTs compute according to which version of whicheveroperating system it’s running on.(There’s a long history related to _OSI that I won’t go into, but basicallyevery OS claims to be Windows now, except on Macs, where we all claim to beDarwin, because it’s easier for everyone else to conform to Windows and macOSthan for the hardware vendors to update their BIOS code when Linux fixes a bug.)

The AML If ((OSYS < 0x07DC)) was being turned into a conditional LLess 0 7dc,but why was OSYS zero?

Looking elsewhere in the DSDT, OSYS is initialized like so:

Basically for each newer version of Windows that the system reports it iscompatible with (OpenBSD reports up to Windows 2015), OSYS is updated to ahigher value.That OSYS variable is then used in various other DSDT methods related to settingup devices, basically to allow backwards compatibility if the machine isbeing used with older versions of Windows that may not be able to deal with adevice setup in one particular way vs. another.

Drivers Hampshire Mice & touchpads drivers

So if OSYS is being initialized in _SB.PCI0._INI, why is it zero when doingthe conditional in the touchpad’s _INI method?

Well as it turns out, the way that OpenBSD’s ACPI stack was walking the entireDSDT tree looking for _INI methods was slightly different than ACPICA (andpresumably Windows).On OpenBSD, nodes were being walked in this order;

But in ACPICA, they were walked in this order:

That slight change in ordering was the entire cause of the interrupt problem.

Remember earlier when I said I checked the list of _INI calls in Linux vs.OpenBSD?Well I did, but I didn’t realize the order of them was important and that they had interdependencies that weren’t explicit.

When _SB_.PCI0.I2C1.TPL1._INI was executed first, OSYS was still zero,meaning that conditional mentioned earlier was returning true, executingSRXO (GDPI, One).

After that, _SB_.PCI0._INI was being executed, properly initializing OSYS.When ihidev would attach later, it would call the touchpad device’s _CRSmethod to retrieve information about the I2C slave address and interruptinformation that was supposed to be setup earlier in its _INI method:

By this time, OSYS was properly set, and it would return resource informationsaying that its interrupts were routing through the IOAPIC on a particular pin,and OpenBSD would try to configure the IOAPIC accordingly.However, that didn’t match what the firmware was actually doing earlier when_INI was executed, because it was being told to route its interrupt throughsome other mechanism or perhaps it never activated anything.

Mice Touchpad Settings

Thefixfor this was to change the node walk algorithm to match ACPICA and execute amatching child node (_INI) of a device before recursing through its childdevices.With that change in place, it now properly executes _SB_.PCI0._INI before_SB_.PCI0.I2C1.TPL1._INI, ensuring that OSYS is set before it’s read.

With that fix in place, I was happy to finallydisable forced-pollingin dwiic for ihidev.

In the end, the bug had nothing to do with the devices being Intel 100 Series,and was most likely affecting all of them similarly because their vendors allused the same DSDT template from Intel, which uses OSYS in device _INImethods without an explicit dependency on _SB_.PCI0._INI to initialize it.