• the eraser can be mapped to any tools. You can hover with the eraser on the canvas then select the eraser tool in the toolbar, that will switch the eraser tool to be an eraser (same behavior as the choice of tool for the primary tip)

Maybe having the option to force/lock the eraser to always stay an eraser could be added ? I feel like that'd be a good addition when you realistically never want the eraser to be anything else on a surface pro (and others cab still change it if for any reason something is detected as an eraser when it shouldn't)

• I'm really not sure about the second button. I can check whether it's detected or not but there can be issues on windows on that subject (similar to Pen buttons not working as intended on windows 11 on Surface pro #785 ) when hovering

Ah yes, just realized that as well while using Rnote. Sorry I'm new to it.
The option sounds good, though I'm no expert in stylus pens (had only 1 before Surface). I suppose indeed it's just that the behavior was a bit unexpected, especially coming from Xournal++ and OneNote etc.

Secondary button doesn't seem to exist, there is another button via eraser click

Windows ink calls the button "shortcut button" and has an option to allow apps to override its behavior. At this point I think it's probably not the 2nd side button... I tired holding the button while touching the screen with the tip or the eraser (in both Rnote and Xournal++), nothing.

I'll reuse this issue to add the feature to lock the shortcut button to the eraser

Oof I see my comment was misleading, edited.
The eraser can either be rubbed against the screen (eraser, functions similarly to the pen tip) or clicked (shortcut/top button, press with finger until it clicks). I thought the secondary side button option would perhaps control either of them, since there isn't a 2nd side button on the slim pen.
I'll also edit the title a bit...

I'll reuse this issue to add the feature to lock the shortcut button to the eraser

I don't get what you mean for this. Afaik, button shortcuts set in the settings panel are locked in place and don't change.

One of the reasons for the confusing behavior is that the pen picker doesn't check what side of the pen is used when clicking. Hence using the pen, switching to the eraser and then directly changing the tool with the pen tip will change the eraser tool instead of the pen tip and the subsequent use of the tip will use the previous pen tip tool and not the one you thought you set.

I think that having the pen picker be sensible to the pen side might be a good improvement. That way if you hover above the pen picker with the pen tip, it will switch the canvas to the pen tip and you'll select the tool for the pen. Same for the eraser.

Tell me if I misunderstand you, but I think the current behaviour and the way Rnote implements this might be unclear:

In addition to the tools you can set in the settings panel there is also dedicated pen "modes".

There is the default "Pen" mode, but also "Eraser" (and theoretically others reported by gtk ). On some pens this Eraser mode is activated through a button press (and hold) of one of the side buttons of the pen, but on others this actually is the backside of the pen. Afaik there is no way to detect between the two.
When this mapped button is pressed it is also not possible to detect it as a button press.
So to make it work for both cases (mapped to button and backside) Rnote currently always checks whether the state has changed and remembers the current active tool.

What I meant when I wrote to "lock the shortcut button to the eraser" is to add an option to hard-lock the "Eraser" mode to the actual eraser tool of Rnote instead of the current behaviour: remembering and switch to the last active tool

Okay, that's what I understood as well (and started to implement in the draft PR).

The goal is to lock the pen mode, no matter what the mechanism on the pen to activate the different modes (reported by gtk) is.

It's probable that the behavior of some pens having their shortcut button activate the eraser mode instead of activating the first/second shortcut button might be input bugs but having this option alleviates some of the usability issues if it were the case.