Feb 13, 2025

Recent proceedings (or regressings)

TL;DR: Azoteq has discontinued their touchpad modules, TPS43 and TPS65. There is no successor or alternative product. I have given up. I will pivot from touchpads to sliders like HHKB Studio, but not placed on case sides.


My current prototype. The keycaps are Junana MX.

What is PTP? Why are Azoteq touchpad modules so irreplaceable?

For the last 20 years, the UI of PC haven't made any advancement. In 2005, we already had mice, touchpads, trackballs, etc... But, wait, really no progress? I think that there was at least one important advancement: inertial scrolling on touchpads.

I am not familiar with Mac history. As far as I checked, MacBook Pro (2008) was the first MacBook with inertial scrolling. On Windows, 8.1 (2013) was the first. On Windows, inertial scrolling comes with "Precision Touchpad". "PTP (Precision Touchpad Protocol)" is often used as the feature name of touchpads. On Mac, there are no (major) third-party touchpads now, so the feature has virtually no name.

In the age of the dot-com bubble, "dog year" was a buzzword. Nostalgic. In 2024, I still saw non-PTP touchpads for Windows everywhere. On Windows, a decade was not enough to popularize PTP. Do only immortal elves like Frieren use Windows now? All dogs are using Mac now?

There are enough reasons of it. After Windows 8.1 (after Vista, actually), Microsoft has almost stopped to invest Windows make better. After 12 years from the first release, PTP feature is still sketchy. For example, it yet cannot change scrolling speed without RegEdit and reboot. Laptop or touchpad manufacturers felt uneasy with such flaws. Logitech implemented their own inertial scrolling (but it is not very smooth like PTP or Mac).

Unlike Logitech, I decided to use PTP for my products. I implemented PTP on QMK. It works well on my prototype (now I am typing this blog by it) for several months. I found some glitches of it in the several months. Today I am going to tell you a glitch lurking in Azoteq IC, IQS550 / IQS572 (and other ICs, probably).

Before going to the glitch, we should know what is Azoteq TPS43, especially why it is so irreplaceable.

First of all, in the market now, there are little touchpad modules. Cirque, Azoteq, and nothing. I don't know why. In Alibaba, there are many touchscreen modules, but no touchpad modules. Moreover, Cirque touchpad modules are not PTP-ready. Cirque makes PTP-ready ICs (Gen 6, Dell uses it), but Cirque touchpad modules don't have them. Azoteq touchpad modules, TPS43 and TPS65, are irreplaceable. They use Azoteq PTP-ready ICs, IQS572 and IQS550 respectively.

But in 2024, Azoteq have discontinued TPS43 and TPS65 without successors.

We can make our own PTP touchpad modules if we have a good PTP-ready IC, PCBA design skill, money, time, motivation, etc. Let's see PTP-ready ICs in the market. You can find just two relevant options: Microchip maXTouch (mXT144U) and Azoteq (IQS550 or IQS572). Where is Cirque Gen6? No sale on Mouser or such retailers. Synaptics also makes PTP-ready ICs (Microsoft uses it), but no sale on retailers too. This situation discourages me from making my own touchpad modules. In this situation, I am not confident enough that I can resolve the glitch. What is the glitch? Now we are ready to go on it.

Power-saving behavior? Does not seem to be the case.

Leave a touchpad alone for a few tens seconds, then suddenly swipe with two fingers. On MacBook, you will see what you expect: Inertial scrolling. On my prototype's Azoteq TPS43 (its IC is IQS572), the first swipe is ignored. Subsequent operations are recognized correctly. Only the first operation is ignored. Not a showstopper, but a noticeably bad experience. Decent touchpads never have this glitch.

The behavior looks like a side effect of power-saving. So I underestimated the glitch for several months. "Just find the power-saving configuration in IQS572 and kill it, that's all".

This was not the case.

I killed every power-saving features in the IQS572, but the glitch remains. I tested a cheap USB PTP touchpad, and I found the same glitch. Now I suspect that the behavior comes from "Auto Tuning Implementation (ATI)" feature of IQS572. The cheap USB PTP touchpad's IC should have similar feature and behave similarly, I guess.

