Maximilian Luz

Thanks. According to the DSDT the underlying UART has HID `QCOM0418`. I can't seem to find any driver for that upstream, so could be that it's missing one (or at...

By having it in AUR, people do not have to add our repo. This is especially useful for older devices, which already have good support out of the box. And...

@TheSnowfield Thanks for tracking this down and submitting the PR upstream!

> its simply that the popular DEs (GNOME and KDE) have decided to implement it just like a mouse pointer I don't think that's necessarily the problem with DEs /...

Right, but then if you'd translate them to touch events by default, you'd break all the existing drawing apps that differentiate between touch and stylus and mouse/pointer. So you again...

> And I forgot to mention that iptsd flickers with these red horizontal lines. Those are just one _really_ big ellipses because processing gets confused. > can I "ban" the...

We might want/need to do that anyways. At the moment, we're just loading based on drivers. The `spi_hid` driver used on the Qualcomm and AMD devices (although it doesn't work...

> The problem with this approach is that if we put the detection code into iptsd, then the service manager can not use the name anymore. We cant tell the...

> Why is this happening? The HID device of IPTS gets removed when suspending, re-added when resuming. Numbers are non-deterministic, so it might be `/dev/hidraw1` before suspend, `/dev/hidraw2` after. Edit:...

Yeah, I think that'd be an acceptable alternative. I don't really plan on doing this myself any time soon (which is kinda why I opened this issue), but I'm happy...