[GH-ISSUE #140] Input Capture not working in Plasma 6.1 #59

Closed
opened 2026-05-05 22:07:19 -06:00 by gitea-mirror · 20 comments
Owner

Originally created by @xf- on GitHub (May 25, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/140

Log entry

lan_mouse::emulate] wayland backend not available: the requested global was not found in the registry

I tried wayland to wayland.

Originally created by @xf- on GitHub (May 25, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/140 Log entry ``` lan_mouse::emulate] wayland backend not available: the requested global was not found in the registry ``` I tried wayland to wayland.
Author
Owner

@feschber commented on GitHub (May 25, 2024):

This log is unrelated. Did you update xdg-desktop-portal-kde as well?

<!-- gh-comment-id:2131059958 --> @feschber commented on GitHub (May 25, 2024): This log is unrelated. Did you update xdg-desktop-portal-kde as well?
Author
Owner

@xf- commented on GitHub (May 25, 2024):

yes - xdg-desktop-portal-kde 6.0.90-1

<!-- gh-comment-id:2131062920 --> @xf- commented on GitHub (May 25, 2024): yes - xdg-desktop-portal-kde 6.0.90-1
Author
Owner

@feschber commented on GitHub (May 25, 2024):

Ah I just noticed: they apparently implemented the input-capture portal. So that's interesting. I will have to test that later!

<!-- gh-comment-id:2131091680 --> @feschber commented on GitHub (May 25, 2024): Ah I just noticed: they apparently implemented the input-capture portal. So that's interesting. I will have to test that later!
Author
Owner

@xf- commented on GitHub (May 25, 2024):

I'm not in a hurry, just reported the issue. It is still a beta.

<!-- gh-comment-id:2131093762 --> @xf- commented on GitHub (May 25, 2024): I'm not in a hurry, just reported the issue. It is still a beta.
Author
Owner

@feschber commented on GitHub (Jun 18, 2024):

Got around to testing this. I am getting valid barriers but not receiving any input events... Will have to see if thats a kwin bug or what else is going on here.

<!-- gh-comment-id:2176765231 --> @feschber commented on GitHub (Jun 18, 2024): Got around to testing this. I am getting valid barriers but not receiving any input events... Will have to see if thats a kwin bug or what else is going on here.
Author
Owner

@feschber commented on GitHub (Jun 19, 2024):

Update: Got in contact with KDE devs. Should be fixed in 6.1.1 it was a type mismatch in dbus

<!-- gh-comment-id:2178256251 --> @feschber commented on GitHub (Jun 19, 2024): Update: Got in contact with KDE devs. Should be fixed in 6.1.1 it was a type mismatch in dbus
Author
Owner

@feschber commented on GitHub (Jun 28, 2024):

Okay TLDR:

Plasma 6.1.0 introduced the input-capture portal, i.e. the "frontend" to libei.
Previously, the layer-shell backend was used as a fallback, which is basically a 1px wide window that grabbed the mouse on the edge of the screen.

Now with the plasma input capture portal there were two issues:

  • Plasma used a wrong type in serialization, causing deserialization to fail in ashpd. This is now fixed in 6.1.1 after I reported it.

  • The second issue is that plasma does not (yet?) report barrier_ids, when input capture is activated.
    This is an optional addition of the spec, however I expected it to be implemented, which is not the case.
    So keep in mind, this is not a plasma bug and please dont report bugs ;).
    The Input Capture Portal works by defining "barriers" and giving them an id. Then, when input capture is activated, The compositor reports the position and optionally a barrier id, which I can use to check which barrier was activated (i.e. which lan-mouse client).

There is several ways to go about this:

  • Wait for plasma to implement barrier_ids & only support one client until this is done
  • Add the option to fallback to the layer-shell capture backend (I'd still prefer this to be a fallback)
  • Work around barrier_ids by calculating the activated barrier from the activation position of the cursor

Nr. 3 is probably the most favourable.

<!-- gh-comment-id:2196505191 --> @feschber commented on GitHub (Jun 28, 2024): Okay TLDR: Plasma 6.1.0 introduced the input-capture portal, i.e. the "frontend" to libei. Previously, the layer-shell backend was used as a fallback, which is basically a 1px wide window that grabbed the mouse on the edge of the screen. Now with the plasma input capture portal there were two issues: - [x] Plasma used a wrong type in serialization, causing deserialization to fail in [ashpd](https://github.com/bilelmoussaoui/ashpd). This is now fixed in 6.1.1 after I reported it. - [ ] The second issue is that plasma does not (yet?) report `barrier_ids`, when input capture is activated. This is an **optional** addition of the spec, however I expected it to be implemented, which is not the case. So keep in mind, this is **not** a plasma bug and please dont report bugs ;). The Input Capture Portal works by defining "barriers" and giving them an id. Then, when input capture is activated, The compositor reports the position and _optionally_ a barrier id, which I can use to check which barrier was activated (i.e. which lan-mouse client). There is several ways to go about this: - Wait for plasma to implement `barrier_ids` & only support one client until this is done - Add the option to fallback to the layer-shell capture backend (I'd still prefer this to be a fallback) - Work around barrier_ids by calculating the activated barrier from the activation position of the cursor Nr. 3 is probably the most favourable.
Author
Owner

@xf- commented on GitHub (Jun 28, 2024):

Is the second issue 6.1.1 input (mouse, keyboard) freezes as soon as I touch edge?

<!-- gh-comment-id:2196891680 --> @xf- commented on GitHub (Jun 28, 2024): Is the second issue 6.1.1 input (mouse, keyboard) freezes as soon as I touch edge?
Author
Owner

@DrYak commented on GitHub (Jun 28, 2024):

@xf- : yup exactly. (My setup suffers the same).

<!-- gh-comment-id:2196942504 --> @DrYak commented on GitHub (Jun 28, 2024): @xf- : yup exactly. (My setup suffers the same).
Author
Owner

@feschber commented on GitHub (Jun 28, 2024):

The specific reason, why its getting stuck is actually because ashpd does not yet correctly handle the case of no barrier_id being sent.
Its already fixed but not yet in a new release.

<!-- gh-comment-id:2197517891 --> @feschber commented on GitHub (Jun 28, 2024): The specific reason, why its getting stuck is actually because ashpd does not yet correctly handle the case of no barrier_id being sent. Its already fixed but not yet in a new release.
Author
Owner

@xf- commented on GitHub (Jun 28, 2024):

The specific reason, why its getting stuck is actually because ashpd does not yet correctly handle the case of no barrier_id being sent. Its already fixed but not yet in a new release.

I build the main branch and I had the issue. You mean committed and pushed towards main or a git release?

<!-- gh-comment-id:2197522069 --> @xf- commented on GitHub (Jun 28, 2024): > The specific reason, why its getting stuck is actually because ashpd does not yet correctly handle the case of no barrier_id being sent. Its already fixed but not yet in a new release. I build the main branch and I had the issue. You mean committed and pushed towards main or a git release?
Author
Owner

@feschber commented on GitHub (Jun 28, 2024):

No, the barrier_id is fixed in the ashpd main branch. It still requires a workaround in lan-mouse and an update of ashpd after there is a new ashpd release.

<!-- gh-comment-id:2197555186 --> @feschber commented on GitHub (Jun 28, 2024): No, the barrier_id is fixed in the ashpd main branch. It still requires a workaround in lan-mouse and an update of ashpd after there is a new ashpd release.
Author
Owner

@feschber commented on GitHub (Jun 28, 2024):

You can now set

capture_backend = "LayerShell"

in config.toml as a workaround

<!-- gh-comment-id:2197720109 --> @feschber commented on GitHub (Jun 28, 2024): You can now set ```toml capture_backend = "LayerShell" ``` in `config.toml` as a workaround
Author
Owner

@DrYak commented on GitHub (Jul 1, 2024):

(Any ETA when you could tag a new release with capture_backend ?)

<!-- gh-comment-id:2200456337 --> @DrYak commented on GitHub (Jul 1, 2024): (Any ETA when you could tag a new release with `capture_backend` ?)
Author
Owner

@xf- commented on GitHub (Jul 1, 2024):

You can now set

capture_backend = "LayerShell"

in config.toml as a workaround

Didn't work, maybe I added it in wrong spot, but via cli argument it works :)

<!-- gh-comment-id:2200461487 --> @xf- commented on GitHub (Jul 1, 2024): > You can now set > > ```toml > capture_backend = "LayerShell" > ``` > > in `config.toml` as a workaround Didn't work, maybe I added it in wrong spot, but via cli argument it works :)
Author
Owner

@feschber commented on GitHub (Jul 1, 2024):

It should go on the top of the file

<!-- gh-comment-id:2200650250 --> @feschber commented on GitHub (Jul 1, 2024): It should go on the top of the file
Author
Owner

@feschber commented on GitHub (Jul 19, 2024):

This should now be fixed.
Unfortunately, there seems to be an issue with the "cursor shake" desktop effect on plasma, which results in a captured cursor appearing visible again, so please be aware of that ;)

https://bugs.kde.org/show_bug.cgi?id=490495

<!-- gh-comment-id:2239187121 --> @feschber commented on GitHub (Jul 19, 2024): This should now be fixed. Unfortunately, there seems to be an issue with the "cursor shake" desktop effect on plasma, which results in a captured cursor appearing visible again, so please be aware of that ;) https://bugs.kde.org/show_bug.cgi?id=490495
Author
Owner

@DrYak commented on GitHub (Jul 25, 2024):

(Any ETA when you'll tag the fixed version, so I update the TumbleWeed package to not omit the InputCapture backend anymore?)

<!-- gh-comment-id:2251221757 --> @DrYak commented on GitHub (Jul 25, 2024): (Any ETA when you'll tag the fixed version, so I update the TumbleWeed package to not omit the InputCapture backend anymore?)
Author
Owner

@feschber commented on GitHub (Jul 26, 2024):

I want to do some more testing and make sure I didnt break anything. I'll do my best to finish that this weekend

<!-- gh-comment-id:2252161935 --> @feschber commented on GitHub (Jul 26, 2024): I want to do some more testing and make sure I didnt break anything. I'll do my best to finish that this weekend
Author
Owner

@feschber commented on GitHub (Jul 30, 2024):

@DrYak I updated the release ;)

<!-- gh-comment-id:2258021856 --> @feschber commented on GitHub (Jul 30, 2024): @DrYak I updated the release ;)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/lan-mouse#59
No description provided.