[Razer Phone 2 ROMs, Kernels, Recoveries, & Other D] CurtisMJ:
As the light up logo on the back of the Razer Phone 2 is one of its most striking features, I felt it was a good idea to get some documentation going on what makes it tick and open the way for possibly using the logo for our own effects. I'll expand this thread as time goes on. My ultimate goal would be to develop an OSS alternative to the stock Chroma service which would not only enhance the stock ROM's implementation, but open the way for the logo to be used on custom ROMs and GSIs when those are available.

Physical:

The logo consists of a total of 9 coloured LEDs.

There are 3 diffuser pads on a flexible PCB.

Each pad contains a red, green and blue LED.

Each pad diffuses the light from the LED into roughly the shape of a portion of the Razer logo.

The pads are roughly centered on each of the three "snake heads"

The entire PCB is covered by a third, larger, diffuser pad. It's actually unclear which of the pads (the 3 individual or the single big pad) are actually responsible for shaping the light into the rough logo shape. It is clear however that the light is diffused into a specific shape and not a general area. (Razer clearly has experience :P )

Controller:

The 9 LEDs are controlled by a Texas Instruments LP5523 9-channel LED programmable controller chip.

The chip has mainline kernel drivers. The Razer phone 2 kernel has additions to these drivers by Razer to allow faster loading of microcode by bypassing the kernel firmware interface.

The 9 LEDs can be controlled through standard sysfs properties (thanks to Razer's additions), or microcode can be uploaded to the controller through the kernel firmware interface.

The controller chip has it's own microcode program banks and can run the animations without interrupting the main processor. This means the processor only has to wake once to set up the animation, then can go back to sleep while the controller chip itself loops the animations. This has a lot of battery saving potential.

Most of the juicy details on the microcode are in section 7.6.3 of the following document: [url]http://www.ti.com/lit/gpn/lp5523[/URL]

Remarks:

The kernel driver allows memory dumps of the controller chip which can allow for inspection of stock microcodes

Razer seems to load at least 2 unique microcodes. 1 for the "Spectrum" effect, and 1 for the "Static" and "Breathing" effects

The microcode can be overridden by the OS by writing to the LEDs sysfs directly, allowing for very complex effects (e.g. Music Visualization), but these require a wakelock or they pause when the screen goes off (not ideal).

The stock Chroma service may need to be disabled entirely to prevent conflicts with an OSS version (as it seems to load microcode at random times). Access to sysfs requires root for normal apps, so an OSS version would need root. System apps may have access to sysfs but I've not checked. There doesnt appear to be a native daemon controlling the logo but I may be wrong. An OSS version may want to apply microcodes for best effectiveness.

Since each pad can be controlled individually, you can actually set more than one colour at once, which looks pretty cool actually.

The LED sysfs paths are:

/sys/class/leds/lp5523:channel[0-8]/*

The device sysfs where microcode can be loaded can be accessed through a symlink in any channel, e.g.

/sys/class/leds/lp5523:channel0/device/*

Stock control methods:

The Chroma configurator app can build microcodes as evidenced by various string handling functions in the app decompiled code as well as a base "Blue Pulse" program which is exactly the length of a single memory page according to the kernel driver (but appears unused? Probably just issues with the decompile)

The microcode gets sent to a system framework service called "Ths", which seems to be what has access to and writes the sysfs values to communicate with the kernel. Dumpsys for the Ths service is blank, which is unusual for a stock android service so this is probably a custom service by Razer(why so lazy? :P ).

An OSS Chroma service could theoretically use the same system service, but this would require it to be installed as a system app and in GSIs (where that's practical), the service is not available anyway, so we would preferably not use it.

I kind of want to know what "THS" stands for...

I managed to decompile the framework of the stock ROM and can confirm the Ths service is a custom service which writes to sysfs directly, even referencing the LP5523 chip by name.

The THS service basically overwrites the memory on the controller directly with a fresh program each time an effect is applied. I was under the impression this is a bit risky, but whatevs. I might prefer using the kernel firmware interface. The service seems to take in three parameters each indicating the starting memory address for the program to run on each of the 3 programmable "engines". I think its possible for all 3 engines to run at once, but not sure. Programs 2 and 3 seem to get the same offset

The THS service never changes controller settings on its own, relying on the configurator app to receive broadcast intents to perform actions such as turning the controller off when the screen goes off (in medium battery mode). An OSS service can work in peace on the stock ROM by simply disabling the configurator app.

Amusingly Razer has used 1337 as a constant in some places in their code :)

Controller OEM support

Texas Instruments has software up on their website ([url]http://www.ti.com/lit/zip/snvc151[/URL]) which can compile an assembly style language called "Lysti" into a prebuilt memory image and set of program offsets ready to upload to the chip. (Relevant program is "LASM.EXE", runs fine on Wine)

They have a dev board available called TIDA-050013 and a demo video of the board on this page: [url]http://www.ti.com/product/LP5523/support[/URL]

I managed to figure out the demo program they have running in the video (its contained in the PDF tech doc for that product, but rather annoyingly with no line breaks :rolleyes: ). It's posted in post #2 of this thread

Channel Mappings:

Channel 0: Left Green

Channel 1: Left Blue

Channel 2: Bottom Green

Channel 3: Bottom Blue

Channel 4: Right Green

Channel 5: Right Blue

Channel 6: Left Red

Channel 7: Bottom Red

Channel 8: Right Red

My OSS implementation can be found at https://github.com/CurtisMJ/LogoPlus and a compiled version is available in the Mods section of the Razer Phone 2 Forums

As a side note: Programs can continuously write to the sysfs values without having to close their file handle by flushing the stream after each write. This applies the value immediately. I used this in my OSS service to fade out the master fader.

Feel free to add any research