Announcements and updates for downstreams

[StollD]

This ticket is meant to provide updates for upcoming changes to how iptsd has to be built.

If you are packaging iptsd, or maintaining a fork of it, feel free to subscribe to this issue to get notified about changes that will impact you in the next update. If you want to, you are also free to leave a note about your work here!

If you have issues with building or using iptsd, please open a new issue. This issue should be strictly for announcements, and advertising your downstream work.

[StollD]

Changes that will be coming in iptsd v1.2

Dependencies:

• The custom math / container code of iptsd has been replaced by the Eigen library: https://eigen.tuxfamily.org
• iptsd now depends on the C++ version of inih, INIReader: https://github.com/benhoyt/inih/tree/master/cpp

Building

• Instead of consisting of multiple cpp files, iptsd itself is now header-only. The only cpp files are the ones containing the main functions for the various tools. It is possible to build every tool with a single call to g++ / clang++ (not including the hidrd shim, which has to be built with a C compiler).
• iptsd includes a new tool: iptsd-check-device. It opens a HID device and check if it is a device that iptsd should read data from. This tool is used in iptsd-find-hidraw, but the script will fall back to matching driver names if it is not found.

Code structure

• Instead of scattering the cpp files for the various tools into a daemon and a debug folder, all apps are now organized under the apps folder. This is also where all the cpp files are for building.
• The code for processing and manipulating data has been split from the platform specific code (e.g. everything that interfaces with the linux kernel API). The iptsd processing logic lives in core/generic while the linux specific parts live in core/linux. The only files allowed to call code in core/linux will be the files in apps.
• Similarly, the apps themselves are mostly implemented as generic application classes now. These classes don't care from where their data comes, they only receive and process it. Getting the data is done by a platform specific application runner. The task of the main function is mostly reduced to loading parameters and invoking the platform specific runner.

That last points might seem a bit redundant but by clearly splitting application logic (turning a heatmap into coordinates) and platform logic (reading HID device data) it becomes massively easier to add new tools that share the same fundamental behaviour. Extreme examples could be ports for a different OS (macOS, BSD), or a version of the daemon that behaves slightly different, for linux-like operating systems (e.g. Android), while keeping the majority of the code as-is.

[Emporea]

will it finally work on surface pro 7 again? I am getting terrible results with pen and multi touch isnt working since the merge with quo a couple months ago.
Appreciate support. Thanks.

[StollD]

This issue should be strictly for announcements, and advertising your downstream work.

You are posting in the wrong issue, with basically no information other than "it doesnt work".

Please make sure you are running the latest surface kernel, with no old DKMS modules overwriting the builtin one, and the latest iptsd release. If you have issues with that setup, please open a new issue and describe what is actually happening (e.g. what you are trying, what you expect and what actually happens, ideally including screenshots for the pen).

[hmtheboy154]

This ticket is meant to provide updates for upcoming changes to how iptsd has to be built.

If you are packaging iptsd, or maintaining a fork of it, feel free to subscribe to this issue to get notified about changes that will impact you in the next update. If you want to, you are also free to leave a note about your work here!

If you have issues with building or using iptsd, please open a new issue. This issue should be strictly for announcements, and advertising your downstream work.

Hi, thanks for this ticket and the announcement of the new changes so that I can catch up.
I am currently maintaining a fork to integrate iptsd into Android-x86 & the deriatives (BlissOS for example). If anyone interested, here it is :
https://github.com/hmtheboy154/iptsd

Additionally, these are forks of dependencies that is needed to compile iptsd :
https://github.com/supremegamers/spdlog
https://github.com/supremegamers/CLI11
https://github.com/supremegamers/GSL
https://github.com/supremegamers/hidrd
https://github.com/supremegamers/inih

[hmtheboy154]

You might want to set fmtlib requirement to 9.0 and above. Sources like AOSP still ship fmtlib 7.x like for example the master branch is still 7.1.3

[StollD]

Is there anything that doesnt work with fmtlib 7? We only do some basic fmt::format calls, the rest is through spdlog which as far as I can tell supports older versions just fine.

EDIT: Tried to build with fmt 7.1.3 and I see what fails now. I will look into what causes it and if I cant fix it, note the required version.

[StollD]

Alright, that was quicker than I thought. spdlog is full of preprocessor statements for older FMT versions but they dont seems to actually support these, and the latest version requires fmt 8 or newer.

However, iptsd successfully builds with spdlog 1.8.5, which is the last version supporting fmt 7. Maybe that is useful for you.

[hmtheboy154]

well I just clone fmt 9, I'll go back in case it has issues

[StollD]

Changes that will be coming in iptsd v1.3:

Dependencies:

• The hidrd dependency will be dropped and replaced with a custom HID descriptor parser. This also means that iptsd will no longer need a C compiler to build, everything is C++ now.

Code structure:

• The part of src/core/linux/hidraw-device.hpp that was specific to the interface exposed by IPTS devices has been moved to src/ipts. hidraw-device.hpp now only contains the code for interacting with the linux hidraw API.

[hmtheboy154]

Changes that will be coming in iptsd v1.3:

Dependencies:

• The hidrd dependency will be dropped and replaced with a custom HID descriptor parser. This also means that iptsd will no longer need a C compiler to build, everything is C++ now.

Code structure:

• The part of src/core/linux/hidraw-device.hpp that was specific to the interface exposed by IPTS devices has been moved to src/ipts. hidraw-device.hpp now only contains the code for interacting with the linux hidraw API.

I was planning to edit Android.mk to automatically generate hidrd makefiles, luckily I don't have to now 😅

[StollD]

FYI, the next release (whenever that is) will drop semantic versioning and be iptsd v2 no matter what changes it contains. Right now the version number is pretty meaningless because I don't maintain multiple branches of iptsd. And while I try to make a distinction between "this is a bugfix release" and "this is a feature release", that isn't always easy or possible.

[StollD]

@hmtheboy154 I don't think you are in our development channel on matrix so I'm just gonna ask this here:

I need to rewrite the helper scripts (e.g. iptsd-find-hidraw) and would like to make them python. Would that cause issues for you on Android? My phone doesn't seem to have python but I don't know if AOSP might allow you to build it.

[hmtheboy154]

@hmtheboy154 I don't think you are in our development channel on matrix so I'm just gonna ask this here:

I need to rewrite the helper scripts (e.g. iptsd-find-hidraw) and would like to make them python. Would that cause issues for you on Android? My phone doesn't seem to have python but I don't know if AOSP might allow you to build it.

Sorry that I haven't noticed Matrix lately as I don't online over there much. However yes it would cause issue as you know there is no Python program got built on Android (unless you install Termux but then that's different).

Could you explain why there need to have a move to Python ? As the current shell script seems to work fine

[StollD]

We need to be able to work with multiple devices to support the touchpad on the Surface Laptop Studio 2. The current bash scripts are entirely unsuited for that, because they only return a single device. So they need to be rewritten and if possible, future proofed.

The reason I would like to use python is that I really don't like bash. It is fine for stupidly chaining commands together, but as soon as you introduce any logic it falls apart. Python is more verbose, but at least an int is an int there and not a string.