CalcProgrammer1

joined 3 years ago
MODERATOR OF
[–] [email protected] 130 points 1 week ago (4 children)

Honestly, not even mad. Sucks for the victims, but we need hackers poking holes in kernel anticheats. Show the game companies that kernel anticheat is a waste of effort and maybe this horrific plague of gaming will die off.

[–] [email protected] 3 points 2 weeks ago

If Bungie is behind it I have zero interest without even knowing what it is. Destiny 2 was an OK game, but its god awful anticheat bans Linux users. That is a sure-fire way to make me pretend your game doesn't exist. Client side anticheat is a plague. Do it properly on the server side.

[–] [email protected] 80 points 2 weeks ago (9 children)

Until any competing store releases a Linux client, I can't really argue against Steam. They are a gatekeeper and almost a monopoly, but they're also the most benevolent and pro-consumer gatekeeper that we have in the PC gaming distribution space. As long as all the competition continue to be Windows-only and, in some cases, actively work against Linux users, I don't want Valve's digital fiefdom to fall.

[–] [email protected] 5 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

I've been experimenting with both of these and recently wrote up a guide for installing FEX on postmarketOS (as I am testing it on my phone and tablet) but the steps should work for Pi as well.

https://wiki.postmarketos.org/wiki/Steam

I also just made a video tutorial/demo on YouTube. I ran Half Life 2 and Tomb Raider (2013). I'm not sure how capable the Pi 4 GPU is in comparison to the Adreno GPUs I tested.

https://youtube.com/watch?v=EuOX2L_yNqI

[–] [email protected] 4 points 3 weeks ago (3 children)

Box86/64 and FEX can both run Steam on ARM. Lighter games should be playable on RPi4 and 5.

[–] [email protected] 8 points 3 weeks ago

APIs can be complex too. Look at how much stuff the Win32 API provides from all the kernel calls, defined data structures/types, libraries, etc. I would venture a guess that if you documented the Win32 API including all the needed system libraries to make something like Wine, it would also be 850 pages long. The fact remains that a documented prototype for a software implementation is free to reimplement but a documented prototype for a hardware implementation requires a license. This makes no sense from a fairness perspective. I'm fine with ARM not giving away their fully developed IP cores which are actual implementations of the ARM instruction set, but locking third parties from making their own compatible designs without a license is horribly anticompetitive. I wish standards organizations still had power. Letting corporations own de-facto "standards" is awful for everyone.

[–] [email protected] 22 points 3 weeks ago (1 children)

In the mobile Linux scene, Qualcomm chips are some of the best supported ones. I don't love everything Qualcomm does, but the Snapdragon 845 makes for a great Linux phone and has open source drivers for most of the stack (little thanks to Qualcomm themselves).

[–] [email protected] 48 points 3 weeks ago

RISC V is just an open standard set of instructions and their encodings. It is not expected nor required for implementations of RISC V to be open sourced, but if they do make a RISC V chip they don't have to pay anyone to have that privilege and the chip will be compatible with other RISC V chips because it is an open and standardized instruction set. That's the point. Qualcomm pays ARM to make their own chip designs that implement the ARM instruction set, they aren't paying for off the shelf ARM designs like most ARM chip companies do.

[–] [email protected] 241 points 3 weeks ago* (last edited 3 weeks ago) (18 children)

Hopefully Qualcomm takes the hint and takes this opportunity to develop a high performance RISC V core. Don't just give the extortionists more money, break free and use an open standard. Instruction sets shouldn't even require licensing to begin with if APIs aren't copyrightable. Why is it OK to make your own implentation of any software API (see Oracle vs. Google on the Java API, Wine implementing the Windows API, etc) but not OK to do the same thing with an instruction set (which is just a hardware API). Why is writing an ARM or x86 emulator fine but not making your own chip? Why are FPGA emulator systems legal if instruction sets are protected? It makes no sense.

The other acceptable outcome here is a Qualcomm vs. ARM lawsuit that sets a precedence that instruction sets are not protected. If they want to copyright their own cores and sell the core design fine, but Qualcomm is making their own in house designs here.

 

I did a video tutorial and demonstration showing the Steam, FEX Emulator, and Distrobox setup I documented on the postmarketOS wiki here:

https://wiki.postmarketos.org/wiki/Steam

I go through the setup process for the Ubuntu container, FEX emulator, Steam, and then install and test two games - Half Life 2: Lost Coast and Tomb Raider (2013) to demonstrate gaming performance on an ARM device (in this case a Xiaomi Pad 5 Pro with Qualcomm Snapdragon 870 chip).

[–] [email protected] 1 points 3 weeks ago

