The top and bottom side of the screens are not clickable. (for example : browser tabs on the top or a plasma panel on the left) On the right and bottom side I have no problems. If I move the mouse by one or more pixel, it becomes clickable again. After bisecting it, the problem appeared with 0c5da45cfce79454d55b6a827a245e9c5724cd57 SOFTWARE/OS VERSIONS Wayland OS : Archlinux KDE Plasma Version: 5.25.90 KDE Frameworks Version: 5.98 Qt Version: 5.15.6
Can you run browser with WAYLAND_DEBUG=1 and move the cursor at the top edge where the tabs are not clickable? One thing though: can you move pointer from bottom to top, if the pointer leaves the surface, it will help us to catch that case. Also, if possible, please keep the log as short as possible, i.e. start the web browser, move the cursor to the top edge, click, and close the browser, e.g. by pressing Ctrl-Q.
Can you clarify also if the first sentence should read that the top and left are not clickable
Is this on a single monitor?
(In reply to Vlad Zahorodnii from comment #1) > Can you run browser with WAYLAND_DEBUG=1 and move the cursor at the top edge > where the tabs are not clickable? > > One thing though: can you move pointer from bottom to top, if the pointer > leaves the surface, it will help us to catch that case. Also, if possible, > please keep the log as short as possible, i.e. start the web browser, move > the cursor to the top edge, click, and close the browser, e.g. by pressing > Ctrl-Q. Hello Vlad, I didn't get any wayland logs from Chromium or Firefox (probably not native wayland) so I used Konsole without a window decoration. I managed to reproduce the same problem with the menus. On the log file, the interesting things start at line 2652. When I try to move the mouse a bit more upper (when the cursor is already on the top), the menu hovering looks flickering. It spammed a lot of lines as it looks to enter / leave multiple times the surface. I also noticed an interesting behaviour. In this case I have another window opened just behind the problematic one. If I click on the top of the current window, the other window is showing up. Also, for windows with a real window decoration, I cannot reproduce the problem. I also added a second file with wayland logs for plasmashell when I try to click on kickoff icon with a vertical panel on the left. I'm not sure it will be useful because there is probably a lot of unrelated stuff like the hover popup.
Created attachment 152287 [details] Moving cursor from bottom to top
Created attachment 152288 [details] Plasma wayland logs
Created attachment 152289 [details] wayland-info
(In reply to David Edmundson from comment #3) > Is this on a single monitor? Hello David, Indeed, the top and left are not clickable but only for plasma panels or windows without a decoration (eg: browsers) I'm using two identical screens (27'' / 1440p). I also tried with a single 22" / 1080p screen and the result is the same. I attached the wayland-info output in case you could find something useful.
Is there anything interesting about your input devices? In particular I'm looking for a calibration matrix set? Given you bisected I assume you can build your own kwin. I have a theory, but it's unproven: Can you mod surface_interface.cpp:773 to read: ``` SurfaceInterfacePrivate::inputContains(const QPointF &position) { return contains(position); } ``` deleting everything from '&& ......' and tell me if that changes anything?
(In reply to David Edmundson from comment #9) > Is there anything interesting about your input devices? In particular I'm > looking for a calibration matrix set? > > > Given you bisected I assume you can build your own kwin. > I have a theory, but it's unproven: > > Can you mod surface_interface.cpp:773 to read: > > ``` > SurfaceInterfacePrivate::inputContains(const QPointF &position) > { > return contains(position); > } > ``` > deleting everything from '&& ......' > > and tell me if that changes anything? It's still the same with the changes to surface_interface.cpp. But you were totally right about the input devices. I currently use a Logitech G502 and I can't reproduce the problem with other mouses (even another Logitech model). With the G502, the problem appears only in Adaptive mode for the acceleration profile. It's ok on the Flat mode. I also tried with different DPI on the different mouses (configurable with a button on the logitech ones), it's the same behavior.
ok, I have a new theory. Sorry to mess you about but it's easier as you can reproduce. Can you change pointer_input.cpp static bool screenContainsPos(const QPointF &pos) - if (output->geometry().contains(pos.toPoint())) { + if (output->geometry().contains(QPoint(std::floor(pos.x()), std::floor(pos.y())))) { I'm rounding a point during the check, but if our mouse ends up at -0.4 due to some acceleration that would incorrect say we're on screen, not auto-correct but then pass a value not valid to our surfaces
We have a similar report in Bug 459373
(In reply to David Edmundson from comment #11) > ok, I have a new theory. Sorry to mess you about but it's easier as you can > reproduce. > > Can you change pointer_input.cpp > > static bool screenContainsPos(const QPointF &pos) > > - if (output->geometry().contains(pos.toPoint())) { > + if (output->geometry().contains(QPoint(std::floor(pos.x()), > std::floor(pos.y())))) { > > I'm rounding a point during the check, but if our mouse ends up at -0.4 due > to some acceleration that would incorrect say we're on screen, not > auto-correct but then pass a value not valid to our surfaces Your new theory is totally right, the problem is gone ! Do you want me to add some debug messages to display the pos values if you want to be sure ?
It's fine, I'll make a MR. Thanks again!
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2998
Git commit e924b1cb231632e53a405a04a24ae63538aa37e1 by David Edmundson. Committed on 26/09/2022 at 09:37. Pushed by davidedmundson into branch 'master'. Fix clamping in screenContainsPos QRect.contains(somePointF.toPoint()) will round the values. This is problematic for the case of a mouse being at -0.4, we will consider it in bounds for the screen, but obviously this doesn't match any surfaces. The detection and confineToBoundingBox need to behave the same and floor. M +2 -1 src/pointer_input.cpp https://invent.kde.org/plasma/kwin/commit/e924b1cb231632e53a405a04a24ae63538aa37e1
Git commit c45d26a334123dd1460e478826c4dcaf756b8211 by David Edmundson. Committed on 26/09/2022 at 09:53. Pushed by davidedmundson into branch 'cherry-pick-e924b1cb'. Fix clamping in screenContainsPos QRect.contains(somePointF.toPoint()) will round the values. This is problematic for the case of a mouse being at -0.4, we will consider it in bounds for the screen, but obviously this doesn't match any surfaces. The detection and confineToBoundingBox need to behave the same and floor. (cherry picked from commit e924b1cb231632e53a405a04a24ae63538aa37e1) M +2 -1 src/pointer_input.cpp https://invent.kde.org/plasma/kwin/commit/c45d26a334123dd1460e478826c4dcaf756b8211
*** Bug 458673 has been marked as a duplicate of this bug. ***