A cheap USB PTP touchpad
A cheap USB PTP touchpad

Capacitive touchpad relies on capacitance sensing, and capacitance is susceptible to changes in circumstances such as room humidity or surface moisture. Touchpad ICs should adapt to such changes every second. At the same time, PTP-ready ICs analyze the sensing data to calculate the position(s) of the finger(s) and to identify / track the finger(s). Analysis and adaptation will be closely intertwined, I think. ATI will be a maze built on a huge amount of experience. ATI should fix almost any malfunctions, but the glitch might be too hard to find. (Apple found and fixed it, of course)

IQS572 datasheet describes the ATI configuration parameters, but I find them quite difficult to manage. To do so, I need a testing machine of touchpads, like an XY plotter. And the configuration should be able to adapt to changing circumstances. I cannot run tests under very many circumstances.

I guess that Cirque or Synaptics PTP-ready ICs may not have the glitch. Do Microsoft and Dell both overlook the glitch? That's unlikely. But Microchip maXTouch? I can test it, but, there is no other way? Isn't investing this way too risky?

The problem is too much for me. I have given up. No touchpad in my future products.

My dream touchpad

I invested a lot in my touchpad project.

Recent fancy laptops' touchpads have Linear Resonant Actuators (LRA). It generates a tactile feeling on the fingers when the user presses the touchpad. This is called haptic feedback. Such touchpads should detect the pressure of fingers, so a pressure sensor is also required.

Does such a feature look too much for a privately run shop like DecentKeyboards? Actually not so much.

LRA is a common component. See Digikey. Vybronics, PUI Audio, Vishay Dale, and JIE YI ELECTRONICS make them. About driver ICs, TI and Renesas make them.

LRA is a promising way, but I pursued piezo actuator. I found that cheap cheap piezo speaker elements in Aliexpress are able to generate a tactile feeling on the fingers via (not very large) touchpads. Piezo driver IC, TI DRV2667 makes possible to design a quite small driver PCBA. The advantages of piezo actuator are not only the cost and footprint. The response time is noticeably faster than LRA. The shortcoming is, the assembly work is cumbersome. This may be critical for mass production, but no problem for me. I built a piezo actuator driver PCBA and it works flawlessly.


Cheap cheap piezo elements


My prototype PCBA, piezo actuator driver and pressure sensing MCU


My testing bed for a stack of touchpad module, piezo elements, force sensing resistors

Pressure sensor is much more burdensome. For the cost, force sensing resistor (film type sensor) is the only option available to us. It is a wacky sensor. Its pressure-resistance curve is not linear, and has a strong hysteresis. I need a MCU (ATtiny 1606) just to sense the pressure of the fingers on the touchpad. Anyway, it works well.

We can make decent touchpads if the glitch does not block us. After discontinuing Azoteq TPS43 and TPS65, the glitch is critical.

The life goes on. Capacitive slider is the next destination.

Recently I was interested in a feature of HHKB Studio: Capacitive sliders placed on case sides.

Sadly they are not PTP for now, but it may be improved by firmware update someday. The sensitivity is not a decent thing ("when I did want to use the touch bars, I found them unresponsive and difficult to engage, often requiring three or four swipes to get them going." It sounds similar to the glitch), but it can be solved if the IC is not sophisticated like PTP-ready ICs, I guess. Sliders placed on case sides were bad idea, but how about top horizontal center? My next prototype will give me the answers.

I have been using my current prototype for several months, and I have found inertial scrolling and zooming features of the PTP touchpad to be indispensable. As a pointing device, touchpad is poor. Just for inertial scrolling and zooming, there is no need for a 2D touchpad. An 1D slider will do.

The downside of capacitive slider: I have to build my own slider module. It looks hard but able to get through, I guess now.

Jun 2, 2024

P2PPCB Compoer F360 Updated (June 2024)

  • Follows the breaking change of F360 in May 2024 release.
  • Now it shows a progress bar during some commands.

Apr 9, 2024

P2PPCB Composer F360 Updated

