-
Notifications
You must be signed in to change notification settings - Fork 877
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pen/Tablet Input Support #99
Comments
…ouseInput, r=paulroget fix return coordinates in MouseInput It is a fix of rust-windowing#97 When working on [servo/#11794](servo/servo#11794). I found the previous PR rust-windowing#97 is wrong. This PR is a fix of that and is right when testing [servo/#11794](servo/servo#11794). Actually, we should return the mouse movement position instead of actual coordination. So the previous PR's return value is wrong. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/glutin/99) <!-- Reviewable:end -->
There is an issue open on imgui (ocornut/imgui#2372) that has a little documentation and discussion on how to handle pen input across platforms that might be relevant when work on this starts. |
I made a preliminary implementation for pen support on X11 here https://github.com/DorianRudolph/winit/tree/stylus Pen pressure can already be accessed on X11 via the raw axis events, but there you get no information about the range of values. |
@DorianRudolph What is the state of your implementation? Any help needed? I could look into stylus support for Wayland but first we should probably make sure the API exposed in Winit is correct. |
@lehmanju if you're interested in contributing Wayland bits, you may add helper for table input to https://github.com/smithay/client-toolkit , since it's something that will be required anyway. |
A bit confused, but how would you consider it to be not implemented? It looks like it effectively is through Touch. |
Pen input devices can have additional values, such as pen pressure, tilt, and azimuth that are not currently supported in winit. Additionally (and anecdotally), applications sometimes want to be able to distinguish between touch and pen input, even if most interactions end up being the same. |
|
That's interesting... Looks like it's only used for the Apple Pencil: winit/src/platform_impl/ios/view.rs Line 233 in b9f3d33
I think we'd still need to hook up azimuth to do that cool tilt shading effect Apple showed off when they released the Pencil... Although even more broadly than that, I still think it's probably worth it to separate it out into a more generalized Edit: this may be a breaking change--at least on Windows, if one explicitly asks for pen input, the OS will stop sending them as touch inputs. |
It looks like Windows does have pressure sensitivity support: winit/src/platform_impl/windows/event_loop.rs Lines 1482 to 1496 in 6685960
Rotation/tilt should be trivial to add as well. I'm confused why normalize_pointer_pressure() expects to only get a maximum of 1024, though this issue seems to imply that the Win32 Pointer API is limited to that number compared to WinRT. It might be worth investigating that in the future? |
I'll admit the last time I seriously used winit was pre-0.20, and pen support wasn't sufficient for any non-trivial pen-based apps (for reference on what's missing, here's a proof concept supporting pen on Windows and web here 2e11615...tangmi:winit-legacy-2). I don't believe that any significant support for pen/tablet input was added since then, so I think that it's meaningful to keep this issue open. |
Agreed, it doesn't seem very mature yet. |
Looking through @DorianRudolph's PR, it looks like pressure is normalized, so could we use the |
For reference, pointer prediction is also a thing: |
Can we have this in foreseeable future? May I help? |
It seems like the pieces are there for all platforms but wayland. So depending on your needs, you can already use a tablet with either mine or Atilogit's PR. Someone (maybe you) just needs to prepare a production ready PR, I think. Currently both PRs implement the pointer on top of the touch event, which is not ideal, so we should create separate events for pen inputs. |
I'm not sure how near the future would be, but we lack the general API for that and the API for tablets is really complicated if you've read into what platforms exposed. |
I think I have a rough understanding of how the wayland API works, and I'll try implementing this for wayland soon. It seems like how to report the events to the user hasn't been decided yet, so should I just use what's convenient? That way people can worry about the specifics after most platforms are implemented. |
The main issue with all of those devices(mouse, touch, pen) is that they are not unified in winit, which a bit annoying. If you have an idea and you want to work on that you could probably try to propose top level API and an example first, without implementation in the backend. There's also patches to add pen which you could probably take a look at #2647 , #2396, and #1879. So you could give some brief information what other backends have. There's a tablet pad(or whatever it's called) to consider, because it also has events... |
Being able to handle pen double-taps on my iPad would be amazing! |
Thanks for the interest in working on this in #3759 @ActuallyHappening! I think the hardest part about this is not so much the implementation, but more figuring out what the generated |
I work primarily with the #[non_exhastive]
#[derive(Debug)[
pub enum PenEvent {
DoubleTab,
// Squeeze // todo
} Thinking about this more, I believe only apple pens have the specific 'Double Tap' feature. Of course there would be documentation to show this. Keeping the enum descriptive (rather than |
…nality Implements rust-windowing#3759 Also see rust-windowing#99
Resolution from the meeting today: We want to start with something matching the web API, specifically On top of that, we could probably add some extra methods to know if an event was e.g. a double tap or a special button press, but we want to start with the above. |
OK interesting, though in the link to the web API you mentioned there is no functionality specific to Apple Pencils / Galaxy SPens buttons. I.e., after implementing the entire web API, I would still not be able to handle Apple Pencil double tap (or squeeze) events like I want to (see bevy issue and #3759). Would this API be mutually compatible with the decided web API? /// Pen events not necessarily tied to a normal touch, move, or drag e.t.c.
pub enum PenSpecialEvent {
DoubleTap { preferred_action: Option<PenPreferredTapAction> },
// Squeeze // todo
} I guess I should explain that the Apple Pencil double tap feature often occurs when the pen is not touching the screen, so information like screen position doesn't make sense for it. |
Maybe it would help to know what kind of events the pen generates when used in a web page? |
…nality Implements rust-windowing#3759 Also see rust-windowing#99 Based on the `master` branch
Ahh I see, trying to mimic the Web API for native. Looking over the web api we could merge it with the features I want.
I understand more what you mean by extending the official spec now:
This does seem to be a more consistent and unified API. The only problem I see with trying to add Apple Pencil double tap event support is that the event itself is not associated with any of the touch event types in the web API spec, here. And, it is required that each pointer event from the spec has a specific |
I'm still eager to implement this, see #3768 |
This is to be expected, there will be a bunch of special events that just don't fit anywhere and maybe are platform-specific with no overlap. I think to start the design work of post-Web-API-pencil-input we want a proper overview.
Documentation:
|
I'm thinking about my future considerations, I'm wanting to custom build a lot of stuff relevant only to iOS. I'm out of my depth here, but is it possible for
I can only speak confidently about iOS since it's the only hardware I have. I'm happy to make a list of iOS features I would eventually want:
|
I don't think PencilKit can be easily integrated into |
The goal is to make a more or less complete list. If you include the links to the apple documentation directly, I'm happy to open an issue about platform-specific functionality so we can start collecting and designing an API for them. |
As the windows side of the implementation was mentioned, and the proposed implementation is relying on the Win32 API, I would like to say that the Win32 API is limited in some ways that create unwanted behavior (as in, different from any other implementation, with my main gripe being the absence of information on the button presses when hovering. The result is that buttons are usually not working correctly on windows for any application using gtk3/gtk4 or qt). I've listed my concerns (and a fix using additional WinRT API calls) on an existing PR here: #2396 (comment) Other Windows-specific features related to pens are only available using WinRT APIS (haptic feedback, pressure levels with more than 1024 levels) |
Another thing to note on windows is that pen APIs are split between Windows Ink (what we get from the Win32 or WinRT APIS) and Wintab, and these two are still used today. Windows Ink is used by all modern tablets with a pen digitizer on the screen, whilst Wintab is still widely used by external graphical tablets (wacom, huion). And of course, if your graphical tablet uses Wintab as the API and you're getting events from the Windows Ink API, these events are seen as mouse events, not pen events ... Usually you have to choose one of the two APIs to catch pen events and restart the app if you want to switch APIs. https://crates.io/crates/wintab_lite This seems like the only rust crate that deals with wintab right now, although, as I've only looked at the Windows ink part, I'm not familiar with the wintab part. (I know both qt and gtk have a wintab option, so there's other C/C++ code that implement the Wintab API). |
I propose we support pen tablet input, such as on devices like the Surface Pro/Studio, Galaxy Note, and eventually the Apple Pencil. These devices support things like pressure sensitivity and rotation/gyro. I don't think this is necessarily relevant to games (although it definitely can be), but it's definitely relevant to the larger digital 3D community.
The text was updated successfully, but these errors were encountered: