This will allow us to compile debug builds of the remote-server for a
different architecture than the one we are developing on.
This also adds a CI step for building our remote server with minimal
dependencies.
Release Notes:
- N/A
Closes #14089, #14416, #15970, #17230, #18485
Release Notes:
- Fixed some cases where Linux X11 mouse scrolling doesn't work at all
(#14089, ##15970, #17230)
- Fixed handling of switching between Linux X11 devices used for
scrolling (#14416, #18485)
Change details:
Also includes the commit from PR #18317 so I don't have to deal with
merge conflicts.
* Now uses valuator info from slave pointers rather than master. This
hopefully fixes remaining cases where scrolling is fully
broken. https://github.com/zed-industries/zed/issues/14089,
https://github.com/zed-industries/zed/issues/15970,
https://github.com/zed-industries/zed/issues/17230
* Per-device recording of "last scroll position" used to calculate
deltas. This meant that swithing scroll devices would cause a sudden
jump of scroll position, often to the beginning or end of the
file (https://github.com/zed-industries/zed/issues/14416).
* Re-queries device metadata when devices change, so that newly
plugged in devices will work, and re-use of device-ids don't use old
metadata with a new device.
* xinput 2 documentation describes support for multiple master
devices. I believe this implementation will support that, since now it
just uses `DeviceInfo` from slave devices. The concept of master
devices is only used in registering for events.
* Uses popcount+bit masking to resolve axis indexes, instead of
iterating bit indices.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Closes#15833
Related to [#12495
comment](https://github.com/zed-industries/zed/pull/12495#issuecomment-2328356125)
Destroying and recreating the Input context was the only way to reset
the IME but it's making the keyboard unresponsive sometimes due to a XIM
error.
The keyboard will still be unresponsive if you close your IME while
using zed, but I don't know how to fix this.
* Fixed preedit drawing for CJK
* Fixed unresponsive keyboard by properly implementing reset_ic in
`xim-rs`
Release Notes:
- N/A
Release Notes:
- N/A
This updates the IME position every time the selection changes, this is
probably only useful when you enumerate languages with your IME.
TODO:
- ~There is a rare chance that the ime panel is not updated because the
window input handler is None.~
- ~Update IME panel in vim mode.~
- ~Update IME panel when leaving Buffer search input.~
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
For future reference: WIP branch of copy/pasting a mixture of images and
text: https://github.com/zed-industries/zed/tree/copy-paste-images -
we'll come back to that one after landing this one.
Release Notes:
- You can now paste images into the Assistant Panel to include them as
context. Currently works only on Mac, and with Anthropic models. Future
support is planned for more models, operating systems, and image
clipboard operations.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Jason <jason@zed.dev>
Co-authored-by: Kyle <kylek@zed.dev>
This fixes an issue where the window's hovered state would be incorrect,
causing the cursor not to update because it would think the window
wasn't hovered ([relevant
check](https://github.com/zed-industries/zed/blob/a03beeeb5bcce3fbb464a5d2a06a6ae47e8dda92/crates/gpui/src/window.rs#L3016-L3017)).
The code here doesn't really seem to make sense, since there's already
the `XinputEnter` and `XinputLeave` events that indicate mouse focus
state on the window. The properties change event wouldn't necessarily
indicate when mouse focus changes.
Thanks @Emc2356 for reporting this on the Discord and helping figure out
the issue!
Release Notes:
- Linux: Fixed the cursor sometimes not changing on X11
This changes the workspace/session serialization to also persist the
order of windows across restarts.
Release Notes:
- Improved restoring of windows across restarts: the order of the
windows is now also restored. That means windows that were in the
foreground when Zed was quit will be in the foreground after restart.
(Right now only supported on Linux/X11, not on Linux/Wayland.)
Demo:
https://github.com/user-attachments/assets/0b8162f8-f06d-43df-88d3-c45d8460fb68
https://github.com/zed-industries/zed/pull/13126 added the
`window_min_size` property for window creation, but it was only
implemented for macOS. This PR implements the property on Linux as well.
Release Notes:
- N/A
Now it is possible to change keyboard layouts with `setxkbmap` without
having to restart zed.
Release Notes:
- x11: Support for keyboard layout hot plugging.
Release Notes:
- linux: Added GPU information to `editor: Copy System Specs to
Clipboard`
- linux: Show a prominant warning before running under llvmpipe and
similar.
This restores https://github.com/zed-industries/zed/pull/13943 which was
reverted in #13974 because it was possible to get in a state where focus
could not be restored on a window.
In this PR there's an additional change: `FocusIn` and `FocusOut` events
are always handled, even if the `event.mode` is not "NORMAL". In my
testing, `alt-tabbing` between windows didn't produce `FocusIn` and
`FocusOut` events when we had that check. Now, with the check removed,
it's possible to switch focus between two windows again with `alt-tab`.
Release Notes:
- N/A
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This reverts #13943 and reopens#13897 since the fix in #13943 comes
with a regression:
Sometimes Zed loses keyboard focus and can't be restored. I haven't
figured out yet exactly when and how this happens and can't reliably
reproduce it yet, but there's something off with focus handling.
One reliable way to reproduce _one_ of the problems:
1. Open two zed windows
2. Focus one Zed window
3. Hover with the mouse over the other
4. Try to type in the window that should still be focused
So, to be careful, I'm going to revert the PR first, since I couldn't
find an obvious fix yet. If we do find a fix, we can unrevert.
Release Notes:
- N/A
Adds the `compositor_support` to the `X11WindowState` struct so that
correct window decorations are selected
Release notes:
- N/A
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR consists of two main changes:
1. The first commit changes the `open` crate for opening URLs/paths for
the `OpenURI` desktop portal. This fixes the activation token not being
passed to programs (at least on KDE).
2. The second commit implements the window `activate()` API on Wayland.
This allows KWin and Mutter to show a visual indicator when the window
is requesting attention. (see
https://github.com/zed-industries/zed/issues/12557)
Release Notes:
- N/A
Pass on all the XkbStateNotify information to XKB.
> "All parameters must always be passed, or the resulting state may be
incoherent."
>
https://docs.rs/xkbcommon/latest/xkbcommon/xkb/struct.State.html#method.update_mask
Previously, many keymaps using multiple groups/layers would not work and
remain in group0.
Release Notes:
- Fixed handling of Xkb keymap groups on X11.
**Edit**:
This PR adds flushes to functions which should have an immediate affect.
I've observed it fixing the following bugs (but there are probably
more):
- The cursor not updating when just hovering.
- The window not maximising after clicking the full-screen button until
you move the mouse.
- The window not minimising after clicking the minimise button until you
move the mouse.
---
**Original content**:
Following #13646, the cursor style wouldn't change because the
`change_window_attributes` command wasn't being flushed. I guess it was
working before because something else was flushing it somewhere else so
it was never noticed.
I just added `check()` which flushes the command so that the cursor will
actually update when just hovering. Before you would need to interact
with the window so that something else could flush the command.
Release Notes:
- N/A
With the new window decorations resizing was _really_ laggy on my X11
machine.
Before:
- Click on window border (hitbox doesn't work properly, but that's
another issue)
- Drag and resize
- 4-5s nothing happens
- Window is resized
After:
- Click on window border
- Drag and resize
- Window is resized
I'm still not 100% sure on why this happens on my machine and not
Conrad's/Mikayla's, but seems like that GTK_EDGE_CONSTRAINTS atom is
sent when resizing.
The other thing that I can't explain is that we get a `ConfigureNotify`
when resizing, with the right size, but maybe not often enough?
Anyway, for now we'll go with this.
Release Notes:
- N/A
This changes the implementation of the X11 client to use `mio`, as a
polling mechanism, and a custom run loop instead of `calloop` and its
callback-based approach.
We're doing this for one big reason: more control over how we handle
events.
With `calloop` we don't have any control over which events are processed
when and how long they're processes for. For example: we could be
blasted with 150 input events from X11 and miss a frame while processing
them, but instead of then drawing a new frame, calloop could decide to
work off the runnables that were generated from application-level code,
which would then again cause us to be behind.
We kinda worked around some of that in
https://github.com/zed-industries/zed/pull/12839 but the problem still
persists.
So what we're doing here is to use `mio` as a polling-mechanism. `mio`
notifies us if there are X11 on the XCB connection socket to be
processed. We also use its timeout mechanism to make sure that we don't
wait for events when we should render frames.
On top of `mio` we now have a custom run loop that allows us to decide
how much time to spend on what — input events, rendering windows, XDG
events, runnables — and in what order we work things off.
This custom run loop is consciously "dumb": we render all windows at the
highest frame rate right now, because we want to keep things predictable
for now while we test this approach more. We can then always switch to
more granular timings. But considering that our loop runs and checks for
windows to be redrawn whenever there's an event, this is more an
optimization than a requirement.
One reason for why we're doing this for X11 but not for Wayland is due
to how peculiar X11's event handling is: it's asynchronous and by
default X11 generates synthetic events when a key is held down. That can
lead to us being flooded with input events if someone keeps a key
pressed.
So another optimization that's in here is inspired by [GLFW's X11 input
handling](https://github.com/glfw/glfw/blob/b35641f4a3c62aa86a0b3c983d163bc0fe36026d/src/x11_window.c#L1321-L1349):
based on a heuristic we detect whether a `KeyRelease` event was
auto-generated and if so, we drop it. That essentially halves the amount
of events we have to process when someone keeps a key pressed.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Conrad <conrad@zed.dev>
Release Notes:
- N/A
Fixed#13463 Fixed crash when the locale was non UTF-8 and fixed the
fallback locale.
Fixed#13010 Fixed crash when `compose.keysym()` was `XKB_KEY_NoSymbol`
I also extracted the `xkb_compose_state` to a single place
The clipboard library we use for X11 doesn't yet support multiple
formats on the clipboard, so for now we just store this in memory for
the current zed process, as we do for Wayland.
Fixes: #11971
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This is a small change that aims to address frames being dropped when we
get a ton of X11 input events.
What it does, in short, is to first read all X11 input events and then
prioritize the rendering.
In my testing, it causes less frames to be dropped when the system is
under heavy load and lots of input events are being created.
Release Notes:
- N/A
This reverts commit f69c8ca74e after it
has already been partially reverted in
https://github.com/zed-industries/zed/pull/13458.
Why the revert?
The changes in that commit/PR fix one type of problem — dropping of
frames when being blasted with input events — but trades it for another
one that I can't explain yet: when the system is under load, then input
becomes _laggy_ and input events seem to be delayed.
Two examples of how that shows up:
1. When the system is under load* and you hold down the `down` key to
scroll, then lift the finger, the cursor stops sometimes. If you then
produce another input event by jiggling the mouse cursor you'll see more
`down`-key events coming up and the cursor moving down. It feels as if
the event loop is not being woken up even though there are still events.
I suspect it might have something to do with XIM, because if it's
disabled, it seems as if problems become less severe.
2. When the system is under load* and you click-and-drag a selection in
the editor, you can see how the selection is delayed and takes 500ms-1s
to catch up to where the cursor is.
* system under load: start Zed, then in another terminal window create a
release build of Zed, for example.
With the changes reverted, the failure mode looks different: we skip
frames. But that, I think, is the better of two bad options, because
skipping frames means that you see what's happening vs. input events
seemingly still coming in seconds after you stopped using the keyboard.
Release Notes:
- N/A
This change ensures that we always render a window according to its
refresh rate, even if there are a lot of X11 events.
We're working around some limitations of `calloop`. In the future, we
think we should revisit how the event loop is implemented on X11, so
that we can ensure proper prioritization of input events vs. rendering.
Release Notes:
- N/A
Co-authored-by: Antonio <me@as-cii.com>
We saw this panic come up:
```
called `Result::unwrap()` on an `Err` value: IoError(Custom { kind: Other, error: UnknownError })
core::panicking::panic_fmt
core::result::unwrap_failed
<gpui::platform::linux::x11::window::X11Window as core::ops::drop::Drop>::drop
core::ptr::drop_in_place<gpui::platform::linux::x11::window::X11Window>
core::ptr::drop_in_place<gpui::window::Window>
gpui::app::AppContext::shutdown
gpui::app::AppContext::new::{{closure}}
gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run
gpui::app::App::run
zed::main
std::sys_common::backtrace::__rust_begin_short_backtrace
std::rt::lang_start::{{closure}}
std::rt::lang_start_internal
main
__libc_start_call_main
__libc_start_main_impl
_start
```
I'm not sure where exactly that error comes from, except from the X11
stuff. So let's be defensive and log error and only then tear down
everything.
I _think_ that if the error is repeatable that means we won't close the
window but instead just log errors, but I do think that's better than
panicking right now.
Release Notes:
- N/A
Michael Sloan
wannacu
Mikayla Maki
Michael SloanandThorsten Ball
Patrick MARIE
Fernando Tagawa
apricotbucket28
Conrad Irwin
aohanhongzhi
fsh
Owen Law
Keenan Wresch
