Reproduced, but the conditions are narrow. The barrier must align with the edge of a monitor and the movement _vector_ must not overlap with the barrier.
e.g. if you're in that corner, moving by 1/1 will block, moving by 1/2 won't block.
Cause is that the fixes code that calculates whether a barrier is blocking doesn't know about screen edges. So the picture the fixes code sees for a movement a to b is
a X
\X
\ b
Which is permitted since the movement goes just past the barrier. The RandR
code to clamp to monitors sees this picture:
Reproduced, but the conditions are narrow. The barrier must align with the edge of a monitor and the movement _vector_ must not overlap with the barrier.
e.g. if you're in that corner, moving by 1/1 will block, moving by 1/2 won't block.
Cause is that the fixes code that calculates whether a barrier is blocking doesn't know about screen edges. So the picture the fixes code sees for a movement a to b is
a X
b
\X
\
Which is permitted since the movement goes just past the barrier. The RandR
code to clamp to monitors sees this picture:
+----- ------- ----+-- ------- ------- -----+
|b |
+-- ------- ------- -----+
| | |
| | |
| | |
| a | |
+---------------\+ |
\ |
Which too is allowed since the destination exists in RandR space. The two
operations are quite separated in the server, merging them is tricky.
As a workaround for now, I suggest either extending the barrier to the bottom of the second monitor like this:
+----- ------- ----+-- ------- ------- -----+
X-- ------- ------- -----+
| | |
| | |
| | |
| X |
+----------------X |
X |
X |
or, alternatively, to create a horizontal barrier in that corner that shares
the same endpoint with the vertical one.