Question on Compiling the Reader
sodface opened this issue · comments
Sorry to keep asking questions but I'm struggling with getting the reader to work unless I compile with debug flags. Attached is the config.c I'm using. In order to shoehorn it into an Alpine package, I'm copying in the config.c as sample-gesture-reader.c and then using make sample-gesture-reader as the build step. The packaging step renames the executable to sgestures.
If I patch out the debug flags:
--- ./Makefile.orig
+++ ./Makefile
@@ -41,7 +41,6 @@
$(CC) $(CFLAGS) $^ -o $@ $(LDFLAGS) -ludev -linput
-sample-gesture-reader: CFLAGS := $(DEBUGGING_FLAGS)
sample-gesture-reader: sample-gesture-reader.o $(SRC:.c=.o)
$(CC) $(CFLAGS) $^ -o $@ -lm
I have the issue previously noted where the only gesture recognized is a tap. If I don't patch the Makefile and compile with the debugging flags then it works well, I get North, South, East, West etc.
What am I doing wrong?
The packaging step renames the executable to sgestures
sgestures is just a renamed executable. It is a shell wrapper and you'll have to manually recompile to see changes.
Also it'll use the config defined in "$SGESTURES_HOME/config.c" rather than sample-gesture-reader.c. So updated sample-gesture-reader in the repo wan't affected the installed version.
I understand this is inconvenient for your usecase. Probably would be best to just always use the sample reader unless the user explicitly creates "$SGESTURES_HOME"... will add that later today
If I don't patch the Makefile and compile with the debugging flags then it works well, I get North, South, East, West etc.
I can reproduce. The problem happens when building without the DEBUG unset which controls MIN_LINE_LEN. Also seeing crashes when trying to pinch. Should be able to fix by tomorrow.
is just a renamed executable. It is a shell wrapper
Yes thanks, I got all that, it's just I've been trying to figure out the best way to package it for myself. I'm trying to stick with my normal Alpine based workflow. As of now I had decided to have two packages, one called "libsgestures" and one called "sgestures". The first one is based on the default make targets with sgestures.sh removed before packaging. The second was going to just be the compiled reader (installed to /usr/bin/sgestures) based on the config.c, which could change over time. So I would just reinstall the second package only as needed for an updated config.
I looked at sgestures.sh though to see how you were compiling the reader and I wasn't 100% sure what files were included with *.c I assumed it was the same SRC as sample-gesture-reader plus config.c, but I was having issues with just compiling those file with gcc outside of the Makefile due to the lack of the debug flags (but I didn't know that was the issue initially).
Line 14 in 9d8efad
Basically, I wasn't sure what was causing the issue with my gcc direct compiled reader vs. the make debug version.
As of now I had decided to have two packages, one called "libsgestures" and one called "sgestures". The first one is based on the default make targets with sgestures.sh removed before packaging.
With the 3766a7d you should be able to just drop your config.c into the source tree, and run make; make install to get the same behavior. You may have to delete ~/.config/sgestures, but now if that directory doesn't exist whatever config.c was present in the source (which will default to the sample) will be used when sgestures (the shell script) is invoked.
I looked at sgestures.sh though to see how you were compiling the reader and I wasn't 100% sure what files were included with *.c
Every c file in ~/.config/sgestures. Just so the user doesn't have to force everything into config.c
For the actual problem:
In gestures-private.h, change define MIN_LINE_LEN to 1 instead of 256. I need to do some more usability testing before I push this. Previously I found it annoying with trying to change directions. Like if you tried to make an "L" and go S -> E, it would likely get interpreted as S -> SE -> E despite a reasonable attempt to have a sharp transition.
I've been debating whether to just make bindings be flexible enough to treat these as the same vs changing the detection.
just drop your config.c into the source tree, and run make; make install
Works good.
change define MIN_LINE_LEN to 1 instead of 256
I tried it again, first at the default of 256 and then changed it to 1 as you said above. At 256, I would only see "TAP" and not "NORTH" or "SOUTH" etc. as I mentioned before, but before the action associated with NORTH and SOUTH gestures also wouldn't fire but this time it did... so just to restate- at 256 the gesture name wasn't printed to terminal but the associated action did seem to work. I changed to 1 and retested, now I get both, all gestures print to screen and the associated action fires.
For my use case, I think either 1 or 256 should work but 1 seems "better". Should I do more testing at 256?
You don't have to. If anything I'd like to know how well 1 works. Especially if you try short/long gestures and/or change directions.
Well, generally, I'm blown away by how well it works. It seems to me to be extremely responsive and very accurate. That said, here's what I'm seeing in testing this evening:
The great:
- Single direction, single finger, gestures seem to always work as expected regardless of swipe distance or duration. So North, South, East, and West.
- Taps seem to always work and the finger count seems to always be correct too, even more than 5 fingers!
The good:
- Multiple direction gestures work pretty well, eg an "L", shows as South East but also frequently as South South_East East, or just South South_East. I'd say 60-70% accuracy even when I'm concentrating on repeating the gesture the same way.
- Single direction, multiple finger swipes sometimes show as two actions, eg. a 3 finger swipe to the East may show as a two finger swipe East followed by a one finger swipe East even though I did it as a single gesture (from my perspective). I don't see that often though, maybe 10% (90% accuracy).
Thanks for the feedback
Taps seem to always work and the finger count seems to always be correct too, even more than 5 fingers!
Yup we don't limit the number of fingers although your device may only be able to detect so many consecutive presses
Single direction, multiple finger swipes sometimes show as two actions
That's interesting. When using the default GestureEndMask, the event is only triggered when all your fingers leave the screen. For example, if you use one finger and press on the screen and tap 99 times with another and then remove the first finger it should show as a 100 finger tap. Similarly if there are press 1 finger, then press another, release the first, press a 3rd, release the 2nd etc, it should show N fingers even if a single press didn't last the whole gesture.
So I would like to believe that in your case there is a small gap when the first 2 fingers leave the screen and before the 3rd touches it.
Multiple direction gestures work pretty well, eg an "L", shows as South East but also frequently as South South_East East, or just South South_East
Leaning more and more towards just making gesture bindings smart and letting a S -> SE -> E optionally match a S -> E
Hello again, after some research and copy/paste coding, I came up with the attached patch in case someone else may find it helpful. The end result is a single executable sgestures-libinput-writer that forks a reader process and pipes the gestures to it. It then builds up a string with some of the gesture details and uses the herbstclient emit_hook command to route the gesture info through the herbstluftwm window manager to a listening shell script for action. So I'm not filtering for specific gestures on the libsgestures side but rather in the shell script for "easier" updates.
This of course locks me into herbstluftwm, but for now that's not an issue. Besides the patch, I'm making a couple edits to the Makefile from the package build file:
sed -i '/^sgestures-libinput-writer:/ s/$/ $(SRC:.c=.o)/' "$builddir"/Makefile
sed -i 's/MIN_LINE_LEN (256)/MIN_LINE_LEN (1)/g' "$builddir"/gestures-private.h