Interactive mode

[chi-lambda]

Tired of restarting PaperTTY every time you want to try a new font? Fear not, for interactive mode has arrived! If started with --interactive the Ctrl-C handler gets replaced by a little menu that lets you change font, size and spacing. And also exit the program. Obviously not for use as a service, but very practical to figure out which font works best for your display.

For best results, start with --autofit.

[joukos]

Hey, that's pretty funky! I haven't yet tried it, just briefly looked at the code.

If we have such a menu available to try out the various options, may I suggest a feature to also print out the command line for the chosen options? Or if taken even further, generate a complete systemd unit file for it that can be run as a service (I guess it could even have an option to install it, if PaperTTY is run with sudo/root). Eventually the settings could just be saved into a config file, but that's still waiting for implementation.

[chi-lambda]

Showing the command-line parameters for the current settings is a neat idea. I don't see that feature being used more than occasionally (that occasion being trying out a new font), so I wouldn't add any fancy extras. The service file currently uses a separate shell script anyway, which I think is a good idea, at least until we have that config file. Copy-pasting should be enough for now.

[joukos]

Yeah, copy-paste is certainly enough. After config file is implemented we can think about the fancy stuff.

[joukos]

I tried this briefly with the 4.2" and noticed that the force_redraw flag doesn't seem to get cleared after changing something in the menu - this may not be noticeable with partial refresh but with this display it's pretty apparent since the full refresh flashes it quite a bit :)

[chi-lambda]

Whoops, you're right! Should be fixed now.

[joukos]

Another related small issue I noticed after the fix was that since the menu is invoked via the signal handler, it can interrupt the program just about anywhere and this can happen:

