will/claude-code
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: Claude Code config and K8s agent orchestrator design

Browse Source 
- Add .gitignore for logs, caches, credentials, and history
- Add K8s agent orchestrator design document
- Include existing Claude Code settings and plugin configs

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
OpenCode Test
2025-12-26 11:16:07 -08:00
commit 216a95cec4
9 changed files with 1116 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

142
plans/cosmic-frolicking-compass.md Normal file
View File

@@ -0,0 +1,142 @@
# Plan: Fix Zed Slow Launch and Performance on Hyprland
## Problem Analysis
**Original Request:** Compile Zed with OpenGL support instead of Vulkan for Intel HD Graphics 4000
**Actual Issue Discovered:** Zed is using X11/XWayland instead of native Wayland on Hyprland, causing:
- 15+ second launch times
- Sluggish runtime performance
- The hardware (Intel HD Graphics 4000) is properly supported and works fine on Gnome
**System Information:**
- Binary: `/usr/lib/zed/zed-editor` (Arch package v0.213.4-1)
- Command: `zeditor`
- Hyprland version: 0.52.1
- Mesa version: 25.2.7-arch1.1
- Environment: Both `WAYLAND_DISPLAY=wayland-1` and `DISPLAY=:1` are set
**Evidence from logs** (`~/.local/share/zed/logs/Zed.log`):
```
2025-12-12T22:12:02-08:00 INFO [gpui::platform::linux::x11::window] Using Visual { id: 112, colormap: 0, depth: 32 }
2025-12-12T22:12:02-08:00 INFO [gpui::platform::linux::x11::window] x11: no compositor present, falling back to server-side window decorations
2025-12-12T22:12:02-08:00 ERROR [gpui::platform::linux::x11::client] XIMClientError: Can't read xim message: Invalid Data ErrorCode: 0
```
## Root Cause
**Mystery Identified:** Despite both environment variables being correctly set (`WAYLAND_DISPLAY=wayland-1` and `DISPLAY=:1`), Zed is still choosing X11.
Based on the code in `crates/gpui/src/platform.rs` (lines 139-164), Zed should prioritize Wayland when `WAYLAND_DISPLAY` is set. The fact that it's using X11 despite this suggests:
**Most Likely:** The Arch package (v0.213.4-1) was compiled **without the `wayland` Cargo feature enabled**, causing the binary to only support X11 even when Wayland is available.
This is supported by:
- The platform selection code has `#[cfg(feature = "wayland")]` guards
- If Wayland feature is disabled at compile time, `guess_compositor()` will always return "X11"
- A similar issue was documented in Arch forums ([thread](https://bbs.archlinux.org/viewtopic.php?id=299290))
## Recommended Solution
**Compile Zed from source with Wayland support enabled.** The Arch package appears to lack Wayland support at compile time.
### Step 1: Build Zed with Wayland Support
From the repository root (`/home/will/repo/zed`):
```bash
# Clean any previous builds (optional)
cargo clean
# Build with Wayland feature explicitly enabled
cargo build --release --features gpui/wayland
# Or build the full zed binary with default features (which includes wayland)
cargo build --release -p zed
```
**Build time estimate:** 20-40 minutes on first build (depending on CPU)
### Step 2: Install the Binary
```bash
# Create installation directory if needed
mkdir -p ~/.local/bin
# Copy the binary
cp target/release/zed ~/.local/bin/zed-wayland
# Or replace the system zeditor
sudo cp target/release/zed /usr/local/bin/zeditor
```
### Step 3: Verify Wayland Support
```bash
# Launch and check logs
~/.local/bin/zed-wayland
grep -E "wayland|x11" ~/.local/share/zed/logs/Zed.log | tail -5
```
Expected output should show Wayland initialization, NOT X11 messages.
## Alternative: Install from AUR or Use Different Package
If you don't want to compile from source, consider:
1. **Install `zed-git` from AUR** (may have Wayland support):
```bash
paru -S zed-git # or yay -S zed-git
```
2. **File a bug report with Arch** to request Wayland support in the official package
3. **Wait for official Arch package update** to include Wayland support
## Why NOT OpenGL/GLES?
The original request was to compile with OpenGL instead of Vulkan. **This is unnecessary** because:
- Your Intel HD Graphics 4000 supports Vulkan (working fine on Gnome)
- The slowness is from X11/XWayland overhead, NOT the graphics backend
- Mesa drivers are properly installed (Vulkan, OpenGL 4.2, OpenGL ES 3.0 all working)
- Switching to GLES won't fix the X11 vs Wayland issue
**GLES compilation would only be needed if:**
- Vulkan completely fails (`vkcube` doesn't work)
- Zed shows "NoSupportedDeviceFound" error
- You get GPU-related crashes
## Expected Outcome
After compiling with Wayland support and running the new binary:
- **Launch time:** Should match Gnome performance (~2 seconds)
- **Runtime performance:** Smooth, no sluggishness
- **Logs:** Will show Wayland client initialization instead of X11
## Build Requirements
The system already has all necessary dependencies:
- Rust toolchain (rustup)
- Wayland development libraries (installed)
- Build tools (gcc, clang, cmake, etc.)
- Vulkan and Mesa drivers (working)
From `crates/gpui/Cargo.toml` (lines 40-59), the `wayland` feature depends on:
- `wayland-client`, `wayland-cursor`, `wayland-protocols` (all available on Arch)
- `blade-graphics` (already in use for Vulkan)
- Font libraries (cosmic-text, font-kit) - already installed
## Critical Files for Reference
- `crates/gpui/Cargo.toml:20` - Default features include "wayland" and "x11"
- `crates/gpui/Cargo.toml:40-59` - Wayland feature dependencies
- `crates/gpui/src/platform.rs:101-164` - Platform selection logic
- `crates/gpui/src/platform/linux/wayland/client.rs` - Wayland client implementation
- `crates/gpui/src/platform/linux/x11/client.rs` - X11 client implementation
## Implementation Steps
1. **Build from source** with Wayland support (20-40 min)
2. **Install the binary** to ~/.local/bin or /usr/local/bin
3. **Test launch** and verify Wayland is being used via logs
4. **Confirm performance** matches Gnome experience

108
plans/elegant-prancing-allen.md Normal file
View File

@@ -0,0 +1,108 @@
# Vulkan Installation Verification Plan
## Goal
Verify that Vulkan is correctly installed and functional on the system, and determine whether the Mesa warning about incomplete Ivy Bridge support is a concern.
## Background Context
**Hardware**: Intel HD Graphics 4000 (Ivy Bridge) - circa 2012
**Current Status**:
- Vulkan 1.4.328 is installed
- `vulkaninfo` runs successfully
- Mesa driver shows warning: "MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete"
- Zed editor launches successfully despite the warning
## Understanding the Warning
The "Ivy Bridge Vulkan support is incomplete" warning is **expected behavior** for your hardware:
1. **Why it appears**: Intel HD Graphics 4000 is a 3rd-generation (Ivy Bridge) GPU from 2012, before Vulkan was standardized
2. **What it means**: Mesa provides best-effort Vulkan support through a compatibility layer, but not all Vulkan features are hardware-accelerated
3. **Is it a problem?**: Generally no - applications will either:
- Use the incomplete Vulkan support (works for most tasks)
- Fall back to OpenGL automatically
- Use the software renderer (llvmpipe) as a last resort
## Verification Approach
### Step 1: Verify Vulkan Device Detection ✅
Diagnostic results confirm:
- ✅ Vulkan loader is installed (`vulkaninfo` successful)
- ✅ GPU is detected (Intel HD Graphics 4000 IVB GT2)
- ✅ Both hardware and software renderers available:
- Hardware: Intel HD Graphics 4000 (using intel_icd.x86_64.json)
- Software fallback: llvmpipe (LLVM 21.1.5, 256 bits)
- ✅ Vulkan ICD files present:
- intel_icd.x86_64.json (for Ivy Bridge/Broadwell)
- intel_hasvk_icd.x86_64.json (for Haswell+)
- lvp_icd.x86_64.json (lavapipe software renderer)
- nouveau_icd.x86_64.json (Nouveau open-source driver)
- nvidia_icd.json (NVIDIA proprietary driver)
### Step 2: Test Vulkan Functionality
Run simple Vulkan test applications to verify:
- Basic rendering works
- Applications can create Vulkan instances and devices
- The warning doesn't prevent normal operation
Commands to run:
```bash
# Verify Vulkan ICD (Installable Client Driver) files
ls -la /usr/share/vulkan/icd.d/
# Check which Vulkan layers are available
vulkaninfo --summary | grep -A 5 "Layer"
# Test with a simple Vulkan application (if vkcube is installed)
vkcube || echo "vkcube not installed, will try alternative"
# Check if Zed can actually use Vulkan
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json /usr/lib/zed/zed-editor --version
```
### Step 3: Verify Mesa Driver Status
Confirm Mesa drivers are up to date:
```bash
# Check Mesa version
glxinfo | grep "OpenGL version"
# Verify Intel driver is loaded
lsmod | grep i915
# Check Vulkan driver info
vulkaninfo | grep -A 10 "GPU id.*Intel"
```
### Step 4: Document Findings
Create a summary report showing:
1. Vulkan is installed: ✅ (version 1.4.328)
2. GPU is detected: ✅ (Intel HD Graphics 4000 + llvmpipe fallback)
3. Warning is expected: ✅ (Ivy Bridge has incomplete Vulkan support by design)
4. Applications work: ✅/❌ (to be verified)
## Expected Outcome
**Vulkan is correctly installed** if:
- `vulkaninfo` runs without errors (✅ confirmed)
- At least one Vulkan device is available (✅ Intel HD 4000 + llvmpipe)
- Applications launch and run (✅ Zed editor works)
**The warning is harmless** because:
- It's informational, not an error
- Applications handle this gracefully by:
- Using available Vulkan features
- Falling back to OpenGL/software rendering
- Automatically selecting the best available renderer
## Recommendations
1. **No action needed** - Vulkan is working as well as it can on Ivy Bridge hardware
2. **Optional**: Set environment variable to suppress the warning if it's annoying:
```bash
export INTEL_DEBUG=nowarn
```
3. **Optional**: For better graphics performance, consider using OpenGL mode in applications when available (Ivy Bridge's OpenGL support is more mature than Vulkan)
## Files to Review
None - this is a system-level verification task, not a code modification.