It's just a matter of flashing the CorsairLightingProtocol firmware (instructions on the project's GitHub page) and then soldering the data pin of your LED strip to the appropriate Arduino pin. You can provide 5V power to the LEDs from a Molex or SATA power cable which allows as much power as your PSU can handle. You can draw 5V from the Arduino directly to run the LEDs but I would only run 30 LEDs or fewer with this power source. If you want more LEDs then connect them straight to your PSU.

[–] [email protected] 3 points 1 month ago (3 children)

Corsair Lighting Node is another good option. The real Corsair one works well but if you're willing to DIY you can use CorsairLightingProtocol on an Arduino Pro Micro and have 2 channels of ARGB with direct mode support for like $6, and you can use multiple. I have one in my case for case lighting as I used up my motherboard headers on fans and I used this as the controller for my OpenRGB desk fan project as well.

[–] [email protected] 6 points 1 month ago

Except the one platform that actually matters, Linux. My girlfriend got me into this game and it's the only game I have to keep a Windows installation around for. It doesn't run on the Steam Deck, so it's the only multiplayer game I play where I would even contemplate having to play it on Switch. I hate Epic Games.

 

I managed to get Steam installed on my OnePlus 6T and Xiaomi Pad 5 Pro, both running postmarketOS, using Distrobox to create an Ubuntu 24.04 container and then installing FEX-Emu inside of it. I wrote up a guide on the postmarketOS wiki on how to do it, some issues I ran into, some tips on how to get around those issues, and a list of games I've tested. Feel free to expand upon this list if you try it out. Older games such as Half Life 2 are quite playable, especially if your device supports keyboard and mouse input. I have not yet tested using a controller.

 

I have added support for system-wide plugin installations in Linux for the upcoming 1.0 release. The plugin files can be installed system-wide to the /usr/lib/openrgb/plugins path, which allows them to be provided by distribution packages rather than manually downloading them.

I have created AUR packages for the following plugins and they have been picked up by the Chaotic AUR repository if you want binary builds.

  • openrgb-plugin-e131-receiver-git
  • openrgb-plugin-effects-git
  • openrgb-plugin-hardware-sync-git
  • openrgb-plugin-visual-map-git

I plan to update the rest of the plugins on https://gitlab.com/OpenRGBDevelopers and get them into the AUR as well before 1.0 releases. Until that happens, you will need to use the openrgb-git AUR package to utilize these new plugin packages. The current 0.9 release in the main repository does not support system-wide plugin installation.

 

I made a 3D printed, Arduino-powered desk fan based around a 120mm Corsair QL120 ARGB fan after seeing Noctua's desk fan. I wanted something similar but with RGB. It is based around CorsairLightingProtocol so it syncs with OpenRGB but also has a knob to adjust fan speed and LED brightness directly. I made a video showing it off but if you prefer to read about it, I have project documentation and files (code, assembly instructions, and 3D models) on GitLab here:

https://gitlab.com/CalcProgrammer1/OpenRGBDeskFan

The 3D models are also on Thingiverse:

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

 

I did an interview with Linux YouTuber and podcaster Brodie Robertson on his podcast Tech Over Tea! We talked about the origins of OpenRGB, the challenges we face with reverse engineering, and discuss the OpenPleb initiative. We also talked about some other miscellaneous Linux things.

23
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
 

#OpenRGB 0.9 has been released! Check it out at https://openrgb.org! The full release notes are available on GitLab here:

https://gitlab.com/CalcProgrammer1/OpenRGB/-/releases/release_0.9

 

After my previous video about the OpenPleb initiative, I wanted to actually demonstrate the process of reverse engineering and show some of the hurdles and pitfalls of trying to understand a protocol without any documentation. This is the second part where I complete the reverse engineering of the effect packet and implement the different modes in my OpenRGB controller.

 

This is not news, just wanted to pin the most recent release here on Lemmy. It released on November 28, 2022. The next release, 0.9, is still being worked on but as always you can try the latest pipeline build at https://openrgb.org/#pl for the latest supported devices and features.

 

It looks like the OpenPleb initiative, a joint effort from Level1Techs and Gamers Nexus to get manufacturers to be more open with their protocol and interface documentation, is working! Case vendor HYTE seems interested and said they're willing to send me some sample devices along with protocol documentation!

This is the first manufacturer I've seen comment on the OpenPleb initiative publicly.

 

I wanted to demonstrate the reverse engineering process we use to figure out how to talk to devices for OpenRGB so I made a video where I start reverse engineering the RGB on the new ASUS ROG Ally. I wanted viewers to get a feel for how confusing and time-consuming this can be, especially with the new OpenPleb initiative that is trying to get manufacturers to open up and provide protocol documentation that would render reverse engineering unnecessary.

view more: next ›