There's a lot of duplicated cleanup code, I think it should probably be refactored into using goto.

I started xrestrict with xcb, but xcb bindings for XInput2 were not ready for my use. As a result I'm mixing xlib and xcb calls. To reduce dependencies, and for uniformity, I want to eventually eliminate xcb code.

--bottom works in other cases, but with --full it confines the cursor to the bottom of the screen, rather than aligning the effective area to the bottom.

I'm trying to build xrestrict on Ubuntu 16.04 and getting this error:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
./configure: line 3459: syntax error near unexpected token `X11,'
./configure: line 3459: `PKG_CHECK_MODULES(X11, x11)'

At present xrestrict does not attempt to use information about the physical size of monitors. On monitors with non-square pixels this could result in incorrect aspect ratios. I am unaware of practical cases where this would be a problem, however I'd prefer to be robust to this issue.

Using xinput to discover the XID of the pointer device is not particularly user friendly. It might be desirable to allow xrestrict to affect all pointer devices with "Abs X" and "Abs Y" axes. This would not affect mice nor touchpads in their default configuration.

If I issue xrestrict -d 15 -c 0 to restrict my tablet to my left monitor, it can actually reach the first column of pixels on my right monitor. It may not be practical to address in all cases due to floating point inaccuracy but it should be addressed where possible.

If a user uses xrestrict to confine their tablet to their left screen, and later wants to confine it to their right screen, they cannot do this. This is because interactive selection requires they be able to click on the right screen, but they've already confined themselves to their left screen.

To work around this, a user may unplug and replug their device but that is ugly.

xrestrict could reset all "Coordinate Transformation Matrix"s to identity prior to grabbing pointers, but that potentially munges state the user may wish to keep. In practice I believe this to be acceptable though, as tablets seem to be the most common type of device with absolute X and Y axes, and it seems unlikely a user would have two connected at once. Therefore the following procedure ought to be good enough:

1. Find all devices with absolute X and Y axes with non-identity "Coordinate Transformation Matrix"s.
2. Remember these matrices
3. Reset all matrices to identity
4. Perform grab
5. Re-apply all matrices
6. Apply xrestrict matrix

Rather than restricting the tablet to a single screen, a user may only wish to fix their aspect ratio. xrestrict should support this use case (at which point the name xrestrict becomes a bit strange).

Use a third party library? I don't particularly like getopt, but I think as soon as I add the remaining command line flags things are going to be pretty messy without some cleanup.

It's possible this is not an issue unique to --full but it's just easier to notice. That might suggest a hardware issue, otherwise there may be something strange with either X.org or the Coordinate Transformation Matrix I generate for --full.

rectangle_align() will align the left, right, top, or bottom edges of the reference and alignee rectangles. Top left is an Ok default, but I made it configurable with the intention that eventually users would be able to specify this alignment.

Though my tablet's logical dimensions and physical dimensions are nearly identical, it's entirely possible some tablets are not, xrestrict should take this into account.

When there is only one CRTC in use, xrestrict should not need to be told which one to use. In fact it might make sense to just default to CRTC 0 in all cases.

As mentioned in #6 , requiring the user to figure out the XID of their tablet before invoking xrestrict is not user friendly. A relatively user friendly user interaction is as follows:

1. User invokes xrestrict --interactive or similar flag
2. User is prompted to use their tablet to click on the monitor they wish to restrict the pointer to.
3. User uses desired tablet device to click on the monitor they wish to use.
4. xrestrict uses this information to discover both the monitor (output+crtc) and the tablet device id.

Open problems:
To support this interaction, each tablet device on the system must be able to reach every screen. This requires resetting the "Coordinate Transformation Matrix" for every tablet to the identity matrix. This might be undesirable, and in case of a bug (or if the user hard-kills xrestrict) could alter system state ("Coordinate Transformation Matrix" of all tablets) undesirably.

Because interactive selection uses the desired device to select the CRTC to use, it is not possible for the user to switch CRTCs in interactive mode. One must first allow the desired device to reach all CRTCs, which may be done any number of ways. A workaround is described in README.md. Another workaround is to simply unplug and replug the device which resets the Coordinate Transformation Matrix to identity, then invoke xrestrict.

Another alternative which might be more user friendly is during the cursor grab, any absolute pointers which move, have their Coordinate Transformation Matrix reset to identity. Drawbacks of this are: user may bump another device which would reset its coordinate Transformation Matrix against the users wishes (mitigation strategy: once the user has selected CRTC, re-set all other matrices). Another drawback is that the cursor jumps when altering its coordinate transformation matrix, perhaps the original proposal is best.

Current "best" proposal: When starting xrestrict in interactive mode, store the non-identity matrices for all devices with absolute X and Y axes. After selecting a screen in interactive mode, restore these matrices before finally calculating and applying the final matrix (Redundantly sets the matrix of the target device twice, but this can be easily mitigated).

Seems like this does not work with more recent versions of autotools? Are you still maintaining this utility? Are you aware of a more recent similar utility?

I would like to support something like the following user interaction:

1. xrestrict --device-file=~/.config/xrestrict/mytablet -i
2. User performs interactive selection of screen
3. xrestrict saves persistent identifier to provided file
4. xrestrict --device-file=~/.config/xrestrict/mytablet [OPTIONS] behaves the same as xrestrict -d $DEVICEID [OPTIONS] except $DEVICEID is discovered based on information in provided file

At present USB VID:PID:Interface numbers seem like the best choice for a persistent identifier.

On linux this "requires" retrieving the "Device Node" property from the XInput2 device, and then querying the device node via udev to discover the VID:PID:Interface numbers.

At least on FreeBSD the XInput2 devices do not appear to have a "Device Node" property so that may not work.

Alternatively, some combination of property values, available valuators and buttons, etc might be combined to create a "fingerprint" of a device, but that's a lot of work and seems like it would be brittle as well.

Finally, this might make sense to implement as a separate utility, the proposed user interaction could be emulated via something like:

1. xfindusbdev $(xrestrict --verbose -i | grep XID | cut -f 2) > ~/.config/xrestrict/mytablet
2. User performs interactive selection of screen
3. xrestrict -d $(xfindusbdev --usbid-file ~/.config/xrestrict/mytablet) [OPTIONS]

The final problem with this is that VID:PID:Interface is not completely unique, two tablet devices of the same make and model may share this triple unfortunately. However, I feel that it's unique enough for the purposes of this utility and most of its potential users.