Re: Full-motion zero-copy screen capture in Weston

[Marius Vlad]

Hi,

Note that systemd-udev will not work in a container. That usually
has the side effect of libinput not working either.

On Tue, Jun 04, 2024 at 08:33:48PM +, Hoosier, Matt wrote:
> Tactical question: I somehow missed until this point that the remote and 
> pipewire plugins will only run if the DRM backend is being used.
> 
> But the DRM backend *really* doesn't want to start nowadays unless you're 
> running on a system with seatd and/or logind available. Toolbox [1] is the de 
> facto way to develop on bleeding edge copies of components these days. But it 
> logind and seatd aren't exposed into it.
> 
> How do Weston people interactively develop on the Weston DRM backend nowadays?
With either seatd or logind. I suspect people use containers to build
but run it on the device.

> 
> [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
> 
> > -Original Message-
> > From: Pekka Paalanen 
> > Sent: Tuesday, June 4, 2024 3:20 AM
> > To: Hoosier, Matt 
> > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad
> > ; wayland-devel@lists.freedesktop.org
> > Subject: Re: Full-motion zero-copy screen capture in Weston
> > 
> > On Mon, 3 Jun 2024 17:57:18 +
> > "Hoosier, Matt"  wrote:
> > 
> > > > What do you mean you can capture all virtual machines with KMS
> > > > writeback?
> > > >
> > > > What's the architecture there? How do virtual machines access KMS
> > > > hardware? Why would Weston be able to capture their outputs at all?
> > > >
> > >
> > > I hope to have more to say about this shortly.
> > 
> > I'm interested because I worry whether it will work. I don't see how it 
> > could
> > work with the traditional display controllers and DRM drivers.
> > 
> > Maybe some kind of hardware assisted plane "leasing" that works around the
> > DRM KMS software model limitations?
> > 
> > > > The disadvantage is that buffer allocations are accounted to the
> > > > compositor (which can manage its own memory consumption, sure), and
> > > > either the compositor allocates a new buffer for every frame
> > > > (possibly serious overhead) or it needs to wait for all consumers to
> > > > tell that they are done with the buffer before it can be used again.
> > > > Clients might hold on to the buffer indefinitely or just a little
> > > > too long, which is the risk.
> > >
> > > It seems to me this would be a risk of the existing Pipewire backend,
> > > no? At least, if I understood the buffering model of the dmabuf MR
> > > that Marius linked earlier.
> > >
> > 
> > I haven't looked at any of that, so I can't say. I don't know if pipewire 
> > is only
> > allocate-send-forget, or does it include consumers signalling they are done 
> > to
> > allow re-use as well. Or maybe the sources trust that rotating N buffers is
> > always enough, and if a sink needs the data for longer, it will make a copy 
> > in
> > time.
> > 
> > It's a trade-off. Sometimes the overhead of allocate-send-forget with the 
> > risk
> > of OOM (KMS writeback might require a specific type of memory that could be
> > scarce), maybe even with an added copy to avoid exhausting writeback-
> > capable memory, may be justified.
> > 
> > 
> > Thanks,
> > pq


signature.asc
Description: PGP signature

Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)

[Pekka Paalanen]

On Tue, 4 Jun 2024 20:33:48 +
"Hoosier, Matt"  wrote:

