Posts by merge

I suspect that your touchscreen doesn't report pressure. In that case, ts_uinput actually should not report pressure either. It must not be a problem, because the original one works too. So anyways, I'd like to fix it in ts_uinput, if you can give me the logs.... no rush I guess there could be a bug with generating BTN_TOUCH, but let's see.

(The only maybe confusing thing is, that tslib internally is "pressure-based". It "invents" pressure values where there are none. But that means nothing more than tslib *users* like ts_uinput can rely on pressure being in tslib-samples. ts_uinput should *not* generate pressure values via uinput if the original device didn't do so. It can still *use* them in order to get everything right.)

If ts_uinput doesn't report pressure, it is a bug. Just record evtest output from the original event device and ts_uinput's and write a bugreport so that we can fix it. It should of course report pressure and does so for all our touchscreen devices.

Sure. The way we do it, is simply check whether the calibfile exists, and if it doesn't, call ts_calibrate. This is done quite early in userspace, before the application starts. This way, users can trigger re-calibration by deleting the calibfile.

Thanks. Yes, the one is reporting the inverted axis over at tslib project just now. And I start liking the idea of and "invert" module.

As I see you also have a custom written "calibration" program: In tslib itself there is also a new option to build the "ts_calibrate" program SDL2-based. I'm not sure why you have your own program, but in case it's because you can't simply draw to the framebuffer and need a standalone program, this might be able to simply replace your program...

It seems like almost all features you need are in tslib's package already by now:

* device detection

* standalone portable SDL2 graphics version of "ts_calibrate"

* ts_uinput daemon (creates a touchscreen device with same properties as the original one, only offers tslib-filtered values)

* multitouch (at least this thread is about multitouch)

* TODO: "invert" filter (tdb in tslib) with "module_raw input" instead of "st1232+invert parameter". This would be tricky, because it would break your users' config files

Quick question: You add the "st1232" module_raw. It this really only "input" plus the invert_y option? If so, we could think about creating afilter module "invert" that takes parameters like "x0=XXX" and "y0=YYY" that defines the point around which the inversion takes place.

I think it's not needed when you use the normal ts_calibrate calibration and linear filter, but there might be cases where manual calibration is not desired and exactly such an inversion is needed.

I see. I remember seeing you at the tslib project Well. In case you need calibration+multitouch one day, you know you can easily have it, and it will reduce your codebase. I might pick up your "module_raw" and include it in tslib if I have time, and who knows, maybe I'll have a look at how you "communicate with python" one day too...

libreelec uses a very old version and heavily patched version of tslib. tslib 1.15 is soon to be released. It includes a full multitouch API and some of the features of your patches: The "ts_uinput" daemon program, see the README.md documentation, for example. If you use this "ts_uinput" daemon, you have multitouch support automatically.

You also add one "module_raw", but we can easily add that to upstream tslib too.

What else do you add to tslib? I'm sure you could shrink, if not completely remove your patches against tslib, by doing 1-2 pull requests, a minor change in libreelec to use tslib's uinput daemon, and bump tslib from 1.1 to 1.15. At the same time you have multitouch support too.

Oh. Also, a recent version of tslib does automatic touchscreen device detection. You would also not need to use evtest to find that.