P2PPCB Composer F360 20240409 is now available.

  • Trackpad modules and Qwiic-to-FFC adapters for them now available. Use Insert Misc command.
  • Some bug fixes

Key decals of XDA and Choc V1 are still odd if your display scale is not 150%. I'd like to wait until Autodesk adds decal API. I think I cannot make it good for all scales without the API.

Apr 4, 2024

New products from DecentKeyboards (Apr. 2024)

P2PPCB is and should be hand-soldering free. And I need trackpad modules for my project. I2C capable trackpad modules on the market are:

That's all.

Both have FFC connector. So I made two Qwiic-to-FFC adapters for them. Connecting FFC is hand-soldering free, and connecting Qwiic is hand-soldering free. FFC is bundled to the kit.

Qwiic-to-FFC adapter for Azoteq TPS43/65 after Dec 2022, with overlay for TPS43/65

Qwiic-to-FFC adapter for Cirque 12-pin trackpad

CAUTION: Trackpad module itself is not bundled.

One more thing. DigiKey or Mouser sells Azoteq TPS43/65, but they don't have overlay. So I made the overlays for them.




The material is 3M DI-NOC PS-999.

Apr 3, 2024

Some knowledges, advises and thoughts about Windows Precision Touchpad

Have you touched a recent Windows laptop? The trackpad can do inertial scrolling, just like smartphones or MacBook. I feel this is a must-have feature of trackpads. But QMK_firmware doesn't have it yet. So I investigated the problem area and wrote some codes on QMK. Today I'd like to share the knowledges from the experience with you.

The key is Windows Precision Touchpad. It is also known as PTP (Precision Touchpad Protocol). It is implemented in Windows 8.1. 11 years ago! It is still sketchy but the only way to get inertial scrolling trackpad on Windows. We should manage to do with the sketchy points of PTP.

The comprehensive document from Microsoft is here: Windows Precision Touchpad Implementation Guide

The codes on QMK is here: GitHub diff

In general

In short, PTP is a special "Digitizer" of USB HID. It tells the geometric and physical positions of fingers on the surface of the trackpad. In contrast, "Mouse" of USB HID tells the moved counts. QMK's pointing device is such a thing. The "geometric and physical position" might look unnoticeable but fatally important idea of PTP. Mouse is based on "count". The difference is fatally important.

Some fancy mice can change speed with their switches. The implementation is simple. Just multiplying counts by speed. But in PTP, it is a completely different game because PTP handles inches or centimeters (physical quantity!), not counts. PTP keeps the trackpad dimensions and the fingers should not go out of the bounds. If we just multiply the centimeters by higher speed, there is no way to avoid overflow! And there are many other subtle but show-stopping problems. The dimensions of the trackpad are written in USB HID report descriptor. If a trackpad want to change the dimensions, resetting USB is the only way. And QMK is not prepared to such hack. Resetting USB requires resetting MCU, and much more... Can you hear the sound of the Rube Goldberg machine?

The Rube Goldberg machine might be more larger than you imagine now. Windows requires to edit the registry and reboot to change the two-finger scrolling speed (see here). It reminds me the MS-DOS era. Windows Precision Touchpad is still sketchy after 11 years. But there is no other way. It is no surprise that MacBook increased the market share in the past decade. The speed changing feature of trackpad is a must-have in such environment.

I don't send PR of PTP codes to QMK for these problems. QMK is already a maze of #ifdef macros. Adding a Rube Goldberg machine is not a good idea. Maybe someday Microsoft will fix the sketchy points after decades of neglect. Otherwise, instead of fixing the problems, Microsoft will discontinue Windows itself. (This will happen in our lifetime, I think. Windows is not a profitable business anymore for anyone, just like Solaris. Microsoft invests almost nothing to make it profitable after two decades, and it is a good decision. We are living in the waning days of PC. Microsoft cannot save PC.)

Anyway Windows barely can do. macOS? No, nothing. There is no way to implement third-party inertial scrolling trackpads. This is why we haven't seen any third-party trackpads for macOS for the past decade. On macOS, an USB PTP trackpad works just as a plain old pointing device which emulates a mouse.

