Open voigtkampff opened 2 years ago
Thanks, it's good to know something like that exists.
While I'm personally still not comfortable writing[^1] SMBus accessing code for platforms I don't directly use/test, that extension may come in handy if someone else wants to work on this.
I'm not a developer myself so don't understand clearly if there is a difference using this kext or using smbus unsafe feature.
Actually, we don't current have an implementation for Mac OS either. Our --unsafe smbus
feature flag is a safety switch for platforms where we do support it, and serves to avoid accidental SMBus reads/writes on those platforms unless the user explicitly opts into allowing them.
[^1]: To be more precise, I'm not personally comfortable shipping that type of code without extensive testing. Which then makes me not want to write it: it might never be tested/used, it generally is a bit more annoying/work to figure out how something works in a platform without having direct access to it, and sometimes people respond with "oh, it's working fine" without actually thoroughly testing the code first (which is mostly fine for low-risk code, but you can more easily brick SMBus devices).
First of all, thanks for answering. Your comment has made me rethink my request and you position.
I think best approach is get more feedback from the hackintosh community (using openRGB) before trying to implement this. I’d like to know @CaseySJ thoughts, if that were possible, in this matter since he has written along with you some drivers for liquidCTL in order to not get my expectations out of this world. :)
@vectorseven
It would be really exciting to control DRAM and possibly GPU lighting modes on a Hackintosh using liquidctl
. However we'll need to be very careful in navigating the dangerous waters of SMBus. But I'm not familiar enough with SMBus to be the helmsman, so to speak! Only a knowledgeable person should write such a driver.
Thanks for your reply.
Based off your comments I clearly underestimate the risk of smbus/i2c manipulation. But I hope, as you said, this could lead someone with the knowledge to implement it (unless hackintosh dies before)
I thinks you should close this issue (apparently I can too). Thanks again.
Actually I would like to keep this issue open, as (thanks to it) supporting SMBus on Mac OS is now viable (IMO).
I wrote macUSPCIO, and its basically a low level access layer for pcie devices io.
A user space driver for the smbus controllers still need to be written similar to what OpenRGB has. OpenRGB ported the drivers from the linux source code and they work the same on windows and macOS.
Smbus/i2c access is somewhat risky but should be mostly fine as long as you are staying within what is implemented in the linux drivers. I would be happy to help implement macos support if somebody manages to port the drivers and get it working on windows.
I'v read the disclaimer about using SMBUS and problems it might cause. However, I saw OpenRGB has implemented this, recently, using a kernel extension (macUSPCIO) that expose PCI devices for User Space IO (Before they didn't support either SMBUS devices cause the lack of this implementation). I'm not a developer myself so don't understand clearly if there is a difference using this kext or using smbus unsafe feature.
Specs:
P.D: Sorry for my English (not a native speaker/writer) and thanks for your answer.