Linux 6.2 Introduces Several More Touchscreen Drivers

[phoronix]

Phoronix: Linux 6.2 Introduces Several More Touchscreen Drivers

In addition to the HID driver updates for the Linux 6.2 kernel that were merged this week, the input subsystem updates also landed this week and were headlined by having several new touchscreen drivers...

https://www.phoronix.com/news/Linux-6.2-Input

[Quackdoc]

Im still looking for a decent cheap touchscreen that is actually worth buying. that I can interface with my desktop

[marlock]

Im still looking for a decent cheap touchscreen that is actually worth buying. that I can interface with my desktop

Did you investigate using a RaspberryPi + Touchscreen module plugged to the PC via usb or interfacing via network?

I suspect the software work to enable it to function like a PC touchscreen might already have been done by someone in the maker community, and the price might be significantly smaller than other alternatives.

I am positive RaspberryPis can be exposed to PCs in a way that fakes an input device like a mouse or keyboard, because I've seen such use before by people trying to create accessibility projects, so simulating a a touchscreen device and passing through the input from the actual touchscreen should be reasonably similar work.

There is also some Raspberry Pi "tablet" and "kiosk"/"point-of-sale" projects if you want a proper casing.

[Quackdoc]

Did you investigate using a RaspberryPi + Touchscreen module plugged to the PC via usb or interfacing via network?

I suspect the software work to enable it to function like a PC touchscreen might already have been done by someone in the maker community, and the price might be significantly smaller than other alternatives.

I am positive RaspberryPis can be exposed to PCs in a way that fakes an input device like a mouse or keyboard, because I've seen such use before by people trying to create accessibility projects, so simulating a a touchscreen device and passing through the input from the actual touchscreen should be reasonably similar work.

There is also some Raspberry Pi "tablet" and "kiosk"/"point-of-sale" projects if you want a proper casing.

I did look at it but ultimately wasn't satisfied with how it would wind up working, I current;y use a cheap used asus wintab I got running arch, and use waypipe to forward wayland over it. this does a "good enough" job but it's still rather laggy even with zstd compression

[skeevy420]

I did look at it but ultimately wasn't satisfied with how it would wind up working, I current;y use a cheap used asus wintab I got running arch, and use waypipe to forward wayland over it. this does a "good enough" job but it's still rather laggy even with zstd compression

Have you tried no compression or LZ4? In this instance, moving stuff from A to B as fast as possible with a bit of compression added for performance, LZ4 is better than Zstd. It's even planned to become the default Waypipe compressor at sometime according to commit logs.

TLDR

Zstd (3 by default) is better for storage devices because you can tune it to the write speed of the storage medium. LZ4 (1 by default) is better for point to point because it operates at the theoretical limit of the devices being used and can sometimes be faster than no compression...so can Zstd assuming you have a very crappy connection and how bottlenecking the connection to Zstd's write speed for a higher compression ratio can maybe give you a performance boost like you do when you set BTRFS Zstd to 2 or 3 for SSDs and 5 to 8 for HDDs.

Ideally you're not massively over-saturating the link and need to reign it in with Zstd like with an HDD or SDD -- you're under-saturated like with RAM and can get a slight performance boost with LZ4.

[Quackdoc]

Have you tried no compression or LZ4? In this instance, moving stuff from A to B as fast as possible with a bit of compression added for performance, LZ4 is better than Zstd. It's even planned to become the default Waypipe compressor at sometime according to commit logs.

TLDR

Zstd (3 by default) is better for storage devices because you can tune it to the write speed of the storage medium. LZ4 (1 by default) is better for point to point because it operates at the theoretical limit of the devices being used and can sometimes be faster than no compression...so can Zstd assuming you have a very crappy connection and how bottlenecking the connection to Zstd's write speed for a higher compression ratio can maybe give you a performance boost like you do when you set BTRFS Zstd to 2 or 3 for SSDs and 5 to 8 for HDDs.

Ideally you're not massively over-saturating the link and need to reign it in with Zstd like with an HDD or SDD -- you're under-saturated like with RAM and can get a slight performance boost with LZ4.

network perf is a far greater issue, don't forget you are sending massive amounts of raw data over the network. zstd is still very fast on anything but the lowest end hardware, it's why zram and zswap are so popular on low end devices like raspberry pi. you get significantly higher compression for a very minor amount of extra overhead. yeah it's slower then LZ4, but not enough to make a significant difference.

and on a device that is dedicated to this task, zstd perf issues are the least of the concern

[skeevy420]

network perf is a far greater issue, don't forget you are sending massive amounts of raw data over the network. zstd is still very fast on anything but the lowest end hardware, it's why zram and zswap are so popular on low end devices like raspberry pi. you get significantly higher compression for a very minor amount of extra overhead. yeah it's slower then LZ4, but not enough to make a significant difference.

and on a device that is dedicated to this task, zstd perf issues are the least of the concern

You're only half-right: Zstd DECOMPRESSION is still very fast on anything but the lowest end hardware. Zstd COMPRESSION isn't necessarily very fast on the lowest end hardware.

Even when setting them to their fastest levels LZ4 is still 50% faster at compression than Zstd and it's a hair faster at decompression than Zstd. Everyone likes to tout how great Zstd is, but for pure speed and throughput LZ4 is the best CODEC to use.

If you're still hellbent on using Zstd in a use-case where you should be using LZ4, assuming this works with Waypipe, try tuning Zstd to use a negative level to increase the write speed. Even then you'll still be slightly limited by Zstd's decompression over LZ4 due to LZ4 being a simpler CODEC.

[Quackdoc]

write speed is not an issue for me at all, network congestion is.