Commit graph

4 commits

Author SHA1 Message Date
Johannes Millan
ecba6c4240 docs(research): add §16 field data from #7270 follow-up
First post-release report on PR #7266 (v18.2.4): X11 widening fires
but doesn't rescue user on Ubuntu 24.04 + Intel Arrow Lake-P. Mesa
DRI still fails, GPU process segfaults in a loop. Lowers the 95%
estimate, promotes --disable-software-rasterizer to must-ship, and
upgrades core24/gpu-2404 migration urgency to 18.3.
2026-04-20 15:48:40 +02:00
Johannes Millan
e738bd2823
docs(research): extend Snap+Wayland GPU research with PR #7273 follow-up (#7275)
Follow-up to issue #7270 and the now-closed PR #7273. Extends the
existing research doc with four new sections based on multi-agent
research, verification passes, and empirical reporter confirmation.

- §12: PR #7273 GPU startup guard framing and mechanism analysis.
- §13: Deepened research on Chromium/Electron/Mesa correctness, prior
  art for crash-loop startup markers (Firefox recent_crashes, Chromium
  in-process GpuMode stack, BugSnag/Sentry patterns), testing strategy
  with concrete spec proposal, edge cases, and long-term strategy.
- §14: Verification pass findings (four parallel agents) — corrections
  applied to §12 (v18.2.3 timeline, --disable-gpu wording), rejected
  claims with evidence, outstanding attribution fixes.
- §15: Final PR re-evaluation — including why PR #7273 was closed in
  favor of #7266 after the reporter empirically confirmed that
  --ozone-platform=x11 resolves their launch failure on Ubuntu 22.04.

Keeps the research available for the next time this class of failure
surfaces (future Chromium bumps, Mesa ABI drift on core24/gpu-2404,
Flatpak packaging, etc.).
2026-04-19 18:50:38 +02:00
Johannes Millan
ac7cf7b853
Claude/snap wayland gpu fix co dc5 (#7266)
* docs(research): add Snap + Wayland GPU init failure research

Synthesizes root cause (Mesa ABI drift in gnome-42-2204), scope,
peer-app consensus, and ranked options. Recommends widening the
existing Snap-gated --ozone-platform=x11 guard in start-app.ts to
cover Snap + Wayland sessions, with core24 + gpu-2404 migration
as the long-term fix.

https://claude.ai/code/session_01Hu6EP7Xux9JRvGGGKpBfwm

* docs(research): correct electron timing and soften unverified peer claims

* fix(electron): force X11 on Snap Wayland to avoid Mesa ABI drift

The existing Snap-only X11 fallback triggered only when $SNAP/gnome-platform
was empty. In practice gnome-platform is populated but its Mesa can drift
out of ABI sync with Electron's bundled libgbm, producing
"Failed to get system egl display" and a GPU process respawn loop on
Wayland sessions. Widen the guard to also fire when the session is
Wayland (XDG_SESSION_TYPE=wayland or WAYLAND_DISPLAY set). X11/GLX
avoids the failing Wayland EGL init path entirely while preserving
hardware acceleration.

Refs: electron-builder#9452, super-productivity#5672,
forum.snapcraft.io #40975, #49173

https://claude.ai/code/session_01JNxazJmDhpMp9UYV6SqnBG

* refactor(electron): address review feedback on Snap X11 force

- Handle space-separated `--ozone-platform wayland` override in addition
  to the `=` form; tighten the argv scan to reject accidental substring
  matches (e.g., arg values that happen to contain `--ozone-platform=`).
- Enrich the log line with raw XDG_SESSION_TYPE and WAYLAND_DISPLAY
  values to make user-reported triage faster.
- Tighten comment: correct "X11/GLX" to "X11 ozone backend" (modern
  Chromium uses EGL on X11), clarify the root cause as Mesa version
  drift rather than bundled-library ABI drift, broaden the loss list
  beyond fractional scaling, and move issue references to the commit
  body per CLAUDE.md guidance.

Follow-ups flagged but not addressed here: possible interaction with
`allowNativeWayland: true` in electron-builder.yaml, GPU cache keyed
by effective ozone platform, and the longer-term core24 migration
already in docs/long-term-plans/electron-upgrade-to-v40.md.

Refs: electron-builder#9452, super-productivity#5672,
forum.snapcraft.io #40975, #49173

https://claude.ai/code/session_01JNxazJmDhpMp9UYV6SqnBG

* docs(research): verify peer-app claims, correct SP electron timing

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-04-18 20:57:00 +02:00
Johannes Millan
d75cc00da8
docs: Add recurring events research and implementation plan (#6375)
* docs(research): add recurring events industry standards analysis

Comprehensive research comparing Super Productivity's recurring task
implementation against RFC 5545 RRULE standard and major applications
(Google Calendar, Todoist, Things 3, TickTick).

Key findings:
- Current implementation covers basic patterns but lacks nth weekday,
  last day of month, and end conditions (COUNT/UNTIL)
- Recommends adopting rrule.js library for RFC 5545 compliance
- Proposes incremental migration path preserving existing functionality
- Notes "after completion" mode as competitive advantage to preserve

https://claude.ai/code/session_01Rhuxtn9JKKhh4J3iLApaWX

* docs(research): add gap analysis and implementation plan for recurring events

Gap analysis compares current TaskRepeatCfg model against RFC 5545 RRULE
and major applications (Google Calendar, Todoist, Things 3, TickTick).

Implementation plan details 4-phase approach:
- Phase 1: Add rrule.js, create DST-safe wrappers
- Phase 2: Enable new patterns (nth weekday, last day, end conditions)
- Phase 3: Lazy migration strategy
- Phase 4: Natural language display, iCal export

https://claude.ai/code/session_01Rhuxtn9JKKhh4J3iLApaWX

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-02-05 15:32:44 +01:00