usb: device_next: add initial HID device support #65801

jfischer-no · 2023-11-27T10:51:21Z

Initial HID device support.
~~Depends on a few patches from different PRs.~~

tmon-nordic · 2023-11-28T08:16:44Z

subsys/usb/device_next/usbd_ch9.c

+		/*
+		 * If the recipient is not the device then it is probably a
+		 * class specific  request where wIndex is the interface
+		 * number or endpoing and not the language ID. e.g. HID


endpoing -> endpoint

tmon-nordic · 2023-11-28T08:23:03Z

dts/bindings/usb/zephyr,hid-device.yaml

+    description: |
+      Device can be used as a Boot Device and supports a predefined protocol
+      for mouse or keyboards.
+      - none:     Device does not support the boot interface


Just make boot-protocol-code not required and treat the absence of property as none. You can determine if the property is there with DT_NODE_HAS_PROP() and then just do COND_CODE_1() or COND_CODE_0() on it.

tmon-nordic · 2023-11-28T08:24:09Z

dts/bindings/usb/zephyr,hid-device.yaml

+      HID device name. When this property is present, a USB device will use it
+      as the string descriptor of the interface.
+
+  boot-protocol-code:


Maybe just renamed to boot-protocol. The user sets the overall protocol and I think it shouldn't be down to individual fields.

tmon-nordic · 2023-11-28T08:26:01Z

dts/bindings/usb/zephyr,hid-device.yaml

+      Input type reports polling rate in number of 125µs periods.
+      Depending on the actual speed, the calculated polling rate could be clamped
+      to 1ms or 255ms.


The 125µs period is the case only on high-speed. On full-speed the meaning is different.

I don't think it's exactly that either... On High Speed it's the formula of (2^(bInterval-1) * 125us) = x. Where it would follow this table.

bInterval uS

1 125

2 250

3 500

4 1000

5 2000

6 4000

7 8000

8 16000

9 32000

10 64000

11 128000

12 256000

13 512000

14 1024000

15 2048000

16 4096000

For Full/Low Speed it's, just 1ms units.

~~Thanks for the point. I want to use 125µs granularity for this property. But the actual code does not handle it properly.~~ Changed to microseconds.

tmon-nordic · 2023-11-28T08:31:32Z

dts/bindings/usb/zephyr,hid-device.yaml

+      Depending on the actual speed, the calculated polling rate could be clamped
+      to 1ms or 255ms.
+
+  in-reports-mps:


I think we should have separate max packet size entry for full-speed and high-speed, because the two have different allowed ranges. While the USB stack does not really support the concept of different configurations for different operating speed we really should have it because otherwise we'll run into unsolvable issues later on.

If there is just one for the time being, put 64 as the maximum value here.

tmon-nordic

Must not be merged before #65165 and #65457

samples/subsys/usb/hid-keyboard/Kconfig

subsys/usb/device_next/class/usbd_hid.c

benedekkupper · 2024-02-22T22:36:09Z

subsys/usb/device_next/class/usbd_hid.c

+		errno = ops->get_report(dev, type, id, net_buf_tailroom(buf), buf->data);
+		break;
+	case HID_REPORT_TYPE_OUTPUT:
+		LOG_DBG("Get Report, Output Report ID %u", id);


Output report type cannot be get, this should be an error case.

This case should be removed, so it falls to the default error handler.

Just like with input report being set, HID Specification leaves it up to developer whether it is possible to get output report or not.

benedekkupper · 2024-02-22T22:43:27Z

subsys/usb/device_next/class/usbd_hid.c

+	const struct hid_device_ops *const ops = ddata->ops;
+	struct usbd_hid_descriptor *const desc = ddata->desc;
+
+	atomic_set_bit(&ddata->state, HID_DEV_CLASS_ENABLED);


I'm not sure where to put this, and maybe I just didn't find where this happens, but ddata->protocol should be reset to REPORT when the HID interface is configured.

Thanks, fixed here as suggested.

Maybe we could also call application's callback informing about the protocol change here? So that application would be explicitly notified about the used protocol and could rely on single source of truth.

below, ready callback is called. Also host should set the protocol whenever initializing a device.

Sounds ok too

MarekPieta · 2024-04-25T06:25:42Z

samples/subsys/usb/hid-keyboard/src/main.c

+		LOG_ERR("Failed to enable device support");
+		return ret;
+	}
+


An info log informing that sample successfully initialized would be really helpful here. Currently there is only a boot banner if I boot without USB connected (it may look as if something went wrong)

MarekPieta · 2024-04-25T06:38:16Z

samples/subsys/usb/hid-keyboard/src/main.c

+			continue;
+		}
+
+		ret = hid_device_submit_report(hid_dev, sizeof(report), report, true);


By default, main thread is preemptive. USB HID device readiness may change after the !kb_ready check (it could also bypass internal checks done by hid_device_submit_report in similar way). Is it safe or could it lead to problems or edge cases in USB stack? Maybe we need cooperative priority here

Why do you think the cooperative thread can not be interrupted and is somehow different then?

A preemptive thread can be supplanted at any time by the scheduler while a cooperative thread needs to perform an action that would make it unready. As long as input_cb is called from a thread context (e.g. not from an interrupt), it would not preempt execution of a cooperative thread (but it still may supplant a preemptive thread).

cooperative thread can be interrupted by an interrupt, AFAIK there is no guaranty it can immediately continue after, am I wrong?

Cooperative thread will continue execution after it is interrupted by an interrupt. There is guarantee that there won't be other thread executing, see https://docs.zephyrproject.org/3.6.0/kernel/services/scheduling/index.html#cooperative-time-slicing for more information.

The CONFIG_INPUT_MODE is CONFIG_INPUT_MODE_THREAD by default, so that events seem broadcasted through a common input thread by default (then cooperative main priority could actually prevent supplant).

Ref: https://docs.zephyrproject.org/latest/services/input/index.html#application-api

I thought synchronous is on by default, added CONFIG_INPUT_MODE_SYNCHRONOUS=y.

Cooperative thread will continue execution after it is interrupted by an interrupt. There is guarantee that there won't be other thread executing,

It seems to me that this article does not pay attention to meta-IRQ threads.

I wonder if using a thread for synchronizing inputs wouldn't actually simplify synchronization here (we could rely on cooperative priorities to simplify sample's implementation and prevent races; in sample's use-case extra latency shouldn't be a problem). You are right that meta-IRQ threads are tricky use-case here (still, I don't recall seeing them used instead of regular threads in most of the subsystems or samples - I guess using them would require some "special handling" to ensure safety)

Still, since it's an improvement to the sample code, I would suggest to add it (but I would not NACK PR because of it)

MarekPieta · 2024-04-25T07:08:45Z

subsys/usb/device_next/class/usbd_hid.c

+
+	return buf;
+}
+


Remove extra empty line, please

MarekPieta · 2024-04-25T07:09:15Z

subsys/usb/device_next/class/usbd_hid.c

+	struct usbd_class_data *c_data = ddata->c_data;
+	struct net_buf *buf;
+
+


Remove extra empty line, please

MarekPieta · 2024-04-25T07:10:40Z

subsys/usb/device_next/class/usbd_hid.c

+		return usbd_ep_buf_free(uds_ctx, buf);
+	}
+
+	if (sync && ops->input_report_done == NULL) {


Shouldn't it be if (sync) ? Currently it seems misaligned with API doc.

Edit: Looking at the usbd_hid_request implementation a bit more, I think we may need to use ops->input_report_done == NULL as condition here (implementation seems not to support concurrent sync and async flows). Maybe we could simply use sync only if ops->input_report_done == NULL and use async otherwise (then an additional function argument may not be needed here).

I updated the documentation, but kept the sync parameter for now. I am still thinking about it.

Shouldn't it be if (sync || ops->input_report_done == NULL) then? (to align with newly introduced API doc)
Currently, if the callback is NULL and sync is set to false, the application has no way to get information that report was actually sent.

I see it's already aligned. Thanks

Maybe we could simply use sync only if ops->input_report_done == NULL and use async otherwise (then an additional function argument may not be needed here).

I followed this suggestion.

tmon-nordic · 2024-04-25T07:15:05Z

dts/bindings/usb/zephyr,hid-device.yaml

+      - keyboard: Device supports boot interface and keyboard protocol
+      - mouse:    Device supports boot interface and mouse protocol
+    enum:
+      - none


none should be removed from here. I know this requires extra macro mapping, but implicitly relying on numbers being the same between different types is something I prefer to avoid.

I did not get it. What types are different and how does removing "none" fix "implicitly relying on numbers being the same between different types" ?

none doesn't really belong under "boot-protocol" from devicetree point of view IMHO (the absence of property signifies that). The "different types" I refer to the enum defined here in devicetree and the protocol code as defined by HID Specification - these two are essentially separate.

MarekPieta · 2024-04-25T07:18:13Z

subsys/usb/device_next/class/usbd_hid_api.c

+	}
+
+	if (legacy_ops->int_in_ready) {
+		LOG_ERR("Input report done for %p", dev);


LOG_DBG ?
Can we align check with other propagated callbacks: legacy_ops != NULL && legacy_ops->int_in_ready != NULL

MarekPieta · 2024-04-25T07:22:54Z

subsys/usb/device_next/class/usbd_hid_api.c

+
+int usb_hid_init(const struct device *dev)
+{
+	LOG_DBG("It does nothing for dev %p", dev);


Please cast the %p argument to (void *) (as required by C standard). Also in other places

Required by what C standard?
I will not add explicit conversion of any pointer to a void pointer.

Apparently all of the major ones. C89, C99 and C11: "The argument shall be a pointer to void", and for the scanf variants the standard say: "The corresponding argument shall be a pointer to a pointer to void."

Not respecting this leads to undefined behavior. Whether this is going to lead to actual real world problems is another story, but from the standard point of view it can (as any undefined behavior).

The other way around is OK. The C standard guarantees conversion from void* to any type of pointer, but not in this direction as pointed out here.
EDIT: I was wrong, no need to cast in either direction. But it is required to cast when using printf and %p, so the fix is required here

The other way around is OK. The C standard guarantees conversion from void* to any type of pointer, but not in this direction as pointed out here.

That is different. C in a Nutshell, "Any object pointer type can be implicitly converted to a pointer to void, and vice versa.".
Not sure fprintf conversion specification is required for cbprintf.

MarekPieta · 2024-04-26T10:06:05Z

subsys/usb/device_next/class/usbd_hid_api.c

+	int l = len;
+
+	if (legacy_ops != NULL && legacy_ops->set_report != NULL) {
+		return legacy_ops->get_report(dev, &setup, &l, &d);


Shouldn't it be set_report here?

MarekPieta · 2024-04-29T07:08:11Z

include/zephyr/usb/class/usbd_hid.h

+ *
+ * @param[in] dev    Pointer to HID device
+ * @param[in] size   Size of the input report
+ * @param[in] report Input report buffer. Report buffer must be aligned.


btw. Do we have e.g. a #define that could be used to get the required alignment?
Could we add an assertion that would ensure proper alignment, please? (I am worried that wrong alignment bug may be quite hard to catch)

MarekPieta · 2024-04-29T07:10:28Z

subsys/usb/device_next/class/usbd_hid_api.c

+#include <zephyr/devicetree.h>
+#include <zephyr/usb/usbd.h>
+#include <zephyr/usb/class/usb_hid.h>
+#include <zephyr/usb/class/usbd_hid.h>


Duplicated include

You are right, sorry for confusion (I misread the second one...)

MarekPieta · 2024-04-29T07:15:13Z

subsys/usb/device_next/class/usbd_hid.c

+	uint8_t protocol;
+};
+
+static uint8_t hid_get_in_ep(struct usbd_class_data *const c_data)


static inline? (for consistency with hid_get_out_ep)

MarekPieta · 2024-04-29T07:53:18Z

subsys/usb/device_next/class/usbd_hid.c

+		return;
+	}
+
+	usbd_ep_enqueue(c_data, buf);


Consider at least emitting an error log on failure here

MarekPieta · 2024-04-29T07:57:29Z

subsys/usb/device_next/class/usbd_hid.c

+		duration = ops->get_idle(dev, id) / 4UL;
+	}
+
+	LOG_DBG("Get Idle, Report ID %u Duration %u", id, duration);


Could we emit log before checks to ensure user would see it? (that would also improve consistency with handle_set_idle)

It may be useful also for other callbacks

I do not find it practical, then we might also have to log every protocol error and that bloats everything.

I would not insist on adding extra logs, we can keep it as is

MarekPieta · 2024-04-29T09:40:52Z

subsys/usb/device_next/class/usbd_hid.c

+	usbd_ep_enqueue(c_data, buf);
+}
+
+static int hid_dev_submit_report(const struct device *dev,


@jfischer-no, would it be possible to allow writing directly to endpoint (in similar way as it was done in legacy stack) to minimize HID data latency here (small latency may be crucial for some HID applications)? Would such functionality be difficult to implement?

No, one always have to enqueue a transfer.

Ok, thanks for clarification.

MarekPieta · 2024-04-29T09:53:13Z

subsys/usb/device_next/class/usbd_hid.c

+		}
+	}
+
+	if (bi->ep == hid_get_in_ep(c_data)) {


else if ?

Why would anyone do that?

I was thinking about explicitly avoiding the second comparison in code (bi->ep cannot match both conditions here)

I still do not get it.

Adding else before the second if leads to omitting the second comparison if the first condition is met

MarekPieta · 2024-04-29T10:02:40Z

subsys/usb/device_next/class/usbd_hid.c

+	if (ops->set_idle != NULL) {
+		ops->set_idle(dev, id, duration * 4UL);
+	} else {
+		errno = -ENOTSUP;


We shouldn't end up with this error if id == 0U

Why not? Id 0 applies to all reports and Set Report is not always required, so we need to issue protocol error if there is no callback.

Then shouldn't we also return error for id == 0 in handle_get_idle if there is no callback? (for consistency).
Also, currently we update our common idle rate even though we return protocol error here.

btw. This is set_idle

Then I have to drop legacy API support.

I think it's worth to keep the legacy API support (even if it has some additional limitations)

MarekPieta · 2024-04-29T10:07:12Z

subsys/usb/device_next/class/usbd_hid.c

+	switch (type) {
+	case HID_REPORT_TYPE_INPUT:
+		LOG_DBG("Set Report, Input Report ID %u", id);
+		errno = ops->set_report(dev, type, id, buf->len, buf->data);


Maybe we could make the HID_REPORT_TYPE_ enum part of the application API and use it to pass report type?

MarekPieta · 2024-04-29T10:31:52Z

samples/subsys/usb/hid-keyboard/src/main.c

+			     const uint8_t *const buf)
+{
+	LOG_HEXDUMP_DBG(buf, len, "o.r.");
+	kb_set_report(dev, 2U, 0U, len, buf);


Do we actually need to pass type and ID here?

Yes, Set Report has different interface.

I meant that most of the parameters passed to kb_set_report are actually unused and we may desist from passing them as function arguments because of that

kb_set_report is the callback implementation for set_report, I changed it a bit, maybe it makes it clearer.

I see you prefer to pass the parameters anyway. We can keep it as is.

tmon-nordic

I'd prefer boot-protocol instead of protocol-code in the devicetree property, but that can be argued to be a style choice.

MarekPieta · 2024-05-07T10:51:41Z

subsys/usb/device_next/class/usbd_hid.c

+	}
+
+	if (usbd_ep_enqueue(c_data, buf)) {
+		LOG_ERR("Failed to enqueue buffer");


Should we free buffer on error here?

🔥 I will look into what happened here.

It is already fixed. Thank you

Add initial HID device support. Unlike the existing HID implementation, the new implementation uses a devicetree to instantiate a HID device. To the user, the HID device appears as a normal Zephyr RTOS device. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>

Add support for the new HID implementation. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>

Add HID keyboard sample for the new experimental USB device support. This is a limited and not fully compliant HID keyboard implementation. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>

MarekPieta

Overall looks good. Added a few more improvement propositions (and one small doc alignment)

MarekPieta · 2024-05-13T13:08:24Z

include/zephyr/usb/class/usbd_hid.h

+/**
+ * @brief Submit new input report
+ *
+ * Submit a new input report to be sent via the interrupt IN pipe. If sync is


sync no longer exists

MarekPieta · 2024-05-13T13:28:52Z

subsys/usb/device_next/class/usbd_hid.c

+
+	if (ops->set_report == NULL) {
+		errno = -ENOTSUP;
+		LOG_DBG("Set Report not supported");


Consider LOG_WRN to ensure user would see it.

MarekPieta · 2024-05-13T13:32:21Z

subsys/usb/device_next/class/usbd_hid.c

+		return 0;
+	}
+
+	LOG_DBG("Set Protocol: %s", protocol ? "Report" : "Boot");


Consider an explicit comparison here to improve readability:
(protocol == HID_PROTOCOL_REPORT)

MarekPieta · 2024-05-13T13:57:47Z

subsys/usb/device_next/class/usbd_hid_internal.h

+ */
+
+struct hid_device_driver_api {
+	int (*enable_output)(const struct device *dev, const bool enable);


Enable output seems unused. Can we remove it?

fabiobaltieri · 2024-05-14T18:43:06Z

dts/bindings/usb/zephyr,hid-device.yaml

+      The size of the longest input report that the HID device can generate.
+      This property is used to determine the buffer length used for transfers.
+
+  in-polling-rate:


the naming of this is a bit odd, rate would imply a frequency, how about in-polling-period-us? same for the out one

jfischer-no added area: USB Universal Serial Bus Experimental Experimental features not enabled by default labels Nov 27, 2023

jfischer-no requested review from carlescufi and tmon-nordic November 27, 2023 10:51

jfischer-no self-assigned this Nov 27, 2023

zephyrbot added area: Devicetree Binding PR modifies or adds a Device Tree binding area: Samples Samples labels Nov 27, 2023

zephyrbot requested review from galak, kartben and nashif November 27, 2023 10:51

tmon-nordic reviewed Nov 28, 2023

View reviewed changes

tmon-nordic requested changes Nov 28, 2023

View reviewed changes

jfischer-no force-pushed the pr-device-next-hid branch from b5dfe7a to 95d7bfe Compare December 11, 2023 12:15

jfischer-no mentioned this pull request Dec 13, 2023

Planned USB device/host support rework/enhancements #42066

Open

52 tasks

tmon-nordic reviewed Dec 20, 2023

View reviewed changes

samples/subsys/usb/hid-keyboard/Kconfig Outdated Show resolved Hide resolved

jfischer-no force-pushed the pr-device-next-hid branch from 95d7bfe to cfeb50b Compare December 20, 2023 10:23

github-actions bot added the Stale label Feb 19, 2024

jfischer-no removed the Stale label Feb 19, 2024

zephyrproject-rtos deleted a comment from github-actions bot Feb 19, 2024

benedekkupper reviewed Feb 22, 2024

View reviewed changes

jfischer-no force-pushed the pr-device-next-hid branch from cfeb50b to d1aec4f Compare March 21, 2024 08:37

zephyrbot added the platform: STM32 ST Micro STM32 label Mar 21, 2024

zephyrbot requested review from ABOSTM, Desvauxm-st, erwango and FRASTM March 21, 2024 08:38

benedekkupper mentioned this pull request Apr 24, 2024

HID doesn't support Get_Report(OUT) nor Set_Report(IN) IntergatedCircuits/c2usb#7

Open

MarekPieta reviewed Apr 25, 2024

View reviewed changes

tmon-nordic reviewed Apr 25, 2024

View reviewed changes

MarekPieta reviewed Apr 25, 2024

View reviewed changes

MarekPieta reviewed Apr 26, 2024

View reviewed changes

MarekPieta reviewed Apr 29, 2024

View reviewed changes

jfischer-no force-pushed the pr-device-next-hid branch from 28ec369 to e46a11f Compare May 3, 2024 15:56

carlescufi requested review from tmon-nordic, MarekPieta and benedekkupper May 6, 2024 13:16

tmon-nordic previously approved these changes May 7, 2024

View reviewed changes

MarekPieta reviewed May 7, 2024

View reviewed changes

jfischer-no added 2 commits May 9, 2024 15:08

samples: hid-mouse: add support for the new HID implementation

67dd652

Add support for the new HID implementation. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>

jfischer-no dismissed tmon-nordic’s stale review via 8682953 May 9, 2024 13:24

jfischer-no force-pushed the pr-device-next-hid branch from e46a11f to 8682953 Compare May 9, 2024 13:24

samples: usb: add HID keyboard sample

b3867cc

Add HID keyboard sample for the new experimental USB device support. This is a limited and not fully compliant HID keyboard implementation. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>

jfischer-no force-pushed the pr-device-next-hid branch from 8682953 to b3867cc Compare May 10, 2024 13:54

tmon-nordic approved these changes May 13, 2024

View reviewed changes

carlescufi requested review from MarekPieta and ddavidebor May 13, 2024 07:57

MarekPieta approved these changes May 13, 2024

View reviewed changes

carlescufi approved these changes May 14, 2024

View reviewed changes

fabiobaltieri reviewed May 14, 2024

View reviewed changes

nashif merged commit 859cc2f into zephyrproject-rtos:main May 14, 2024
22 checks passed

bInterval	uS
1	125
2	250
3	500
4	1000
5	2000
6	4000
7	8000
8	16000
9	32000
10	64000
11	128000
12	256000
13	512000
14	`1024000`
15	2048000
16	`4096000`

		struct usbd_class_data *c_data = ddata->c_data;
		struct net_buf *buf;

usb: device_next: add initial HID device support #65801

usb: device_next: add initial HID device support #65801

Conversation

jfischer-no commented Nov 27, 2023 • edited by carlescufi Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

XenuIsWatching Dec 15, 2023 • edited Loading

Choose a reason for hiding this comment

jfischer-no Dec 15, 2023 • edited Loading

Choose a reason for hiding this comment

tmon-nordic Nov 28, 2023 • edited Loading

Choose a reason for hiding this comment

tmon-nordic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarekPieta Apr 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarekPieta Apr 26, 2024 • edited Loading

Choose a reason for hiding this comment

MarekPieta Apr 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarekPieta May 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarekPieta May 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarekPieta Apr 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tmon-nordic Apr 25, 2024 • edited Loading

Choose a reason for hiding this comment

carlescufi Apr 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarekPieta May 9, 2024 • edited Loading

Choose a reason for hiding this comment

jfischer-no commented Nov 27, 2023 •

edited by carlescufi

Loading

XenuIsWatching Dec 15, 2023 •

edited

Loading

jfischer-no Dec 15, 2023 •

edited

Loading

tmon-nordic Nov 28, 2023 •

edited

Loading

MarekPieta Apr 25, 2024 •

edited

Loading

MarekPieta Apr 26, 2024 •

edited

Loading

MarekPieta Apr 25, 2024 •

edited

Loading

MarekPieta May 6, 2024 •

edited

Loading

MarekPieta May 13, 2024 •

edited

Loading

MarekPieta Apr 25, 2024 •

edited

Loading

tmon-nordic Apr 25, 2024 •

edited

Loading

carlescufi Apr 25, 2024 •

edited

Loading

MarekPieta May 9, 2024 •

edited

Loading