Distinguish "eraser" and "pen" sides of the Marker Plus

[taradinoc]

The Marker Plus has a pen tip on one end and a pressure-sensitive eraser on the other. Currently, both ends are treated the same by remouseable - they both move the mouse and click the left button, using the same pressure threshold. This presents a couple problems:

1. The pressure readings from the eraser end are lower than the pen end, so it requires more actual pressure to generate a click from the eraser end.
2. Drawing with the eraser end should probably do something different anyway. Maybe a right click?

Here are some debug event logs with marks made by the pen and eraser side. I don't see anything in there that would help distinguish the two ends, though.

pen.txt eraser.txt

[kevinconway]

The eraser related events might not be in the debug stream if they aren't related to pen positioning. This was an oversight on my part. https://github.com/kevinconway/remouseable/blob/master/main.go#L104-L110 is the code branch that activates event debugging. It is filtering the event output to only events that the current application expects to see which are those related to pen position. I imagine there's a separate event type being used for the eraser to trigger the different behavior. It might even be that the eraser requires more pressure so it activates some other "click" type of event before being considered touching paper.

If you're comfortable hacking in Go then I'd recommend setting the it variable in the link I pasted to

&remouseable.FileEvdevIterator{
    Source: ioutil.NopCloser(pipe),
},

directly and removing the filtering middleware. That will give you a much more verbose and raw event stream to look at.

As for actually doing something with the events, though, I'm not sure that there are good options. It would be possible to refactor the app to handle a second mouse button click but I'm not sure that helps add any useful behavior. For example, it could right or middle click when the eraser is used but those buttons would still need to trigger an erase in the drawing app to be useful. None of the drawing apps I've seen support something like that unless you're operating a full wacom style tablet.

The Python version of this feature over at https://github.com/Evidlo/remarkable_mouse offers the full tablet behavior but only for linux. They're able to do this by translating the hardware events from the tablet into a virtual driver that supports exactly the same set of events. It becomes a device proxy. The Go version of the device driver library they use is https://github.com/gvalkov/golang-evdev and I used parts of it while building this project. Unfortunately, the Go library does not support creating devices on the system but only reading and listing them. This makes it a bit more difficult to build that feature even for linux.

I don't think the eraser, tilt, and custom button features of different pens have a clear use when we're only talking about the basic moving and clicking feature that this program implements. They'd make a lot of sense if we were implementing tablet device drivers. Unfortunately, the bar for entry in building the device drivers is a bit high because it requires writing OS specific code and linking to OS specific SDKs/APIs. We'd basically need three totally different programs to cover Windows, OSX, and Linux. I think that would be an awesome feature set to provide but it's pretty far beyond the investment I'm able to make in this project.

At least, that's my take on things. I'm open to other ideas, though.

[taradinoc]

As for actually doing something with the events, though, I'm not sure that there are good options. It would be possible to refactor the app to handle a second mouse button click but I'm not sure that helps add any useful behavior. For example, it could right or middle click when the eraser is used but those buttons would still need to trigger an erase in the drawing app to be useful. None of the drawing apps I've seen support something like that unless you're operating a full wacom style tablet.

A couple ideas:

1. Even just being able to map the eraser to the right (or middle) button would be useful for some common tasks, like opening context menus in Explorer and other mouse-oriented software. Some drawing software can make good use of right- or middle-clicking: for example, in Paint.NET, you can right-click to draw with the selected background color (almost like erasing), or middle-click to pan the document.

2. A simple way to generalize it might be to send a configurable keystroke when switching between eraser and pen marking. For example, in Paint.NET, you can press "E" to select the eraser tool or "P" to select the pencil. If the app detects that I've flipped the pen around to erase, it could send an "E" keystroke before the next motion or click event, then send a "P" when I flip it back over to use the pen tip. For use cases where the tool has to be selected from a palette, the app could generate a click at a specified screen position instead of a keystroke, although it'd depend on the window having a fixed location.

[kevinconway]

I think that idea makes sense for pens with secondary buttons. It would require a more complex state machine to handle the new inputs and a relaxation of the raw event filter to let button clicks come through from the tablet. It would also require bringing in keyboard support if the secondary feature used something other than a mouse button.

I'm not likely to have the time or motivation to make this change myself but I'll leave the issue open in case you or someone else in the future is interested in hacking on the idea.