Would it be possible do tag a release (for packaging) ? The 1.0 tag is pretty old and I have used the current master for years without any issue.

Whenever I open a window, xedgewarp bails out and crashes.

Log here:

http://pastebin.com/D1FiCBCd

The error is:

ERROR: Received error: Could not register for events on window, bailing out.

Here is a problem I have run into several times now. It may seem hard to reproduce under practical conditions, but I have run into this bug twice within the last hour.

To reproduce:

Turn torus mode on (with -t).

Slowly move the mouse to touch the edge of the screen and then stop the mouse right after the warp.

Move the mouse in the opposite direction. It won't warp to where it came from. It's stuck.

You can "reset" the warping ability by moving the mouse forward and backward a little bit and the warping will happen again.

If this explanation was difficult to follow, I can write a longer more detailed example of the problem for you.

Relevant debug log:

[src/event.c:100] DEBUG: Entering event loop.
[src/event.c:182] DEBUG: Touching a dead border segment at 2674 / 899.
[src/pointer.c:127] DEBUG: Successfully warped pointer from 2674 / 899 (639) to 2674 / 0 (639)
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:182] DEBUG: Touching a dead border segment at 2361 / 0.
[src/pointer.c:127] DEBUG: Successfully warped pointer from 2361 / 0 (639) to 2361 / 899 (639)
[src/event.c:182] DEBUG: Touching a dead border segment at 2362 / 899.
[src/pointer.c:127] DEBUG: Successfully warped pointer from 2362 / 899 (639) to 2362 / 0 (639)
[src/event.c:182] DEBUG: Touching a dead border segment at 2363 / 0.
[src/pointer.c:127] DEBUG: Successfully warped pointer from 2363 / 0 (639) to 2363 / 899 (639)
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.
[src/event.c:178] DEBUG: Pointer has already been warped, not warping it again.

Can you please document which packages are required to build xedgewarp?

Do we need development files for libX11, X11 Protocol headers or what?

