New GMUX version with screen backlight control through the original brightness keys (F1 and F2)

[Sjenja87]

Hello and many thanks for starting the open source project in the first place! I have implemented a working version of on the back of yours and Romain verilog code, where its possible to use the brightness keys F1 and F2 to control the screen brightness without scraping into the U1800, with a simple 1 wire and 1 resistor mod. Sjenja87

[Benedolt]

Hi Sjenja87, that sounds really interesting! Would you mind sharing your work?

[Sjenja87]

Its on my github

[Benedolt]

Awesome, thanks!

[roddoart]

@Sjenja87 This is really a great job ! Congratulations ! As you are familiar with Verilog code (which is pretty rare), we could maybe try to work together to have the « real » Behavior with LPC interface support in the FPGA. I have one implementation of the LPC half-working (write is working but read is buggy). I did not published my code for now, but I can publish it if you are interested.

[Sjenja87]

Actually I have only worked with VHDL in a limited capacity, and I kinda quick learned verilog by doing this project seems a bit more intuitive and easter to get in to. On the LPC part I might not have to much time right now but we could try to coock something up. If I remember I tried to listen for the screen brightness control packages on the LPC bus after flashing the FPGA but I could only see the brightness controle packages for the keyboard light, but I might be mistaken. Did you find out if the brightness control is transmitted through the LPC? I will try to hook up my logic analyzer once again, and on the LPC FPGA implementation i think Lattice has some LPC souce code for LPC peripheral here: https://www.latticesemi.com/products/designsoftwareandip/intellectualproperty/referencedesigns/referencedesigns02/lpcbuscontroller So i should be straight forward....(I know it never is) if we can find the right transmissions and decode them.

[roddoart]

I have already implemented the lattice LPC layer in my design. The LPC performs read/write operations to some registers inside the FPGA. I will come back to you with more detailed information next week. Yeah it would be good if you can scope the LOC bus with a logic analyzer. That may help us to understand why my read is not working...

[Sjenja87]

I have just quickly hooked up the scope to the LPC bus and unfortunately i dont see any transfer of any data when the F1 and F2 keys are pressed, only when F5 and F6. So I dont get how the OS controls the brightness, maybe why you have problems reading ?

[roddoart]

Hi @Sjenja87. Sorry for my late answer. Did you perform your measurements on the original apple GMUX ? According to our reverse analysis, the brightness control is managed by MacOS (or Linux) by writing a register inside the GMUX (Address 0x774) through the LPC bus. Before that, the OS reads a "Max_Brightness" constant value (register address 0x770), that allows it to calculate the different brightness steps values. If you want to participate to a working group that discuss this GMUX topic, your help will be welcome :-). Here is a permanent link to a discord channel that we are using : https://discord.gg/4QCEUV87YD. I think the first thing to do is to continue to reverse the GMUX LPC bus communications on the orginal Apple GMUX. We must see some transactions with Address 0x770 (max_brightness), 0x774 (brightness control), but also 0x704/705/706 (GMux versions, displayed in MacOS). Once done, I can share my LPC-ready verilog code and we could try to investigate the LPC frames and understand why the read is not working properly. Or maybe just a visual inspection of my verilog code on your side will allow you to discover something wrong in my code ? ;-)

[jacksonium]

@Sjenja87, I would like to supplement that we tested Romain's LPC code on linux and the brightness control sort of worked but it is intermittent due to the reading error of the max value(i.e. writing to 0x774 is ok but reading from it is not). We can also control the brightness by sending outb command directly to 0x774.

On original apple gmux, reading and writing to 0x774 would get, of course, consistent value. But at the moment we are having problem with exactly that. We can write to 0x774 but reading it out will always have different value.

Could you see what happen on the scope hooked to LPC when you read/write 0x774?

[Sjenja87]

I will see if I can find time, I dont have a machine with a working GPU so I may need to borrow one of a friend first so I can scope out the original GMUX communication. Im joining the Discord to.

[daviewales]

You are all much smarter than I, so you have probably thought of this already (or discounted it as unrelated) — @jacksonium says: "We can write to 0x774 but reading it out will always have different value.".

Could this possibly due to the ambient light sensor? Specifically, the "Automatically adjust brightness" setting in the Displays system preferences?

Does disabling "Automatically adjust brightness" fix the inconsistent reads? Or covering the ambient light sensor with black tape?

Do you get higher values for 0x774 if you shine a bright light at the ambient light sensor?