> Tactical question: I somehow missed until this point that the remote
> and pipewire plugins will only run if the DRM backend is being used.
> 
> But the DRM backend *really* doesn't want to start nowadays unless
> you're running on a system with seatd and/or logind available.
> Toolbox [1] is the de facto way to develop on bleeding edge copies of
> components these days. But it logind and seatd aren't exposed into it.
> 
> How do Weston people interactively develop on the Weston DRM backend
> nowadays?
> 
> [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/

Hi Matt,

I'm doing it old-school on my workstation, without any containers. What
dependencies my distribution does not provide, I build and install
manually into a prefix under $HOME:

https://www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/

The "clean and reliable" is probably outdated in this era of
containers...

There is also 'meson devenv', but since I need multiple manually built
projects in the same session, I haven't really looked into how to make
that work for me.

https://mesonbuild.com/Commands.html#devenv

When launching Weston, I have two different cases. Both need
my prefix installed environment as in the blog post.

- When I want to run on the same gfx card as my desktop, I VT-switch to
  a text mode login, log in, enter the environment, and simply run
  'weston'. This gets input and output devices from logind.

- When I want to run on my dedicated testing gfx card (no desktop
  there), I do it from a terminal window from my normal desktop: enter
  the environment, and run 'SEATD_VTBOUND=0 weston -Bdrm-backend.so
  --seat=seat-insecure -i0'. This requires prior setup:

  
https://wayland.pages.freedesktop.org/weston/toc/running-weston.html#running-weston-on-a-different-seat-on-a-stand-alone-back-end

  It uses libseat's built-in backend, so no seatd and no logind. The
  prior setup gives my user direct access to the necessary device
  nodes. I have a separate monitor, keyboard and mouse reserved for
  this.


Thanks,
pq


pgpi5sye1gU6b.pgp
Description: OpenPGP digital signature

Re: [RFC PATCH v4 00/42] Color Pipeline API w/ VKMS

[Melissa Wen]

On 02/26, Harry Wentland wrote:
> This is an RFC set for a color pipeline API, along with a sample
> implementation in VKMS. All the key API bits are here. VKMS now
> supports two named transfer function colorops and two matrix
> colorops. We have IGT tests that check all four of these colorops
> with a pixel-by-pixel comparison that checks that these colorops
> do what we expect them to do with a +/- 1 8 bpc code point margin.
> 
> The big new change with v4 is the addition of an amdgpu color
> pipeline, for all AMD GPUs with DCN 3 and newer. Amdgpu now support
> the following:
> 
> 1. 1D Curve EOTF
> 2. 3x4 CTM
> 3. Multiplier
> 4. 1D Curve Inverse EOTF
> 5. 1D LUT
> 6. 1D Curve EOTF
> 7. 1D LUT
> 
> The supported curves for the 1D Curve type are:
> - sRGB EOTF and its inverse
> - PQ EOTF, scaled to [0.0, 125.0] and its inverse
> - BT.2020/BT.709 OETF and its inverse

So, as we talked in the 2024 Linux Display Next Hackfest, I hacked
`drm_info` to show the KMS color pipeline properties. You can find the
experimental-and-ugly code here:
- https://gitlab.freedesktop.org/mwen/drm_info/-/merge_requests/1
It depends on updating libdrm [1] and you will only see something if you
use a custom kernel with this series applied.

After checking the output, I missed a kind of Default or "Identity"
curve for the `CURVE_1D_TYPE` enum. I understand that if the color
operation is set bypass, we can ignore all property values, but I didn't
find a similar approach on plane properties, so it looks weird to me:

└───"CURVE_1D_TYPE" (atomic): enum {sRGB Inverse EOTF, BT.2020 OETF, PQ 125 
Inverse EOTF} = invalid (0)

Another thing that caught my attention was the size property for 1D
Curve Custom LUT, that I expected a similar setup to CRTC 1D LUTs:

└───"GAMMA_LUT_SIZE" (immutable): range [0, UINT32_MAX] = 4096

But I got:

├───"SIZE" (atomic): range [4096, 4096] = 4096

Any thoughts?

Anyway, see below an example of `drm_info` output on AMD DCN301 for a
given Overlay/Primary plane without userspace usage of the properties:

│   └───"COLOR_PIPELINE" (atomic): enum {Bypass, Color Pipeline 265} = 
Bypass
│   ├───Bypass
│   └───Color Pipeline 265
│   ├───Color Operation 265
│   │   ├───"TYPE" (immutable): enum {1D Curve, 1D Curve Custom 
LUT, 3x4 Matrix, Multiplier} = 1D Curve
│   │   ├───"BYPASS" (atomic): range [0, 1] = 1
│   │   └───"CURVE_1D_TYPE" (atomic): enum {sRGB EOTF, BT.2020 
Inverse OETF, PQ 125 EOTF} = sRGB EOTF
│   ├───Color Operation 270
│   │   ├───"TYPE" (immutable): enum {1D Curve, 1D Curve Custom 
LUT, 3x4 Matrix, Multiplier} = 3x4 Matrix
│   │   ├───"BYPASS" (atomic): range [0, 1] = 1
│   │   └───"DATA" (atomic): blob = 0
│   ├───Color Operation 275
│   │   ├───"TYPE" (immutable): enum {1D Curve, 1D Curve Custom 
LUT, 3x4 Matrix, Multiplier} = Multiplier
│   │   ├───"BYPASS" (atomic): range [0, 1] = 1
│   │   └───"MULTIPLIER" (atomic): range [0, UINT64_MAX] = 0
│   ├───Color Operation 280
│   │   ├───"TYPE" (immutable): enum {1D Curve, 1D Curve Custom 
LUT, 3x4 Matrix, Multiplier} = 1D Curve
│   │   ├───"BYPASS" (atomic): range [0, 1] = 1
│   │   └───"CURVE_1D_TYPE" (atomic): enum {sRGB Inverse EOTF, 
BT.2020 OETF, PQ 125 Inverse EOTF} = invalid (0)
│   ├───Color Operation 285
│   │   ├───"TYPE" (immutable): enum {1D Curve, 1D Curve Custom 
LUT, 3x4 Matrix, Multiplier} = 1D Curve Custom LUT
│   │   ├───"BYPASS" (atomic): range [0, 1] = 1
│   │   ├───"SIZE" (atomic): range [4096, 4096] = 4096
│   │   └───"DATA" (atomic): blob = 0
│   ├───Color Operation 291
│   │   ├───"TYPE" (immutable): enum {1D Curve, 1D Curve Custom 
LUT, 3x4 Matrix, Multiplier} = 1D Curve
│   │   ├───"BYPASS" (atomic): range [0, 1] = 1
│   │   └───"CURVE_1D_TYPE" (atomic): enum {sRGB EOTF, BT.2020 
Inverse OETF, PQ 125 EOTF} = sRGB EOTF
│   └───Color Operation 296
│   ├───"TYPE" (immutable): enum {1D Curve, 1D Curve Custom 
LUT, 3x4 Matrix, Multiplier} = 1D Curve Custom LUT
│   ├───"BYPASS" (atomic): range [0, 1] = 1
│   ├───"SIZE" (atomic): range [4096, 4096] = 4096
│   └───"DATA" (atomic): blob = 0

It's a WIP and the output still needs to be reviewed. So feel free to
point out any mistake.

BR,

Melissa

> 
> Note that the 1st and 5th colorops take the EOTF or Inverse
> OETF while the 3rd colorop takes the Inverse EOTF or OETF.
> 
> We are working on two more ops for amdgpu, the HDR multiplier
> and the 3DLUT, which will give us this:
> 
> 1. 1D Curve EOTF
> 2. 3x4 CTM
> 3. HDR Multiplier
> 4. 1D Curve Inverse EOTF
>

Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)