I also investigated Linux. It can do with PTP. Two-finger scrolling is available. But not inertial, so far.

Undocumented behaviors of Windows

The PTP document from Microsoft is very long, but lacks some critical informations.

USB descriptor: Once Windows recognizes that a VENDOR_ID / PRODUCT_ID pair does not have PTP, Windows never finds PTP in the VENDOR_ID / PRODUCT_ID pair anymore.

In other words, we must use unique VENDOR_ID / PRODUCT_ID pair for PTP. Usually we don't care about VENDOR_ID / PRODUCT_ID pair while debugging. It is not OK when we debug PTP device. You can erase the history by USBDeview.

HID report descriptor: Physical and Logical Maximum of Scan Time should be 32-bit width.

Excerpt from Sample Report Descriptors:

The value itself is 16-bit but Physical and Logical Maximum should be 32-bit width.

HID report descriptor: USAGE_PAGE(Button 0x09), USAGE_(Button 1 0x01) is mandatory.

Excerpt from Sample Report Descriptors:

The document says it is optional. But in my experience, it is mandatory. If a HID report descriptor lacks it, Windows becomes BSOD. Just always set UP (false) in the report.

A behavior of Linux

I tried to get the complete picture of Linux USB HID stack from the source code, but failed. I couldn't find the origin of SET_FEATURE request in the source code. The knowledge below is fragmental from my experience.

HID report descriptor: USAGE_PAGE(Digitizers 0x0D), USAGE_(Tip Pressure 0x30) makes PTP device ignored.

We should not use Tip Pressure if we need to do with Linux. I couldn't find the advantages of Tip Pressure in Windows.

QMK source code for PTP implementation

Let's see several points of my codes.

PRECISION_TOUCHPAD_ENABLE and Azoteq IQS5xx

common_features.mk

config.h

rules.mk

The codes in quantum/pointing_device/ of QMK is not available for PTP. I implemented just Azoteq IQS5xx.

EEPROM entry for speed value

eeconfig.c

As I wrote above, the speed changing feature is a Rube Goldberg machine. It requires non-volatile memory to save speed value.

HID report descriptor array is variable (not const).

usb_descriptor.c

This is for the speed changing feature. As I wrote above, I need to change the HID report descriptor dynamically.

Mark and overwrite by magic number in HID report descriptor array

usb_descriptor.c

usb_descriptor.c

usb_descriptor.c

Quick hack. If the magic number collides to other values in the array, it will be a disaster.

RDY line is mandatory.

config.h

precision_touchpad_drivers.c

RDY line is good for fast response and power savings. If you dare to do without RDY line, see pointing_device_driver.c.

My advises

If you are going to make a precision touchpad with Azoteq IQS5xx, there is no problem. Merge the code above to yours.

If not Azoteq IQS5xx, it can be cumbersome. But there is no such multi-touch trackpad module on the market (ICs are a lot. Module is rare). Then you are going to design your own trackpad module. So cumbersome but easy for you.

If you are going to implement another USB HID protocol (there are quite a lot of vendor specific protocol!), get an USB Sniffer box. I bought this one. I don't believe that I could wrote the code above without the box.

My thoughts

QMK is perfect for ATmega32U4, i.e. Pro Micro. But now, we need new codebase for 32-bit MCUs like Cortex-M0+ or RISC-V. With their rich computing resources, initializing after MCU reset can be much richer. It can add much more flexibility to keyboard firmware design and reduce the complexity of codes. C is going to be obsolete in the long run. Zig is a good candidate to replace C in this area.

USB HID lacks good support for programming. HID report descriptor should correspond to the report struct, but no tool can check the correspondence. In the ecosystem of C, such a tool is hard to maintain and use. Zig looks promising in this viewpoint.

Feb 18, 2024

For residents / visitors of Japan in March 2, 2024

I'll participate in an exhibition. In March 2, 2024, at 東京都立産業貿易センター台東館 (Tokyo Metropolitan Industry and Trade Center Taito Building), the name of the exibition is キーボードマーケット トーキョー(キーケット).

The figures below are the flyers for the exibition. No English version, sorry.