What's the optimal settings for 6"HD?

[Wim4rk]

Hi, I'm trying to run a terminal on a 6"HD. It's VERY slow right now, noway near the results you're showing on Youtube. This is the commands I currently run:

sudo /home/whoever/.cache/pypoetry/virtualenvs/papertty-Zhwut_C6-py3.9/bin/papertty --driver IT8951 terminal --font ~/fonts/erika/'Erika Ormig.ttf' --size 32 --cols 55 --rows 38 --interactive

I'm running a Pi Zero W over SSH. When the screen is initialized I use a keyboard directly to the Pi. I get an update every two seconds or so. I'd be comfortable tweaking the code. Been trying to do that for a couple of days... But I'd love some directions.

Thanks for all your GREAT, GREAT work!

[mcarr823]

The Pi Zero is pretty slow compared to the full raspberry pis. It'll be having a hard time running a panel of that resolution. You could experiment with the font and font size settings, but it probably won't help much unless you go with a very small/thin font.

One thing you could try is turning on A2 mode. If you edit the driver_it8951.py file there's a block of code which mentions the 6inch panel. It currently has A2 mode turned off, because the 6" panel is a bit different than the others, and I don't own one to test with. All you'd need to do is uncomment this line: #self.supports_a2 = True then restart papertty. If it works, you'll be using A2 mode instead of DU mode, which is a little faster.

You could also try using this branch that I'm working on: https://github.com/mcarr823/PaperTTY/tree/single-line-refresh It's a work-in-progress and doesn't work on all orientations. However, it should provide a significant speed boost for a pi zero and the 6" HD panel. It has some optimizations specifically for the IT8951 driver. It also tackles some of the big performance bottlenecks for low-end hardware. Full-screen refreshes will still be slow, but single-line changes or partial refreshes should be significantly faster.

[Wim4rk]

Thank for your answer @mcarr823 !

I've been trying a lot of things, and I can get marginally better results by using simpler fonts and such. The thing is A2 doesn't work of the bat on 6"HD, it needs to be four byte aligned. I don't really know what that means so that's where I'm stuck right now. Can you tell me more about that?

I'll check your branch out, have only skimmed it so far.

[mcarr823]

@Wim4rk Regarding 4-byte alignment https://www.waveshare.com/wiki/10.3inch_e-Paper_HAT#4-byte_alignment_description My understanding is that the 6" panels need to align to a 4-byte boundary on the x axis and for the width when in 1bpp mode. In 1bpp mode there are 8 pixels per byte, meaning 4 bytes = 32 pixels. So the x coordinate of a draw would need to be divisible by 32, and the width of the image you're drawing would need to be divisible by 32 as well. eg. You can't draw a 16x16 image because it needs to be at least 32 pixels wide. You can't draw a 48x48 image because it's not evenly divisible by 32. And so on. And you could draw at x coordinate 0 or 32, but not at x coordinate 16 or 48, for example.

That being said, the IT8951 driver already has a variable of self.align_1bpp_width = 32 papertty.py passes that through to the "band" method if you're in 1bpp mode (which is turned on by default for terminal mode). The band method then modified the x boundary and width to suit that value. So it should already be giving you images which have an x coordinate and a width divisible by 32. I would have thought that for the 6" panels it would be a matter of uncommenting #self.supports_a2 = True and it would "just work". But if that didn't work for you then I guess there's still something else which needs to be done.

[Wim4rk]

@mcarr823 Great answer. I wrote a function: self.width - (self.width % 32) to double check. will keep looking into all that again. It's been working all along, in that I've always gotten an image. Maybe it's easy as getting a beefier Pi (and a large battery). It's just...

The demos Waveshare put out for the screen are running quick and snappy. That indicates to me that there should be something I can do.

I'm working on your branch now, added a PR for a new GPIO version. We'll be talking again over there, I'd guess. Thanks a million for your answers.

[mcarr823]

@Wim4rk If uncommenting that line did work (or if you can get it to work) it would be great if you could submit a PR with that change confirming that A2 mode works for you on that model. Might need to test both landscape and portrait mode, just in case there's a change needed there with how the 4-byte alignment works.

In terms of a beefier pi, that's certainly one way to go about it. DU -> A2 mode shaves off something like 120-140ms. But most of the lag you're facing is because you've paired a low-power pi with a high-res screen, which is something papertty doesn't currently handle well.

I went into some detail about that on this issue https://github.com/joukos/PaperTTY/issues/107 And that performance problem is what the branch I linked to aims to solve https://github.com/mcarr823/PaperTTY/tree/single-line-refresh As noted on the linked issue, I was able to get the delay for a rpi 2b (which I believe has single-thread performance similar to the pi zero) down from 1.2s -> 250ms.

I'll go into greater detail on the PR when I've fixed up that branch and actually submitted one, but basically papertty has a bottleneck in performance. It's present on all pairings, but it's especially noticeable in situations like yours (low-power pi, high-res panel). Basically papertty currently works like this: Grabs text from buffer -> builds fullscreen image -> compares new image to previous image -> writes what has changed to the panel. For a high-res panel and a low-power pi, drawing a fullscreen image, then comparing that image to another image of the same size, is quite an expensive operation. The branch I linked to instead works like this: Grabs text from buffer -> compares text to previous text buffer -> builds a small image containing only the changed text -> writes to panel Comparing text is way faster than drawing and comparing images, especially with a low-power CPU and a high-res screen.

So trying that branch should help a lot. Switching to a faster pi would also help. Doing both should help immensely. With a rpi 2b on that branch I get around 200-250ms of overhead from papertty for minor text changes. With a rpi 4b on that branch I get around 8-20ms of overhead. So if switching to that branch still isn't fast enough, getting a faster pi would certainly help.

[Wim4rk]

@mcarr823 Define working. I get an image, both in portrait and landscape. It updates, although slowly. It seems stable and safe for the screen.

[mcarr823]

@Wim4rk If it's running in terminal mode, and you can type a few lines of text without any of it becoming garbled or looking broken in any way, then I think it's working.