[Daniel Stone]

Hi,

On Wed, 5 Jun 2024 at 09:09, Pekka Paalanen
 wrote:
> On Tue, 4 Jun 2024 20:33:48 +
> "Hoosier, Matt"  wrote:
> > Tactical question: I somehow missed until this point that the remote
> > and pipewire plugins will only run if the DRM backend is being used.
> >
> > But the DRM backend *really* doesn't want to start nowadays unless
> > you're running on a system with seatd and/or logind available.
> > Toolbox [1] is the de facto way to develop on bleeding edge copies of
> > components these days. But it logind and seatd aren't exposed into it.
> >
> > How do Weston people interactively develop on the Weston DRM backend
> > nowadays?
> >
> > [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
>
> I'm doing it old-school on my workstation, without any containers. What
> dependencies my distribution does not provide, I build and install
> manually into a prefix under $HOME:
>
> https://www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/
>
> The "clean and reliable" is probably outdated in this era of
> containers...

Yes, doing it in containers is a little bit tricky since it's not
exactly the design case. Honestly, on my Silverblue systems, I just
install a bunch of relevant dependencies into the system image with
rpm-ostree, and have a pile of self-built dependencies in a local
prefix.

This might give you some insight however:
https://github.com/containers/toolbox/issues/992

It probably needs some minor changes in Weston but does at least seem doable ...

Cheers,
Daniel

Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)

