* Bind the wp-viewporter and wp-fractional-scale-manager globals.
* Create a viewport and fractional-scale when instantiating a window.
* Add fractional-scale listener (that does nothing at the moment).
* Destroy everything on teardown.
When background alpha is changed at runtime (using OSC-11), we (may)
have to update the opaque hint we send to the compositor.
We must also update the subpixel mode used when rendering font
glyphs.
Why?
When the window is fully opaque, we use wl_surface_set_opaque_region()
on the entire surface, to hint to the compositor that it doesn’t have
to blend the window content with whatever is behind the
window. Obviously, if alpha is changed from opaque, to transparent (or
semi-transparent), that hint must be removed.
Sub-pixel mode is harder to explain, but in short, we can’t do
subpixel hinting with a (semi-)transparent background. Thus, similar
to the opaque hint, subpixel antialiasing must be enabled/disabled
when background alpha is changed.
Closes#1249
Note that it is still unclear whether ack:ing a configure event for an
unmapped surface is a protocol violation, or something that should be
handled by the compositor.
According to
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/108,
Kwin, Mutter and Weston handles it, while wlroots does not.
This pointer ends up being passed to various printf-family functions,
where passing a NULL pointer for an "%s" format specifier invokes
undefined behaviour.
If an output has a bogus physical width or height, the DPI can become
so high that the cell width/height is too large for
pixman_image_fill_rectangles(), resulting in a crash in pixman_fill().
Since it doesn’t make any sense to use a DPI that is obviously bogus,
don’t. Force it 96 instead.
When XDG activation support was added to URL mode, we introduced a
regression, where it is possible to flood the Wayland socket with XDG
activation token requests.
Start foot with “foot -o bell.urgency=yes”, then run:
while true; do echo -en ‘\a’; done
Finally, switch keyboard focus to another window. Foot crashes.
Throttle the token requests by limiting the number of outstanding
urgency token requests to 1.
Closes#1065
First, add a ‘token’ argument to spawn(). When non-NULL, spawn() will
set the ‘XDG_ACTIVATION_TOKEN’ environment variable in the forked
process. If DISPLAY is non-NULL, we also set DESKTOP_STARTUP_ID, for
compatibility with X11 applications. Note that failing to set either
of these environment variables are considered non-fatal - i.e. we
ignore failures.
Next, add a helper function, wayl_get_activation_token(), to generate
an XDG activation token, and call a user-provided callback when it’s
‘done (since token generation is asynchronous). This function takes an
optional ‘seat’ and ‘serial’ arguments - when both are non-NULL/zero,
we set the serial on the token. ‘win’ is a required argument, used to
set the surface on the token.
Re-write wayl_win_set_urgent() to use the new helper function.
Finally, rewrite activate_url() to first try to get an activation
token (and spawn the URL launcher in the token callback). If that
fails, or if we don’t have XDG activation support, spawn the URL
launcher immediately (like before this patch).
Closes#1058
The global config doesn’t necessarily reflect the correct
configuration to use - we should *always* use the current terminal
instance’s conf pointer.
* Move selection override modifier mask to the key_binding_set struct
* Always warn if XDG activation is unavailable, not just if
bell.urgent is set (we no longer have access to this information)
* Pass ‘bool presentation_timings’ as a parameter to wayl_init()
* Remove ‘presentation_timings’ member from the ‘terminal’ struct
Closes#932
Up until now, our Wayland seats have been tracking key bindings. This
makes sense, since the seat’s keymap determines how the key bindings
are resolved.
However, tying bindings to the seat/keymap alone isn’t enough, since
we also depend on the current configuration (i.e. user settings) when
resolving a key binding.
This means configurations that doesn’t match the wayland object’s
configuration, currently don’t resolve key bindings correctly. This
applies to footclients where the user has overridden key bindings on
the command line (e.g. --override key-bindings.foo=bar).
Thus, to correctly resolve key bindings, each set of key bindings must
be tied *both* to a seat/keymap, *and* a configuration.
This patch introduces a key-binding manager, with an API to
add/remove/lookup, and load/unload keymaps from sets of key bindings.
In the API, sets are tied to a seat and terminal instance, since this
makes the most sense (we need to instantiate, or incref a set whenever
a new terminal instance is created). Internally, the set is tied to a
seat and the terminal’s configuration.
Sets are *added* when a new seat is added, and when a new terminal
instance is created. Since there can only be one instance of each
seat, sets are always removed when a seat is removed.
Terminals on the other hand can re-use the same configuration (and
typically do). Thus, sets ref-count the configuration. In other words,
when instantiating a new terminal, we may not have to instantiate a
new set of key bindings, but can often be incref:ed instead.
Whenever the keymap changes on a seat, all key bindings sets
associated with that seat reloads (re-resolves) their key bindings.
Closes#931
Search mode and ‘flash’ (OSC-555) both achieves similar visual
effects: flash tints the entire window yellow, and search mode dims
it (except the search match).
But, they do so in completely different ways. Search mode is detected
in render_cell(), and the colors are then dimmed there.
Flash is implemented by blending a yellow, semi-transparent color on
top of the rendered grid.
This patch replaces those two implementations with a single one. We
add a new sub-surface, called the ‘overlay’. In normal mode, it’s
unmapped.
When either search mode, or flash, is enabled, we enable it, and
fill it with a semi-transparent color. Yellow for ‘flash’, and
“black” (i.e. no color) for search mode.
The compositor then blends it with the grid. Hopefully on the GPU,
meaning it’ll be faster than if we blend in software.
There are more performance benefits however. By using a separate
surface, we can do much better damage tracking.
The normal grid rendering code no longer have to care about neither
search mode, nor flash. Thus, we get rid of a couple of ‘if’
statements in render_cell(), which is nice. But more importantly, we
can drop full grid repaints in a couple of circumstances:
* Entering/exiting search mode
* Every frame while flash is active
Now, when rendering the search mode overlay, we do want to do some
damage tracking, also of the overlay.
This, since search mode doesn’t dim the *entire* window. The search
match is *not* dimmed. This is implemented by punching a hole in the
overlay sub-surface. That is, we make part of it *fully*
transparent. The basic idea is to set a clip region that excludes the
search match, and then dim the rest of the overlay.
It’s slightly more complicated than that however, if we want to reuse
the last frame’s overlay buffer (i.e we don’t want to re-render
the *entire* overlay every frame).
In short, we need to:
* Clear (punch hole) in areas that are part of this frame’s search
match, but not the last frame’s (since those parts are _already_
cleared).
* Dim the areas that were part of the last frame’s search match, but
aren’t anymore (the rest of the overlay should already be dimmed).
To do this, we save the last frame’s “holes” (as a pixman
region). Then, when rendering the next frame, we first calculate the
new frame’s “holes” region.
The region to clear is “this frame’s holes minus last frame’s holes”
The region to dim is “last frame’s holes minus this frames holes”.
Finally, we compute the bounding box of all modified cells by taking
the union of the two diff regions mentioned above. This allows us to
limit the buffer damage sent to the compositor.
We have a number of sub-surfaces for which we are *not* interrested in
pointer (or touch) input.
Up until now, we’ve manually dealt with these, by recognizing these
surfaces in all pointer events, and ignoring them.
But, lo and behold, there are better ways of doing this. By clearing
the subsurface’s input region, the compositor will do this for us -
when a pointer is outside a surface’s input region, the event is
passed to the next surface underneath it.
This is exactly what we want! Do this for all subsurfaces, *except*
the CSDs.
When the compositor is asking us to resize ourselves, take
our (visible) CSD borders into account. This is similar to how we
already take the titlebar size into account.
This fixes an issue where the window size “jumps” when the user starts
an interactive resize, when csd.border-width > 0.
This as been observed in GNOME.
In Sway-1.5, sway waits for configure ACKs from hidden windows when
views are being resized. I.e. if you have e.g. a stacked view, with
one or more windows currently not visible, and you resize the stack,
then sway will emit configure events to all windows, and then wait for
ACKs before rendering the resized view.
The problem with this is that sway also does **not** call frame
callbacks on hidden windows. So if we have rendered one frame, and
thus registered a frame callback, we’ll never render any more frames
until the window becomes visible again. Ergo, if you resize the view
interactively, only the first resize actually happens. After that, all
hidden views are “stuck”, causing ACK timeouts.
We worked around this in foot by preempting the frame
callback. I.e. destroying it, and rendering the frame anyway.
This has fixed in sway-1.6, and thus we can remove the workaround.
From the NOTES section of getenv(3):
The string pointed to by the return value of getenv() may be statically
allocated, and can be modified by a subsequent call to getenv()...
So, previously xcursor_theme could be modified by libc to contain
xcursor_size. This has been fixed by getting xcursor_theme after
computing the value of xcursor_size.
The compositor may offer version 4, while we’re still linked against
an old libwayland that does not implement version 4.
While we properly #ifdef the callbacks from version 4, we were still
requesting version 4 (if offered by the compositor), even when
compiled against a too old libwayland.
Closes#876
These are new in version 4 of the wl_output interface (first included
in wayland-1.20).
This allows us to get the name and description of the outputs, also on
compositors without the XDG output interface.
This makes us slightly more resilient against a missing XDG output
interface.
We use the “real” (the physical) dimensions, combined with the scaling
factor, to estimate the logical dimensions.
This works out correctly with non-fractional scaling, but not
otherwise.
If there aren’t any seats available, input is not possible (neither
keyboard nor mouse input).
Note that this is not the same thing as e.g. no keyboard being plugged
in. In this case, there will be a seat, but without the keybaord
capability. Input may not be possible _right now_, but may be later,
if the user plugs in a keyboard.
Closes#779
This is an application of the xdg activation protocol that will allow
compositors to associate new foot toplevels with the command that
launched them.
footclient receives an activation token from the launcher which the
compositor can use to track application startup. It passes the token
to the foot server, which then activates the new window with the token
to complete the startup sequence.
With dpi-aware=auto (the default), scale fonts using DPI *only*
if *all* available monitors have a scaling factor of one.
The idea is this: if a user, with multiple monitors, have enabled
scaling on *at least* one monitor, he/she has most likely done so to
match the size of his/hers other monitors.
For example, if the user has one monitor with a scaling factor of one,
and another one with a scaling factor of two, he/she expects things to
be twice as large on the second monitor.
If we (foot) scale using DPI on the first monitor, and using the
scaling factor on the second monitor, foot will *not* look twice as
big on the second monitor (this was the old behavior of
dpi-aware=auto).
Part of #714
If the call to fdm_wayl() with EPOLLHUP was followed by calls to
wayl_roundtrip(), foot would hang.
The reason for this is that the EPOLLHUP handler in fdm_wayl() would
call wl_display_cancel_read().
wayl_roundtrip() also calls wl_display_cancel_read() (since we
normally have called wl_display_prepare_read()), before calling
wl_display_roundtrip().
When calling wl_display_cancel_read() two times in a row, without a
wl_display_prepare_read() in between, wl_display_roundtrip() hangs.
Fix by not calling wl_display_cancel_read() in fdm_wayl(). This
ensures our invariant holds: wl_display_prepare_read() is *always* in
effect outside of fdm_wayl().
Closes#651
We still use the primary font, but use a custom size, based on the
title bar’s height.
This fixes an issue where the window title could be way too small, or
way too big. And changed size when the terminal font size was changed.
Up until now, *all* buffers have been tracked in a single, global
buffer list. We've used 'cookies' to separate buffers from different
contexts (so that shm_get_buffer() doesn't try to re-use e.g. a
search-box buffer for the main grid).
This patch refactors this, and completely removes the global
list.
Instead of cookies, we now use 'chains'. A chain tracks both the
properties to apply to newly created buffers (scrollable, number of
pixman instances to instantiate etc), as well as the instantiated
buffers themselves.
This means there's strictly speaking not much use for shm_fini()
anymore, since its up to the chain owner to call shm_chain_free(),
which will also purge all buffers.
However, since purging a buffer may be deferred, if the buffer is
owned by the compositor at the time of the call to shm_purge() or
shm_chain_free(), we still keep a global 'deferred' list, on to which
deferred buffers are pushed. shm_fini() iterates this list and
destroys the buffers _even_ if they are still owned by the
compositor. This only happens at program termination, and not when
destroying a terminal instance. I.e. closing a window in a “foot
--server” does *not* trigger this.
Each terminal instatiates a number of chains, and these chains are
destroyed when the terminal instance is destroyed. Note that some
buffers may be put on the deferred list, as mentioned above.
All SHM pixmap cookies depend on the terminal instance’s memory
address. Thus, after a terminal instance has been destroyed, shm
pixmaps that belonged to it will never be purged automatically.
CSDs aren’t typically toggled on and off. Thus, when disabled,
immediately purge their corresponding pixmap buffers, to free up some
memory, and release file descriptors.
Unlike other surface types, the SHM cookie depends on the address of
each URL instance. This means if we enable, disable, and then enable
URL mode again (thus showing exactly the same URLs as the first time),
the URLs will have new addresses, and thus the old SHM pixmaps will
not get purged automatically.
So, manually purge them when destroying the URLs.
* Set win->configure.csd_mode, not win->csd_mode. Otherwise our
‘configure’ handler will swap out the CSD_YES we set, for
CSD_UNKNOWN(?), resulting in no CSDs at all.
* Don’t instantiate the CSDs in wayl_win_init(), let the ‘configure’
event handler do that. Just like it does when we have a decoration
manager emitting decoration configure events.
The configure event asks the client to change its decoration
mode. The configured state should not be applied immediately.
Clients must send an ack_configure in response to this event.
See xdg_surface.configure and xdg_surface.ack_configure for
details.
In particular, ”the configured state should *not* be applied
immediately”.
Instead, treat CSD/SSD changes like all other window dimension related
changes: store the to-be mode in win->configure, and apply it in the
surface configure event.
This fixes an issue where foot incorrectly resized the window when the
server switched between CSD/SSD at run-time.
ayl_roundtrip() has the following code:
wl_display_roundtrip(wayl->display);
while (wl_display_prepare_read(wayl->display) != 0)
wl_display_dispatch_pending(wayl->display);
wayl_flush(wayl);
If the first wl_display_roundtrip() fails, for example because the
Wayland socket has been closed, we may get stuck in the while-loop.
This happens if the read queue isn’t empty, in which case
wl_display_prepare_read() will return -1 and we’ll continue trying to
dispatch the pending events forever, never succeeding since the socket
is gone.
Closes#542
