• 6 Posts
  • 33 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle


  • universal-pidff is working on support for many wheels. I believe they are also working on upstreaming.

    Thrustmaster hid-tmff2 is a module that supports some common belt drive wheels. (I had a t300 but upgraded, see below)

    OpenFFBoard is fully supported without any extra drivers/modules in Linux. Even the configurator is just python+qt and works fine (This is the wheel I use).

    Running the drivers in wine won’t work, or at least there is no benifit that I’ve seen. Oversteer provides some udev rules which improve logitech support, you should install that and reboot even if you don’t plan to use it. The udev rules initialize the wheel correctly, set permissions on the sysfs components, etc. AFAIK the Logitech Driving Force GT is fully supported by the in-tree logitec driver link. Can you post more details about the issues you are having, maybe with screenshots?

    EDIT: I forgot that oversteer recommends using new-lg4ff for most logi wheels. So definitely give that a try as others said.

    Lastly there’s sim community https://infosec.pub/c/[email protected] (the creator of openffboard is the mod of that community) if you’re interested. It doesn’t see that much action but there’s a little here and there.











  • the qobuz webapp is hi-res too, I just use it in Firefox and my dac reports the same bit/sample rate that qobuz does. AFAIK there’s no compression there though I haven’t extensively verified that, only that the end result is 24bit/192kHz if that’s what qobuz says is playing.

    EDIT: Also, qobuz is nice because there’s very few things you can click on in the web interface which cause the music to stop playing. I really appreciate that feature… looking at you bandcamp…



  • Are your games all wine/proton games? For me in sway they all have the same class followed by some uid thing:

    ] > swaymsg -t get_tree
    [...]
      #92: output "DP-5"
        #70: workspace "21"
          #126: con "Automobilista 2" (xwayland, pid: 171976, instance: "steam_app_1066890", class: "steam_app_1066890", X11 window: 0x5400001)
    

    Or gamescope:

    ] > swaymsg -t get_tree
    [...]
      #92: output "DP-5"
        #70: workspace "21"
          #124: con "Assetto Corsa" (xdg_shell, pid: 170694, app_id: "gamescope")
    

    EDIT: Also allow_tearing was added to master 3 weeks ago, so this is definitely not in the current release. FYI to anyone who might try it.





  • Gatgetbridge (your link) has a breakdown of devices they support https://gadgetbridge.org/gadgets/ . You can click through the vendors to find devices which are both “highly supported” and “no vendor-pair”. Meaning most/all the features work without any reliance on the vendor app.

    As for the similarity you are asking about with pixel->GrapheneOS, there are very few watches that can run an alternative open source firmware or operating systems apart from the ones that are already open source, like bangle.js, pinetime, etc. Wearables are even more specialized than phones, they require specialized code designed specifically for them and would likely require pretty extreme effort to reverse-engineer.

    I use a pebble 2 HR with gadgetbridge but the watch it self runs the old pebble firmware which gadgetbridge talks to. This is fine for me, but if you are looking for a more modern watch you may have to make some compromises.


  • The SQLite database is encrypted, though there was a period of time where it wasn’t I think which may persist if your DB is older, but the key is stored right next to it on the filesystem. Signal desktop doesn’t use your keyring or any of the other available methods to unlock it’s database which is why you don’t have to enter anything when starting the application, and why you can move it between machines by simply copying the .config/Signal dir. So while they are “encrypted”, it’s effectively clear text if you have access to the directory the database is stored in.