[Feature Request] Child Lock / Screen Lock on touchscreen models

[Kiss1]

Posting this in Firmware because it’s a pure firmware/UI feature with no hardware dependency.

There’s a long-standing thread in General Discussions (Childlock?) open since January 2023 — three years later, still nothing has shipped, not even on current-generation touchscreen machines. I’ve just added a fresh comment there with two real-world incidents from my X2D; this thread is the companion technical proposal for the firmware team, with a concrete implementation spec.

The problem (and why it’s specifically a touchscreen-era problem)

I own a P1S and an X2D, and the contrast between them is exactly what makes this request urgent.

On the P1S, the small monochrome display with physical buttons is essentially child-proof by accident: a kid would need to navigate a multi-step menu structure with the knob to reach anything destructive. Clunky enough that no toddler stumbles into stopping a print.

On the X2D, it’s the opposite. The big, bright, color touchscreen makes the Stop button a single tap away — large, red, centrally placed and visually the most attractive element on the LCD. The better UX of the modern touch interface has, ironically, removed the friction that used to act as an implicit safety layer.

Compounding this: today’s kids are touch-native. They grow up assuming everything is a touchscreen — they try to swipe TVs, magazines, car windows. The moment they see a glowing color display at toddler height, they don’t hesitate, they just tap. There’s no learning curve to overcome anymore.

Two real incidents from the last few weeks, both with my X2D (full context in the Childlock? thread):

1. My 4-year-old son went straight for the red Stop button mid-print. Half-second save on a 12-hour job.

2. Days later he navigated into the Files menu and was about to start a print of the pre-installed Panda model. Catastrophe avoided only because the model required PLA and both AMS and the secondary extruder were loaded with PETG, so the printer refused.

The second incident matters most for this proposal: a touchscreen this capable, with no lock, means a child can start a print job from scratch — wrong filament, wrong bed prep, wrong settings. The material-mismatch check happened to catch it; it’s not a substitute for access control.

In short: as Bambu’s UI has matured, an implicit safeguard has been lost, and nothing has replaced it. There is currently zero protection against accidental destructive or constructive input on the touchscreen models.

Proposed implementation

Firmware-only. No hardware changes.

1. Settings → Security → Screen Lock (off by default, opt-in)

2. Lock methods: slide-to-unlock (lightweight) and/or 4-digit PIN (stronger)

3. Scope = any state-changing action:

   • Stop print

   • Pause / Resume

   • Start a new print (Files menu, Print button) ← critical, often overlooked

   • Filament load/unload

   • Home axes / manual movement

   • Settings changes

4. Always accessible without unlock:

   • Print progress / status

   • Temperature readouts

   • Read-only navigation (browsing menus without committing actions)

5. Auto-lock: configurable inactivity timer (e.g. 30s / 1min / 5min / never)

6. Persistence: lock state survives reboot; PIN stored in NVRAM

7. Recovery: PIN reset via Bambu Handy account binding (same trust path already used for the access code)

This only needs to apply to the touchscreen models (X1 series, X2D, H2C, H2D, A1 series). The P1 series is already de facto protected by its physical-button UI.

Why this is low-risk to ship

• No new hardware, no new sensors, no new dependencies

• UI layer already has modal/overlay infrastructure (filament change confirmation, error overlays) — same pattern reused

• Precedent already exists in your own firmware: on the X2D, the door sensor uses exactly the configuration pattern this feature would need — user-configurable behavior (notify only / auto-pause). That same Settings → choose-behavior-on-event pattern maps 1:1 onto a screen lock. The plumbing is already there.

• Off by default → zero impact on existing users

• Already a solved UX problem: every smartphone since 2007 has nailed this interaction

Optional second tier (nice-to-have, not required for v1)

• Extend the existing door sensor logic with a “lock screen” option alongside “notify”/“pause” — opening the door during a print would also lock the LCD

• Per-action permission granularity (e.g. allow Pause but not Stop, or allow viewing files but not starting them) — useful in classroom/makerspace contexts

Markets this directly serves

Parents, schools, makerspaces, robotics shops, shared offices — all segments Bambu is actively courting. Many of these environments require some form of access control as a procurement checkbox; this would unblock institutional purchases that currently require physical lockboxes or supervision.

This is genuinely basic UX hygiene that every modern smart appliance has had for over a decade. Could the firmware team please give an indication of whether this is on the roadmap, and if not, what the blocker is?

Thanks

feature-request bambu-firmware product-request Bambu Lab X Series > Bambu Lab X2D

[user_1996984904]

I think your proposal is not just a “screen lock,” but a UI-level authorization layer sitting between input events and command dispatch.

[Kiss1]

Exactly — thank you, that’s a much sharper framing of what I was trying to describe, and it’s the one the firmware team should actually adopt.

A “screen lock” suggests a binary surface-level gate (locked/unlocked), but what’s really needed is an authorization layer between input events and command dispatch. The lock UI is just one consumer of that layer; everything else (per-action permissions, auto-lock policies, door-sensor integration, audit logging, future fleet/MDM policies) becomes trivial once the underlying gate exists.

Concretely, the architectural shift is:

• Current: touch event → command handler → execute

• Proposed: touch event → authorization check (action class, current lock state, policy) → command handler → execute

Once that’s in place, the UI-level “screen lock with PIN” is just the default policy. But the same hook supports things like:

• “Allow Pause but not Stop” (classroom mode)

• “Allow viewing files but not starting prints” (showroom / demo mode)

• “Auto-lock when door opens during print” (reuses the existing door sensor event pipeline)

• “Log every state-changing action with timestamp + source” (useful for shared environments and post-mortem on failed prints)

• Eventually, remote policy push from Bambu Handy or an MDM-style admin console for fleets

None of this is exotic — it’s the same pattern as a permission middleware in any modern app framework. And it’s worth doing properly in firmware once, rather than bolting on a screen lock now and discovering in two years that the architecture can’t support classroom mode or fleet management without a rewrite.

So yes, my original “screen lock” framing was the symptom-level ask. The real ask is the authorization primitive underneath it.

[CarbonForge]

How do you keep your kid out of other things you don’t want them getting into?

[Mike28]

Hope this time Bambu will notice this request. It’s really important feature, and do not say that just keep your kids away, child lock is to prevent from unwanted situations. i understand that the printer has a glass, hot-end and other dangerous parts but i am not printing all the time.
My daughter could disconnect my p1s from the account, put prints on my x2d…

[Rhurley_1982]

That would be amazing. My son sees this as an infanite toy generator and he wants to touch the shiny buttons.

[CarbonForge]

@Rhurley_1982

My son sees this as an infanite toy generator and he wants to touch the shiny buttons.

I mean…he’s not wrong!

[MaeDay]

I just upgraded from the P1S to an H2C and it was so big it has to live in a playroom…so yes, locking the screen is a MUST!!! And a surprise it’s not an OOTB part of the interface. Upvote.

[3D_Husky]

Bingo! Someone finally said it. I’ve been waiting for this feature for a long time. I even had to print screen covers for my P1S just to prevent my kids from accidentally pressing buttons during a print. A simple PIN lock or child lock would solve this perfectly. Please add it!