Tinkering — mizore / notes

New Blog Features: Language Icons, Source Quotes, Tickers, and Charts

Mon, 22 Jun 2026 00:00:00 +0000

This post was written during the old blog (Next.js + MDX) era. After migrating to the current static site, all of these features happen at build time: TradingView widgets became ticker cards that only load the live chart when you click "Live chart"; ECharts blocks became static SVG charts with hover values; source embeds are pinned commit snippets with line numbers; and language icons became corner language labels on code blocks.

This update pushes the blog's writing experience another step forward: code blocks are easier to scan, code references link straight to GitHub, and financial posts can embed TradingView charts with a tiny shortcode.

What's New

Language Icons on Code Blocks

A language logo and copy button float in the top-right corner of every code block—no title bar, no badge border, and no extra vertical space. When a block has a title or comes from GitHub, a small path line appears above the code and the GitHub link sits tucked into a small icon in the top-right corner.

const feature = 'language icons'
const theme = 'catppuccin'
console.log(feature, theme)

Restyled Inline Code

Inline code in prose like git log --follow, $AAPL, and ::tv AAPL no longer sticks out like a bright patch. In light mode it blends closer to Catppuccin Latte's paper tone, and in dark mode it settles into a low-luminance Mocha surface.

Quoting GitHub Code Directly

When writing a post, enter:

::github-code repo="mizorewww/blog" ref="c067042276d4b4b384c66c0c61fcd4f6716eb599" path="contentlayer.config.ts" lines="251-253" lang="ts" title="contentlayer.config.ts"

It renders as a code block with Shiki syntax highlighting, a language icon, and a direct link to GitHub:

contentlayer.config.tsL251–253 · c067042 ↗

251const githubEmbedPattern = /^::github-(code|diff)\s+(.+)$/
252const tradingViewMiniPattern = /^\$([A-Za-z0-9._:-]+)$/
253const tradingViewAdvancedPattern = /^::(?:tv|tv-advanced|tradingview)\s+(.+)$/

Line-by-Line Diff Highlighting Like GitHub

When writing a post, enter:

::github-diff repo="mizorewww/blog" ref="c067042276d4b4b384c66c0c61fcd4f6716eb599" path="css/prism.css" lines="1-15"

Rendered output:

Changes to css/prism.css in c067042

