1
1
mirror of https://github.com/wez/wezterm.git synced 2024-12-18 19:01:36 +03:00
Commit Graph

284 Commits

Author SHA1 Message Date
Wez Furlong
dddf67e07a egl: add explicit drop impl for GlState
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
2020-07-13 09:36:37 -07:00
Wez Furlong
888cded0e3 x11: remove Rc cycle between XConnection, Window, bitmaps
refs: https://github.com/wez/wezterm/issues/238

It's not a smoking gun, but helps clean up the valgrind output
2020-07-13 09:00:00 -07:00
Wez Furlong
4cd4ee2eb5 egl: revise how we report egl init errors 2020-07-13 08:02:19 -07:00
Wez Furlong
30f0e5b2c1 egl: look for exactly 8bpc configurations
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
2020-07-11 13:29:05 -07:00
Wez Furlong
68a91835ee window: egl: speculatively relax min alpha size
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.
2020-07-09 17:47:38 -07:00
Wez Furlong
1e50493b84 window: x11: fix minor leak of a display connection
These were two separate one-time losses.

refs: https://github.com/wez/wezterm/issues/238
2020-07-08 09:16:43 -07:00
Wez Furlong
95a52fb661 window: egl: log available, matching configurations
Hopefully this can shed some light on why we're not matching any configs
in refs: https://github.com/wez/wezterm/issues/240
2020-07-07 08:59:44 -07:00
Wez Furlong
793af71592 egl: relax context creation requirements
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
2020-07-06 07:49:02 -07:00
Wez Furlong
627a1c6c1b x11: improve support for non-24bpp displays
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?
2020-07-05 11:10:18 -07:00
Wez Furlong
ab1e83c7eb window: fallback to basic opengl context if extensions fail
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
2020-06-29 18:05:43 -07:00
Wez Furlong
8f1f1a65ea window: handle opengl context loss on windows.
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
2020-06-16 21:17:48 -07:00
Wez Furlong
ff32dc727f window: allow opengl reinit on context loss on macos
Again, I haven't seen a case where this triggers, but this compiles
and works in the normal case.
2020-06-15 12:33:52 -07:00
Wez Furlong
6744a0235d window: fixup tests for opengl init changes 2020-06-15 12:33:30 -07:00
Wez Furlong
aa93008935 window: allow re-initializing opengl for X11 and Wayland
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!
2020-06-15 09:03:16 -07:00
Wez Furlong
500e404db4 window: move opengl post-init to a callback on the trait
This allows potentially automatically re-initializing the
state if the context is lost.
2020-06-14 21:47:40 -07:00
Wez Furlong
90fa968a34 window: glium and gl_generator version bump 2020-06-14 21:24:54 -07:00
Wez Furlong
2803e8fc58 wezterm: improve left vs right alt behavior on macos
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
2020-06-13 22:45:13 -07:00
Wez Furlong
e70a58e7f3 cargo update 2020-06-13 10:21:49 -07:00
Wez Furlong
9395fd3465 window: remove unused feature from cargo.toml 2020-06-12 18:14:15 -07:00
Wez Furlong
542fede5a5 window: update smithay-client-toolkit 2020-06-06 11:58:38 -07:00
Wez Furlong
9ff9bf15fd window: allow for stronger separation between raw and composed keys
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
2020-05-28 19:35:50 -07:00
Wez Furlong
ed1450326d window: Windows: dos->unix line endings when fetching clipboard 2020-05-22 18:22:33 -07:00
Wez Furlong
a9d1429888 window: allow specifying the clipboard context when getting clipboard
refs: https://github.com/wez/wezterm/issues/183
2020-05-21 08:46:16 -07:00
Wez Furlong
7ddff705a4 window: Windows: improve AltGr handling
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
2020-05-20 20:35:04 -07:00
Wez Furlong
a92b33c727 Revert "window: default to reading the PRIMARY selection under X11"
This reverts commit 5ebdcc3642.

