This is a bit of a switch-up, see this comment for more background:
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
This commit:
* Adds a pre-compiled mesa3d opengl32.dll replacement
* The mesa dll is deployed to `<appdir>/mesa/opengl32.dll` which by
default is ignored.
* When the frontend is set to `Software` then the `mesa` directory
is added to the dll search path, causing the llvmpipe renderer
to be enabled.
* The old software renderer implementation is available using the
`OldSoftware` frontend name
I'm not a huge fan of the subdirectory for the opengl32.dll, but
I couldn't get it to work under a different dll name; the code
thought that everything was initialized, but the window just rendered
a white rectangle.
If we've failed to initialize EGL, try setting `LIBGL_ALWAYS_SOFTWARE=true`
in the environment and make another pass at initialization in the hope
that it brings up something usable.
This commit only impacts linux systems at the time of writing.
I've made the line that logs the GL implementation information
have `error` level again, because it is more convenient for me
even if it isn't technically an error.
refs: https://github.com/wez/wezterm/issues/272
(but isn't the true fix; this is just trying to make the consequences
of that problem less. I would like to get that fixed correctly)
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
(which discusses what I think the end state should be)
This could be reproduced via `wezterm connect localhost`.
This bug was surfaced after the last release added a Drop impl
to cleanup the display.
This commit tracks the display in the connection.
closes: https://github.com/wez/wezterm/issues/252
This isn't a fix by any stretch of the imagination, but it stops
a crash. Should be good enough until I get a chance to fix this
properly.
refs: https://github.com/wez/wezterm/issues/252
This tidies up the valgrind output some more, but seems to highlight
some leaks in the egl implementation around init/shutdown.
I still don't see a smoking gun for a memory leak that grows over time.
refs: https://github.com/wez/wezterm/issues/238
When running on a 30bpp display with 2 bit alpha, eglChooseConfig
will match and list the 10bpc configuration first, which don't match
the desired pixel format.
Filter the config list so that it only includes 8bpc configurations.
refs: https://github.com/wez/wezterm/issues/240
In refs: https://github.com/wez/wezterm/issues/240 there are a number
of configurations that report 0 for the alpha size and where we are
unable to otherwise find a working config.
This is a speculative commit to releax the alpha channel size to
basically anything available and see if that helps.
This commit refactors the wayland EGL init code to call into the
non-wayland init code which is more in the spirit of DRY.
It also highlights that we were requesting PBUFFER and PIXMAP capable
contexts in the non-wayland case. Since we appear to survive without
those in the wayland renderer, presumably we can survive without them
in all cases.
This may help with activating opengl for this issue:
refs: https://github.com/wez/wezterm/issues/240
While looking into what it might take to support 10bpc (30bpp) displays
(https://github.com/wez/wezterm/issues/240) I was experimenting with
Xephyr at a reduced 16bpp depth and noticed that the server still
offered a 32bpp TrueColor depth option.
This commit adjusts the window/bitmap code to allow it to select depths
24bpp or 32bpp, preferring the largest depth. we restrict ourselves to
24 and 32 bit selections for this, as those appear to be bit for bit
compatible for the r/g/b channels. I suspect that 10bpc will require
some scaling somewhere.
This change allows running wezterm against the reduced depth Xephyr, but
since Xephyr doesn't support GL it runs with the software renderer; I
don't know quite how opengl is going to play with this. I can confirm
that running wezterm on my native 24bpp display when it picks a 32bpp
visual does run with opengl enabled, so maybe this is good enough?
8f1f1a65ea added support for probing
for opengl extensions, and I thought that I had the fallback covered
but it turned out that we were only falling back if one of the major
extensions wasn't present.
This commit adds a fallback for the case where things look ok at
first glance, but where they fail at runtime for whatever reason.
refs: https://github.com/wez/wezterm/issues/235
With this commit, we now survive a reinstall or upgrade of the nvidia
drivers on my Windows sytem without crashing.
This commit allows notifying the application of the context loss
so the application can either try to reinit opengl or open a new
window as a replacement and init opengl there.
I've not had success at reinitializing opengl after a driver upgrade;
it seems to be persistently stuck in a state where it fails to allocate
a vertex buffer.
SO, the state we have now is that we try to reinit opengl on a new
window, and if that fails, leave it set to the software renderer.
This isn't a perfect UX, but it is better than terminating!
refs: https://github.com/wez/wezterm/issues/156
I don't have a great way to test this on those platforms,
so other than compiling and running and verifying that things
work normally, I'm not sure if this is sufficient!
This commit allows distinguishing between left and right alt
modifiers at the window layer. So far only macos provides
this additional information.
Expand the logic that decides whether Alt should emit the
composed key or act as the raw key with the Alt modifier flag
set so that we can set that behavior separately for the left
and right modifiers on systems that support it, and use the
existing config for systems that don't support it.
The default settings for these flags is that Left Alt will
send the uncomposed key + Alt modifier while the Right Alt
will behave more like AltGr (which is typically on the RHS
of the keyboard) and send the composed key.
This gives more flexibility by default and hopefully matches
expectations a bit better.
refs: https://github.com/wez/wezterm/issues/216
The goal at the window layer is to preserve enough useful information
for other layers. In this specific circumstance on macos we'd like
to be able know both that eg: ALT-1 was pressed and that ALT-1 composes
to a different unmodified sequence and then allow the user's key
binding assignment to potentially match on both.
We sort of allowed for this, but didn't separate out the modifier keys.
This commit adds a `raw_modifiers` concept to the underlying event
struct so that we can carry both the raw key and modifier information
as well as the composed key and modifier information.
In the scenario above, we want the raw key/modifier tuple to be ALT-1
but the composed key/modifier to be eg: unmodified `¡` in my english
keymap.
refs: https://github.com/wez/wezterm/issues/158
Adds some detection to see if the active keyboard layout has
AltGr, and if so, adjust our key mapping logic to accomodate it.
With this change, when using an ENG layout, I can use either left
or right alt-b/alt-f to move through words in wsl. When I switch
to DEU my left alt is still alt and my right alt causes the
Windows On-Screen keyboard to act as though AltGr is pressed.
I can then use the On-Screen keyboard to press the `<` key which
is to the left of the `Z` key on a German layout and have it produce
the `|` character.
refs: https://github.com/wez/wezterm/issues/185
We switched to using clipboard because of problems under XWayland.
These days we have much better native Wayland support and folks
should use that.
Test plan:
In one window:
```
echo "clipboard" | xclip -i -selection clipboard; echo "primary" | xclip -i -selection primary;
```
then start `wezterm` and press shfit-insert.
Prior to this change we'd always print `clipboard`.
After this change we'll print `primary`.
However, if you run:
```
WEZTERM_X11_PREFER_CLIPBOARD_OVER_PRIMARY=1 wezterm
```
then we'll use the old `clipboard` behavior.
Teach the window layer about window icons and implement the
plumbing for this on X11.
For Wayland there is no direct way to specify the icon; instead
the application ID is used to locate an appropriate .desktop filename.
We set the app id from the classname but that didn't match the installed
name for our desktop file which is namespaced under my domain, so change
the window class to match that and enable the window icon on Wayland.
refs: https://github.com/wez/wezterm/issues/172#issuecomment-619938047
@kalgynirae showed me weirdly laggy behavior when moving the mouse
in front of his x11 window. My suspicion was that this is somehow
related to updating the mouse cursor glyph, and looking at this code
there were two things that might influence this:
* We weren't saving the newly applied cursor value, so we'd create
a new cursor every time the mouse moved (doh!)
* We'd create a new cursor id each time it changed, and then destroy it
(which isn't that bad, but if it contributes to lag, maybe it is?)
This commit addresses both of these by making a little cache map
from cursor type to cursor id.
I can't observe a difference on my system, so I wonder if this might
also be partially related to graphics drivers and hardware/software
cursors?
Hiding a window is implemented as miniaturizing the window, which
is typically shown with an animation of the window moving into the
dock.
This is not the same as the application-wide hide function in macOS;
that function hides the entire app with no animation. We don't use
that here because our Hide function is defined as a window operation
and not an application operation.
refs: https://github.com/wez/wezterm/issues/150
The opengl based render first clears the window to the background
color and then renders the cells over the top.
on macOS I noticed a weird lighter strip to the bottom and right of
the window and ran it down to the initial clear: our colors are SRGB
rather than plain RGB and the discrepancy from rendering SRGB as RGB
results in the color being made a brighter shade. This was less
noticeable for black backgrounds.
Remove a normalizing function that made assumptions based on the
keycaps that did not hold up when selecting Dvorak as an input
source. For example "CTRL-C" where `C` is the key with the C keycap
would send `CTRL-C` even when Dvorak was selected; it should send CTRL-J
in that layout.
I think with the other normalization that happens in the termwindow
layer we don't need this function any more.
The default values are 3 lines. With this change, scrolling speed now seems
similar to other programs like cmd.exe. Before this change it feels too slow.
I noticed my trackpoint or touchpad reports a lot of < 120 (WHEEL_DELTA) events.
They shouldn't be ignored.
Also https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel says:
> The wheel rotation will be a multiple of WHEEL_DELTA, which is set at 120.
> This is the threshold for action to be taken, and one such action (for
> example, scrolling one increment) should occur for each delta.
>
> The delta was set to 120 to allow Microsoft or other vendors to build
> finer-resolution wheels (a freely-rotating wheel with no notches) to send
> more messages per rotation, but with a smaller value in each message. To use
> this feature, you can either add the incoming delta values until WHEEL_DELTA
> is reached (so for a delta-rotation you get the same response), or scroll
> partial lines in response to the more frequent messages. You can also choose
> your scroll granularity and accumulate deltas until it is reached.
macos generates fractional distance values for the mouse wheel,
with one tick starting at 0.1. We were truncating this to a 0 row
move, which meant that you'd need to build up some acceleration to
move the rows when all you really wanted was a single tick.
This commit changes things so that we round up to at least 1.0 in this
situation.
The IME stuff on macos tends to swallow repeats for some keys.
Ugh. So this commit adds an option to disable the use of the IME.
Switching away from it effectively inverts the meanging of backspace
and delete (because our method is no longer called by the IME), so
we need to check for that and remap it. Ugh.
Ugh.
double clicks weren't registering correctly with the new selection
logic. Tell windows that we're doing all our own click counting
and simplify the logic.
Force using xcb-util 0.2.1 precisely because 0.2.2 pulls in a
conflicting major version of xcb (0.8 -> 0.9).
It's a non-trivial upgrade: the types around xkb are different
and features need to be specified in the manifest to enable compilation
of the things that we depend upon.
In addition, xkbdcommon, on which we depend, requires xcb 0.8 and
results in pulling in two conflicting versions of the crates.
It's a bit of a painful situation and will require some effort to
figure out how to upgrade the xcb dependency, when we're ready for that.
refs: https://github.com/meh/rust-xcb-util/issues/12
On x11 we'd get just a single line per scroll wheel tick.
Contrast with Wayland where we get multiple.
This config change makes us feel more snappy by default on X11.
I'd like to make this configurable using the live configuration
infra, but we don't currently have a way for this crate to see
that config, so this just changes the default to be "better".
refs: https://github.com/wez/wezterm/issues/92
This reverts commit bfa8d0c207,
which proved not to be needed because it was already covered
by the `KeyboardEvent::Enter` and `KeyboardEvent::Leave` handling.
On a Fedora 31 system running Wayland I noticed that wezterm and
the compositor were running pretty hot on their respective CPU
cores.
It turned out that we had a lot of
[Refresh](https://docs.rs/smithay-client-toolkit/0.6.4/smithay_client_toolkit/window/enum.Event.html#variant.Refresh)
events being generated and consumed. We were treating this as needing
a full paint so we'd be effectively continually running the opengl
paint cycle over and over.
The docs for that event say that it is intended to refresh the client
decorations so let's focus it towards that instead. This does bring
the CPU usage back down to intended levels.
I believe this hot CPU usage to be compositor-dependent: this is the
first I've seen of it out of 4 different Wayland environments!
1f81a064ed added support for noticing
that the dpi scale was not 1 on startup, but the timing of this
signal was different between the opengl and software renderers.
When using the software renderer, we'd end up computing a scaling
change with a pre-change pixel size but adjusted by a post-post
scaling factor, and that effectively caused the window to halve
its size on startup.
This commit improves things by also tracking the dpi in our locally
stored dimensions.
@sunshowers mentioned to me that the window appeared blurry on a hidpi
display on startup, and was fixed by changing focus in a tiling window
manager.
I could replicate this using weston with scaling set to 2; the issue was
that the initial scale factor change event wasn't fully propagated and
bubbled up as a resize event to the terminal layer.
This commit taps into the dpi change event and forces it to be
interpreted as a window configuration change, resulting in more crisp
text.
Adds the ability to specify `--font-shaper Allsorts` and use that
for metrics and shaping.
It is sufficient to expand things like ligatures, but there's something
slightly off about how the metrics are computed and they differ slightly
from the freetype renderer, which leads to some artifacts when rendering
with opengl.
One of my tests is to `grep message src/main.rs` to pull out the line
that has a selection of emoji. The heart emoji is missing from that
line currently.
Refs: https://github.com/wez/wezterm/issues/66
I noticed that we were relatively undersized for newly created
windows; there were two problems:
1. We weren't propagating the old rows and cols counts through
to the speculative resize.
2. The speculative resize wasn't implemented on wayland, and
needs a surprising amout of work to actually make the resize
take effect.
