From d448a82990efb5c510064f1de5b5d32e932a4f9e Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Sat, 4 Jul 2026 14:22:00 +0200
Subject: Use the real user avatar on the lock screen, and let its keyboard
 type every character

Two gaps, both found by being asked about them.

~/.face was never read. The file exists here, a 300x300 JPEG, and a grep for
.face/AccountsService/avatar_path returned nothing anywhere in the codebase:
the lock screen drew a coloured circle with the user's initial
unconditionally. It now looks for ~/.face, ~/.face.icon, then
/var/lib/AccountsService/icons/$USER, which is where GNOME and KDE keep the
picture their settings UI sets. Scaled to cover the circle and
centre-cropped rather than letterboxed, and masked with a soft edge. Falls
back to the initial when nothing is set or the file will not decode.

That needed a raster decoder, since ~/.face is JPEG and the only image code
here was resvg, which is SVG-only. Added image with default features off and
only jpeg and png.

The on-screen keyboard could not type most passwords. It had letters,
digits, and the digits' own shifted symbols, and nothing else - no -, _, .,
/, =, [, ], ;, ', comma, backslash or backtick. For the case that keyboard
exists for, a session with no reachable physical keyboard, a password
containing any of those meant no way in at all. Every printable ASCII
character now has a key, with a test asserting the whole 0x20..0x7f range
rather than spot-checking.

The lock screen itself could not be screenshotted: locking a nested instance
hits the pre-existing EGL context-loss crash already recorded in docs/TODO.md,
confirmed again here. That is environmental and predates this change, so the
on-screen appearance still needs the real session. The avatar path is covered
by four tests including one that decodes the real ~/.face through the same
function the lock screen calls.

529 tests pass, clippy clean.
---
 docs/DEFAULTS.md | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

(limited to 'docs/DEFAULTS.md')

diff --git a/docs/DEFAULTS.md b/docs/DEFAULTS.md
index 014c6f5..ded5b03 100644
--- a/docs/DEFAULTS.md
+++ b/docs/DEFAULTS.md
@@ -1107,3 +1107,26 @@ own `chrome/` directory uses for `userChrome-traditional.css` versus
 Firefox is a separate surface again: it draws its window buttons itself and
 takes them from `userChrome.css`, which needs
 `toolkit.legacyUserProfileCustomizations.stylesheets` set to `true`.
+
+## Lock screen: avatar and on-screen keyboard
+
+**Avatar.** The lock screen shows the user's own picture, looked for in the
+conventional places, most specific first:
+
+1. `~/.face`
+2. `~/.face.icon`
+3. `/var/lib/AccountsService/icons/$USER` - where GNOME and KDE store the
+   picture set through their own settings UI
+
+These are conventionally JPEG or PNG. The image is scaled to *cover* the
+circle and centre-cropped, not letterboxed into it, and masked with a
+one-pixel-soft edge. With no avatar set, or a file that cannot be decoded,
+it falls back to the coloured circle with the user's initial
+(`theme.lock.avatar_bg`).
+
+**On-screen keyboard.** `theme.lock.show_keyboard` (default on) draws a
+QWERTY layout for a session with no reachable physical keyboard. Every
+printable ASCII character is typable, shifted or unshifted - letters,
+digits, and all of ``-_=+[]{}\|;:'",.<>/?~`` plus space. A test asserts
+the full range, because a lock screen that cannot type some character in
+the password is a lockout rather than an inconvenience.
-- 
cgit v1.2.3