[Hoosier, Matt]

Thanks, everybody.

After some trial and error, I find that if I install seatd in the host and the 
seatd dev package in the Toolbox container and I then symlink the host seatd 
socket into /tmp on the container, Weston seems to start up okay on my physical 
KMS connectors:

user@host:~$ toolbox enter
…

user@toolbox:~$ sudo ln -s /run/host/run/seatd.socket /run/
user@toolbox:~$ weston --backend=drm

-Matt

From: Daniel Stone 
Date: Wednesday, June 5, 2024 at 5:07 AM
To: Pekka Paalanen 
Cc: "Hoosier, Matt" , "s...@cmpwn.com" 
, "cont...@emersion.fr" , Marius Vlad 
, "wayland-devel@lists.freedesktop.org" 

Subject: Re: Ways to test Weston during development (Re: Full-motion zero-copy 
screen capture in Weston)

Hi, On Wed, 5 Jun 2024 at 09: 09, Pekka Paalanen  wrote: > On Tue, 4 Jun 2024 20: 33: 48 + > "Hoosier, Matt"  wrote: > > Tactical question: I somehow missed until


Hi,



On Wed, 5 Jun 2024 at 09:09, Pekka Paalanen

 wrote:

> On Tue, 4 Jun 2024 20:33:48 +

> "Hoosier, Matt"  wrote:

> > Tactical question: I somehow missed until this point that the remote

> > and pipewire plugins will only run if the DRM backend is being used.

> >

> > But the DRM backend *really* doesn't want to start nowadays unless

> > you're running on a system with seatd and/or logind available.

> > Toolbox [1] is the de facto way to develop on bleeding edge copies of

> > components these days. But it logind and seatd aren't exposed into it.

> >

> > How do Weston people interactively develop on the Weston DRM backend

> > nowadays?

> >

> > [1] 
> > https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2SJoQzfs$

>

> I'm doing it old-school on my workstation, without any containers. What

> dependencies my distribution does not provide, I build and install

> manually into a prefix under $HOME:

>

> https://urldefense.com/v3/__https://www.collabora.com/news-and-blog/blog/2020/04/10/clean-reliable-setup-for-dependency-installation/__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK2Y5E0gB4$

>

> The "clean and reliable" is probably outdated in this era of

> containers...



Yes, doing it in containers is a little bit tricky since it's not

exactly the design case. Honestly, on my Silverblue systems, I just

install a bunch of relevant dependencies into the system image with

rpm-ostree, and have a pile of self-built dependencies in a local

prefix.



This might give you some insight however:

https://urldefense.com/v3/__https://github.com/containers/toolbox/issues/992__;!!EJc4YC3iFmQ!X9PIq-FMYhremNjhMhD6uGHUdYcYt4QKcl5CIjQAi0gYX5IyFx63gK1QZDWepwQBxB3mu1WTvjK21Tr-34M$



It probably needs some minor changes in Weston but does at least seem doable ...



Cheers,

Daniel

[ANNOUNCE] weston 13.0.3

[Marius Vlad]

Hi all,

Due to a few issues (script missing to account for git log @upstream..
command, glab creating automatically tags with the default main branch when 
not find a remote tag, and me not having a branch entry in the git config), 
it made it so that 13.0.1 and 13.0.2 point releases were released based 
on the main branch rather than the correct, 13 branch.

For the 13.0.1 point release I assumed that I could get away with it
just by deleting and re-creating, but apparently some mirrors were quick
to pick up that, and the recent fdo update made it so that people hit
that mirror instead of fdo and managed use the wrong tag.

That required a new 13.0.2 point release, but because I dismissed the
initial issue, assuming that it was just something I might have done
temporarily, I hit this again.

The 13.0.2 release is still available, but now states the same thing as
here, and that it is broken and recommends everyone to use the latest one, 
13.0.3.

I'm including the changelog from 13.0.1 until now (there no new changes
just the meson.build bumps and a fix for CI to be able to do the release), 
but here there are:

Marius Vlad (2):
  build: bump to version 13.0.2 for the point release
  build: bump to version 13.0.3 for the point release

