Stylus eraser: should it be a new pointerType instead of a button state?

[mustaqahmed]

I couldn't locate the motivation in the spec for treating "eraser" as a button state instead of a pointerType. Have we ever considered adding a new pointerType="eraser"?

Below are my thoughts about why pointerType="eraser" seems to be a better idea. To ease the discussion, I will use "eraser mode" to mean the physical orientation of a pen that is flipped to become an eraser, and "pencil mode" to mean the pen's normal orientation. (If the pen doesn't allow the flipped orientation but has a "eraser" button instead, my points still hold although a bit weakly.)

Consider a pen that is switched from "pencil" to "eraser" mode while hovering. Even though our recent spec change supports hovering pen buttons, this state of the pen seems awkward in quite a few different ways:

A. This is in "active button state" which is conceptually a stronger state than just an "active state". E.g., the pointer can now be captured. The analogous state for a "pencil" mode is only "active state" and not "active button state". An eraser is intuitively a destructive mode, so should never have a stronger effect than the corresponding "constructive" mode IMO.

B. At the moment of the flip to the eraser mode, if the pen stayed within the range of the digitizer, the pen moved from "inactive" to "active button state". The current spec wording means the UA needs to fire a pointerdown. So, one could click a button by just flipping to eraser mode!

C. If the pen momentarily moves away from the digitizer range during the flip to the eraser mode, it can possibly feel like a new stylus device with a button already pressed. If that is the case, will the very first event be a pointermove and not a pointerdown because the new device never switched its button state? This is a corner case for hovering buttons that we narrowly missed.

A quick web search reveals we have examples to support the change: many (most?) low (OS/device) level APIs treat eraser mode as a new device type similar to mouse/pen. Examples:

• EPointerType=EEraser in Wacom developer's guide for Mac,
• TOOL_TYPE_ERASER in Android, and
• BTN_TOOL_RUBBER in Linux.

[scottgonzalez]

I think the spec only talks about buttons in the location that a standard pencil's eraser would be in, not about pens that have been inverted to use as an eraser.

I agree that it makes sense to treat an inverted stylus that supports the flipped behavior as being a different pointer type.

[RByers]

Interesting. Maybe the biggest question here is "should pressing the eraser button be distinguishable from using a pen inverted". I assume there are art use cases where the user does really expect for these to be different operations, right? Does anyone know if apps like Photoshop these differently today?

If we did introduce a new "eraser" pointerType, would we also use a different pointerId (and so get a leave/enter pair when the pen is flipped)?

[patrickhlauke]

(accidentally answered by email on the PEWG list rather than here/to the github email, so copying the relevant part of my message)

I admit to not having played around with this too much with my Wacom tablet, but fundamentally I would still perceive the pen as being a single "pen" type even when flipped. Whether it's a flipped pen (like the Wacom stylus) or the pen in the same orientation but with the eraser button pressed (like on the Surface) seems more of a skeuomorphic gimmick / usability issue to me...the end result is still that the user wants to erase something with their pen.

I'm not sure if there are pens that have BOTH an eraser button AND can be used inverted.

[mustaqahmed]

... I would still perceive the pen as being a single "pen" type even when flipped.

I completely agree that from the usability standpoint, it should behave as a single pen. But the "active button state" is what gives me worries, see below...

Whether it's a flipped pen (like the Wacom stylus) or the pen in the same orientation but with the eraser button pressed (like on the Surface) seems more of a skeuomorphic gimmick / usability issue to me...the end result is still that the user wants to erase something with their pen.

Again, I agree that for both cases, the user wants to erase something. The follow-up action is more important here: when should the user start to erase something? I argue that erasing while hovering seems too destructive, erasing should start only when the pen is touching the surface.

[patrickhlauke]

To clarify the current behavior:

• for Wacom-style pen with eraser at the other end / with stylus flipped, the eraser end itself is pressure sensitive just like the regular tip. hovering the pen (even when flipped) over the digitizer surface registers no active buttons; once you touch the eraser tip to the digitizer, you get buttons==32 and the relevant pressure, so this scenario is not a concern I'd say (as I'd posit this is the same behavior as any other pens that require the user to flip to erase...the erase button itself is only pressed/registered once it touches the digitizer surface)
• testing the Surface pen, where eraser is an actual button, it seems that somewhere (in the device itself, or the driver) there's some cleverness built-in: when hovering the pen, I can press the eraser button and no buttons are registered. only if i keep the eraser button pressed when then touching the actual screen do i get buttons==32; so once again, this scenario is not a concern. question is: are there any other types of pen/stylus with an eraser button where pressing the eraser button in mid-air DOES actually register as a button press? these would be the only scenario that's of concern

