Printer control via touch interface

[xblax]

Discussed in https://github.com/xblax/flashforge_adm5_klipper_mod/discussions/12

Adding this issue as a place-holder for future integration of a touch-screen UI solution using the ADM5 built-in screen. Options discussed are currently:

• Porting Guppyscreen. Based on LVGL, so far used as a mod on the Creality K1.
• Porting CYD-Klipper. Based on LVGL, so far used with ESP32 and dedicated touch screens.
• Enabling Klipper Screen. Needs X11, libgl, Gtk3 etc.

All discussion around that topic should continue here, until the road map for this feature becomes more clear.

[consp]

I created a test build for klipperscreen: https://github.com/xblax/flashforge_adm5_klipper_mod/releases/tag/v00.01-alpha-klipperscreen-test for those interested, only the chroot environment is provided. Read the notes please.

[consp]

For future reference: it's now also possible to build a guppyscreen variant (pull feature branch) which is far more lightweight than klipperscreen but lacks some functionality. It's WIP.

[consp]

For klipperscreen the changes for the next update (v0.5) will be (merge feature branch):

• Removed error in update (system info) screen #106 #109
• Added custom fbturbo driver with g2d (see fork consp/xf86-video-fbturbo), since it uses a blitter it speeds the rendering up a bit and should provide the maximum possible experience (since we lack a (E)GL compatible display device).
• Decreased niceness of xorg and klipperscreen to make them a bit less nicer than they used to be
• Increased loglevel to error to avoid too excessive logging and hogging memory, this might be the cause of some memory issues.
• Added -OO option to avoid a tiny bit of memory usage
• Wifi and ethernet will now show in the wifi screen #39

Known issues:

• It's a bit sluggisch, can't be done much about that without a complete rewrite
• Initial loading of each panel might be a bit slow, subsequent ones will be faster (up to four panels).
• Wifi might not show up due to bugs in the network representation code. If you see no or very few networks: please send us your /tmp/KlipperScreen.log! That would be very helpful.

Memory reduction in klipperscreen will be nigh impossible as it will require a rewrite to avoid the massive use of dicts. Good for ease of development, bad for memory they are. To people running large prints I recommend switching to guppyscreen.

For guppyscreen changelog see #134

[xblax]

@consp: Have you already tried if disabling the "UseBackingStore" setting of fbturbo helps with memory usage? https://manpages.opensuse.org/Tumbleweed/xf86-video-fbturbo/fbturbo.4.en.html#Option~4

Last time I looked at memory usage it seemed like the X11 process itself might be holding a copy of the framebuffer.

[consp]

Have you already tried if disabling the "UseBackingStore" setting of fbturbo helps with memory usage? https://manpages.opensuse.org/Tumbleweed/xf86-video-fbturbo/fbturbo.4.en.html#Option~4

The new driver has no backing store at all :) It uses 4-6mb, the original did about 8mb max. It's a direct interface to the framebuffer and the g2d interface. I'll have a look if it reserves a shadow buffer or not but it's not enabled afaik.

Btw: the reason for not merging is the changes to the build system, haven't tried them yet, job for another day.

Current usage after running for about two hours (no printing):

 1356 root     /usr/bin/Xorg :0.0 vt01 -s      4124     3508     3813     4564
 1387 root     /root/printer_software/klip     9032     4812     5268     6944
 1426 root     ustreamer -d /dev/video0 -r      128     5928     5949     6316
 2914 root     /usr/bin/python3 /usr/bin/s        0     6896     8008    10832
 1393 root     /root/printer_software/moon    10712    12916    13741    16052
 2285 root     /root/printer_software/Klip     1472    29404    31011    34320

I compiled it with every "fast" and memory lean option I know of (including unsafe math) since it will only result in artifacts and the software renderer of glx will redraw anyway. The main improvement will be the fast buffer switching with g2d which takes no added memory (ok, about 1kb for internal structures, but not MBs).

If you start xeyes you can see the 'bugs' (eyes draw over, not update background) which are not present when using glx so for our case it's fine.

Funny thing is I thought the driver was broken until someone forked it and did some minor updatew I already did but never pushed. Then I realized it simply needed a "Screen" section in xorg.conf to get it working ...
Don't know the actual speedup/memory usage improvement but it uses all the "fancy" stuff available and does it mostly in place. Might have a look at the actual memory usage later but the main improvement would be to get klipperscreen to use weak references and drop most dictionaries and replace them with lists. And I'd rather spend the time on getting guppyscreen on par since it's way more lean.

[xblax]

Yes, refactoring the complete python code does not make much sense.

I've also looked into two "easy" optimizations regarding KlipperScreen, I also pushed them to the buildsystem branch. Maybe you can take a look.

1. I clean up the buildroot packages in the klipperscreen variant a bit and only keep the minimum required. I also removed the xfonts and added the truetype fonts that KlipperScreen seems to use. That gives a bit reduction in memory usage (seems to be ~3.5MB less ram usage after boot), it also cuts down the packaged size by almost 30MB.

2. I wanted to get rid of heavyweight librsvg dependency (that lib is over 7MB). I found this project: https://michael.orlitzky.com/code/libsvgtiny-pixbuf.xhtml I manged to integrate it but was quite some work because I had to integrate the dependencies for that as well. Maybe ~1.5MB RAM saving. But at least I learned more about build root package creation thanks to that :)

I think another way to save a bit more RAM would be to convert the SVGs to PNG in the first place.

[consp]

Good 'easy' spots!

I think another way to save a bit more RAM would be to convert the SVGs to PNG in the first place.

That would definitely be a worthwhile thing to do. SVG's is nice but doesn't make sense on an embedded system.

At least guppyscreen uses byte encoded images, that's the leanest way to do it since every compression or image lib would probably take more space than the images themselves.

But at least I learned more about build root package creation thanks to that :)

Ah, the "I changed two characters in the code but learned a lot" journey. My record is two weeks of work for swapping two lines of code so a week per line!

[consp]

That would definitely be a worthwhile thing to do. SVG's is nice but doesn't make sense on an embedded system.

Just tested it with existing installation (note, also some memory checking module included so don't look at the footprint only the difference).

original svg and librsvg

 3981 root     /root/printer_software/Klip      968    37644    39541    43068

96dpi png

 4062 root     /root/printer_software/Klip        0    34972    37141    40948

So some savings, don't see lot of difference visually

Python data is about 12MB in total (strings, dicts, gtk objects etc).

I'm going to make a new build with your improvements and check the total difference.

Boot to initial screen

 1439 root     /root/printer_software/Klip     2484    27968    29310    32328