[–] [S] 7 points 1 day ago (1 child)

Only as useless as you want it to be, you could, for instance, use it with the hardware sync plugin to display CPU or GPU usage. I should mark it as manually configurable for segments so you can divide it up and use it for both CPU and GPU actually.

  • source
  • parent
  • context
  • [–] 1 point 2 days ago

    Mainly for development purposes. I plan to use the Steam Machine as my new travel PC and for my work on OpenRGB I want both Linux and Windows for testing. I use Windows to reverse engineer the official software and protocols for devices so I can reimplement them in a cross platform way to work across all OSes. Also maybe for Fortnite, the only game I still need Windows for, though my friend group hasn't been playing lately, I know how to fix the bootloader, spent time getting a customized rEFInd config going.

  • source
  • parent
  • context
  • [–] [S] 4 points 2 days ago

    While I'm generally pretty anti-AI especially in OpenRGB itself, I did try slop coding a Decky plugin with free AIs for selecting OpenRGB profiles and colors just as an experiment. It didn't go well though and I'm not familiar enough wih Decky or the languages it uses to really do it justice. I'd love to see such a thing from someone who knows what they're doing.

  • source
  • parent
  • context
  • [–] [S] 2 points 2 days ago (1 child)

    It does not, but Steam isn't constantly writing to the LEDs. The Customization tab in game mode just lets you pick from the built in hardware effects so it's not continuously writing. That means it generally is not fighting OpenRGB. The only time it does seem to write to the LEDs repeatedly is during downloads when it uses the LEDs as a progress bar. Also, in desktop mode (on SteamOS or on other distros) it does not seem that Steam touches LEDs at all.

  • source
  • parent
  • context
  • [–] [S] 7 points 2 days ago

    In game mode yes, at least during downloads when it uses the LEDs as an indicator. It does not stream effects in software otherwise, it just lets you choose from the built in effects, so OpenRGB can take over without Steam trying to fight it most of the time.

  • source
  • parent
  • context
  • [–] 1 point 2 days ago (2 children)

    I got my Steam Machine on Thursday and after running initial updates, I tore it apart and installed my Crucial RAM and 2TB SSD. So far it's running great, 32GB and no apparent memory instability issues. On the fresh SSD I installed SteamOS, then repartitioned it to shrink SteamOS to 1TB and made two 512GB partitions, then installed Arch and Windows on them. Triple boot with rEFInd is working well.

  • source
  • parent
  • context
  •  

    Support for the #Valve #SteamMachine under #Linux has been merged into #OpenRGB. This relies on the leds-valve kernel module that is included in the SteamOS kernel. A DKMS package is available to install this kernel module on #Arch and #Debian distros:

    https://gitlab.com/CalcProgrammer1/leds-valve-dkms

    or AUR leds-valve-dkms-git

     

    A follow up to my earlier post about the leds-valve DKMS module, now it is usable within the latest experimental build of OpenRGB itself as long as that leds-valve module is loaded.

    Support for the #Valve #SteamMachine under #Linux has been merged into #OpenRGB. This relies on the leds-valve kernel module that is included in the SteamOS kernel. A DKMS package is available to install this kernel module on #Arch and #Debian distros:

    https://gitlab.com/CalcProgrammer1/leds-valve-dkms

    or AUR leds-valve-dkms-git

     

    I made a DKMS package for Valve's leds-valve driver, the Linux kernel driver that drives the LED strip in the Steam Machine. I also made an AUR package leds-valve-dkms-git. The GitLab repo has a Debian build in the build artifacts though I haven't tested it, but it works on Arch.

    I am working on a controller in OpenRGB to use this driver, it still needs some cleanup but I have it working. There is a lot of room for optimization as the interface leds-valve exposes only allows writing one LED at a time but refreshes the whole strip for every change. I'd like to add an additional path to send the whole strip at once go get better update rates but this will require a change to the leds-valve driver directly.

    [–] 1 point 5 days ago

    Glad to see things stabilizing for SteamOS on the Steam Machine and on custom hardware outside of the Steam Deck. I just installed SteamOS on an old PC over the weekend to experiment with some things before getting my Steam Machine (which should come tomorrow). I'm glad they're adding a Great on Machine store category, as the Great on Deck category also serves the purpose of "Works on Linux" but some games are excluded purely due to Steam Deck performance issues that don't apply to a general Linux gaming PC context. At least the Machine has significantly higher specs so this should be less of an issue with the Machine category. Also like to see the continued improvements to Steam Input and the Steam Controller.

  • source
  • [–] 3 points 6 days ago

    Isn't Poolside AI US-based? They recently released an open model for coding that I've found useful and it's small enough to run on consumer hardware (16GB 5080 + 32GB system RAM). Giant models are useless for anyone but the big players with datacenters regardless if they are open or closed. Small, focused models seem like the real winning play for general use if you want true independence from the walled gardens and datacenters. I don't really like AI coding but I've been using Copilot for work and was experimenting on some side projects with free models on Cline, but most interested in the tech if I can run it locally.

  • source
  • parent
  • context
  •  

    OpenRGB Release Candidate 1.0rc3 has been released! This new release candidate build should be considered the latest stable build and is recommended for end users. It doesn't contain the next branch changes yet, but there are some major stability improvements as well as a lot of new device updates and some UI cleanups in this build. Distro maintainers, please update 1.0rc2 packages to 1.0rc3, keep using qt5 for now.

    Builds are available on Codeberg:

    https://codeberg.org/OpenRGB/OpenRGB/releases/tag/release_candidate_1.0rc3

    Links are also updated on https://openrgb.org/

    The Flatpak release will be updated soon.

    https://floss.social/@OpenRGB/116830393836395905

     

    ARGB splitters and hubs suck. They actively take the "addressable" out of ARGB by sending the same signal to all downstream LED components. While dedicated USB ARGB controllers like the Nollie and Airgoo have come out with 16+ ports to alleviate the need for splitters, some times a splitter is more convenient. I just updated my PC and my new Thermaltake CPU cooler has 4 separate ARGB components (an LED strip on each tower as well as 2 ARGB fans) all tied together with splitters so it all gets addressed as one uneven blob. A discussion on the OpenRGB Discord made me want to revisit the idea of a smart splitter, something I previously failed to make using an ATTiny as well as discrete logic. However, this time I tried using a RP2040 and its high speed programmable PIO architecture and succeeded! This project is the result. One ARGB signal goes in to GPIO0, and it gets divided up into channels based on the number of LEDs configured for each channel on GPIOs 2, 3, 4, and 5. It could be expanded for more GPIOs pretty easily as well. It acts on the signal in real time with no buffering, so theoretically you could chain them together without penalty or latency.

    OpenRGB Desk Fan V2 (lemmy.today)
     

    https://www.thingiverse.com/thing:7310885

    https://gitlab.com/CalcProgrammer1/OpenRGBDeskFan

    I've created a new version of my OpenRGB Desk Fan project! This is a 3D printed stand and Arduino Pro Micro based controller to turn any ARGB 120mm or 140mm PC fan into a colorful desk fan that syncs with your OpenRGB setup. The software is based on CorsairLightingProtocol. I originally designed it in 2024 but now have updated the 3D models to provide 140mm support and clean up the base.

     

    I haven't abandoned OpenRGB. It might seem that way given the last "stable" release was in 2023, but rest assured 1.0 is on the horizon still. I originally intended to release 1.0 last year shortly after 1.0rc1, but external setbacks pushed it back, namely WinRing0 being taken down by Windows Defender and Qt5 reaching EOL. However, after putting out those fires I decided I was not happy releasing 1.0 in its current state. Several other developers had open concerns about the backend and about rough edges in the user experience, and more issues came to light after 1.0rc2 in September.

    Moving to a client/service architecture on Windows was desired to get around PawnIO's need to run as admin, but significant parts of the user interface (settings and profiles mainly) were not made to work with the SDK server.

    This led to the creation of the next branch, a separate branch where I have been doing some major user-facing as well as backend changes. Notable big changes are below.

    • Update to Plugin API v5 and SDK Protocol v6
    • New profile system that properly integrates plugin settings into OpenRGB profiles
    • Settings and profile sync with background service
    • USB HID device hotplugging
    • Dynamic list updates
    • Per-Zone Modes
    • Lots of potential crashes mitigated by backend cleanups, protocol improvements, and better definition of plugin interfaces

    For more detail, see this merge request:

    https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/2935

    You can also download pipeline builds there to test, and -next-git AUR packages are available for testing as well on Arch based distros.

    view more: next ›