(and for this scenario i think it'd be overkill to invent a whole new pointerType)

[patrickhlauke]

oh i should probably clarify i'm testing here using https://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-pointer-hud.html in Edge

[mustaqahmed]

I tested the low-level events from a Wacom Intuos Pro through Pixel evtest tool. A flipped ("eraser mode") pen appears as BTN_TOOL_RUBBER even when hovering.

@patrickhlauke: Does your test above use the same Wacom digitizer?

[patrickhlauke]

Yes, Wacom Intuos Pro with default stylus

[patrickhlauke]

Cross-posting Dave Fleck's response on the mailing list https://lists.w3.org/Archives/Public/public-pointer-events/2016JulSep/0290.html here:

I would say yes. As Mustaq pointed out there’s “Eraser Mode” and “Erasing Action”. Eraser Mode signals the UI to switch to an erasing tool and/or show an eraser cursor. Erasing Action performs an erase stroke.

Flipping to the eraser end, or pressing the erase side switch, activates Eraser Mode. At the lowest level, USB HID has an Invert bit usage (not a switch usage) to indicate Erase Mode. Using the tail transducer, or pressing the eraser side switch sets this bit. Using this bit to set a pointerType to Eraser would be a great way to indicate Eraser Mode.

Drawing (tip pressure > 0) while in Eraser Mode performs an Eraser Action. In PE this is currently Buttons==32 and the erase mode vs erase action are inseparable. So there’s no way to indicate (tool setting or cursor shape) that erasing will occur (erasing mode).

If there was a pointerType eraser there’s no need for button = 32. Button 1 for an eraser pointerType would do an erase action and is consistent with allowing other button presses while hovering (1 + 4, 1 + 8).

A note about hover switches: Side switches can be used to changes modes or to target (click on things). Mode changes while hovering (such as switching to eraser mode) are fine because there’s no need for high precision. If a side switch is set to a targeting action (such as right click) it is difficult for the user to precisely target because pressing a side switch while hovering often results in unintended lateral stylus movement. Microsoft’s solution was to make the right click button a modifier instead of an action, so you have to press the button and also press the tip to execute a right click. This makes right click targeting more precise. The Wacom control panel gives a choice, immediately act on a side switch or force it to be combined with the tip. Linux also gives this choice. Chrome immediately acts on side switches (a side switch set to right click acts immediately when pressed).

[patrickhlauke]

So if I understand the current situation correctly: in Windows/Edge, erasing has been implemented/forced as a modifier key that's tied specifically to pressure on the digitizer (in the case of the Surface Pen, pressing eraser button while hovering has no effect, and it only acts as modifier once the tip touches the screen; in the case of the Wacom stylus, having the stylus flipped - which at low level is distinguished as being an "eraser mode" switch - has no effect, and the hovering eraser is treated exactly the same as a hovering writing tip, and only once the eraser has any pressure it's translated into a pen action with eraser modifier).

The question for me is: are Microsoft likely to change the model and treat the eraser button not as a modifier, but as a means of switching into "eraser mode", changing the pointerType to something new like eraser? Or will PE somehow have to cater for both models (eraser as modifier vs eraser as its own tool/type)?

@teddink any thoughts?

[patrickhlauke]

also, based on dave's other message concerning USI https://lists.w3.org/Archives/Public/public-pointer-events/2016JulSep/0293.html

For eraser USI follows the “current standard” - there’s an Invert bit that indicates the tail transducer or erase side switch has been activated to indicate erase mode. Erasing action takes place when the tip is pressed while the Invert bit is set.

would this mean that instead of doing any special-casing with buttons == 32, we could instead add a new property inverted or similar, which is set when either the eraser switch on the barrel is pressed or the stylus is flipped, but still treat it as pointerType=="pen" ? if the desire/ambition is to align PE more with USI, this seems to me to be the best option?

(and to clarify, this would probably then mean removing any notion of "erase button" itself from button / buttons, meaning that authors would look for the inverted property to see if a pen is in eraser mode, rather than trying to rely on buttons etc)

[mustaqahmed]

Cross-posting Dave Fleck's recent response that I missed:

On Aug 27, 2016, at 4:49 AM, Patrick H.Lauke via GitHub sysbot+gh@w3.org wrote:

So if I understand the current situation correctly: in Windows/Edge, erasing has been implemented/forced as a modifier key that's tied specifically to pressure on the digitizer (in the case of the Surface Pen, pressing eraser button while hovering has no effect, and it only acts as modifier once the tip touches the screen; in the case of the Wacom stylus, having the stylus flipped - which at low level is distinguished as being an erased mode switch - has no effect, and the hovering eraser is treated exactly the same as a hovering writing tip, and only once the eraser has any pressure it's translated into a pen action with eraser modifier).

Backing up a bit. At the hardware HID protocol level there’s three bits of interest here: Invert = pen inverted or erase button depressed Tip = pressure on tip but no Invert Erase = pressure on tip while Inverted

What the system does with these: Tip -> left click Erase -> left click Invert -> (sorry, this list is incomplete) Mac: pointerType = Eraser Windows Wintab: cursor number = 2 and orientation = -90 degrees and TPS_INVERT is set in pkStatus Windows: PointerPoint Properties IsEraser or IsInverted X11: erase device send events

The question for me is: are Microsoft likely to change the model and treat the eraser button not as a modifier, but as a means of switching into "eraser mode", changing the pointerType to something new like eraser? Or will PE somehow have to cater for both models (eraser as modifier vs eraser as its own tool/type)?

