Feedback S-Pen button/negate 1.31

Hi, as you were already suspecting, some issues occured:

When pressing the button before drawing, the cursor is frozen, and no pen stroke is recognized at all

So I have to press the button after beginning a stroke.

But then what happens is that it the negative state toggles with every movement of the pen so I get a line like this for example when painting

grafik

Thanks, I’m redoing a quick release for another reason, so I’ll quickly add a fix for the “toggle” issue.

Hmm weird, not sure I’ll be able to fix that easily.

Keep me up-to-date for the next release (today or tomorrow).

In painting apps that don’t support the button, it’s the same freeze behavior (illustrator, adobe sketch).

In other apps like clip studio or samsung’s notes app, it works well though. These ignore button events during a stroke and only only decide on what to do when the button is pressed either away from the tablet with no cursor showing or in proximity with the cursor showing but not touched yet

will do that

Update 1.32 is live on Android.

Thanks for the quick update, button works as expected during the stroke now without the flashing. Pen is still inactive when pressing the button before the stroke.

Btw I’ve just installed visual studio and I could see the function AMotionEvent_getButtonState returns “34” instead of “0” when the button is down when nearing the tablet or touching. Don’t know why some applications appear to block the pen when the button is down, I was using the standard C++ HelloWorld example to check.

It’s weird I don’t do anything special.

I hope it’s not something stupid where you are forced to use the Samsung SDK in that scenario or something.

Actually the very first touch event is recognized with the button pressed because the “sub” icon switches color

Hmm are you sure it’s “34” and not “32”?
“34” means you are pressure AMOTION_EVENT_BUTTON_STYLUS_PRIMARY and AMOTION_EVENT_BUTTON_SECONDARY at the same time (android doc)

Do you know the value returned by AMotionEvent_getAction ?

The reason why it’s “frozen” is probably because of Issue with pen (Android)

I do release all the pointers when there is something that I don’t recognize (although as you noticed I introduced a small bugs and sometimes it’s not released well).

If I can know what exactly is the returned value from AMotionEvent_getAction maybe I can fix the frozen thing as well.

Ok you can forget about the questions above.

An Android release is on its way and we’ll see if I managed to fix the “button press frozen” issue while fixing the other “spen frozen” issue.

still checked… couldn’t help myself …:slight_smile:

pen approach-hover-remove without drawing, AMotionEvent_getAction returns 9-7-7-…-7-7-10
pen approach-hover-draw-hover-remove is AMotionEvent_getAction returns 9-7-7-…-7-7-10-0-2-2-…-2-2-1-9-9-7-7-…-7-7-10

so nothing special, except the weird double 9

getButtonState is 34 maybe to simulate the right mouse button for some apps
getToolType is the same (2) with button down or not
on my wacom pen from the 90’s there’s secondary button which switches the tooltype to 4 (eraser)

AMOTION_EVENT_ACTION_DOWN = 0,
AMOTION_EVENT_ACTION_UP = 1,
AMOTION_EVENT_ACTION_MOVE = 2,
AMOTION_EVENT_ACTION_CANCEL = 3,
AMOTION_EVENT_ACTION_OUTSIDE = 4,
AMOTION_EVENT_ACTION_POINTER_DOWN = 5,
AMOTION_EVENT_ACTION_POINTER_UP = 6,
AMOTION_EVENT_ACTION_HOVER_MOVE = 7,
AMOTION_EVENT_ACTION_SCROLL = 8,
AMOTION_EVENT_ACTION_HOVER_ENTER = 9,
AMOTION_EVENT_ACTION_HOVER_EXIT = 10,
AMOTION_EVENT_ACTION_BUTTON_PRESS = 11,
AMOTION_EVENT_ACTION_BUTTON_RELEASE = 12,

Not 100% but I think it should work better on 1.32.1 (available soon, probably tomorrow)