Yeah Facebook did good for networking. But only so they could be evil more efficiently so… it was incidental.
This is a fantastic initiative. I also agree with what others have been saying - the name should probably be something more serious. The Open PC Alliance, perhaps?
I haven’t had a chance to look through this much yet, but it sounds very interesting. I’m the creator of OpenRGB and I’d like to offer my support as it sounds like anything that would come out of this would be very beneficial to the OpenRGB project and the RGB ecosystem as a whole.
We absolutely need open standards and available documentation for things like custom protocols. If manufacturers changed nothing else other than providing documentation on their RGB communication interface protocols that would already make our work massively easier! Adopting a unified protocol would be the icing on the cake.
15 Likes
This is awesome and I love the “OpenPleb” naming!!!
Not sure if this is in the spirit of the project. . .But I would love to see the community put pressure on the motherboard makers to stop putting the ridiculous non-BIOS functions in the BIOS/UEFI.
Asus has two utilities the BIOS attempts to auto download and install (on by default) and the toggles are reset to on by default with every BIOS update. These are the Armoury Crate and MyASUS apps. This strikes me as essentially being a rootkit. . . .
I do not have experience with other vendors. But I heard Gigabyte had a remote update utility in their BIOS that was poorly implemented/maintained that was recently exposed as vulnerable and required patching.
Ideally, these types of things should either not be present and/or there should be an open standard that is able to be reviewed and vetted.
1 Like
The latest pipeline builds of OpenRGB support DMX single-zone lights (spots, PARs, washes, etc) using the ENTTEC OpenDMX adapter! You can group them with the Visual Map plugin for more custom layouts as well.
4 Likes
I did screw up the SPD on my Trident Z RGB modules at some point while reverse engineering them for OpenRGB development. Had to get Thaiphoon to reflash them. Windows has a terrible implementation of SMBus because every application has to talk directly to the hardware which makes access conflicts very possible.
3 Likes
Seems some people complain about the name. I think you don’t have to worry because it’s a good name from multiple levels.
It’s easy to impress people that they heard of it once saw it.
It’s unique. Sooner or later, when you google, it’ll show up everywhere which won’t have ambiguous meanings.
The name indicative of a ‘grass root’ movement fighting against established institutions. What could be less vogue than a grass root movement these days - for the people, by the people. And ‘when do we want it?’ ‘We want it now’
When the initiative picks up steam becoming another established institution, it’s not late to rename by then.
I see lost opportunity for established motherboard vendors to lead. Wish OpenPleb every success. 
2 Likes
There’s a lot of bullshit like this everywhere. “Proprietary parts” is just shorthand for DRM.
Over the past 15 years we’ve given up our rights as consumers to companies in exchange for what? Waiting 30min for a download instead of putting in a disc that we own, that works offline, that we have access to forever, that will install in the same amount of time or less?
It starts with RGB everything even though it’s ugly and ridiculous at this point. Soon they will lock us out of everything and cripple products that would have lasted 10 to 20 years like PCs from 1990s that still work with original parts, to 2 to 5 years. It only gets worse from here. For example:
We’ve been fooled into accepting “digital downloads”. And while we still have access to our files for now, over the next 10 years more companies will be pushing streaming. Why is streaming bad? Because you lose access to the raw files. Look at what happened with Steam and Windows 7. Can’t play games or access your account any more.
But who cares about Windows 7?
That’s not the point. The point is, at any moment any company can pull support for products you paid for. Is it not hilarious that you can still play Sega Genesis games on the Genesis, but can’t play your Steam library with games that were made for Windows XP and 7 some that only work on Windows 7 on windows 7?
The same thing will happen with PC parts, users will be locked out of a functioning product because support for insert product controller has depreciated.
We need to deDRM everything. It’s great that this is the first step, but there is a massive mountain in our way as consumers. Why can’t you watch your purchased iTunes movies and shows anywhere without iTunes? Users resort to torrenting and “piracy” because they have no control over their own media/purchases.
Yes there are people who want free everything, these people will never change. They’d skip paying bills at restaurants if they can. But the fundamental reason for emulators and torrents today is ownership and control in a world of digital DRM and proprietary parts.
Companies want to control every aspect of their product. From who can use it, where can they use it, in what region they can use it, how they access it and for how long they have access for. From Disney to Google to Netflix to YouTube etc the list goes on. Pay us money to ensure perpetual infinite growth and income for our shareholders while we continue to monetize every aspect of our platform.
Everything you buy today is anti-consumer. I hope this doesn’t stop at RGB software. We need to take back our rights and our world from corporations.
4 Likes
getting back to the issue of how to actually implement sets of features into an online open database:
a part of the benefits of supplying telementry data (through projects such as openrgb). but also manual product issue reports is that:
a product record can include version histories of all its firmware and software or utility updates. such that we can better track silent, closed and proprietary api changes. and this is immensely importany and critical factor for many 3rd party programs and utilities, or even the linux kernel!
take sonos for example:
in order to use sonos product with the sonos own provided software, it will silently update the firmware ota over the lan to your sonos device.
however at some point in time, sonos decided to completely break / change / encrypt / drm enable the whole sonos http upnp service api. which then completely broke all 3rd party open source software alternatives to control your sonos and send music to it.
this was dutifully and automatically pushed out and a completely random time by mandatory sonos software updates. and if you did not update your sonos app. then you were blocked from using the sonos.
there are 2-3 (or even 4) necessary things to track on an open online peripheral and accessory database (oopad). in order to have a registered user informed. somebody who has also registered this ‘sonos’ product to their online oopad account (aka an ooopada, or a product’s oopada entry, with is a poopada).
the things are:
-
whether the manufacturer has disclosed a clear firmware updates policy for the lifetime of the product. and through which mechanism(s) which components of that product gets updated. including sub-components or bundling firmware binaries within other firmware binaries (=asus toolchain). this is general product information. however it needs to be maintained and kept up to date. since there are many products dont get even their 1st firmware update until well after release.
-
version historyies of official product utility software. which may be multiple different software tools or pkgs, on multiple platfforms each with their own versions
-
the sets of firmware version that might be included within those software, it might be a standalone updater, or otherwise in a control utility. or one of a wide variety of many software updating mechanisms. this is a quite broad subject to research because you dont want to assume or narrow the scope too much. yet whilst still providing a coherent and structured parsable data. fields like:
-
if updates are mandatory (which versions)
-
if updates are initiated by a remote server, automatically from a local tool, or manually by user choosing to update the device
-
if updates prevents device from working (and bricks the device, im looking at you dell, with your xps laptops bios)
-
if not updating prevents the device from working
-
which ranges of api versions are inter compatible with which software
so as we can clearly see, it gets difficult, complex and messy quickly. yet to name and shame requires documenting all this stuff to some sufficient level(s). and presenting that information in a way that is clear and transparent.
and this is where color coded status, scores or ratings comes in. and also where publicly expressed statements from manufacturer policy comes in. for them to publically assure and say that ‘we will never do x’. or otherwise publicly explain why ‘we need to do y, for product z, and this is the reason, and here is how’
so hopefully you see my point. and where exists a lot of the challenges. perhaps user questionairre wizards can help. if data entry is required, when you register your new product to your account you will be presented with multiple choice questions, and amongst the options also be able to see how many other users already chose option x in the prior data entry. with helpful little pictures / icons. and/or volunteered links to manufacturer faq, specs pages, or other external data reources.
a smarter system of data gathering can then present collated data a bit like the steam proton database does. with statistics to show the relative certainty of those reported data field(s) about the specific product.
some amount of beta testing periods and trials should be conducted. to help hone and tune the process. it is a lot of work involved to get it right.
2 Likes
Whoa, welcome! And exactly the sort of suffering you’ve endured from reverse engineering is what we want to avoid in the future. Id like to add a quote or something from you to the openpleb site when we flesh it out a little more.
2 Likes
By staying with the idea of RGB and Sensors it would be awesome to have:
- Connector name/type SN
- Connector pinout
- Data protocol (Layer 0 and 1)
- Layer 0 could be I2C, SPI, PWM, ANALOG.
- Layer 1 could be the register description or a flowchart containing what to write and where if a manufacturer doesn’t want to provide full register descriptions.
- For example most RGBs LEDs use the WS2812 Layer 1 protocol, based on PWM ish Layer 0.
Recently (not in PC space) I’ve seen SPI-like LEDs (SCLK + DATA) and also some addressable 2-wire like the ones used by some IKEA products.
What I think needs to be well documented are the USB endpoints for the HID data of the various controllers.
In the future, an open standard reference implementation of a controller would also be welcome. Maybe based on an RPI2040, STM32, ESP, ATMEL, etc. I was working on one RGB + FAN hub for my next build. still in initial design phases:
If the open standard wants to include a standardized connector I would love to have a kind of connector that has a locking tab. I personally really like the Molex SL the one used by Corsair.
(It brings back memories of old cd players and discrete audio cards…)
JST PH and XH could also be cheaper and still valid alternatives. While the JST connectors are available from multiple manufacturers I’m not sure about the Molex SL. So for manufacturers going with a more common JST-like connector would be a better choice.
Just for reference if someone needs the fan connectors are Molex series KK.
Going back to the sensor, while some of the points above are the same a standardized definition for the sensor would need to be quite accurate.
Let’s take the example of a “10K NTC”, the beta factor most of the time is not mentioned and this might skew the result.
As others stated Gigabyte MBs use ITE chips that are not well supported (or not at all) under Linux. The driver is out of the tree, not well-maintained, and forked by multiple persons. While this is an issue for the Linux community I think that providing proper documentation would benefit them.
I’m not sure if this EC/SIO could be in the future (maybe a new chip revision with a built-in RGB controller to cut board costs) used to control RGB but for sure it is used to read basic MB values. So proper documentation of such a chip would be needed if we want to include sensors in the wiki. But seeing how Gigabyte is dealing with its customers it doesn’t instill confidence in me.
From what I can see Server/Workstation MBs are less prone to this issue due to the BMC/IPMI chip that handles all the sensors.
Talking about IPMI brings to my mind another issue, while the future of HEDT is not completely clear, some workstation hardware has IPMI chips, and those chips are running proprietary code.
Once the support period is ended they can be used as attack vectors if not properly updated. Such chips (mostly Aspeed and I think Nuvoton in jumping too) are supported by the OpenBMC project but the lack of documentation prevents individuals to port the firmware.
I’m in fact in such a case. I’ve re-purposed an X99 MB as my server. all the sensors run to the BMC but its software is trash and it locks. I need to perform a cold reboot via IPMI to have access to the sensor info. I would love to run OpenBMC but the lack of block diagram/details prevents me to do this.
I have some Dell machines with Dracs using JAVA web applets that are a nightmare to work with due to deprecated protocols.
This is just to say that we cannot expect a piece of software to work as intended forever.
This is just my thought, other users have raised other issues. There are many more we are not considering.
2 Likes
how about:
doodap
distributed online open database for accessories and peripherals
the you can have a doodap for your doodads
3 Likes
I agree with the idea of this. Using Linux and RGB can result in a limited experience if OpenRGB does not support something. And even then it has inherent risks. It would be much better if companies allowed the technology to be easily programmable without their bloatware.
1 Like
Please no merging with the regular PWM fan header. I’d like to still be able to use my old Noctua fans thank you very much.
A good place to start would be a great open source project on Github Called Fan Control.
Rem0o/FanControl
I would suggest contacting the authour if you can use it as boiler plate so sensor, pump, fans etc detection and interface. Add RGB and you have the start of a great open source RGB, Fan, Controllers, GPU, Pump software. Could a a little VM be setup to emulate controller chips etc maybe Hmmmm. Ill have a think on it.
1 Like
Unfortunately, at least last I checked, FanControl is not actually Open Source. Just because something is hosted on GitHub does not make it open. You have to look at the license, and I don’t even think there was source code on the repo.
This is NOT an open source license:
Fan Control License Agreement
© [2023] [Rémi Mercier]. All rights reserved.
This software is provided by [Rémi Mercier] ("the Licensor") for personal and non-commercial use only. You may download, install, and use this software on any device that you own or control.
You may not modify, reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of this software. You may not distribute, sublicense, rent, lease, lend or transfer this software or any part thereof to any third party without the prior consent of the Licensor.
You acknowledge and agree that this software is the proprietary and confidential property of the Licensor and that all intellectual property rights in this software belong to the Licensor. You agree to respect and protect these rights and not to infringe or violate them in any way.
The Licensor makes no warranties or representations of any kind with respect to this software. This software is provided "as is" and "as available" without any express or implied warranty of any kind. The Licensor disclaims all liability for any damages or losses arising from your use of or inability to use this software.
By downloading, installing, or using this software, you agree to be bound by the terms and conditions of this license.
OpenRGB is licensed under GPL v2 which IS an open source license. I like what FanControl is doing, but please stop grouping them in with FOSS projects. It is not FOSS.
5 Likes
in terms of pwm fan header… its the sort of thing would be nice to just extend / add optional extra pins sideways. while [trying to] re-use the existing power pin(s). This seems theoretically possible… IDK what other considerations to think about though. Just ‘seems’ relatively the simplest approach / shortest path between two straight lines. [edit] and just make sure the keying prevents mis-plugging. The existing version of the connector is already keyed. so you know… what more could you possible want? it has the 0.1" inch standard spacing. Just please no proprietary connectors to “claim” the so called territory. And then utterly abuse it with yet more proprietary nonsense.
I think it would be reasonable to make a backwards-compatible PWM fan + ARGB header that takes a 4-pin PWM header and sticks 2 or 3 extra pins on the side for ARGB (you could get by with 2 if the LEDs and the fan share a ground).
However, there is at least one reason I can think of that these proprietary ARGB connections exist - detection. I’m going to focus on NZXT’s Hue 2 ARGB standard because I think it’s reasonably designed and would make for a decent extension to the actual standard, or at least something similar to it. NZXT’s Hue 2 devices (fans, strips, case parts, etc) that have ARGB use a 4-pin connector. The first 3 pins are the same as any other ARGB device - +5V, GND, and Data (WS28xx format). The fourth pin is an NZXT proprietary addition that allows each “device” (fan, strip, etc) to identify itself. The NZXT system allows up to 6 devices to be chained together on one Hue 2 ARGB port and this extra pin allows the NZXT controller to know what 6 devices are attached, which means it automatically can split up the ARGB output into the appropriate zones of the appropriate number of LEDs.
This is something I’d like to see become an actual standard, but it couldn’t just be NZXT’s design directly as theirs just uses single-byte IDs for the device types and with so many devices out there, the 256 possible values for the ID would get used up almost immediately. I’d say a standardized ARGB device detection system should report a data block containing at very least a device name string i.e. “NZXT Aer 2 140mm”, a device type i.e. “Fan”, and the number of ARGB LEDs in the device i.e. 8. A future standardized fan+ARGB header therefore could have 4 PWM pins, 3 standard ARGB pins, and however many pins are required for this new identification system. If you put them in that order, you could use any type of device you wanted. 3-pin fan, 4-pin PWM fan, 7-pin PWM+ARGB fan, and 8+ pin PWM+ARGB+DeviceID fan.
1 Like
Ahhhh Sorry I swear when I came across it, it claimed open source, My bad. Bit dissapointed I donated $5 lol. But it did what I needed so never actualy checked the code.
Well we need a Fan control style open source tool then, aswell as RGB.
Having the ability to use curve’s like in fan curves for mixing and designing LED effects and speed would be good. You could have fan curves drive custom RGB effects
For OpenRGB, we have the Fan Control Plugin, but it hasn’t been updated in a while and doesn’t work with USB fan controllers. It’s something I’d like to improve:
gitlab OpenRGBDevelopers/OpenRGBFanControlPlugin
(I don’t have permission to post links)
2 Likes