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
