Add macro prompt display/responses

[consp]

First: great work with the gui, it works a lot smoother than KlipperScreen!

We are porting guppyscreen to the flashforge 5m printer (see https://github.com/xblax/flashforge_adm5_klipper_mod) and I've written a simple "hack" to show prompts as the power button is triggered that way (via klipper).

code here, I'm not going to make a pull request (unless asked) since it's a c-in-c++ hack for now (It's been a long time since I did any c++) and lacks finesse but for the early tests I wanted to do it will work.

Is/was there any plans on including this functionality in guppyscreen or is it simply something that hasn't come up yet?

(mainsail macro prompt docs)

[ballaswag]

This is great! Love to see Guppy Screen get adoption in other printers. What platform does the flashforge 5m run on? I'm guessing bullseye on ARM? I have been trying to push adoption in those platforms since main usage has been on the K1 SoC.

I welcome PRs but do expect them to be C++ where appropriate. Will give your changes and run and comment later.

There's also now a guppy-screen channel in the Mainsail discord server now. Feel free to drop by and chat.

[consp]

bullseye

Don't think debian would like the system, it's a buildroot custom install, but it is armhf abi so most is the same. Main limitation is the tiny 128MB of ram. Everything requires cross_compilation since no build tools available on the device. We used klipperscreen before but that's a bit too heavy for the system (eats about 40mb of ram + xorg, guppy only asks for about 9mb) and causes heaviers stuff like the input shaper calibration to sometimes crash which is annoying.

I welcome PRs but do expect them to be C++ where appropriate.

Then I'll leave it be for now since it's mainly c and c++ where needed, might be a bit too odd for now, but I'll keep it in mind when altering things to see if they can be applied back to main.

We also require some custom code for the blanking since the normal framebuffer blanking leaves the lcd on full brightness, so there are some more patches to guppyscreen which wil have to be included for it to work properly. I've already added that but I think it's not very applicable to other systems unless they it also uses the sunxi t113 or compatible chip and that specific lcd driver (and kernel 5.4).

[ballaswag]

I went through the commits in your fork. I think input dev discovery and lcd brightness should be generalized across devices. I was lazy with input devices and hardcoded because they turns out to be the same for k1/nebula pad/btt pad 7 which are devices I or the community verified.

LCD brightness has been a feature ask, and I had a general idea of attempting to implement it using ioctl (looks like that's they accomplished). Would be great to adopt that for the other devices too.

LVGL is great for resource constraint devices. It works without X and can be distributed without much external dependencies, e.g. static linking everything and the binary is still just less than 5MB.

Which toolchain are you guys using to cross compile for the flashforge? I release an ARMv6 build and wondering if that's compatible on that system.

[consp]

Update since there is a pull request not see #97

As for the brightness: see #44

[consp]

Close as fixed by #97