“eraser mode” is a “modifier” as opposed to an action.

This behavior is ages old and highly unlikely to change.

I think the suggestion of having an eraser pointer type caters to both models.

I’ll be off the grid for the next week and a half so sorry if I don’t follow up.

[mustaqahmed]

Just realized that @RByers's questions went unanswered. I will draw others attention through my two cents:

Maybe the biggest question here is "should pressing the eraser button be distinguishable from using a pen inverted". I assume there are art use cases where the user does really expect for these to be different operations, right? Does anyone know if apps like Photoshop these differently today?

If a pen has both an eraser button and a flipped eraser mode, IMO it's the job of the driver/OS to let us distinguish between them. I think @patrickhlauke once posted a screenshot of Wacom settings which even allows associating a button to "touching the screen", right?

An analogous example for mouse: if the OS lets users define simultaneous L+R click as a middle button (Linux used to support this for two button mouse), an WebApp perhaps shouldn't care.

If we did introduce a new "eraser" pointerType, would we also use a different pointerId (and so get a leave/enter pair when the pen is flipped)?

Right now, both Edge & Chrome emits a new pointerId if the same pen leaves-then-enters the digitizer range. We can safely do the same for a flipped pen, right?

[patrickhlauke]

so what would happen if a stylus is either hovering or touching the digitizer, and then the eraser barrel button is pressed? does it need to pretend that the pen left (so firing off pointerout, pointerleave), and the new eraser pointer entered (pointerover, pointerenter)? or are we talking about having two separate models for pens with eraser button and pens which can be flipped (which is getting very confusing, at least to me)?

[mustaqahmed]

so what would happen if a stylus is either hovering or touching the digitizer, and then the eraser barrel button is pressed? does it need to pretend that the pen left (so firing off pointerout, pointerleave), and the new eraser pointer entered (pointerover, pointerenter)?

I see that pointerType="eraser" model will have to pretend pen leaving-and-entering, which will be terrible! Thanks for the catch.

or are we talking about having two separate models for pens with eraser button and pens which can be flipped (which is getting very confusing, at least to me)?

It seems to me that adding a Boolean property IsInverted works (as in the Windows case Dave Fleck mentioned):

• If distinguishing between the two eraser states (flipped vs buttoned) is important, we can leave the current eraser button as is. "Inverted pen" and "eraser button" are conceptually different enough to cause any confusion, right? And this change will be backward compatible with IsInverted defaulting to false.
• Or if we find two separate eraser models confusing, we can replace the current eraser button with the IsInverted property.

[mustaqahmed]

It seems pointerType="eraser" model is not as terrible as I commented above, see Dave Fleck's reply in the list.

[dfleck]

(adding this here from discussion thread)

Here’s the Windows requirement that the pen leave and re-enter in eraser mode - from: https://msdn.microsoft.com/en-us/library/windows/hardware/mt604235(v=vs.85).aspx

While the pen is within detection range of the digitizer, but not in contact with the screen, activation/deactivation of the erase affordance should be honored. However, direct transitions between the "Pen is in range" and the "Pen is in range with intent to erase" states are not supported, and in this scenario, the pen states must always transition via "Pen is out of range."

[patrickhlauke]

Due to lack of momentum (or implementation) on this, marking this as a potential future/v3 feature

[patrickhlauke]

I don't think there's much appetite/movement on this even for v3. Current state of play - based on testing with Surface at least - seems to be that there's no differentiation between a stylus writing and erasing in terms of pointerType, but once the stylus eraser contacts the screen buttons is showing 32. this leaves out the possibility of hovering eraser, but perhaps that's too much of an edge case to worry about? (and this seems to match with the behavior described here i think https://github.com/w3c/pointerevents/issues/134#issuecomment-248774795)

Propose closing this.

[smaug----]

@BoCupp-Microsoft, we're thinking to close this issue. Given https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/324 and similar discussion, do you think MS will have a proposal which will require new pointerTypes? Or I guess we could close this and reopen or create a new issue if needed.

[Dwood15]

Sorry for chatting on such an old topic, but am I correct in saying that since this ticket is still open, the standard has no official way to get whether a pen tablet or pen input is an eraser without checking button state?

Sorry if this is noise, but I've been googling for the last couple hours and this is the most relevant answer I could find from either google or duckduckgo.

I'm building a silly webapp for my wacom screen tablet and not distinguishing pointer "pen" from "eraser" is giving me a hard time. The only documentation I've been able to find has been from: https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/mozInputSource

Which is, well, non-standard. So if someone was willing to pick this up, as a developer trying to use the raw api's, adding an eraser pointer-type would be real nice.

Edit: After investigating it, I could find no way of telling if my pen is flipped and thus swapped to an 'eraser' mode.

[patrickhlauke]

i personally still think we could/should consider an actual eraser pointer type, as the current approach of just identifying "presses" that are with the eraser (button value of 5 per https://w3c.github.io/pointerevents/#the-button-property) leaves out scenarios like a hovering stylus in eraser mode.

once v3 is out of the door, i'd really like to flesh this out some more and see if there could be renewed appetite from implementers to actually support it.