Announcement

Collapse
No announcement yet.

Linux 6.2 Introduces Several More Touchscreen Drivers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 6.2 Introduces Several More Touchscreen Drivers

    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

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

    Comment


    • #3
      Originally posted by Quackdoc View Post
      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.

      Comment


      • #4
        Originally posted by marlock View Post
        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

        Comment


        • #5
          Originally posted by Quackdoc View Post

          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.

          Comment


          • #6
            Originally posted by skeevy420 View Post

            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

            Comment


            • #7
              Originally posted by Quackdoc View Post

              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.

              Comment


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

                Comment

                Working...
                X