Pekka Paalanen (1):
  CI: work around LeakSanitizer crashes with use_tls=0

git tag: 13.0.3

https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.3/downloads/weston-13.0.3.tar.xz
SHA256: 27f68d96e3b97d98daadef13a202356524924fa381418fa6716b9136ef099093  
weston-13.0.3.tar.xz
SHA512: 
60e655b57cf418902ec6e4371883354165241d9a99a712aabe2165e11ac190dec22836fd885f5178def5416dc5f00e70042b022c96a8e0aa74827bbd4563f9cb
  weston-13.0.3.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.3/downloads/weston-13.0.3.tar.xz.sig



signature.asc
Description: PGP signature

Re: [ANNOUNCE] Weston 13.0.1

[Marius Vlad]

Hi all,

Further update on this, some folks reported that 13.0.1 tag was wrong,
which prompted a new 13.0.2 point release.

I managed to trip a few issues with the release script again and that
one is botched as well. I've sent out a recent announcement for 13.0.3
so please use that one as the latest stable point release.

Apologies if this caused issues/inconsistencies, but there were some
cumulative factors that lead to this.

On Tue, Apr 23, 2024 at 08:07:41PM +0300, Marius Vlad wrote:
> Hi all,
> 
> Someone pointed out that the tag was wrong, pointing apparently to
> main branch. Had to delete the tag and re-create it. Should now point
> correctly. All links are the same, with the same files.
> 
> Thanks for heads-up Dylan!
> 
> On Tue, Apr 23, 2024 at 06:55:45PM +0300, Marius Vlad wrote:
> > Hi all,
> > 
> > Weston 13.0.1, a bug fix release for 13.0.0 has been released.
> > 
> > Full changelog below:
> > 
> > Arnaud Vrac (3):
> >   desktop-shell: clamp view alpha correctly
> >   desktop-shell: set proper curtain size when no output is created yet
> >   clients/desktop-shell: fix crash on init when panel is disabled
> > 
> > Derek Foreman (3):
> >   gl-renderer: apply output transform before readback in repaint
> >   libweston: Clip damage to paint node visible region
> >   libweston/backends: Move damage flush into backends
> > 
> > Jeffy Chen (2):
> >   renderer-gl: Fix wrong stride error when reading pixels
> >   desktop-shell: Avoid using maximized size in fullscreen state
> > 
> > Marius Vlad (3):
> >   backend-pipewire: Move region initialization at the start
> >   libweston: Add paint node destruction into weston_layer_entry_remove()
> >   build: bump to version 13.0.1 for the point release
> > 
> > Michael Olbrich (1):
> >   ivi-shell: clear seat focus if necessary when a surface is destroyed
> > 
> > Philipp Zabel (1):
> >   libweston-desktop: Work around crash when opening popup menu
> > 
> > Ray Smith (1):
> >   backend-drm: fix confused fallback format handling
> > 
> > Robert Mader (2):
> >   backend-drm: Don't force non-opaque overlays to primary plane
> >   backend-drm: Sort planes by faked zpos
> > 
> > Wujian Sun (1):
> >   libweston-desktop: Fix weston crash when lost the shsurf
> > 
> > git tag: 13.0.1
> > 
> > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz
> > SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a  
> > weston-13.0.1.tar.xz
> > SHA512: 
> > 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122
> >   weston-13.0.1.tar.xz
> > PGP:
> > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig
> > 
> 
> 




signature.asc
Description: PGP signature

[ANNOUNCE] libinput 1.26.0

[Peter Hutterer]

libinput 1.26.0 is now available. It's been a while since the last release
but we have a few notable changes in here:

Touchpads can now configure a clickfinger button map, so you can change
whether two- or three-finger click means a right or middle click.
See libinput_device_config_click_set_clickfinger_button_map

Tablet pads now have an API for relative dials. These are typically wheel-like
(e.g. Huion Inspiroy 2) or ring-like (e.g. Huion Inspiroy Dial 2) physical 
devices
that send REL_WHEEL and REL_HWHEEL. libinput now provides these via
libinput_event_tablet_pad_get_dial_delta_v120() in much the same manner as the
v120-based scroll wheel API.

