Add support for the new xdg-toplevel-tag-v1 Wayland protocol, by
exposing a new config option, `toplevel-tag`, and a corresponding
command option, `--toplevel-tag` (in both `foot` and `footclient`).
This can help the compositor with session management, or custom window
rules.
Closes#2212
The version bump was done since we now use XKB_VMOD_NAME_*; macros
added in libxkbcommon 1.8.0.
Not all distros have updated libxkbcommon yet (read: Debian). Since
it's fairly easy to work around, let's do that.
Closes#2103
This adds supports for 16-bit surfaces, using the new
PIXMAN_a16b16g16r16 buffer format. This maps to
WL_SHM_FORMAT_ABGR16161616 (little-endian).
Use the new 16-bit surfaces by default, when
gamma-correct-blending=yes.
d3f692990e moved emoji-variation-sequences.h header inclusion from
vt.c to terminal.c. these two files are part of different libraries
hence target for generating emoji-variation-sequences.h needs to be
moved too.
Trying to build with an older libxkbcommon fails as follow:
```
../input.c: In function ‘keyboard_keymap’:
../input.c:648:82: error: ‘XKB_VMOD_NAME_ALT’ undeclared (first use in this function); did you mean ‘XKB_MOD_NAME_ALT’?
648 | xkb_mod_index_t alt = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_ALT);
| ^~~~~~~~~~~~~~~~~
| XKB_MOD_NAME_ALT
../input.c:648:82: note: each undeclared identifier is reported only once for each function it appears in
../input.c:649:83: error: ‘XKB_VMOD_NAME_META’ undeclared (first use in this function); did you mean XKB_MOD_NAME_ALT’?
649 | xkb_mod_index_t meta = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_META);
| ^~~~~~~~~~~~~~~~~~
| XKB_MOD_NAME_ALT
../input.c:650:84: error: ‘XKB_VMOD_NAME_SUPER’ undeclared (first use in this function); did you mean ‘XKB_MOD_NAME_NUM’?
650 | xkb_mod_index_t super = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_SUPER);
| ^~~~~~~~~~~~~~~~~~~
| XKB_MOD_NAME_NUM
../input.c:651:84: error: ‘XKB_VMOD_NAME_HYPER’ undeclared (first use in this function); did you mean ‘XKB_MOD_NAME_CAPS’?
651 | xkb_mod_index_t hyper = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_HYPER);
| ^~~~~~~~~~~~~~~~~~~
| XKB_MOD_NAME_CAPS
../input.c:652:87: error: ‘XKB_VMOD_NAME_NUM’ undeclared (first use in this function); did you mean ‘XKB_MOD_NAME_NUM’?
652 | xkb_mod_index_t num_lock = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_NUM);
| ^~~~~~~~~~~~~~~~~
| XKB_MOD_NAME_NUM
../input.c:653:90: error: ‘XKB_VMOD_NAME_SCROLL’ undeclared (first use in this function); did you mean ‘XKB_LED_NAME_SCROLL’?
653 | xkb_mod_index_t scroll_lock = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_SCROLL);
| ^~~~~~~~~~~~~~~~~~~~
| XKB_LED_NAME_SCROLL
../input.c:654:90: error: ‘XKB_VMOD_NAME_LEVEL3’ undeclared (first use in this function); did you mean ‘XKB_MOD_NAME_CTRL’?
654 | xkb_mod_index_t level_three = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_LEVEL3);
| ^~~~~~~~~~~~~~~~~~~~
| XKB_MOD_NAME_CTRL
../input.c:655:89: error: ‘XKB_VMOD_NAME_LEVEL5’ undeclared (first use in this function); did you mean ‘XKB_MOD_NAME_CTRL’?
655 | xkb_mod_index_t level_five = xkb_keymap_mod_get_index(seat->kbd.xkb_keymap, XKB_VMOD_NAME_LEVEL5);
| ^~~~~~~~~~~~~~~~~~~~
| XKB_MOD_NAME_CTRL
```
otherwise, depending on ninja dependency resolution order and parallel
build, srgb.h may not be built in time
Fixes: ccf625b991 ("render: gamma-correct blending")
Update tweak.scaling-filter to recognize the new scaling filters added
in fcft-3.3.0.
Since fcft_set_scaling_filter() is deprecated in 3.3.0, don't use it
anymore, and set the scaling filter via fcft_font_options instead.
This implements gamma-correct blending, which mainly affects font
rendering.
The implementation requires compile-time availability of the new
color-management protocol (available in wayland-protocols >= 1.41),
and run-time support for the same in the compositor (specifically, the
EXT_LINEAR TF function and sRGB primaries).
How it works: all colors are decoded from sRGB to linear (using a
lookup table, generated in the exact same way pixman generates it's
internal conversion tables) before being used by pixman. The resulting
image buffer is thus in decoded/linear format. We use the
color-management protocol to inform the compositor of this, by tagging
the wayland surfaces with the 'ext_linear' image attribute.
Sixes: all colors are sRGB internally, and decoded to linear before
being used in any sixels. Thus, the image buffers will contain linear
colors. This is important, since otherwise there would be a
decode/encode penalty every time a sixel is blended to the grid.
Emojis: we require fcft >= 3.2, which adds support for sRGB decoding
color glyphs. Meaning, the emoji pixman surfaces can be blended
directly to the grid, just like sixels.
Gamma-correct blending is enabled by default *when the compositor
supports it*. There's a new option to explicitly enable/disable it:
gamma-correct-blending=no|yes. If set to 'yes', and the compositor
does not implement the required color-management features, warning
logs are emitted.
There's a loss of precision when storing linear pixels in 8-bit
channels. For this reason, this patch also adds supports for 10-bit
surfaces. For now, this is disabled by default since such surfaces
only have 2 bits for alpha. It can be enabled with
tweak.surface-bit-depth=10-bit.
Perhaps, in the future, we can enable it by default if:
* gamma-correct blending is enabled
* the user has not enabled a transparent background
From the release notes:
system bell - allowing e.g. terminal emulators to hand off system
bell alerts to the compositor for among other things accessibility
purposes
The new protocol is used when the new config option
bell.system=yes (and the compositor implements the protocol,
obviously).
The system bell is rung independent of whether the foot window has
keyboard focus or not (thus relying on compositor configuration to
determine whether anything should be done or not in response to the
bell).
The new option is enabled by default.
Summary of changes:
* Make xvsnprintf() static
* restrict-qualify pointer arguments (as done by the libc equivalents)
* Make comments and spec references more thorough
* Remove pointless `n <= INT_MAX` assertion (see comment)
* Use FATAL_ERROR() instead of xassert() (since the assertion is inside
a shared util function but the caller is responsible for ensuring the
condition holds true)
* Change some callers to use size_t instead of int for the return value
(negative returns are impossible and all subsequent uses are size_t)
The updated comments and code were taken (and adapted) from:
49260bb154/src/util/xsnprintf.c (L6-50)
This work was entirely authored by me and I hereby license this
contribution under the MIT license (stated explicitly, so that
there's no ambiguity w.r.t. the original license).
That is, skip the reverse DNS naming scheme suggested by the .desktop
specification, and directly match our app-ids ("foot", and
"footclient").
This simplifies .desktop -> window instance mapping, allowing DEs to
match the filenames directly, without having to look at the
StartupWMClass key in the .desktop files.
These are the original names of the .desktop files. There were
renamed (to use the reverse DNS syntax) to please the flathub people,
who *required* this scheme to accept the foot package.
But, since:
* We don't package foot ourselves
* We don't go out of our way to support non-distro packaging schemes
* Flathub still hasn't merged the foot PR (it's now 2 years old)
* There are no know issues in any known DE that prevents a non-reverse
DNS .desktop filename from working
* There are plenty of other applications that doesn't use reverse DNS
names (a very clear majority, in my case)
Let's just revert back to the simpler naming scheme.
Closes#1607
The back-reference to 'tokenize.c' in the parent directory causes PGO
build failures, where gcc can't find the PGO data. Likely due to
path/naming issues caused by meson's generated build directories.
At compile time, build a lookup table from the Unicode data file
'emoji-variation-sequences.txt'.
At run-time, when we detect a VS-15/16 sequence, do a lookup in this
table, and enforce the variation selector iff the sequence is valid.
Closes#1742
The unicode-mode, and flash overlays are single color buffers. This
means we can use the single-pixel buffer protocol.
It's undefined whether the compositor will release the buffer or not;
to make things easier, simply destroy the buffer as soon as we've
committed it.
Note that since compositors don't necessarily release single-pixel
buffers, we can't plug them into our own buffer interface. This means
we can't use buffer pointers to check if we can re-use the previous
buffer (i.e. we can skip comitting a new buffer), or if we have to
create a new one.
It's _almost_ enough to just check if the last overlay style is the
same as the current one. Except that that doesn't take window resizes
into account...
