Skip to content

feat: Add FreeInkDisplay functions to work with absolute grayscale luts - #40

Open
theZiz wants to merge 2 commits into
Free-Ink:mainfrom
theZiz:feat/absolute-lut-grayscale
Open

feat: Add FreeInkDisplay functions to work with absolute grayscale luts#40
theZiz wants to merge 2 commits into
Free-Ink:mainfrom
theZiz:feat/absolute-lut-grayscale

Conversation

@theZiz

@theZiz theZiz commented Aug 15, 2026

Copy link
Copy Markdown

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 supportsAbsoluteGrayscale is 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::displayAbsoluteGrayBuffer is basically a copy of FreeInkDisplay::displayGrayBuffer but with calling _driver->displayGrayAbsolute in the end.

@itsthisjustin

Copy link
Copy Markdown
Contributor

Ha I just fixed this too and opened the same PR. Compare implementations for me? crosspoint-reader/crosspoint-reader#3046

@theZiz

theZiz commented Aug 15, 2026

Copy link
Copy Markdown
Author

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

  • keeps calling it factory mode instead of absolute and
  • doesn't handle the other corner cases I found.

So imho my implementation does a bit more of the needed extra mile. :)

@theZiz

theZiz commented Aug 15, 2026

Copy link
Copy Markdown
Author

Tbh I don't see where your change is in the freesdk-space. Don't we work wir PRs here? 🤔

@itsthisjustin

Copy link
Copy Markdown
Contributor

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

@theZiz

theZiz commented Aug 15, 2026

Copy link
Copy Markdown
Author

Okay, I will update my PR based on your changes. :)

@theZiz
theZiz force-pushed the feat/absolute-lut-grayscale branch from bc444a9 to 4ffcb53 Compare August 15, 2026 17:48
@theZiz

theZiz commented Aug 15, 2026

Copy link
Copy Markdown
Author

@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.

@theZiz

theZiz commented Aug 15, 2026

Copy link
Copy Markdown
Author

Thanks for the 👍, any more to do for merging this, @itsthisjustin ? 🙂

theZiz added 2 commits August 16, 2026 21:21
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
@theZiz
theZiz force-pushed the feat/absolute-lut-grayscale branch from 2deca46 to f3ba6c3 Compare August 16, 2026 19:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants