How I Finally Bypassed the Endless Confirm Dialogs in Marlin 2.1 (TwoTrees SP‑5 V3 high speed upgrade + MKS WiFi)


⚠️ Warning: These confirm dialogs are safety features. Disabling them removes a layer of protection for actions that can damage hardware or create fire risk (heaters, PSU off, homing, etc.). Only proceed if you understand the risks, have backups, and can test safely.

Preface — why this post exists

This isn’t a tidy tutorial pulled from documentation — it’s the result of a long, very real fight. I could not find concrete steps anywhere on the internet. Marlin’s docs were silent about LVGL-specific dialogs. I hope this write‑up saves someone else the hours I burned.


My real problem (the battle)

  1. No documentation for LVGL in Marlin with MKSWiFi. Marlin 2.1 forces the LVGL UI when using the MKS Robin v3.1 controller (used in the TwoTrees SP‑5 V3 high‑speed upgrade with MKSWiFi). Online resources were scarce or nonexistent for LVGL + Marlin confirm dialogs.
  2. Supplier shipped only a compiled, modified firmware on the SD card. The supplied binary was not WiFi enabled, so I had to untangle what they changed and re-enable/replace functionality.
  3. Finding the correct files was a struggle. Because the build used LVGL instead of the classic Marlin LCD code paths, the confirm dialog code lived in unexpected places.
  4. Placement of the dialogs was hidden. Calls that end up showing a confirmation dialog are sometimes routed through LVGL wrappers (lv_msgbox, custom UI wrappers), not plainly ui.confirm_action() everywhere.
  5. Debugging was required. I had to trace calls, add log prints, and patch the LVGL wrappers so I could safely bypass confirmations.
  6. The dialogs caused endless physical back‑and‑forth. To upload a file via WiFi I had to: walk to the printer and clear any dialog, walk back, upload, walk to the printer again to accept upload and start the print, then clear the final dialog after the print finished — rinse and repeat. That was the real motivation to fix this.

Symptoms (what made me stop tolerating it)

  • WiFi file upload would fail to start because the printer was sitting on a blocking messagebox.
  • After a print completed, another blocking dialog prevented subsequent uploads.
  • Development and testing became painfully slow because every small action sometimes needed a physical trip to the device.

How I approached the fix — practical steps I used

These are the exact, practical things I did to find and patch the confirmation flow on a LVGL-based Marlin build.

    The files I changed are:

    • draw_dialog.cpp
    • draw_printing.cpp

    Testing checklist

    • WiFi file uploads remotely with no blocking dialog.
    • Print jobs can be started from selecting in the file list immediately without first clearing the confirm box.
    • After finish printing there is no blocking dialog box so that i can upload another file immediately.

    Conclusion

    This fix saved me from endless walking to the printer for WiFi uploads and made testing practical. It required tracing LVGL wrappers, not just editing classic menu files. Use compile-time toggles for safety and keep backups.

    If anyone wants the exact code snippets/patches I used, please use the website contact form and I’ll share the detailed code I applied.

    💬 WhatsApp Now