Using KDE Connect remote control doesn't make the cursor visible

[k-wax]

Looks like only tapping can bring up the cursor. Moving/scrolling keeps the cursor hidden.

[Airblader]

Can you please check the output of xev -event mouse when you scroll? Does scrolling that way generate any events and if so, what is that output?

[k-wax]

here i move the mouse first and then do a two finger scroll:

MotionNotify event, serial 25, synthetic NO, window 0x3a00001, root 0xd4, subw 0x0, time 209525011, (306,208), root:(1110,232), state 0x10, is_hint 0, same_screen YES

MotionNotify event, serial 25, synthetic NO, window 0x3a00001, root 0xd4, subw 0x0, time 209525028, (306,206), root:(1110,230), state 0x10, is_hint 0, same_screen YES

ButtonPress event, serial 25, synthetic NO, window 0x3a00001, root 0xd4, subw 0x0, time 209525545, (306,206), root:(1110,230), state 0x10, button 5, same_screen YES

ButtonRelease event, serial 25, synthetic NO, window 0x3a00001, root 0xd4, subw 0x0, time 209525545, (306,206), root:(1110,230), state 0x1010, button 5, same_screen YES

[Airblader]

I assume the problem here is that no raw events are emitted. I don't really know what we can do against that – we don't listen for MotionNotify because selecting these events breaks many applications, in particular browsers.

[albertvaka]

KDE Connect uses QCursor::setPos() from Qt. I don't think this is a bug in Qt, though.... KDE apps that hide the mouse cursor when you type (eg: Konsole, Kate) do manage to make it visible again when you use KDE Connect to move the cursor. Most likely, they check something like if cursor_position != previous_cursor_position. Is this not an option for unclutter-xfixes?

[Airblader]

The fundamental way unclutter-xfixes works is by using raw events over normal events and over polling the mouse position (and by using the xfixes extension over other things).

I don't want to constantly poll the mouse position because it generates a constant CPU load. And selecting normal mouse events causes severe problems with certain applications.

I'm open for other ways if we can find a reasonable one.

[albertvaka]

How can I generate an event so that unclutter realizes that the cursor should be made visible?

[Airblader]

Perhaps through the XTEST extension, but I'm not sure that works properly for raw events. I'd also be open to implementing signal handlers for this.

[albertvaka]

We already include XTest, so if you can tell me which event should I send to make the cursor visible I can easily add it.

[Airblader]

You'd have to send RawMotion and RawButtonPress, see the last function here: https://github.com/Airblader/unclutter-xfixes/blob/master/src/event.c (the file is overall pretty simple and a little but above you'll find how we currently detect relevant events).

I'm not entirely sure if emitting these events could interfere with other things, so you'll have to test that.

[Airblader]

Is there an open issue in KDE Connect for this? It would make more sense to track it there, I think.

[willdeberry]

I had a very similar issue with specific capacitive screens and had to adjust for that. You may want to check out https://github.com/Airblader/unclutter-xfixes/pull/29 and see if it helps in this case as well.

[FunctionalHacker]

This does work on vanilla unclutter, not on unclutter-xfixes. Just an observation.

[sandsmark]

the fact that it uses QCursor doesn't matter, unclutter doesn't unhide even when calling XTestFakeMotionEvent directly.

I've tried calling XFixesShowCursor myself to "override" unclutter, but that doesn't help either.

For some reason Synergy works, though, so might want to look into what that is doing.

edit: never mind, I don't know why it didn't work earlier (I probably forgot to rebuild), but XTestFakeMotionEvent(display, -1, position.x(), position.y(), CurrentTime); XFlush(display); does indeed work.