$ make
rm -f xedgewarp obj/xedgewarp.o obj/pointer.o obj/extensions.o obj/randr.o obj/event.o obj/util.o obj/fake_outputs.o
rm -f man/*.1 man/*.xml
rm -f test/GLOB*
gcc -D'__VERSION="heads/master-0-g04ca182"' -Iinclude -std=gnu99 -Wall -Wundef -Wshadow -o obj/xedgewarp.o -c src/xedgewarp.c
In file included from include/all.h:4:0,
                 from src/xedgewarp.c:2:
include/externals.h:13:36: fatal error: X11/extensions/XInput2.h: No such file or directory
 #include <X11/extensions/XInput2.h>
                                    ^
compilation terminated.
Makefile:33: recipe for target 'obj/xedgewarp.o' failed
make: *** [obj/xedgewarp.o] Error 1

I noticed that in Chrome, when xedgewarp is running, the cursor doesn't change on hovers etc.

With two outputs 200x200+0+0 and 200x200+200+100, the torus behavior doesn't consider warping behavior. So we have these two, inconsistent, warps with torus behavior:

+-----+
|<   >|
|     +-----+
|     |     |
+-----+     |
      |     |
      +-----+

+-----+
|     |
|     +-----+
|<    |    >|
+-----+     |
      |     |
      +-----+

It should be discussed whether this is the behavior we should expect or whether it should be changed to consider warping so that the first case becomes

+-----+
|<    |
|     +-----+
|     |    >|
+-----+     |
      |     |
      +-----+

A valid solution would also be to make this a configurable behavior.

Also (C) information

I have DP-1 (3440x1440) sitting above eDP-1 (1920x1080).

I run xedgewarp -m relative -t horizontal

When hitting the vertical edge of eDP1 i'd like it to warp proportionally to the horizontal bottom of DP-1.

I hope that makes sense. If not i'll try and make a pretty ascii picture :)

I think it would be great to have the possibility to fork xedgewarp on startup. Something like "xedgewarp -d". I could implement this.

There are two modes that come to mind of how a user wants the pointer to be warped:

• Simply warp the pointer as much as needed and no more, i.e., warp it to the very edge of the output. This is the current (and implemented) behavior.
• Figure out the relative position of the pointer on the source output and warp it to the corresponding relative position on the target output.

• Add to install / uninstall target

But think about it first.

Warping the pointer from the left to the right screen on the top should not cause events for the top border on the right screen.

+----+
|    |----+
+----|    |   
     +----+

This will only case trouble for more outputs.

Make sure it's >= 2.0 as Xinput1 used the extension offset which we do not handle for Xinput.

Warping on the dead border segment on the left screen should warp to the nearest screen on the right.

     +----+
+----|    |   
|    |----+
|    |   
|    |----+
+----|    |   
     +----+

… via -b.

This eliminates Xlib from the code. This will only be possible in the distant feature because xcb-xinput, in any released version, is currently unusable and broken. It works better in the current git version, but we cannot use that yet to not force users to install xcb-xinput from source.

Define formatting rules and apply them.

In pacman, when you move off of the left edge of the screen, you end up at the right part of the screen.

I want a sort of "wrap around" effect for my cursor, so if I go to the leftmost edge of the leftmost monitor, I warp to the rightmost edge of the rightmost monitor. And similarly for the top and bottom.

Top/bottom and left/right should be configurable separately.

I don't know if I would actually use this long term, but I might, and it would be really novel to try.

Tests currently fall back to default pointer motion events since warp_pointer won't generate the raw motion event we ususally listen for. Fix this.

… and add a badge.

This is probably going to be painful due to the dependencies.

We could have a --quiet switch, but since that requires the user to explicitly add it, explicitly enabling logging is probably better. Best thing would be a -l trace|debug|error which defaults to error.

Not sure how to proceed.

makepkg -si
==> Making package: xedgewarp 1.1-1 (Thu 22 Dec 2022 10:18:09 PM EST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found v1.1.tar.gz
==> Validating source files with sha256sums...
    v1.1.tar.gz ... Passed
==> Extracting sources...
  -> Extracting v1.1.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Starting build()...
rm -f xedgewarp obj/event.o obj/extensions.o obj/fake_outputs.o obj/pointer.o obj/randr.o obj/util.o obj/xedgewarp.o
rm -f man/*.1 man/*.xml
rm -f test/GLOB*
gcc -D'__VERSION="1.1"' -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Iinclude -std=gnu99 -Wall -Wundef -Wshadow -o obj/event.o -c src/event.c
gcc -D'__VERSION="1.1"' -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Iinclude -std=gnu99 -Wall -Wundef -Wshadow -o obj/extensions.o -c src/extensions.c
gcc -D'__VERSION="1.1"' -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Iinclude -std=gnu99 -Wall -Wundef -Wshadow -o obj/fake_outputs.o -c src/fake_outputs.c
gcc -D'__VERSION="1.1"' -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Iinclude -std=gnu99 -Wall -Wundef -Wshadow -o obj/pointer.o -c src/pointer.c
gcc -D'__VERSION="1.1"' -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Iinclude -std=gnu99 -Wall -Wundef -Wshadow -o obj/randr.o -c src/randr.c
gcc -D'__VERSION="1.1"' -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Iinclude -std=gnu99 -Wall -Wundef -Wshadow -o obj/util.o -c src/util.c
src/util.c: In function ‘bail’:
src/util.c:11:5: error: format not a string literal and no format arguments [-Werror=format-security]
   11 |     errx(EXIT_FAILURE, message);
      |     ^~~~
cc1: some warnings being treated as errors
make: *** [Makefile:34: obj/util.o] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

Print a final report when executing tests as with a lot of tests it can become hard to see whether any of them failed.

I have xedgewarp installed with my screen setup: at the bottom: 3440x1440, above, left corner, 712x400 ... but when I move the cursor on top of the big screen, where not the little one is above, the cursor seems to be in nowhere, and i must move it left now to get it on the little screen. Not what i have expected ...

• -v switch, too

The "make" command fails if a2x is not installed (used for generating xedgewarp man pages). However, a2x is not listed as a dependency.

The solution is to install the asciidocs package before running make:

sudo apt-get install asciidoc

(or equivalent package install command)

When the mouse is dragged exactly into the corner of an output, both possible directions should be considered.