A new configuration option for tablet tools allow reducing the available
logical range. This is useful for users that want the tool to register only
when some physical pressure value is reached, or to reduce the maximum amount
of pressure needed to reach the logical maximum pressure. See
libinput_tablet_tool_config_pressure_range_set() and friends.

Tablet tools can now use BTN_STYLUS3 too and tablet pad strip support should
now work for non-Wacom devices, where the kernel driver implements it.

Huion tablets (well, and all vendors that use the 256C vendor id) now have a 
fallback
resolution set. This is going to be wrong on most devices but at least it will
make those tablets work out of the box, instead of failing with the
"missing tablet capabilities: resolution" log message.

And of course a varied assortment of device specific quirks and fixes.

As usual, the git shortlog is below, many thanks to all our contributors.

Bogdan Mircea (1):
  Added quirks for TongFang/Uniwill touchpad and ITE keyboard

Derrick Timmermans (1):
  Add quirk for the Legion Slim 7 Gen 8 keyboard

Hooloovoo Blue (1):
  Update 50-system-lenovo.quirks to fix X201t tablet buttons

Joshua Goins (1):
  tablet: add API for relative dials

Josip Medved (1):
  Recognizing Framework 16 keyboard modules as internal keyboards

José Expósito (8):
  doc/user: Document "Closes" and "Fixes" tags
  CONTRIBUTING: Add CONTRIBUTING.md
  Add libinput_device_get_id_bustype()
  quirks: add quirk for Dell Precision 5480 touchpad
  sparse: make some variables static
  touchpad: use boolean operator for booleans
  quirks: fix end-of-file in 50-system-huawei.quirks
  evdev: log the right mouse wheel angle

Julian Orth (1):
  Ring positions increase clockwise

Maarten de Vries (1):
  quirks: add quirk for Lenovo Legion keyboard 048d:c103

Marge Yang (1):
  quirks: add quirk for HP Haptics Touchpad.

Martin Rys (2):
  Add definitions for LIBINPUT_LED_COMPOSE and LIBINPUT_LED_KANA
  Include COMPOSE and KANA keys in tests

PLTorrent (1):
  Add support for Matebook X Pro 2024 Touchpad

Peter Hutterer (48):
  Add a helper for radians to degrees
  test: debug print the events we're draining
  test: set pressure to zero on proxout for the tablets with forced prox out
  test: fix a wrong value for the auto-assigned BTN_TOOL
  tablet: handle BTN_STYLUS3
  Revert "tablet: fix the pressure offset range being off by one"
  util: add a helper to normalize an axis to [0.0, 1.0]
  tablet: fix tilt handling for even-ranged tablets
  tablet: don't use absinfo_range for the percentage calculation
  tablet: move tool creation into a helper function
  tablet: document a known bug about pressure thresholds across tablets
  tablet: add tablet tool pressure range configuration
  triage-policies: add a bugbot command to close issue in favour of an MR
  doc/user: note the requirement to apply for gitlab fork permissions
  doc: drop permissions to 644 for the gesture state machine SVG
  quirks: tighten the match for the Graviton N15i touchpad
  doc: fix end-of-file in the state machine SVG
  test: only expect one button event from the intuos-like test
  CI: only check the MR if we're in a merge request pipeline
  touchpad: disable the immediate scroll state if tapping is enabled
  quirks: Add a the onebutton apple touchpad quirk for an old MacBook
  tools: fix two black warnings
  ci: bump to Fedora 39 and FreeBSD to 13.2
  util: add a LIST_INIT macro
  test: add helpers for checking (negative) errnos
  Move mkdir_p into a utility header
  util: fix error in mkdir_p if a parent directory fails to be created
  test: add two more more libinput_dispatch() calls
  test: slightly increase the finger switch timeout wait
  Revert "test: allow for substring matching in the various --filter- 
arguments"
  test: fix some tests that may cause pointer jumps
  test: fix two wrong timeout calls
  util: slightly improve the trace() macro
  test: remove a workaround for libevdev 1.2 and earlier
  test: remove some old compat code for kernel<4.5
  test: force the apple magicmouse to 1000dpi
  test: replace an assert with double_ge