@@ -8,6 +8,44 @@ figure[data-rehype-pretty-code-figure] [data-rehype-pretty-code-title] {
   @apply flex items-center justify-between gap-3 border-b border-slate-200 bg-white/70 px-4 py-2 text-xs text-slate-600 dark:border-[#405064] dark:bg-white/[0.035] dark:text-white/65;
 }
 
+figure[data-rehype-pretty-code-figure] .code-title-main {
+  @apply inline-flex min-w-0 items-center gap-2;
+}
+
+figure[data-rehype-pretty-code-figure] .code-language-icon {
+  @apply inline-flex h-5 min-w-5 shrink-0 items-center justify-center rounded-[5px] border border-slate-300 bg-slate-100 px-1 font-sans text-[0.62rem] leading-none font-semibold text-slate-600 dark:border-white/15 dark:bg-white/10 dark:text-white/70;
+}
+
+figure[data-rehype-pretty-code-figure] .code-language-icon[data-code-language='ts'],
+figure[data-rehype-pretty-code-figure] .code-language-icon[data-code-language='tsx'] {
+  @apply border-sky-200 bg-sky-50 text-sky-700 dark:border-sky-400/25 dark:bg-sky-400/10 dark:text-sky-200;

diff

Single-Line Tickers Become Mini Charts

Put a ticker on its own line:

$AAPL
$BINANCE:BTCUSDT.P

On the old site, each of these lines turned into a Mini Chart. The current static site doesn't load TradingView scripts upfront—instead, it renders a ticker card linking to TradingView:

NASDAQ:AAPLApple Inc.TradingView ↗

BINANCE:BTCUSDT.PBitcoin / USDT PerpetualTradingView ↗

Shortcode for Advanced Charts

When writing a post, enter:

::tv AAPL interval=60 height=460

On the old site this rendered an interactive Advanced Chart; here it is likewise a ticker card.

Rendering ECharts Directly from Code Blocks

Use an ```echarts code block whose body is the chart's option JSON, with title and height supported in the meta string:

```echarts title="Weekly Visits" height=320
{
  "tooltip": { "trigger": "axis" },
  "xAxis": {
    "type": "category",
    "data": ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]
  },
  "yAxis": { "type": "value" },
  "series": [
    {
      "name": "Visits",
      "type": "line",
      "smooth": true,
      "areaStyle": {},
      "data": [120, 200, 150, 80, 70, 110, 130]
    }
  ]
}
```

On the old site these were two ECharts instances. The current site draws the same data as static SVG at build time; since there is no pie chart type, the second example is represented as a data table:

Weekly Visits

050100150200TueThuSat200 · Tue

Posts by Category

Category	Posts	Share
Tinkering	40	40%
Dev	32	32%
Notes	18	18%
Other	10	10%

If the JSON is invalid, it gracefully falls back to a regular code block instead of breaking the build. When you need functions or other options that plain JSON cannot express, you can also pass a JS object directly to the <ECharts> component. Charts follow the site's light/dark theme, and the echarts library is lazy-loaded on demand so it stays out of the initial bundle.

How It Works Under the Hood

Turning Shortcodes into Components in Remark

These regular expressions match the ticker chart syntax. $AAPL becomes a Mini Chart and ::tv AAPL becomes an Advanced Chart.

contentlayer.config.tsL251–253 · c067042 ↗

251const githubEmbedPattern = /^::github-(code|diff)\s+(.+)$/
252const tradingViewMiniPattern = /^\$([A-Za-z0-9._:-]+)$/
253const tradingViewAdvancedPattern = /^::(?:tv|tv-advanced|tradingview)\s+(.+)$/

The Mini Chart transform is intentionally conservative: it only triggers when an entire paragraph consists of a single ticker, so mentioning $AAPL in the middle of a sentence won't drop a giant chart into the paragraph.

contentlayer.config.tsL288–295 · c067042 ↗

288function createTradingViewMiniNode(symbol: string): MdastNode | null {
289  if (!isTradingViewTicker(symbol)) {
290    return null
291  }
292
293  return createMdxFlowNode('TradingViewMiniChart', {
294    symbol: normalizeTradingViewSymbol(symbol),
295  })

Advanced Chart adds parameter parsing so attributes like height=460 and interval=60 are forwarded as JSX props.

contentlayer.config.tsL298–313 · c067042 ↗

298function createTradingViewAdvancedNode(source: string): MdastNode | null {
299  const [rawSymbol, ...attrParts] = source.trim().split(/\s+/)
300
301  if (!rawSymbol || !isTradingViewTicker(rawSymbol)) {
302    return null
303  }
304
305  const attrs = parseEmbedAttributes(attrParts.join(' ')) as TradingViewAttrs
306
307  return createMdxFlowNode('TradingViewAdvancedChart', {
308    height: attrs.height,
309    interval: attrs.interval,
310    locale: attrs.locale,
311    symbol: normalizeTradingViewSymbol(rawSymbol),
312    timezone: attrs.timezone,
313  })

Finally, the plugins are wired into Contentlayer's remark pipeline. Because shortcodes are transformed before MDX compilation, no string scanning happens in the browser.

contentlayer.config.tsL1063–1069 · c067042 ↗

1063export default makeSource({
1064  contentDirPath: 'data',
1065  documentTypes: [Blog, Authors],
1066  mdx: {
1067    cwd: process.cwd(),
1068    remarkPlugins: [remarkGfm, remarkTradingViewWidgets, remarkIconShortcodes, remarkGitHubEmbeds],
1069    rehypePlugins: [

Loading TradingView Only on the Client

The official TradingView widget requires injecting an external <script>, so the component stays a client component. On render, it clears the container and inserts the widget mount node and config script; whenever the theme or props change, it rebuilds the widget.

components/TradingViewWidgets.tsxL83–101 · c067042 ↗

83useEffect(() => {
84  const container = containerRef.current
85
86  if (!container) {
87    return
88  }
89
90  container.innerHTML = '<div class="tradingview-widget-container__widget"></div>'
91
92  const script = document.createElement('script')
93  script.async = true
94  script.src = scriptSrc
95  script.text = JSON.stringify(config)
96  container.appendChild(script)
97
98  return () => {
99    container.innerHTML = ''
100  }
101}, [config, scriptSrc])

Ticker symbols are normalized first. Bare AAPL defaults to NASDAQ:AAPL, while an explicit symbol like NYSE:IBM is left untouched.

lib/tradingview.tsL4–20 · c067042 ↗

4export function normalizeTradingViewSymbol(value: string, defaultExchange = 'NASDAQ') {
5  const symbol = value.trim().replace(/^\$/, '').toUpperCase()
6
7  if (!symbol) {
8    return ''
9  }
10
11  if (explicitTradingViewSymbolPattern.test(symbol)) {
12    return symbol
13  }
14
15  if (plainTickerPattern.test(symbol)) {
16    return `${defaultExchange}:${symbol}`
17  }
18
19  return symbol
20}

Enhancing Code Block Title Bars in Rehype

Language icons aren't written by hand in each post; they're injected across the board during the rehype pass. It locates the figure generated by Shiki and ensures a title bar exists.

contentlayer.config.tsL850–868 · c067042 ↗

850function enhanceCodeTitle(node: HastNode) {
851  if (
852    node.tagName !== 'figure' ||
853    node.properties?.['data-rehype-pretty-code-figure'] === undefined
854  ) {
855    return
856  }
857
858  const title = ensureCodeTitle(node)
859  const code = findDescendantElement(node, 'code')
860  const sourceUrl = typeof code?.data?.githubSourceUrl === 'string' ? code.data.githubSourceUrl : ''
861  const language = getCodeLanguage(code)
862  const titleText = getNodeText(title) || getLanguageName(language)
863
864  title.children = [createCodeTitleNode(titleText, language)]
865
866  if (sourceUrl) {
867    title.children.push(createCodeSourceLinkNode(sourceUrl, language))
868  }

The left side of the title bar pairs the language icon with the title text. When no explicit title is provided, it falls back to the language display name—such as TypeScript, Diff, or Markdown.

contentlayer.config.tsL787–799 · c067042 ↗

787function createCodeTitleNode(titleText: string, language: string): HastNode {
788  return {
789    type: 'element',
790    tagName: 'span',
791    properties: { className: ['code-title-main'] },
792    children: [
793      createCodeLanguageIconNode(language),
794      {
795        type: 'element',
796        tagName: 'span',
797        properties: { className: ['code-title-text'] },
798        children: [{ type: 'text', value: titleText || getLanguageName(language) }],
799      },

Visually, the logos come straight from simple-icons brand icons, tree-shaken on demand so they don't bloat first-load JavaScript; languages without a brand icon fall back to a short text badge.

css/prism.cssL11–17 · c067042 ↗

11figure[data-rehype-pretty-code-figure] .code-title-main {
12  @apply inline-flex min-w-0 items-center gap-2;
13}
14
15figure[data-rehype-pretty-code-figure] .code-language-icon {
16  @apply inline-flex h-5 min-w-5 shrink-0 items-center justify-center rounded-[5px] border border-slate-300 bg-slate-100 px-1 font-sans text-[0.62rem] leading-none font-semibold text-slate-600 dark:border-white/15 dark:bg-white/10 dark:text-white/70;
17}

Keeping Inline Code from Stealing Attention

Inline code now uses a low-contrast, subtly bordered token style. It's still unmistakably code, without popping out of the paragraph like a button.

css/tailwind.cssL110–124 · c067042 ↗

110& :where(code):not(pre code) {
111  border: 1px solid color-mix(in oklab, var(--color-slate-300) 72%, transparent);
112  border-radius: 6px;
113  background: linear-gradient(
114    to bottom,
115    color-mix(in oklab, white 92%, var(--color-slate-100)),
116    color-mix(in oklab, var(--color-slate-100) 88%, white)
117  );
118  box-shadow: inset 0 -1px 0 color-mix(in oklab, var(--color-slate-300) 45%, transparent);
119  color: #4c4f69;
120  padding: 0.08rem 0.34rem;
121  font-size: 0.86em;
122  font-weight: 500;
123  line-height: 1.75;
124  word-break: break-word;

GitHub Code and Diffs Still Go Through Shiki

At build time, ::github-code and ::github-diff fetch the real source file or diff and emit a standard code AST node. That means they don't need a custom renderer—Shiki highlights them just like any other code block.

contentlayer.config.tsL543–552 · c067042 ↗

543if (kind === 'code') {
544  const value = selectCodeLines(await getGitHubFile(attrs), attrs.lines)
545  const title =
546    attrs.title ||
547    `${normalizeGitHubRepo(attrs.repo)}:${attrs.path}${attrs.lines ? `#L${attrs.lines}` : ''}`
548
549  return createCodeNode(value, attrs.lang || 'text', title, {
550    showLineNumbers: true,
551    sourceUrl: getGitHubCodeUrl(attrs),
552  })

Diffs follow the exact same path, except the data source is a patch and the language defaults to diff.

contentlayer.config.tsL555–563 · c067042 ↗

555const value = selectCodeLines(await getGitHubDiff(attrs), attrs.lines)
556const title =
557  attrs.title ||
558  `${normalizeGitHubRepo(attrs.repo)}:${attrs.path || `${attrs.base || attrs.ref}...${attrs.head || ''}`}`
559
560return createCodeNode(value || 'No diff matched this query.', attrs.lang || 'diff', title, {
561  showLineNumbers: true,
562  sourceUrl: getGitHubDiffUrl(attrs),
563})

That's why GitHub embeds get the Shiki color theme, language icon, copy button, GitHub link, and diff line backgrounds all at once.

The Mental Model for Writing Posts

For normal posts, you just write Markdown. When you want an icon, write :icon-code:; for a market ticker, write $AAPL or ::tv AAPL; for a data chart, write an ```echarts block; to quote source code, write ::github-code; and to quote a commit diff, write ::github-diff.

The build step turns these shortcodes into stable MDX components or Shiki code blocks, while the runtime only handles interactivity and external widgets. The authoring syntax stays brief, and the rendered page stays predictable.

Fixing Obsidian Web Clipper Not Working on KDE Plasma Wayland

Sun, 10 May 2026 00:00:00 +0000

While using Obsidian on Plasma Wayland, I noticed that whenever Obsidian was already open, clicking Add to Obsidian in Chrome's Obsidian Web Clipper extension created a completely blank note.

The content would only show up properly if I closed Obsidian completely before clipping from Web Clipper.

Cause

This isn't because Web Clipper failed to capture the page—it's because KDE prevented the already-running Obsidian instance from properly receiving focus.

When Web Clipper hands page content over to Obsidian, Obsidian needs to be raised and focused properly to read the incoming data. Under KDE's default window management rules, an Obsidian instance running in the background can be blocked from stealing focus, so the clipped content is never written and you end up with an empty note.

Analysis

The key symptoms are:

Clipping works normally when Obsidian is closed;
Clipping produces an empty note when Obsidian is already open;
This means the browser extension itself is working fine;
The failure happens when Obsidian is already running and KDE prevents it from responding properly to Web Clipper's activation request.

So this is a window focus and activation permission issue in KDE, not a misconfiguration in your Obsidian vault, templates, or Chrome extension.

Solution

Add a window rule for Obsidian in KDE: open System Settings → Window Management → Window Rules and configure it as shown below.

Xiaomi Book Pro 14 on Linux

Sun, 10 May 2026 00:00:00 +0000

The reason I picked up this Xiaomi Book Pro 14 is quite simple: I already have a MacBook Pro that works great for my daily needs, but there are always things that a Mac either can't do or does awkwardly. I needed an x86 thin-and-light to handle the tasks that are "best done on x86."

As someone who can't stand leaving things stock, the first order of business with a new machine was, naturally, installing Arch Linux. I ran into a few pitfalls along the way and thoroughly dug into the fingerprint feature—something I’d never used before. I’m documenting it all here as a record for myself and a reference for anyone who encounters similar issues.

First, here are the specs of my unit:

SoC: Intel Ultra X7 358H
RAM: 32GB LPDDR5x 9600MT/s (Soldered)
GPU: Intel Arc B390

Problem 1: Screen Artifacts

Right after the installation, the screen was glitching out. After some digging, the culprit turned out to be Intel's Panel Self Refresh technology.

The fix is straightforward—just add this line to your kernel parameters:

xe.enable_psr=0

Problem 2: Keyboard Not Recognized

This one was even weirder: the keyboard worked perfectly in the BIOS and GRUB, but became completely unresponsive as soon as the system booted. Getting stuck here during the installation process is incredibly frustrating.

The solution, again, is to add kernel parameters:

i8042.nopnp=1 i8042.dumbkbd=1

Once the screen and keyboard were sorted out, the system was basically usable. What follows is the part I spent the most time on—the fingerprint reader.

Fingerprint: The Main Event

Honestly, I'd never used a device with a fingerprint reader before, so I explored this area quite meticulously and hit many snags. It deserves its own write-up.

Why doesn't `sudo` pop up a fingerprint GUI like macOS?

This was the most irritating part of the whole ordeal. On macOS, sudo can use Touch ID. Why not on Linux?

It's not that "no one thought of it"; it's that the architectures are fundamentally different.

The authentication chain for sudo looks like this:

sudo → PAM → Terminal session or askpass

The beautiful KDE fingerprint authentication dialog, on the other hand, follows a different path:

App → Polkit → KDE Polkit Agent → PAM → fprintd

That GUI is provided by the Polkit agent. It doesn't spring forth from PAM itself, nor is it part of sudo. The PAM module can only participate in the authentication flow; it can't magically transform a terminal-based sudo prompt into a KDE-style identity verification pop-up.

Using sudo -A with SUDO_ASKPASS can indeed pop up a graphical password box, but that's still on sudo's own askpass track, which is separate from the KDE Polkit agent. So, at best, it makes the "enter password" step a GUI, but it can't bring over the fingerprint experience.

macOS can do it because Apple integrated sudo, PAM, Touch ID, the Secure Enclave, and LocalAuthentication at the system level right from the start. On Linux, these components belong to different projects and thus have no natural path to a unified experience.

A Key Limitation of `pam_fprintd`: The PAM Stack is Serial

There's another fundamental limitation with pam_fprintd: in a standard PAM stack, it and password authentication execute in series.

My initial ideal experience was something like this:

For a single sudo prompt, it would simultaneously wait for my password and my fingerprint, using whichever was provided first.

But in reality, this isn't possible. A login manager can use more complex methods to fire up multiple PAM sessions to simulate concurrency, but a regular sudo won't do that.

So, the real-world choices are limited to the following experiences:

Option A: Fingerprint first, fallback to password on failure.
Option B: Password first, fallback to fingerprint if you press Enter with an empty field.
Option C: Only use the Polkit GUI, don't force fingerprint on sudo.
Option D: Use a third-party hack module (not recommended—don't mess around with root authentication).

I eventually settled on Option B, but I tried Option A first. Let me explain why it flopped.

Option A: Fingerprint First, Fallback to Password (Post-Mortem)

My initial, intuitive configuration was this, in /etc/pam.d/sudo:

#%PAM-1.0

auth        sufficient  pam_fprintd.so max-tries=3 timeout=8
auth        include     system-auth
account     include     system-auth
session     include     system-auth

Logically, this looks fine: try the fingerprint first. If it succeeds, great; if not, it'll ask for a password.

But in practice, it broke. I deliberately let the fingerprint recognition fail, then typed the correct password, but sudo still would not let me through. The logs showed entries like this:

pam_unix(sudo:auth): conversation failed
pam_unix(sudo:auth): auth could not identify password for [...]
pam_faillock(sudo:auth): Consecutive login failures ... account temporarily locked

Meanwhile, fprintd was also complaining:

Device was already claimed
Verification was in progress, stopping it

It seems the interaction between sudo, the terminal PAM conversation, pam_fprintd, and the subsequent password stack gets into a messy state. After the fingerprint failed, the password fallback didn't take over cleanly, and it also increased the faillock failure count, temporarily locking my account.

The biggest danger with this kind of problem is that you're modifying the root privilege escalation entry point. If you bork /etc/pam.d/sudo and don't have another root channel, it's easy to lock yourself out.

My recovery method at that time was using a still-functional Polkit:

pkexec sh -c 'cat > /etc/pam.d/sudo <<EOF
#%PAM-1.0
auth        include     system-auth
account     include     system-auth
session     include     system-auth
EOF
faillock --user username --reset
systemctl restart fprintd
'

bash

I suggest keeping this rollback method in mind: first, revert sudo to Arch's default password-only path, then clear faillock, and finally restart fprintd to release any lingering device claims. It's a lifesaver in critical moments.

Option B: Password First, Empty Enter for Fingerprint (My Current Setup)

I later switched to a different approach: the system presents a normal sudo password prompt, but if you just press Enter (submitting an empty password), it falls back to fingerprint verification.

My current configuration in /etc/pam.d/sudo:

#%PAM-1.0

# Prompt for password first; an empty password triggers a fingerprint attempt
auth        sufficient  pam_unix.so try_first_pass likeauth nullok

# Prevent fingerprint prompts in non-tty background sudo processes
auth        [success=1 default=ignore] pam_succeed_if.so service in sudo:su:su-l tty in :unknown
-auth       sufficient  pam_fprintd.so max-tries=3 timeout=8

# Arch's default fallback
auth        include     system-auth
account     include     system-auth
session     include     system-auth

The interactive flow goes like this:

[sudo] password for user:

If you want to enter a password, just type it. If you want to use your fingerprint, press Enter on an empty field, and it will switch to:

Place your right index finger on the fingerprint reader

This approach feels more intuitive in the terminal than "fingerprint first," but it has its own little quirks.

The Catch with Option B: Empty Enter Can Leave a Failure Record

That "empty Enter" step inherently goes through pam_unix.so first. From pam_unix's perspective, an empty string is not a correct password, so it registers an authentication failure before the PAM flow moves on to pam_fprintd.

When you check faillock, you might see a record like this:

user:
When                Type  Source       Valid
2026-05-08 ...      TTY   /dev/pts/1   V

This means that even if the subsequent fingerprint authentication is successful, that initial empty Enter step might still be logged as a failed attempt.

So, if you go with this option, keep a few things in mind:

Don't set faillock's failure threshold too low.
Always leave a working root backdoor while debugging PAM, like a currently functional pkexec.
After consecutive failures, remember to check:

faillock --user "$USER"

bash

And manually reset it if necessary:

faillock --user "$USER" --reset

bash

Also, a side note: if you want the most stable graphical privilege escalation experience, it's best to just prefer Polkit for daily use and not force everything through sudo.

KWallet: Why You Can't Unlock It with a Fingerprint

This is another common point of confusion.

The role of kwallet-pam is, when you log in with your password, to pass that login password to KWallet, allowing the wallet to be automatically unlocked with the same credentials.

There's a line in the logs that says it all:

pam_kwallet5(plasmalogin-autologin:auth): Empty or missing password, doing nothing

This line makes the problem crystal clear: an automatic or fingerprint-based login does not provide the plaintext "user password," so KWallet doesn't get the key it needs.

A fingerprint authentication only answers one question:

Is this person who they claim to be?

KWallet's decryption requires an answer to a different question:

What is the key or password used to open the wallet?

The fingerprint device won't spit out your login password; it only tells the system if the authentication was successful. Therefore, KWallet has no way to decrypt using a fingerprint alone.

There are a few ways to handle this:

Disable automatic login, log in with your password, and keep your KWallet password synchronized with your login password.
Accept reality and manually enter your KWallet password once after reaching the desktop.
Reduce wallet security, for instance, by using a wallet with an empty password—but this is absolutely not recommended, especially if you're storing important keys.

So, this isn't a case of KDE failing to connect things; it's that "authentication" and "decryption" are fundamentally two different things.

`fprintd` Device Contention Issues

During my tinkering, I also encountered this error:

Device was already claimed
Verification was in progress, stopping it

This usually means a previous verification didn't terminate cleanly, or several authentication requests are simultaneously trying to claim the same fingerprint device.

The fix is simple:

systemctl restart fprintd

bash

If you lack sufficient user permissions, use your confirmed-working Polkit backdoor:

pkexec systemctl restart fprintd

bash

This is also why I don't recommend configuring too many authentication entry points to automatically grab the fingerprint reader. The device can serve only one verification request at a time. When multiple PAM or Polkit requests compete for it, the resulting experience becomes incredibly erratic.

Final State Summary

After all that tinkering, here's the current fingerprint and authentication configuration for this machine:

fprintd: Correctly identifies the Goodix device. I have enrolled my right index finger.
KDE User Settings: Fingerprint can be managed through kcm_users.
Polkit: Prioritizes fingerprint, falls back to password on failure.
kio-admin: Installed, allowing graphical root file operations via the admin:// protocol.
sudo: Asks for password first; pressing Enter on empty triggers a fingerprint attempt (max 3 tries).
Plasma Login Manager: PAM is configured for fingerprint, but auto-login bypasses it.
KWallet: Cannot be unlocked with a fingerprint alone.

Conclusion

The Linux compatibility of this Xiaomi Book Pro 14 is far better than I imagined. The few issues I faced all had clear causes and solutions, and in general, it's been a very smooth experience.

Another feeling I have is that tinkering with systems is much faster than it used to be. In the past, I'd have to dig through piles of ArchWiki entries and man pages for a problem. Now, you can just ask ChatGPT "how to fix xxx," and the efficiency is on a whole different level. This time, I even used OpenAI Codex, making the overall debugging process smoother by orders of magnitude.

Tinkering — mizore / notes

New Blog Features: Language Icons, Source Quotes, Tickers, and Charts

What's New

Language Icons on Code Blocks

Restyled Inline Code

Quoting GitHub Code Directly

Line-by-Line Diff Highlighting Like GitHub

Single-Line Tickers Become Mini Charts

Shortcode for Advanced Charts

Rendering ECharts Directly from Code Blocks

How It Works Under the Hood

Turning Shortcodes into Components in Remark

Loading TradingView Only on the Client

Enhancing Code Block Title Bars in Rehype

Keeping Inline Code from Stealing Attention

GitHub Code and Diffs Still Go Through Shiki

The Mental Model for Writing Posts

Fixing Obsidian Web Clipper Not Working on KDE Plasma Wayland

Cause

Analysis

Solution

Xiaomi Book Pro 14 on Linux

Problem 1: Screen Artifacts

Problem 2: Keyboard Not Recognized

Fingerprint: The Main Event

Why doesn't sudo pop up a fingerprint GUI like macOS?

A Key Limitation of pam_fprintd: The PAM Stack is Serial

Option A: Fingerprint First, Fallback to Password (Post-Mortem)

Option B: Password First, Empty Enter for Fingerprint (My Current Setup)

The Catch with Option B: Empty Enter Can Leave a Failure Record

KWallet: Why You Can't Unlock It with a Fingerprint

fprintd Device Contention Issues

Final State Summary

Conclusion

Why doesn't `sudo` pop up a fingerprint GUI like macOS?

A Key Limitation of `pam_fprintd`: The PAM Stack is Serial

`fprintd` Device Contention Issues