**** BEGIN LOGGING AT Sat Jul 06 02:59:56 2019 Jul 06 05:20:55 Maxdamantus: Sounds neat :-) Jul 06 08:03:56 maxd: what soc? Jul 06 08:04:25 as for terminal, you would have your own app, so refreshes wont drive it dead ;) Jul 06 08:04:33 *write your own app Jul 06 08:21:43 Do modern e-ink displays have lifetime issues? Jul 06 08:22:09 I imagine the main reason for having to write some special screen update mechanism is just to avoid ghosting. Jul 06 08:23:25 as for continuous updates, I've noticed the included web browser supports canvas .. was able to run http://maxdamantus.github.io/recplay/ on it. Jul 06 08:23:26 they are physical medium Jul 06 08:23:47 So is everything. Jul 06 08:23:50 so i would assume they do, although it was more about refresh rate Jul 06 08:23:51 including LCD. Jul 06 08:23:55 imagine running dmesg on it Jul 06 08:23:57 ;) Jul 06 13:57:59 KotCzarny: on what? e-ink? X-D Jul 06 13:59:03 there's even 2-color e-ink paper now. Black&red. I guess other colors exist as well Jul 06 14:00:24 the "A4" size display allegedly (according to the fuzzy dadashit) takes up to 40 seconds for one full erase&scan Jul 06 14:01:26 yep, forty. aka 2/3 of a minute Jul 06 15:40:01 well, 16 level grayscale 1024x768 takes ~1s for full update Jul 06 15:40:08 with reset Jul 06 15:41:01 and color eink is just color filter applied on particular subpixels Jul 06 15:41:46 so color is tripling horizontal resolution in terms of pixels to refresh Jul 06 22:31:37 I don't think the resolution is going to have an effect on how long it takes to update. Jul 06 22:32:08 unless something about the pixel density makes low-latency refreshes harder. Jul 06 22:33:42 I would expect a terminal to update fairly quickly (resulting in ghosting) if it knows that it's scrolling through many lines of text, and when it stops scrolling, it should do a full redraw. Jul 06 22:34:07 but I don't think a full redraw takes 1s on my kobo. Jul 06 22:34:41 iirc takes probably less than 0.5s, but don't want to test that atm since I'm trying to get Xorg working Jul 06 22:39:53 btw, rationale for resolution not having an effect on how long it takes to update: two e-ink devices should update in the same amount of time as one e-ink device, and two e-ink devices obviously have twice the number of pixels as one e-ink device. Jul 06 22:40:47 so if more resolution means more time, you've just got some vertical scaling issue (eg, need more CPU power), not some issue inherent to e-ink technology. Jul 06 23:04:46 Decent demonstration of changes in update frequency: https://youtu.be/6pw-oCItgx8?t=356 Jul 07 01:55:18 Seems to handle text quite a bit differently to random pixel updates that occur from video: https://drive.google.com/file/d/1SLoa9XsNXRPk1UhxOo5xh3UcTlZyujQI/view Jul 07 01:55:59 (that's doing a "partial" update of the entire screen every second) Jul 07 01:59:39 * Maxdamantus wonders if it's possible to get have more control over the update mechanism. Jul 07 02:01:44 the way the updates work there is you just call some ioctl on /dev/fb0 telling it the region to update, and then presumably something compares the current state of the FB to the previously drawn FB and does some sort of cycling through values of the pixels that have changed. Jul 07 02:02:04 dunno if that "something" is in hardware/firmware/kernel. Jul 07 02:02:57 * Maxdamantus suspects it's in hardware/firmware. **** ENDING LOGGING AT Sun Jul 07 03:00:53 2019