It turns out not to be desirable, so lets back it out and think up
a different way to satisfy this.
2020-05-16 15:55:20 -07:00
Wez Furlong
5ebdcc3642 window: default to reading the PRIMARY selection under X11
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.
2020-05-16 11:53:42 -07:00
Wez Furlong
538ce5e110 window: fix shift-tab processing on X11
This was being silently swallowed.  For some reason shift-tab generates
ISO Left Tab rather than regular Tab and we weren't mapping that.
2020-05-16 08:35:25 -07:00
Wez Furlong
d3cb27129c upgrade to latest smithay client toolkit
This version greatly improves the client side decoration handling
under Wayland and allows rendering the window title in the titlebar
(shocker!).
2020-05-03 10:31:30 -07:00
Wez Furlong
14c73f7122 window: linux: set window icon
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
2020-05-02 12:07:34 -07:00
Wez Furlong
8511bda6cf window: Adjust some debug logging
https://github.com/wez/wezterm/issues/172#issuecomment-619935565
interpreted these as errors but they're really just informational
messages.
2020-05-02 09:32:08 -07:00
Wez Furlong
73c0c02ffb window: x11: adjust log level for a debug print 2020-03-08 08:40:46 -07:00
Wez Furlong
8cd029ae63 wayland: remove a debug print 2020-02-26 23:21:59 -08:00
Wez Furlong
7e714a5ca1 x11: avoid changing the mouse cursor glyph on each move
@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?
2020-02-21 09:10:13 -08:00
Wez Furlong
bc6cf6eed6 fix typo in some debug 2020-02-16 09:32:22 -08:00
Wez Furlong
754f8166b5 Add HideApplication and QuitApplication key assignments
```
[[keys]]
key = "q"
mods = "CMD"
action = "QuitApplication"
```

refs: https://github.com/wez/wezterm/issues/150
2020-02-14 08:49:15 -08:00
Wez Furlong
da6783bbd0 macos: implement Hide function
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
2020-02-12 22:04:10 -08:00
Wez Furlong
02ace26e0a macos: Fix an issue with chorded keys in norwegian keymap
fixes: https://github.com/wez/wezterm/issues/151
2020-02-12 18:36:05 -08:00
Wez Furlong
c778307b0e macos: fix light background/border
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.
2020-01-26 19:04:34 -08:00
Wez Furlong
85c70aebb7 macos: improve support for dvorak
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.
2020-01-26 18:13:16 -08:00
Wez Furlong
f3e42c3d2a point to local filedescriptor crate 2020-01-26 09:15:24 -08:00
Wez Furlong
e67022344f remove a debug print 2020-01-25 23:20:01 -08:00
Jun Wu
511fc55b10 Respect wheel scrolling speed settings on Windows
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.
2020-01-20 15:18:33 -08:00
Jun Wu
ff6ff649af Make mouse wheel scroll smooth on Windows
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.
2020-01-20 15:17:44 -08:00
Wez Furlong
dc0573457c windows: fix compilation for 32-bit target
The CI shouldn't be trying to build this, but this is what was blocking
its builds on windows.
2020-01-17 10:12:25 -08:00
Wez Furlong
2eed9d67f4 fixup windows build 2020-01-17 09:23:30 -08:00
Wez Furlong
55e1cceb87 remove more Executors 2020-01-16 23:27:54 -08:00
Wez Furlong
75eb16bec4 move spawn_task into a new promise::spawn module 2020-01-16 03:50:48 -08:00
Wez Furlong
ac3ccab1c5 window: adopt async_task for spawn_task 2020-01-16 01:31:28 -08:00
Wez Furlong
256b4e6da8 fix pollable_channel to be non-blocking on Windows
Upgrade filedescriptor to 0.7 to use the portable helper for
setting non-blocking mode, and enable non-blocking mode on Windows.
2020-01-15 21:30:14 -08:00
Wez Furlong
ad2f724416 bump some versions 2020-01-09 22:39:34 -08:00