On Windows, GDI returns unintuitive names like "\\.\DISPLAY6" that
may not start numbered at either 0 or 1.
This commit grubs through the various APIs so that we can produce more
meaningful names like "DISPLAY6: Gigabyte M32u on NVIDIA 2080 TI"
instead.
This commit also makes the lua wezterm.window.screens() function
consistent with the internal resolve_geom functions that each different
implementation had, so that we can eliminate those functions in
favor of this new one on the ConnectionOps trait.
Still need to do macOS and verify that this commit doesn't break X11.
Currently implemented on X11 only, this function returns information
about the geometry of the screen(s).
This is taken from the same source of information we use for the
`--position` CLI argument to `wezterm start`.
```
> wezterm.window.screens()
{
"by_name": {
"DisplayPort-1": {
"height": 2160,
"name": "DisplayPort-1",
"width": 3840,
"x": 0,
"y": 0,
},
},
"main": {
"height": 2160,
"name": "DisplayPort-1",
"width": 3840,
"x": 0,
"y": 0,
},
"origin_x": 0,
"origin_y": 0,
"virtual_height": 2160,
"virtual_width": 3840,
}
```
This is a bit of an unsatisfactory commit... the bulk of it is
augmenting our calls into XCB to ensure that we check the status of each
request; the idea was that doing so would highlight the source of the
bad drawable error that is being surfaced in #2198, but after doing
that, it still doesn't highlight the offending call.
My conclusion is that either something in MESA/EGL or the IME is
generating calls that we cannot see into and that one of those is
referencing the window id that we just destroyed.
The resolution then is a bit gross: instead of destroying the window
when we need to close it, we first unmap it to remove it from the
screen, then after 2 seconds we destroy it.
refs: https://github.com/wez/wezterm/issues/2198
This commit adds more trace logging around selection
related events.
That tracing uncovered a situation, when multiple wezterm windows within
the same process were involved, where one window didn't receive a
selection-clear event notification.
Since Window::get_clipboard trusted our local understand of the
clipboard contents, it would return those until the selection was
changed in that window.
This commit changes that code to always ask the X server for the
selection. It makes pasting slightly slower, but should always produce
consistent results.
refs: https://github.com/wez/wezterm/issues/2110
deadkeys that are triggered through shift (eg: backtick on a German
layout) weren't working because we were trying to lookup in our maps
using `SHIFT | LEFT_SHIFT` when the map data was keyed only by `SHIFT`.
This commit removes the positional modifier flags from the modifier
keys and restores the correct behavior.
refs: https://github.com/wez/wezterm/issues/2102
This does two things:
* Sets the event queue owner explicitly to xcb
* Adopts a dri2 resize related workaround from the rust-xcb opengl
example
I think the latter is probably a NOP, but the former sounds like
something important.
refs: #1992
Adds a configuration option, `focus_change_repaint_delay` to allow customisation of the delay added in 9b6329b454.
The default delay remains 100ms, and can be disabled by setting it to `0`, if the workaround is not required on the user's system.
refs: #2063
refs: #1992
The hope here is that the nvidia-specific resize issue might have
a workaround if it is emitting some other events that we were
previously not listening for.
This commit optionally enables the Present extension and listens
for its version of CONFIGURE_NOTIFY, routing it through the same
logic as the base CONFIGURE_NOTIFY event.
On my AMD hardware under Gnome, I see something like:
```
18:04:26.476 TRACE window::os::x11::window > Present::ConfigureNotify: width 1168 -> 1180, height 858 -> 873, dpi 124.7998046875 -> 124.7998046875
18:04:26.478 TRACE window::os::x11::window > Ignoring X::ConfigureNotify (1180x873 dpi=124.7998046875) because width,height,dpi are unchanged
```
with the Present event firing before the X event.
Let's see how this goes.
refs: #2063
refs: #1992
Main idea here is to add expose events to the trace so that we
can get a sense of whether those are emitted when a WM isn't delivering
CONFIGURE_NOTIFY consistently.
If the exposed area is bigger than what we think the window is,
then we mark geometry as unsure.
I'm considering always marking as unsure for an expose event,
or at least, adding a config option to enable that, as a way
to workaround this situation.
refs: https://github.com/wez/wezterm/issues/2063
refs: https://github.com/wez/wezterm/issues/1992
This commit:
* Logs atom names in property change events (makes it easier to
understand user's logs)
* Sets flags in cases where property changes might imply that a
configure or focus event should have or should be sent
* Adjusts the "unsure about state" logic so that it doesn't just
trigger on the initial paint, but also on those flags being set
refs: https://github.com/wez/wezterm/issues/1992
I think this might only be a thing on Windows.
This commit speculatively (I'm on a mac at the moment!) allows tracking
the left/right control/shift modifier flags and passing that through
to the win32 input mode logic.
refs: https://github.com/wez/wezterm/issues/2009
Mutter recently started to enforce a protocol error that enforces
the ordering of buffer updates and that is flushing out some
bugs in various places; here's a related issue that I stumbled
into when I set my scaling to 300% and got stuck:
https://gitlab.gnome.org/GNOME/mutter/-/issues/2083
What that means to us is that we have to be careful when updating
the buffer scaling properties on our EGL surface.
We don't actually own the underlying buffer or the underlying
buffer commits, so we have to be a little indirect: what
we do here is detach the EGL managed buffer when we notice
that scaling has changed, and that appears to satisfy the
compositor.
refs: https://github.com/wez/wezterm/issues/1727
