Re: [PATCH v2 wayland-protocols] Add the tablet protocol
I should point out that a big surprise for me was discovering that acceleration was applied to the relative motion of the tool. I discovered that while trying to draw rectangles to determine the scale and realized that only if I moved really slowly would I get the same size every time. I had been using this pretty naturally for sketching and I would have thought that acceleration would mess this up, but obviously it does not and I was not even aware it was happening. Acceleration means some simple ideas about reusing absolute mode code and just moving the tablet->screen mapping rectangle on each proximity-in will not work, as that would have no acceleration. I need to test the Mac and Windows drivers to see what they do, and also see if acceleration is necessary by turning it off. Possibly it is not needed. Despite this I found that I had adjusted it so that the size on-screen of the slowest motion is almost exactly the same as the distance the stylus moves. On 12/12/2015 12:15 PM, Bill Spitzak wrote: On Tue, Dec 8, 2015 at 2:00 PM, Peter Hutterer mailto:peter.hutte...@who-t.net>> wrote: On Tue, Dec 08, 2015 at 11:58:20AM -0800, Bill Spitzak wrote: > What is the plan for using a tablet in "relative" mode? This is pretty > common if the tablet is smaller than the screen, as many modern ones are. I would love to hear where you get this information from, because the one thing we're suffering from is not knowing how our users use the tablet. Relative mode is common (and default) in the wacom driver for the lens/puck tool but few users have that one. Relative mode for the stylus is available, but we have little to no data on who's using it. I am using a Wacom Inutos 6x8 tablet. This is a professional and expensive device (I got it from the bankruptcy auction for Rhythm & Hues, every artist used these things except for a very small number that had the much larger 16x16 (?) ones). My screens are a 4x3 and a 16x9 screen arranged next to each other. Mapping the tablet area to the entire display results in a horizontal magnification between physical stylus movement and on-screen movement of about 6 and vertical scale of about 2. This is too large for me to use on sketching or 3D modelling unless the model is zoomed in so much that I lose any context. In addition motion of the stylus is distorted by 2.33 times more horizontally than vertically, which I find very disconcerting. Mapping to only one screen reduces both of these problems, but not enough imho, and makes it impossible to use the stylus on one of the screens. I am also using this on an IMac which has a screen that is closer to 4/3 so there is no distortion, but I still found the scale much too large to use on photoshop work. For these reasons I use the tablet in relative mode for all the tools. I find it hard to believe that my hardware setup is uncommon. It was used this way at R&H, and Linux and Windows and Mac all have the ability to set it. Linux support is quite broken and refuses to produce a square aspect ratio of the motion unless you send xsetwacom commands. Previous versions had weird bugs where the commands depended on the size of the outputs, but these seem to be fixed. Here is the cryptic commands I am using (a further bug is that I have to run this each time after the machine sleeps): xsetwacom --set "Wacom Intuos3 6x8 stylus" Mode Relative xsetwacom --set "Wacom Intuos3 6x8 stylus" Area "0 0 162560 121920" xsetwacom --set "Wacom Intuos3 6x8 eraser" Mode Relative xsetwacom --set "Wacom Intuos3 6x8 eraser" Area "0 0 162560 121920" I would say that Mac is not much better. It produces a square aspect but you have no control over the scale. Windows (well the Wacom-supplied driver) is much better with a scale control. I personally believe that what the user wants is to limit the magnification and distortion of motion, and would use absolute mode if possible without violating these constraints. Therefore instead of the controls being whether relative motion is used or not, the controls are a range of magnification and distortion that the user accepts. This will allow the tablet to switch automatically between modes if the area is changed (for instance if a client is able to restrict the tablet to it's own surface). Looking at my settings I seem to have a physical magnification very close to 1:1 (I have to move the stylus very slow so that acceleration does not change the dimension). I also know that a distortion of 4/3 horizontally is outside my limits. I suspect also that if I had a third tool I would have to add a line for it, an easy way to set all tools without knowing what they are would be nice. Relative mode uses acceleration just like a mouse. This does not have any detrimental effect on using it for painting as far as I can tell. That aside, relative mode is handled by the compositor, it's not something exposed on the protocol. A client always g
Re: [PATCH v2 wayland-protocols] Add the tablet protocol
On Tue, Dec 8, 2015 at 2:00 PM, Peter Hutterer wrote: > On Tue, Dec 08, 2015 at 11:58:20AM -0800, Bill Spitzak wrote: > > What is the plan for using a tablet in "relative" mode? This is pretty > > common if the tablet is smaller than the screen, as many modern ones are. > > I would love to hear where you get this information from, because the one > thing we're suffering from is not knowing how our users use the tablet. > Relative mode is common (and default) in the wacom driver for the lens/puck > tool but few users have that one. Relative mode for the stylus is > available, > but we have little to no data on who's using it. > I am using a Wacom Inutos 6x8 tablet. This is a professional and expensive device (I got it from the bankruptcy auction for Rhythm & Hues, every artist used these things except for a very small number that had the much larger 16x16 (?) ones). My screens are a 4x3 and a 16x9 screen arranged next to each other. Mapping the tablet area to the entire display results in a horizontal magnification between physical stylus movement and on-screen movement of about 6 and vertical scale of about 2. This is too large for me to use on sketching or 3D modelling unless the model is zoomed in so much that I lose any context. In addition motion of the stylus is distorted by 2.33 times more horizontally than vertically, which I find very disconcerting. Mapping to only one screen reduces both of these problems, but not enough imho, and makes it impossible to use the stylus on one of the screens. I am also using this on an IMac which has a screen that is closer to 4/3 so there is no distortion, but I still found the scale much too large to use on photoshop work. For these reasons I use the tablet in relative mode for all the tools. I find it hard to believe that my hardware setup is uncommon. It was used this way at R&H, and Linux and Windows and Mac all have the ability to set it. Linux support is quite broken and refuses to produce a square aspect ratio of the motion unless you send xsetwacom commands. Previous versions had weird bugs where the commands depended on the size of the outputs, but these seem to be fixed. Here is the cryptic commands I am using (a further bug is that I have to run this each time after the machine sleeps): xsetwacom --set "Wacom Intuos3 6x8 stylus" Mode Relative xsetwacom --set "Wacom Intuos3 6x8 stylus" Area "0 0 162560 121920" xsetwacom --set "Wacom Intuos3 6x8 eraser" Mode Relative xsetwacom --set "Wacom Intuos3 6x8 eraser" Area "0 0 162560 121920" I would say that Mac is not much better. It produces a square aspect but you have no control over the scale. Windows (well the Wacom-supplied driver) is much better with a scale control. I personally believe that what the user wants is to limit the magnification and distortion of motion, and would use absolute mode if possible without violating these constraints. Therefore instead of the controls being whether relative motion is used or not, the controls are a range of magnification and distortion that the user accepts. This will allow the tablet to switch automatically between modes if the area is changed (for instance if a client is able to restrict the tablet to it's own surface). Looking at my settings I seem to have a physical magnification very close to 1:1 (I have to move the stylus very slow so that acceleration does not change the dimension). I also know that a distortion of 4/3 horizontally is outside my limits. I suspect also that if I had a third tool I would have to add a line for it, an easy way to set all tools without knowing what they are would be nice. Relative mode uses acceleration just like a mouse. This does not have any detrimental effect on using it for painting as far as I can tell. > > That aside, relative mode is handled by the compositor, it's not something > exposed on the protocol. A client always gets absolute coordinates, > regardless of the input mode. > > > My guess is that you plan to deliver screen/surface coordinates, and that > > the client is unaware of the actual size of the tablet. However it is not > > clear from this. > > Please suggest a rewording that makes this clearer. > No it is ok, a bit of thought will show that the coordinates *must* be in surface coordinates, therefore relative motion must have been handled already by the compositor before the client gets these events. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 wayland-protocols] Add the tablet protocol
What is the plan for using a tablet in "relative" mode? This is pretty common if the tablet is smaller than the screen, as many modern ones are. My guess is that you plan to deliver screen/surface coordinates, and that the client is unaware of the actual size of the tablet. However it is not clear from this. On Mon, Dec 7, 2015 at 9:31 PM, Peter Hutterer wrote: > fixing up the weston patches for this showed a couple of typos: > > On Tue, Dec 08, 2015 at 12:50:01PM +1000, Peter Hutterer wrote: > > + > > the protocol name should just be "tablet", i.e. tablet_unstable_v1 in this > case. > > > + > > this should be ...seat_v1 > > > + > > this should be v1 > > These are all fixed locally now. > > Cheers, >Peter > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 wayland-protocols] Add the tablet protocol
On Tue, Dec 08, 2015 at 11:58:20AM -0800, Bill Spitzak wrote: > What is the plan for using a tablet in "relative" mode? This is pretty > common if the tablet is smaller than the screen, as many modern ones are. I would love to hear where you get this information from, because the one thing we're suffering from is not knowing how our users use the tablet. Relative mode is common (and default) in the wacom driver for the lens/puck tool but few users have that one. Relative mode for the stylus is available, but we have little to no data on who's using it. So, please tell me how you know this, because we desparately need this type of information and I want to figure out more usage data. That aside, relative mode is handled by the compositor, it's not something exposed on the protocol. A client always gets absolute coordinates, regardless of the input mode. > My guess is that you plan to deliver screen/surface coordinates, and that > the client is unaware of the actual size of the tablet. However it is not > clear from this. Please suggest a rewording that makes this clearer. Cheers, Peter > On Mon, Dec 7, 2015 at 9:31 PM, Peter Hutterer > wrote: > > > fixing up the weston patches for this showed a couple of typos: > > > > On Tue, Dec 08, 2015 at 12:50:01PM +1000, Peter Hutterer wrote: > > > + > > > > the protocol name should just be "tablet", i.e. tablet_unstable_v1 in this > > case. > > > > > + > > > > this should be ...seat_v1 > > > > > + > > > > this should be v1 > > > > These are all fixed locally now. > > > > Cheers, > >Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 wayland-protocols] Add the tablet protocol
fixing up the weston patches for this showed a couple of typos: On Tue, Dec 08, 2015 at 12:50:01PM +1000, Peter Hutterer wrote: > + the protocol name should just be "tablet", i.e. tablet_unstable_v1 in this case. > + this should be ...seat_v1 > + this should be v1 These are all fixed locally now. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 wayland-protocols] Add the tablet protocol
Signed-off-by: Peter Hutterer Reviewed-by: Jason Gerecke Reviewed-by: Daniel Stone --- Changes to v1: - drop the display type event, mostly useless in the protocol. clients that need it can get it through pid/vid + libwacom - add the enum references - extra clarification for the button-state-on-proximity event ordering - extra clarification about the uniqueness of a tool - rename tool_serial to hwserial - rename msb/lsb to hi/lo to match other protocols - clarify vid/pid - rename to new wp_.*_v1 interface versioning Makefile.am| 1 + unstable/tablet/README | 4 + unstable/tablet/tablet-unstable-v1.xml | 574 + 3 files changed, 579 insertions(+) create mode 100644 unstable/tablet/README create mode 100644 unstable/tablet/tablet-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index fb00ebe..49433ea 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5,6 +5,7 @@ unstable_protocols = \ unstable/text-input/text-input-unstable-v1.xml \ unstable/input-method/input-method-unstable-v1.xml \ unstable/xdg-shell/xdg-shell-unstable-v5.xml \ + unstable/tablet/tablet-unstable-v1.xml \ $(NULL) nobase_dist_pkgdata_DATA = \ diff --git a/unstable/tablet/README b/unstable/tablet/README new file mode 100644 index 000..7ba8e77 --- /dev/null +++ b/unstable/tablet/README @@ -0,0 +1,4 @@ +Tablet protocol + +Maintainers: +Peter Hutterer diff --git a/unstable/tablet/tablet-unstable-v1.xml b/unstable/tablet/tablet-unstable-v1.xml new file mode 100644 index 000..84c2934 --- /dev/null +++ b/unstable/tablet/tablet-unstable-v1.xml @@ -0,0 +1,574 @@ + + + +This description provides a high-level overview of the interplay between +the interfaces defined this protocol. For details, see the protocol +specification. + +More than one tablet may exist, and device-specifics matter. Tablets are +not represented by a single virtual device like wl_pointer. A client +binds to the tablet manager object which is just a proxy object. From +that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat) +and that returns the actual interface that has all the tablets. With +this indirection, we can avoid merging wp_tablet into the actual wayland +protocol, a long-term benefit. + +The wp_tablet_seat sends a "tablet added" for each tablet connected. +That event is followed by descriptive events about the hardware; +currently that includes events for name, vid/pid and +a wp_tablet.path event that describes a local path. This path can be +used to uniquely identify a tablet, or get more information through +libwacom. Emulated or nested tablets can skip any of those, e.g. a +virtual tablet may not have a vid/pid. The sequence of descriptive +events is terminated by a wp_tablet.done event to signal that a client +may now finalize any initialization for that tablet. + +Events from tablets require a tool in proximity. Tools are also managed +by the tablet seat, a "tool added" is sent whenever a tool is new to +the compositor. That event is followed by a number of descriptive events +about the hardware; currently that includes capabilities, serial id, +hardware serial and tool type. Similar to the tablet interface, a +wp_tablet_tool.done event is sent to terminate that initial sequence. + +Any event from a tool happens on the wp_tablet_tool interface. When the +tool gets into proximity of the tablet, a proximity_in event is sent on +the wp_tablet_tool interface, listing the tablet and the surface. That +event is followed by a motion event with the coordinates. After that, +it's the usual motion, axis, button, etc. events. +The protocol's serialisation means events are grouped by by +wp_tablet_tool.frame events. + +Two special events (that don't exist in X) are down and up. They signal +"tip touching the surface". For tablets without real proximity +detection, the sequence is: proximity_in, motion, down, frame. + +When the tool leaves proximity, a proximity_out event is sent. If any +button is still down, a button release event is sent before this +proximity event. These button events are sent in the same frame as the +proximity event to signal to the client that the buttons were held when +the tool left proximity. + +If the tool moves out of the surface but stays in proximity (i.e. +between windows), compositor-specific grab policies apply. This usually +means that the proximity-out is delayed until all buttons are released. + +Moving a tool physically from one tablet to the other has no real effect +on the protocol, sinc