1. Program is started and immediately after the "Started displaying..." line is printed, user presses Ctrl-C
2. Program already got to the point where it's drawing the image with the settings from command line
3. User changes the font in the menu that appears
4. Nothing seems to happen - the console content must change (or something changed in the menu, but it's confusing that the menu does print the correct setting in this case)

This can be fixed by simply moving the flags['force_redraw'] = False line to https://github.com/joukos/PaperTTY/pull/49/commits/21af7310ab00fa4c48e8656280bb100f242037f0#diff-4f982808b89753021a5915d3fc11a8f9L663, at the start of the if.

The problem is that if we clear the flag after showtext is running, the initial one will cause the redraw to be skipped, but the rearrangement should be good enough to not cause it in practice.

[joukos]

I see this being pretty useful to find the correct settings, and now I wonder if it should also have the cursor, portrait, flipx/y and so on...

If so, input handling could use some flexibility perhaps, and I just remembered that Click actually does have built-in prompting methods that might help keep it nice and clean if we add even more options:

• https://click.palletsprojects.com/en/7.x/prompts/
• https://click.palletsprojects.com/en/7.x/api/#click.prompt
• https://click.palletsprojects.com/en/7.x/api/#click.Choice (etc.)

[chi-lambda]

To make changes at a predictable point, we could also redo the signal handler so it merely sets a flag like we do for scrub_requested and then do the processing in the loop.

On a related note, I think it would be a good idea to refactor the whole terminal thing into a separate class.

[joukos]

I've been a bit busy so I actually forgot if this was ready to merge, or was there going to be some changes still? :)

[chi-lambda]

I think I'll add another option to trigger scrubbing and/or re-initializing. I should get around to it soonish.

[chi-lambda]

Added the scrubbing and blanking to the menu. On IT8951 displays, there's a special mode to do a proper re-init. On all others I just make it black and white, which should have some good results, but I don't have the hardware to test.

These would be pretty good to have when running as a service as well. We already have scrubbing on SIGUSR1. For more flexibility, some kind of IPC would probably be better. Maybe a FIFO? Or if you're feeling particularly adventurous, a small webserver?

BTW, did you get your hi-res 6" display yet?

[joukos]

Yes, I've been thinking that eventually the service needs some controls via some socket perhaps, but haven't had the time to plan it more than that. Shouldn't be too much work to implement it, though. I think a simple web interface may be a front-end but it shouldn't be the only one. It all depends ultimately on how much functionality is going to be implemented - if for example there eventually is a convenient option to choose a "source" (TTY, framebuffer device, VNC, piped data...) or even multiple displays at the same time to render them, a lot more complex configuration options may be needed to make it usable. Not that there needs to be fancy GUI for everything though, but at least the easy-to-use config file.

Anyway, I tried the initialization with the 4.2" and it seemed to work fine. I also tried merging the WIP partial refresh code from the other PR and running it, and no problems with that either. Can't test it much more than that right now myself. However, I feel that the inner workings of the clear functionality should be a detail of the drivers and that the menu should just call the method for the current driver - maybe in the future a tricolor display or something else needs a more customized routine for clearing it.

I didn't get the 6" just yet, but should very soon. I delayed it a bit myself accidentally, the package just idled a few days in storage while waiting for me to figure out that I had forgotten to do the finishing touches with customs :)

I hope the 6" works well, but there's also a few other displays there too, so I can test how they work:

• 7.5" BW - I have a simple application in mind for it
• 2.9" BWR - to see how to support the tricolor ones
• 2.9" flexible BW - because it's cool?
• 2.13" BW - already have one, but not 100% working and I like the form factor, so maybe this one works as it should

Hopefully I even get to try all of them before the end of the year...

[chi-lambda]

The 4in2 driver in #40 also has a clear method, which I think is compatible with this one, but again: No hardware to test with. Also, you should have write access to my branch now.

[joukos]

The clear method in the PaperTTY class should be removed now? Or changed to use the driver's clear in case we want to accompany it with debug output.

On another note, I got the 6" HD etc. now and tried it quickly, worked without bigger issues with 20MHz SPI speed but with 24 it wouldn't go (Pi3B+). The display itself updates very quickly but there seems to be a lot of waiting for some reason that makes me think it's not just the delay in sending the image data but something else. I'd need to profile it to know for sure but can't right now. It does look quite beautiful, although the DPI is so high a magnifying glass would be useful.

One thing I noticed that when I first plugged the thing in, I had my laptop's charging cable lurking under the flat flex (about a centimeter away from it) - this seemed to cause some interference with either the Pi or the display but it was very very slow until I simply disconnected the charging cable... perhaps need to test it again.

There was also some issues with VNC - I've hard-coded the timeout to only 10 seconds and experienced timeouts surprisingly often with this display (not a problem with 400x300) so it should be upped to something more reasonable, like 30, and made configurable, along with a reconnect feature - it needs to be more robust for actual usage.

Here's a couple of teaser photos (where my phone's poor camera doesn't do the display justice):

(The Blake Stone window there is 640x400...)

[chi-lambda]

Oh, I seem to have forgotten to commit papertty.py! Well, that's rectified now.

How long have you run the display at 20 MHz? Mine seems to be doing fine at 18, but sometimes can't restarted at the same speed if it has been running for a while. Though I haven't tried the handy reset button at the side, maybe that could help.

[joukos]

I haven't tried to run it for long yet, just briefly tested that it works.

I'll try the latest changes today if I have time and will probably merge this after that, unless you have some pending stuff you want to include.

[chi-lambda]

I don't think there's anything left right now. Go ahead.

[joukos]

I merged this now (and tested committing directly to your branch to update the dates).

I only briefly tried it but noticed a problem with my 7.5"V2 when trying to clear the display, but I don't think it's the problem of this code, so I'll create another issue for that tomorrow, maybe. Related to frame buffer going out of bounds or so. It's nice that I now have a couple of more displays to test with, but not so nice that now I stumble into all sorts of bugs that affect them :sweat_smile:

[joukos]

Also, thanks again for your contribution! It really helps a lot.