In retrospect, I don't even want cursor tracking - I was thinking of mousePolling, but that no-ops here anyway.

In D7323#135959, @davidedmundson wrote:

In retrospect, I don't even want cursor tracking - I was thinking of mousePolling, but that no-ops here anyway.

KWin doesn't do mousePolling anymore in "normal" situations. On X11 with XInput2 and on Wayland in general. So nothing to worry about.

Just some more thinking: if the aim is better trackmouse or mousemark extending scripts or effects is the wrong approach. Ideally one would want to use the DRM cursor layer for this. The big disadvantage of trackmouse currently is that it causes repaints in the compositor. Doing it through QtQuick would make this worse (these are the performance implications mentioned in the previous comment). We would have the rendering of QtQuick which is not synced in any way to the rendering of the compositor. Plus the overhead of getting QtQuick into the compositor scene.

But also effects are not well suited for it in a Wayland world as it just doesn't make use of what we have now: drm layers. By using drm layers we would get the rendering for free without affecting the compositor performance at all. The compositor could even stay idle and not be woken up at all. This was btw. how I envisioned something like the mouse cursor enlargement which @broulik talked about would work. We just render larger in the drm platform plugin.

2¢ - you don't have to expose the cursor position for those effects, just a signal that the cursor position changed and the ability to "do some" at the "current" cursor position (which is then resolved by the core)

In D7323#136066, @luebking wrote:

2¢ - you don't have to expose the cursor position for those effects, just a signal that the cursor position changed and the ability to "do some" at the "current" cursor position (which is then resolved by the core)

that would be an elegant solution to my security concerns.

Security in scripts/effects is an existing problem, Scripts already can do literally anything, from manipulating workspace windows to low level DBus calls...as kwin. It needs solving regardless at a much higher level than restricting what API is available.

I could write my thing as C++, but I was very much under the impression you wanted to move scripts away from that?

If you want to do these effects in a scripted approach we need to extend the scripting API.

That's what I am doing...unless scripting API and the declarative scripting API are conceptually different?

Something something planes

This is something I want to to do too. But declarative and using planes aren't in any way exclusive. A DRM buffer still needs content from somewhere.

For the thing I was doing (some obscure accessibility thing for someone) the cursor plane wouldn't really work. Nor for mousemark, where the content remains static.

Given how many effects are simply overlays - having platforms provide a plane for all overlays (with some compositior fallback) is something that IMHO would make sense, that I would happily work on. I don't think throwing it into the DRM backend itself is a system that will scale.

In D7323#136114, @davidedmundson wrote:

Security in scripts/effects is an existing problem, Scripts already can do literally anything, from manipulating workspace windows to low level DBus calls...as kwin. It needs solving regardless at a much higher level than restricting what API is available.

Only partially. E.g. Wayland windows are not exposed to scripting for security concerns. So scripting currently only allows X11 which does not reduce the overall security.

Yes it needs a better solution, but a few years ago I decided to not expose anything Wayland related till we have a solution in place.

I could write my thing as C++, but I was very much under the impression you wanted to move scripts away from that?

If you want to do these effects in a scripted approach we need to extend the scripting API.

That's what I am doing...unless scripting API and the declarative scripting API are conceptually different?

We have three APIs:

• effects (QScript based)
• kwin scripts (QScript based)
• kwin declarative scripts

The latter two are the same thing with different languages, the first one is a different beast. Effects cannot use QML. Code wise the effect scripts live in effects/ subdir, the two scripted in scripts/ subdir.

Something something planes

This is something I want to to do too. But declarative and using planes aren't in any way exclusive. A DRM buffer still needs content from somewhere.

True, but we need to get the content. If it's done by QtQuick we don't get the content (c.f. in Aurorae we do an expensive to QImage copy, for normal QWindows (on Wayland) we use an FBO which we cannot share at all with the DRM buffer). If we have the data as QImage we can relatively easy get it into a DRM layer, even if we do it in OpenGL not using QtQuick we could get it into a layer (with some serious engeneering work). Just with QtQuick - well difficult.

For the thing I was doing (some obscure accessibility thing for someone) the cursor plane wouldn't really work. Nor for mousemark, where the content remains static.

Given how many effects are simply overlays - having platforms provide a plane for all overlays (with some compositior fallback) is something that IMHO would make sense, that I would happily work on. I don't think throwing it into the DRM backend itself is a system that will scale.

Nah, of course not everything in DRM platform plugin. An abstraction which would allow to move it to into the platform is what we need. E.g. like we can do software rendering of cursor or doing it in the platform. Or the invert of screen which can either be done by an effect or through the platform (except it's in core).