clicking using trackpoint is a pain on some screens
pony-montana opened this issue · 7 comments
Info
dwl version: here https://github.com/pony-montana/simple-dwl is based on lastest master commit + some patches
wlroots version: 0.16.2
Description
Using trackpoint and clicking mouse-integrated-buttons (left button in particular) on my thinkpad x200 result in a painful experience on some screens.
The problem is: when I click, the screen registers some micro-movements from trackpoint input; so clicking doesnt produce effects (or, in some screens, it produce the effect of "keep-clicked-and-drag").
Only if I click the left button when I'm not touching the trackpoint all goes fine. But this result in a pretty slow user experience, not the way a trackpoint is intended to be used.
In particular, I found this problem in some qt-screens (navigation menus in electrum bitcoin wallet) and in firefox options.
For example, clicking on web-content and on the main firefox interface works fine. The problem comes only on some screen, when I click on menus that sovrappose to the main screen.
This problem is not present when I click on dwl-bar for example.
Can you reproduce in sway (or in another non-minimal compositor)?
Using sway I don't have this issue (on the same machine, with all the same libraries and same environment).
So I think that there are problems with compositing. On screens where I have problems I feel like it "reacts to trackpoint inputs de-focusing from the thing that is on-focus in that moment" where it would need just to move the cursor on the screen and nothing else.
The problem is also present on plain dwl last main commit and plain dwl 4.0.
Could you test in wlroots-next?, I suspect this happens because a hack I did.
Tested wlroots-next branch with wlroots compiled at last commit and still the issue is present.
I isolated some lines in the code (from main branch) that when are changed the issue is solved (but other non-intended behaviour happens):
in dwl.c, if I remove the lines number 1691 and 1692 in the motionnotify function like that:
dwl.c
if (cursor_mode == CurPressed && !seat->drag) {
if ((type = toplevel_from_wlr_surface(
seat->pointer_state.focused_surface, &w, &l)) >= 0) {
c = w;
surface = seat->pointer_state.focused_surface;
/* !!!!!! sx = cursor->x - (type == LayerShell ? l->geom.x : w->geom.x); !!!!! line 1961
!!!!!! sy = cursor->y - (type == LayerShell ? l->geom.y : w->geom.y); !!!!! line 1962 */
}
}Then the issue is solved, but strange new issues happens when keeping leftbutton pressed trying to select text on the screen and the cursor goes out of the focused window (because the function is no-more uptating sx and sy).
Another way (not correlated with the previous) to solve my issue is modifying in this way client.h around the line 100:
client.h
case WLR_XDG_SURFACE_ROLE_TOPLEVEL:
/* c = xdg_surface->data; line 100
type = c->type; line 101
goto end; line 102 */
return -1; /*<----- !!!NEW ADDED LINE!!! */
case WLR_XDG_SURFACE_ROLE_NONE:
return -1;In this way we solve my issue but we have new strange issues similar to what we obtain with the first method, but not totally identical.
Hoping this will help.
The problem as I try to understand it is that the surfaces where this misbehaviour happens seems to not be recognized by compositor and differentiated from the layer they are on top (the surfaces I talk about are nor popup nor they are on the same level of the base surface of the window).
p.s. the chanche I say something wrog are very high, hoping that someone more expert will find something useful in my noob digressions :)