When the connection to X is broken zed will go into an infinite loop and
eat up 100% (of one core) of CPU; this change causes it to exit with an
error instead.
I encountered this behavior while running zed in
[Xephyr](https://freedesktop.org/wiki/Software/Xephyr/) for testing,
though I do sometimes terminate my X server as a way to log out or
attempt to recover from a (very) broken state, and I appreciate a
graceful exit in those situations!
Exiting in case of X server disconnect is common practice in my
observations, likely as the difficulty of recreating state stored
server-side outweighs the potential utility in attempting to recover (if
"reconnecting" to an X server is ever desired in regular usage,
[Xpra](https://xpra.org/index.html) might be able to help!).
Release Notes:
- N/A
Previously, `get_layer_surface` always passed `None` as the output,
causing all layer shell windows to appear on the compositor's default
output regardless of the requested display.
Store `wl_output` proxies in client state and resolve them from
`DisplayId` so the correct output is passed to `get_layer_surface`.
Release Notes:
- N/A
Co-Authored-By: Eric Holk <eric@zed.dev>
In app drop we had been calling `.close()` on the executors. This caused
problems with the BackgroundExecutor on Linux because it raced with
concurrent work: If task A was running and about to poll task B, the
poll to task B would panic with "Task polled after completion". This
didn't really matter (because the app was shutting down anyway) but
inflated our panic metrics on Linux.
It turns out that the call to `.close()` is not needed. It was added to
prevent foreground tasks being scheduled after the app was dropped; but
on all platforms the App run method does not return until after the
ForegroundExecutor is stopped (so no further tasks will run anyway).
The background case is more interesting. In test code it didn't matter
(the background executor is simulated on the main thread so tests can't
leak tasks); in app code it also didn't really make a difference. When
`fn main` returns (which it does immediately after the app is dropped)
all the background threads will be cancelled anyway.
Further confounding debugging, it turns out that the App does not get
dropped on macOS and Windows due to a reference cycle; so this was only
happening on Linux where the app quit callback is dropped instead of
retained after being called. (Fix in #50985)
Release Notes:
- N/A
---------
Co-authored-by: Eric Holk <eric@zed.dev>
I'm embedding a 3D viewport inside GPUI by creating a child window with
its own surface that fits the bounds of a GPUI element, and I need
access to the raw window handle of the current window to manage it.
Right now on X11 this is stubbed as unimplemented and results in a
panic. I've copied most of the same implementation from the associated
`RawWindow` into `X11Window`.
Small clip of a Bevy app embedded inside GPUI with a popover that draws
above the 3d surface to show testing was done:
[Screencast_20260304_182657.webm](https://github.com/user-attachments/assets/829f9197-1613-41a7-af83-d377f3154751)
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Added implementations of `rwh::HasDisplayHandle` and
`rwh::HasWindowHandle` for `X11Window`
This uses the compositor hints if available to pick the best GPU. If
none is
available, it tries each GPU in turn, and the first that actually works
is chosen
Release Notes:
- Linux: Select a more appropriate GPU
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Implements a basic web platform for the wasm32-unknown-unknown target
for gpui
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: John Tur <john-tur@outlook.com>
The test suite was failing with this error: methods
`is_screen_capture_supported` and `screen_capture_sources` are never
used. I added allow(dead_code) attribute on both methods to fix it
action that was failing:
https://github.com/zed-industries/zed/actions/runs/22444029970/job/64993825469
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
## Summary
Fixes RefCell borrow panic on Linux (Wayland and X11) when callbacks try
to register new callbacks.
**Root cause:** Linux GPUI backends invoked callbacks while still
holding a `RefCell` borrow on the `Callbacks` struct. If a callback
tried to register a new
callback (e.g., `on_window_should_close`), it would panic with "already
borrowed: BorrowMutError".
**Bug pattern:**
```rust
// Callback runs while borrow is held - panics if callback borrows
callbacks
if let Some(ref mut fun) = self.callbacks.borrow_mut().input {
fun(input);
}
Fix: Apply the take-call-restore pattern (already used in macOS
backend):
// Take callback out, release borrow, call, restore
let callback = self.callbacks.borrow_mut().input.take();
if let Some(mut fun) = callback {
let result = fun(input);
self.callbacks.borrow_mut().input = Some(fun);
}
Changes
- Wayland (window.rs): Fixed 6 callback invocations
- X11 (window.rs): Fixed 4 callback invocations
Test plan
- cargo check -p gpui compiles successfully
- Tested on Linux (Wayland) - no more RefCell panic
Release Notes:
- Fixed a crash on Linux when window callbacks attempted to register new
callbacks
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Closes #ISSUE
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Fixes ZED-54X
Release Notes:
- Linux: wait to request a graphics context until we have a window so we
can (ideally) pick a better context or (less ideally) fail more
gracefully.
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes #ISSUE
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
#2874 on steroids
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
---------
Co-authored-by: Eric Holk <eric@zed.dev>
kitt