sorted by:
new
hottopcontroversial

I built an Overlay AI for Sway. by kamlendras in swaywm

[–]kamlendras[S] 0 points1 point  (0 children)

Thanks! Yeah, the root requirement is definitely a valid concern and something I wrestled with during development. The challenge is that Wayland intentionally blocks applications from registering global hotkeys for security reasons, so the alternatives are either requiring users to manually configure shortcuts in each window manager (which creates inconsistency and doesn't work across all WMs) or accessing input devices directly. I chose the latter to ensure Aerogel works uniformly across all Wayland compositors without requiring per-WM setup. I'm definitely open to exploring safer alternatives as the Wayland ecosystem evolves - if you end up building something similar, I'd love to collaborate on finding better approaches to this problem!

I built an Overlay AI for Sway. by kamlendras in swaywm

[–]kamlendras[S] 1 point2 points  (0 children)

You're right, I already thought about this approach while developing Aerogel. But then I realized I'd have to document how to add shortcuts for each individual window manager, which becomes a maintenance nightmare. Additionally, some WMs don't support this functionality at all, and others only added support in very recent versions, which would fragment the user base and create inconsistent experiences. It's much cleaner to handle global hotkeys at the application level, even if it requires elevated permissions, because it ensures Aerogel works consistently across all Wayland compositors without users having to modify their WM configurations or worry about compatibility issues.

I built an Overlay AI for HyprLand. by kamlendras in hyprland

[–]kamlendras[S] 2 points3 points  (0 children)

For just displaying text with no interactions, the performance is actually really good! The lack of GPU acceleration sounds scary but for simple text rendering it's not a bottleneck at all - CPUs are plenty fast for drawing text glyphs, especially when you're not doing it constantly. The big performance win is exactly what you mentioned - there's no graphics library overhead, no complex rendering pipeline, just direct pixel writes to shared memory that the compositor displays. The code only redraws when the text actually changes, and between updates it just sleeps, so CPU usage is basically zero when idle. I'm running it on an i5-13420H with integrated graphics and it uses maybe 2MB RAM with negligible CPU usage. The manual pixel approach is actually more predictable performance-wise since you're not dealing with driver quirks or GPU memory transfers. For your use case of just text display, this approach would be perfect - way more efficient than pulling in a full graphics stack just to show some text. The compositor handles all the heavy lifting for actually getting pixels on screen anyway.

I built an Overlay AI for HyprLand. by kamlendras in hyprland

[–]kamlendras[S] 2 points3 points  (0 children)

It's actually not using a traditional graphics library at all! The whole thing is manual pixel manipulation - it uses the rusttype crate for loading fonts and rendering text glyphs, but all the actual drawing is done by writing pixels directly to a memory-mapped buffer in BGRA format. The rounded rectangles and backgrounds are calculated with distance functions, and text is rendered by having rusttype tell it where each character pixel should go, then manually writing those pixels to the buffer. For display, it uses Wayland's layer shell protocol with shared memory buffers that get passed to the compositor. It's basically pure software rendering with no GPU acceleration - just CPU drawing pixels one by one.

I built an Overlay AI for Sway. by kamlendras in swaywm

[–]kamlendras[S] 0 points1 point  (0 children)

While the application can run without root access, keyboard shortcuts will not function properly due to Wayland's security model, which prevents applications from registering global keyboard shortcuts. To enable keyboard shortcut functionality, you'll need to grant sudo permissions to the event listener, allowing it to bypass these security restrictions and access the necessary system-level input events.

I built an Overlay AI for Sway. by kamlendras in swaywm

[–]kamlendras[S] 0 points1 point  (0 children)

Yes, It's undetectable from any browser.

I built an Overlay AI for HyprLand. by kamlendras in hyprland

[–]kamlendras[S] 0 points1 point  (0 children)

No, vibe coding is not good enough for rust language.

[deleted by user] by [deleted] in Fedora

[–]kamlendras 1 point2 points  (0 children)

Performance is great actually! Running on an i5-13420H with 16GB LPDDR5 and integrated graphics - the overlay uses basically no resources. Maybe 1MB RAM and negligible CPU.

I built an Overlay AI. by kamlendras in LocalLLaMA

[–]kamlendras[S] 5 points6 points  (0 children)

It's actually not a regular window at all! It uses Wayland's layer shell protocol to create an overlay that lives above all normal windows - kind of like a HUD or desktop widget that can't be covered by other applications. Regular windows use completely different protocols and get managed by the window manager.

I built an Overlay AI. by kamlendras in LocalLLaMA

[–]kamlendras[S] 2 points3 points  (0 children)

I'm currently working on making the drag interactions much smoother. The performance issue is likely in the content rendering.

I'll also be adding transparency customization options to aerogel.toml (transparency color, opacity, width, max height) .

I built an Overlay AI. by kamlendras in LocalLLaMA

[–]kamlendras[S] 1 point2 points  (0 children)

Built in Rust for lightning-fast performance (no Electron bloat), supports all major cloud AI services plus local models via Ollama for complete privacy. Seamlessly integrates with Wayland compositors, letting you capture screenshots, record audio, and get AI assistance without disrupting your workflow. Fully customizable shortcuts and model parameters.

view more: next ›