mb1986
Feature Req: Lamy pen functions
Hi. I recently discovered these hacks, and was blown away by all the new features you have implemented. Needless to say, I am immensely grateful for the work you and others have put into making this happen.
Over the past few weeks (before I was aware of these hacks), I was hacking around a bit on slotThe/remarkableLamyEraser. The results of my experimentation are a few new features I would like to propose for the (Lamy) pen:
- Add a "long click" trigger, which activates by pressing and holding the button for some time before releasing (as opposed to a normal click, which must happen with a short timeframe). I have found this to be preferable to double-click. You can also do a double long-click by doing a normal click followed by a long click (and triple long-click etc.). You abort a long-click by moving the pen away from the screen. And if you write on the screen, the long click is also aborted (so as not to interfere with press+hold).
- Detect when the pen is lifted from the screen, enabling two possible features (not limited to Lamy pen):
- "One-off" effects -- e.g., toggling the current pen with last used, and automatically switching back when the pen leaves the screen). You can extend a one-off effect by pressing the button while the pen is still on the screen.
- Allowing the user to release the button while pressing and holding for eraser/selection eraser (it will know to switch back to pen when you lift the nub from the screen)
- Count the number of separate segments/strokes drawn within the screen within a short time of one another -- this will enable a "batch undo" operation that performs this many undos. This could eliminate many uses of the eraser/selection eraser if all you want to do is delete, for example, the last word that you wrote. In the UI you could maybe map this to press+hold on the undo button.
Here is my opinionated take on what the default pen actions should be (though feel free to disagree with me):
- click: undo
- double-click: batch undo
- long-click: toggle tool with last used
- double-long-click: toggle tool with last used, one-off
- press+hold: eraser (can release while erasing, pen will switch pack when lifted)
- double press+hold: selection eraser (can also release while erasing)
You can find my prototype implementation of all of these features here. To build and run it, first clone the repo, change to the dev branch and run qmake to generate the Makefile:
git clone [email protected]:Rish987/RemarkableLamyEraser.git
cd RemarkableLamyEraser
git checkout hl-toggle-long-click
qmake
Then use the following command to build and run it on your Remarkable:
source /opt/codex/rm2/4.0.117/environment-setup-cortexa7hf-neon-remarkable-linux-gnueabi && make && scp RemarkableLamyEraser remarkable:/usr/sbin/ && ssh -t remarkable "/usr/sbin/RemarkableLamyEraser --trigger-debug"
You will see messages printed whenever you activate a pen event.
This is the main function that handles all of the different triggers. I tried to document it well, but let me know if anything remains unclear. In particular, there were a few tricky issues that I had to handle when implementing it:
- I wanted to give the user the option to "abort" a long click by moving the pen away if they pressed down on the Lamy button but then changed their minds -- while working on this, I noticed a bug (that the current implementation in
rm-hacksalso suffers from): if you press the button, then move the pen quickly away from the screen, this would register as a click. I believe that the pen sending a button release signal in this case is because of a physical limitation of the Lamy pen (rather than a bug) because this would cause the pen to send aBTN_TOOL_PEN = 0followed by aBTN_STYLUS = 0signal. I have dealt with this by delaying the confirmation of the pen button release until after receiving another signal within a short enough period of time. - A similar issue of spurious signals happens when pressing the button while the pen is drawing on the screen, as this would send some signals suggesting that the pen was lifted. I solved this in a similar fashion by delaying the pen lift event.
- The abort logic relies on tentatively assuming the pen was pulled away when receiving
BTN_TOOL_PEN = 0-- however, since this signal can occur in other contexts, we cannot be sure of an abort until a significant amount of time passes before receiving a non-EV_SYN/BTN_STYLUSsignal. So, in effect, we can only really complete an abort sequence after the pen re-approaches the screen (because our event loop blocks on waiting for a pen signal).
As for the implementation in this repo, there are two possible ways to go about it:
- We integrate some of this code into xochitl's event handling, or perhaps use the
get_triggerfunction directly -- this would probably not be too complex, but the drawback is that it will then no longer be open-source. - We could try to add some kind of "API" to xochitl to allow for setting and querying the pen state from an external program -- I have no idea about the technology we would need to do this, but the concept of "RPC" sounds relevant. The obvious benefit of this is that we can keep the pen support as a separate open-source repo which just calls these routines.
I understand that you are thoroughly occupied working on other features at the moment, so I would be happy to look into the implementation details of this myself! Let me know what you think, and we can follow up on Discord.
Are the Lamy hacks pen-specific or do they work with other styluses? If so, which ones?
Thanks, LKW
On Sat, Jan 6, 2024 at 8:40 PM Rishikesh Vaishnav @.***> wrote:
Hi. I recently discovered these hacks, and was blown away by all the new features you have implemented. Needless to say, I am immensely grateful for the work you and others have put into making this happen.
Over the past few weeks (before I was aware of these hacks), I was hacking around a bit on slotThe/remarkableLamyEraser https://github.com/slotThe/RemarkableLamyEraser/. The results of my experimentation are a few new features I would like to propose for the (Lamy) pen:
- Add a "long click" trigger, which activates by pressing and holding the button for some time before releasing (as opposed to a normal click, which must happen with a short timeframe). I have found this to be preferable to double-click. You can also do a double long-click by doing a normal click followed by a long click (and triple long-click etc.). You abort a long-click by moving the pen away from the screen. And if you write on the screen, the long click is also aborted (so as not to interfere with press+hold).
- Detect when the pen is lifted from the screen, enabling two possible features (not limited to Lamy pen):
- "One-off" effects -- e.g., toggling the current pen with last used, and automatically switching back when the pen leaves the screen). You can extend a one-off effect by pressing the button while the pen is still on the screen.
- Allowing the user to release the button while pressing and holding for eraser/selection eraser (it will know to switch back to pen when you lift the nub from the screen)
- Count the number of separate segments/strokes drawn within the screen within a short time of one another -- this will enable a "batch undo" operation that performs this many undos. This could eliminate many uses of the eraser/selection eraser if all you want to do is delete, for example, the last word that you wrote. In the UI you could maybe map this to press+hold on the undo button.
Here is my opinionated take on what the default pen actions should be (though feel free to disagree with me):
- click: undo
- double-click: batch undo
- long-click: toggle tool with last used
- double-long-click: toggle tool with last used, one-off
- press+hold: eraser (can release while erasing, pen will switch pack when lifted)
- double press+hold: selection eraser (can also release while erasing)
You can find my prototype implementation of all of these features here https://github.com/rish987/RemarkableLamyEraser/tree/hl-toggle-long-click. To build and run it, first clone the repo, change to the dev branch and run qmake to generate the Makefile:
git clone @.***:Rish987/RemarkableLamyEraser.gitcd RemarkableLamyEraser git checkout hl-toggle-long-click qmake
Then use the following command to build and run it on your Remarkable:
source /opt/codex/rm2/4.0.117/environment-setup-cortexa7hf-neon-remarkable-linux-gnueabi && make && scp RemarkableLamyEraser remarkable:/usr/sbin/ && ssh -t remarkable "/usr/sbin/RemarkableLamyEraser --trigger-debug"
You will see messages printed whenever you activate a pen event.
This is the main function https://github.com/rish987/RemarkableLamyEraser/blob/50a70aa64bb08d9b82558c8df6016b72cd90eea3/sources/triggers.c#L12 that handles all of the different triggers. I tried to document it well, but let me know if anything remains unclear. In particular, there were a few tricky issues that I had to handle when implementing it:
- I wanted to give the user the option to "abort" a long click by moving the pen away if they pressed down on the Lamy button but then changed their minds -- while working on this, I noticed a bug (that the current implementation in rm-hacks also suffers from): if you press the button, then move the pen quickly away from the screen, this would register as a click. I believe that this is because of a physical limitation of the Lamy pen (rather than a bug) because this would cause the pen to send a BTN_TOOL_PEN = 0 followed by a BTN_STYLUS = 0 signal. I have dealt with this by delaying the confirmation of the pen button release until after receiving another signal within a short enough period of time https://github.com/rish987/RemarkableLamyEraser/blob/50a70aa64bb08d9b82558c8df6016b72cd90eea3/sources/triggers.c#L135 .
- A similar issue of spurious signals happens when pressing the button while the pen is drawing on the screen, as this would send some signals suggesting that the pen was lifted. I solved this in a similar fashion by delaying the pen lift event https://github.com/rish987/RemarkableLamyEraser/blob/50a70aa64bb08d9b82558c8df6016b72cd90eea3/sources/triggers.c#L77 .
- The abort logic relies on tentatively assuming the pen was pulled away when receiving BTN_TOOL_PEN = 0 -- however, since this signal can occur in other contexts, we cannot be sure of an abort until a significant amount of time passes before receiving a non-EV_SYN/BTN_STYLUS signal. So, in effect, we can only really complete an abort sequence after the pen re-approaches the screen https://github.com/rish987/RemarkableLamyEraser/blob/50a70aa64bb08d9b82558c8df6016b72cd90eea3/sources/triggers.c#L47 (because our event loop blocks on waiting for a pen signal).
As for the implementation in this repo, there are two possible ways to go about it:
- We integrate some of this code into xochitl's event handling, or perhaps use the get_trigger function directly -- this would probably not be too complex, but the drawback is that it will then no longer be open-source.
- We could try to add some kind of "API" to xochitl to allow for setting and querying the pen state from an external program -- I have no idea about the technology we would need to do this, but the concept of "RPC" sounds relevant. The obvious benefit of this is that we can keep the pen support as a separate open-source repo which just calls these routines.
I understand that you are thoroughly occupied working on other features at the moment, so I would be happy to look into the implementation details of this myself! Let me know what you think, and we can follow up on Discord.
— Reply to this email directly, view it on GitHub https://github.com/mb1986/rm-hacks/issues/140, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP4X7X6R2A3TQESEFKIWDADYNIDK5AVCNFSM6AAAAABBP7QCMGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3DQOJTHA2TONY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I think they work with any stylus with a button (or at least most of them), but not 100% sure -- you can verify by trying to run this prototype using my instructions above, and seeing if everything triggers as expected.
I don't have a stylus with a button yet but would love to get one if these hacks work. Looked at the Lamy but it won't fit in my Cobak case. ☹️
On Sat, Jan 6, 2024, 11:37 PM Rishikesh Vaishnav @.***> wrote:
I think they work with any stylus with a button (or at least most of them), but not 100% sure -- you can verify by trying to run this prototype using my instructions above, and seeing if everything triggers as expected.
— Reply to this email directly, view it on GitHub https://github.com/mb1986/rm-hacks/issues/140#issuecomment-1879952800, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP4X7XYWLACPGRR25IOXZVTYNIYBRAVCNFSM6AAAAABBP7QCMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZHE2TEOBQGA . You are receiving this because you commented.Message ID: @.***>
Are the Lamy hacks pen-specific or do they work with other styluses? If so, which ones?
There is a little bit about that at the end of the README:
The project was—at one point in time—also confirmed to work with:
- Kindle Scribe Pen
- Samsung S6 S Pen
- Wacom One Pen CP91300B2Z
- iFlytec T1 4096
I would also assume that any stylus with a button should just work.
Thanks, Tony!
LKW
On Sun, Jan 7, 2024 at 2:52 AM Tony Zorman @.***> wrote:
Are the Lamy hacks pen-specific or do they work with other styluses? If so, which ones?
There is a little bit about that at the end of the README:
The project was—at one point in time—also confirmed to work with:
- Kindle Scribe Pen
- Samsung S6 S Pen
- Wacom One Pen CP91300B2Z
- iFlytec T1 4096
I would also assume that any stylus with a button should just work.
— Reply to this email directly, view it on GitHub https://github.com/mb1986/rm-hacks/issues/140#issuecomment-1879996576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP4X7XY4R5US7WN7PBW7LCLYNJO5FAVCNFSM6AAAAABBP7QCMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZHE4TMNJXGY . You are receiving this because you commented.Message ID: @.***>
@rish987, thanks for the feedback and your ideas! I will definitely try to implement at least some of them. When I was reading your comment, I came up with an idea too. Currently, we are relying on ddvk's implementation (https://github.com/ddvk/remarkable-stylus) for handling Lamy button presses - it simply converts them into keyboard key press/release events, which are easy to work with. On the other hand, it clutters QMLs with logic related to Lamy button presses. I think that we could move this implementation to the Qt plugin level. It will probably perform better and be easier to maintain. If there's no better idea, we could send different keyboard key press/release events to integrate it with the rest of the code in the QML files.
Would you like to work on this Qt plugin part? I'd be also happy to help, test, and integrate it with rm-hacks.
Would you like to work on this Qt plugin part? I'd be also happy to help, test, and integrate it with rm-hacks.
I would love to! I'll reach out to you on Discord.