Hacker News new | past | comments | ask | show | jobs | submit login

> From what I've seen working on an e-reader,

> f you want to use the nice partial refresh waveform, the open source aspect of this is going to run face first into secrecy requirements. The company selling you the display controller may be willing to build you an out of tree kernel module, and you can totally figure out what it does, but it won't be open source at that point.

I'm sorry but you're making rather clearly incorrect statements which makes me suspicious of the veracity of your other comments. I'm quite familiar with their current and past technologies. You used the term "Partial refresh waveform". First of all, E Ink's active matrix electrophoretic displays like the ones in the Kindle don't need to be refreshed. That's a fundamental property. Secondly, in case you meant "partial update", that's a property of the display controller, not of the waveform. You can google this and easily see that it in fact open source and commonly utilized. https://github.com/UDOOboard/Kernel_Unico/blob/master/driver... . Most modern EPDC even the hardware ones contain that feature and it is exposed as open source.

> run face first into secrecy requirements.

I'd like to see an elaboration of your claims. Please share what evidence you have about all this "secrecy". I work in the display industry, not for E Ink, and I've never heard of these things going on so it would be quite interesting for me to learn about it.




Refresh, as in transitioning from one image to another on the display. Partial refresh as in not running the waveform on pixels that don't change color, which dramatically reduces the visual noise for the user. The problem with partial refreshes is the accumulated errors on pixels, and the effects of updating a pixel on the neighboring pixels. The longer you go between full refreshes, the more ghosted cruft you end up with on screen.

There is a waveform that specifically maintains image quality over many partial refreshes. (Interestingly it only works for black text on white backgrounds, and not the other way around, though I'd hope they would have fixed that by now.) It required quite a bit of pre-processing before you slam the frame buffers into the hardware. That logic came to us as a pre-baked kernel module from our hardware vendor, and EIH did not want us to know what was in it, though it wasn't too hard for us to figure out what it did.

And, to some extent, you can just say screw them, I'm making my own waveforms. However, a junk waveform can damage the display if they aren't correctly built to prevent static charge build up. Also, each batch of displays comes out different enough that EIH provides slightly tuned versions of the waveform on a per batch basis. I'm not sure how well the open source model will work when people don't have equivalent hardware. If someone is tuning the waveforms for their panel, that may not work for all users.

The static build up is interesting. I've seen pictures return to the display minutes after it was cleared to white because the charge built up on the display was still affecting the pigments. Never seen a display break due to it, but it was described to us as a theoretical possibility if a waveform wasn't roughly balanced in its actions.

Do I get my nerd cred now? Have I satisfied you, all knowing hacker news poster?


> Do I get my nerd cred now? Have I satisfied you, all knowing hacker news poster?

No, you have fundamental errors in your understanding of how electrophoretic displays work. That's not how waveforms work. You're confusing refresh with REAGL. Since you have some kind of attitude issue, I guess no further beneficial discussion is possible.

> That logic came to us as a pre-baked kernel module from our hardware vendor, and EIH did not want us to know what was in it, though it wasn't too hard for us to figure out what it did.

Evidence free comments don't strengthen a claim.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: