feat: Add FreeInkDisplay functions to work with absolute grayscale luts - #40
feat: Add FreeInkDisplay functions to work with absolute grayscale luts#40theZiz wants to merge 2 commits into
Conversation
|
Ha I just fixed this too and opened the same PR. Compare implementations for me? crosspoint-reader/crosspoint-reader#3046 |
|
Ha, but I was faster 😂 However, I don't see your PR in the freeSDK-space. 🤔 In the crosspoint-reader-space your fix does more or less the same, but
So imho my implementation does a bit more of the needed extra mile. :) |
|
Tbh I don't see where your change is in the freesdk-space. Don't we work wir PRs here? 🤔 |
For critical paths I commit directly a lot of times. Feel free to shore up two prs for each repo and we can get them merged together |
|
Okay, I will update my PR based on your changes. :) |
bc444a9 to
4ffcb53
Compare
|
@itsthisjustin I updated my PR. I renamed your function and removed the mentioning of the SSD1677 as the functionality itself is display controller independent. If something figures out an absolute lut for the different display controllers (e.g. by extracting them from original firmwares), they could also benefit from this approach and it would work directly in Crosspoint Reader. :) I also kept the displayAbsoluteGrayBuffer` "shortcut" so that the lut stays in the driver. Again: Another implementation could use it's own absolute lut here. |
|
Thanks for the 👍, any more to do for merging this, @itsthisjustin ? 🙂 |
This is needed for using the absolute factory lut of the SS1677 on X4 without device specific information in crosspoint reader. Renamed supportsFactoryGrayscale to supportsAbsoluteGrayscale to make the difference more to the default differential approach more clear
2deca46 to
f3ba6c3
Compare
This is needed for using the absolute factory lut of the SS1677 on X4 without device specific information in crosspoint reader.
Summary
First of all I changed the naming from "factory" to "absolute", because it is very X4 specific that we got those lut from the original firmware. In fact the whole point is using a direct rendering approach instead of BW + 2 differential steps. So the naming "absolute".
The method
supportsAbsoluteGrayscaleis needed to make sure to use this functionality only on einks having absolute lut defined, which is right now only the ssd1677 afaik. Right now I am checking whether the device is an X4 in crosspoint reader and this is not correct as newer X4 might have a different controller.FreeInkDisplay::displayAbsoluteGrayBufferis basically a copy ofFreeInkDisplay::displayGrayBufferbut with calling_driver->displayGrayAbsolutein the end.