After investigating the bug this weekend, I found the problem:

In file https://invent.kde.org/plasma/kwin-x11/-/blob/master/src/backends/x11/standalone/x11_standalone_cursor.cpp :
```
X11Cursor::X11Cursor(bool xInputSupport)
    : Cursor()
    , m_buttonMask(0)
    , m_hasXInput(xInputSupport)
{
    Cursors::self()->setMouse(this);
    if (!m_hasXInput) {
        // without XInput we don't get events about cursor movement, so we have to poll instead
        connect(&m_mousePollingTimer, &QTimer::timeout, this, &X11Cursor::pollMouse);
        m_mousePollingTimer.setSingleShot(false);
        m_mousePollingTimer.setInterval(50);
        m_mousePollingTimer.start();
    }
    if (Xcb::Extensions::self()->isFixesAvailable()) {
        xcb_xfixes_select_cursor_input(connection(), rootWindow(), XCB_XFIXES_CURSOR_NOTIFY_MASK_DISPLAY_CURSOR);
    }

#ifndef KCMRULES
    connect(kwinApp(), &Application::workspaceCreated, this, [this]() {
        if (Xcb::Extensions::self()->isFixesAvailable()) {
            m_xfixesFilter = std::make_unique<XFixesCursorEventFilter>(this);
        }
    });
#endif
}
```
From what I understood, if Xinput doesn't exist, the cursor position is polled regularly. I reduced the polling timeout to 20ms instead of 50ms and lines are now much smoother again. This implies that for some reason Xinput is not working/detected?

Can you as a workaround use a higher polling rate (like 8ms) to keep Plasma looking smooth? I found that this polling rate affects the mouseChanged() signal so it makes any compositor effect (like mouse mark, startup feedback...) relying on it appear laggy.

Figuring out why Xinput isn't being detected for you would be better, but as a workaround I guess it wouldn't be too bad to reduce the interval. Feel free to make a MR changing it

(In reply to Zamundaaa from comment #2)
> Figuring out why Xinput isn't being detected for you would be better, but as
> a workaround I guess it wouldn't be too bad to reduce the interval. Feel
> free to make a MR changing it

I may try to investigate why Xinput isn't working, but it may take a while since I'm not familiar with GUI development in general, let alone X11.

I discovered(In reply to Zamundaaa from comment #2)
> Figuring out why Xinput isn't being detected for you would be better, but as
> a workaround I guess it wouldn't be too bad to reduce the interval. Feel
> free to make a MR changing it

While digging for the root cause, I found out that I can't place a breakpoint using GDB in the file https://invent.kde.org/plasma/kwin-x11/-/blob/master/src/backends/x11/standalone/x11_standalone_xinputintegration.cpp
But I can do in most other files (not a debug symbol issue). It turns out that CMake is the culprit. When investigating its logs I found the following message:

-- The following features have been disabled:

 * XInput, Required for poll-free mouse cursor updates

I'm not sure why CMake is failing to detect XInput, even when I'm sure it exists on my system. As a hack I forced CMake to act as if it detected XInput but now compilation fails due to some warnings: one of them is related to an uninitialized value when setting capsLock or numLock state, other warnings were about some QT functions being depreciated.

I will close this bug as it turned out to be a Debian specific issue.