Re: [PATCH wayland-protocols] Add the tablet protocol
Hi Daniel, Thanks for the review. I'll reply to a few select pieces, anything skipped is something I'll just fold into the next diff. On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: > Peter, Stephen, > > On 6 November 2015 at 04:24, Peter Hutterer wrote: > > This is the revamped version of the tablet protocol for graphics tablets > > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > > so), so I won't detail them, best to look at it with fresh eyes. > > Thanks a lot for doing this! Looks really good to me, and I think > getting it in wayland-protocols would be good. > > Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer > (ha) to those would be great. > > Obligatory nitpicks follow: > > > + > > + > > + > > +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. > > Yes, it turns out the wl_seat.get_* model was probably a pretty bad > anti-pattern. Oh well. To avoid too much object proliferation though, > how about something like: > > > > Add a seat of interest to this tablet manager. The client will > receive events for all tablets currently on this seat, as well as > tablets added to this seat in future. > > > > [inline wp_tablet_seat here ...] > > > Then you can just bin wp_tablet_seat. > > Not a pattern we've previously employed, but I think it's a good one > that avoids one extra step of indirection, as well as making it a bit > easier for clients to do the right thing. > > > +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 > > +internal/external/display type, 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. > > Is VID/PID in USB space? (Answers in diff form preferred.) > > > +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, followed > > +by button release events for any button still down. This signals to > > +the client that the buttons were held when the tool left proximity. > > +Those events are all sent within the same frame. > > Can we please enforce a strict bracketing of down/up occurring in > matched pairs inside of proximity_in/out? So, the total event stream > would be: > - proximity_in > - motion > - down > - motion/motion/button/... > - up > - proximity_out > > I assume the implementation does this, but it would be nice to have > encoded in the protocol. the original plan was to have the proximity out event sent before the button event iff the tool goes out of proximity with the button still pressed. the frame events (similar to SYN_REPORT) group them together, so as long as you process those correctly you still know the state. so the order would be, and I'm using button event here rather than the tip event because that is actually likely to happen: - proximity_in - motion - frame - button down - frame - proximity out - button up - frame The above signals that the button was still down during proximity. but you're right, it be easier to pair them symmetrically and any sensible client that handles frame events correctly will do exactly the right thing. So the above would turn into: - proximity_in - motion - frame - button down - frame - button up - proximity out - frame I'll reword that. > > +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. > > If no buttons are down, we'd _expect_ to just get a proximity_out >
Re: [PATCH wayland-protocols] Add the tablet protocol
On Mon, Nov 16, 2015 at 12:07:12PM +, Daniel Stone wrote: > Hi Jonas, > > On 16 November 2015 at 11:59, Jonas Ådahl wrote: > > On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: > >> On 6 November 2015 at 04:24, Peter Hutterer > >> wrote: > >> > +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. > >> > >> Yes, it turns out the wl_seat.get_* model was probably a pretty bad > >> anti-pattern. Oh well. To avoid too much object proliferation though, > >> how about something like: > >> > >> > >> > >> Add a seat of interest to this tablet manager. The client will > >> receive events for all tablets currently on this seat, as well as > >> tablets added to this seat in future. > >> > >> > >> > >> [inline wp_tablet_seat here ...] > >> > >> > >> Then you can just bin wp_tablet_seat. > >> > >> Not a pattern we've previously employed, but I think it's a good one > >> that avoids one extra step of indirection, as well as making it a bit > >> easier for clients to do the right thing. > > > > How would it be easier for clients to do the right thing? It'd just make > > it easy to mix different seats' tools and tablets as there would be no > > more separation (except if one would bind a tablet manager per seat). Or > > should tools and tablets be considered on the same "super seat", i.e. > > would it be possible to see tool A from seat X on tablet V on seat Y? > > It makes it easier, because right now we expect them to hold a > wp_tablet_manager, respond to new seats by creating a new > wp_tablet_seat, and having them respond to events on that as well. We > already make people hold absolute piles of objects, so one less seems > like it could be a good thing. I have to say it sounds a lot worse in the protocol than it is in the implementation. But this was the easiest bit of the implementation, clients already have some wrapper object for the wl_seat anyway, this just adds one pointer for the tablet seat to that object, plus one global one for the tablet manager. [1] And that too is just adding one more pointer to existing infrastructure. And the effective cost is minimal - how many wl_seats do we expect in the worst case? 10? In the 99% case we only have one and that's what IMO we should optimise for (and the code would look identical anyway since in the client it'll all hang off the struct seat_something). I think that the potential confusion of mixing tablets from different seats is a lot worse than the extra objects here. Cheers, Peter [1] https://github.com/whot/weston/commit/64dc64a4dbabd7fbe1b6b80a2a08ff2cc8c0c288#diff-87a1da5a7e6453c81e19091e66a9015dR5757 > > Seems to me that making it possible to shove all seats in one pile is > > more error prone than having them clearly separated. > > Possibly. I guess it depends on the failure mode. I can see it either way. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
On Mon, Nov 16, 2015 at 11:55 AM, Carlos Garnacho wrote: > It's probably worth pointing out that his concerns are moot, there is > no blinking, or rather, has an easy solution in compositors. > > When a tool physically enters in proximity over a surface, the cursor > should be effectively invisible, the client below it will emit > wp_tablet_tool.set_cursor in response to proximity_in, and it will be > set accordingly from the previous invisible state. If the tool moves > across surfaces, the cursor won't be modified until the new focus > surface calls wp_tablet_tool.set_cursor, just like it happens with > wl_pointer.set_cursor and wl_pointer.enter. When the tool physically > leaves proximity, the cursor would be made invisible, destroyed, or > whatnot. > > Compositors may of course want to set a default cursor if the > proximity_in happened outside a surface, so that there's something > visible until the tool enters a surface, but this is easy enough to > detect before even showing the cursor. AFAICS the only source of > "blinking" would be compositors invariably setting a visible cursor > before the client has an opportunity to do so, that sounds somewhat > sloppy though. > I'm not sure why you think I am arguing for an old point, as Carlos describes exactly the same thing I am thinking of. His proposal removes the need for there to be a per-tool cursor in the client api. The client only sets the cursor for the most recent tool, and the user can only see one cursor. IMHO this can be done in the easiest way by reusing the wl_pointer api, rather than adding new api that clients will just be forced to select between because only one of the api's works at any time. He is proposing the "strong" version of what I said, which is that the cursor is actually frozen (not moving or changing) until a cursor-set is received from the client that has focus. If this is a good idea it probably should be done for normal pointer enter events as well. The benifit of this is that it obeys the "every frame is perfect" rule of Wayland. I was assuming a "soft" version that works like the current pointer enter events, where the cursor does not change but follows the pointer without waiting for the client to set the image. The cursor image is thus a "guess" by the compositor. IMHO the best "guess" is to leave the cursor unchanged from whatever it is now, as this will reduce the number of transitions when the guess is wrong, and it is how enter events work currently. However a compositor could try to save a "guess" that tracks the cursor per-tool, per-surface, or even per tool+surface combination. None of that should be visible in the client api however. Changing the cursor on proximity-in outside any client is an interesting problem. I think the compositor should be entirely in charge of this, though "guessing" that it is the same as the most-recent client, which seems to be the proposal here, may be reasonable. The compositor is still going to need an image to use if no client has gotten a proximity-in yet, so this does not remove the need for it to supply something without client help. I also have no idea what you mean by this being a repeat of some mistake done by X11. I am not changing in any way what events are being received by the client compared to the current proposal, therefore if my idea is wrong, so is the current proposal. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hey, On Mon, Nov 16, 2015 at 8:04 PM, Daniel Stone wrote: > Bill, > > On Monday, 16 November 2015, Bill Spitzak wrote: >> >> There is a need to distinguish proximity-out from exit events. It is quite >> possible to move the stylus so that the focus enters another client without >> doing a proximity-out. Clients are interested in distinguishing these. > > > This is true, hence my suggestion. > >> >> I really feel the best method is to say a "seat" has a keyboard focus and >> a pointer focus, and let the stylus manipulate the pointer focus. Thus the >> client will get enter/exit events as the stylus is moved around above the >> tablet, and proximity in/out when it is moved toward/away from the tablet >> (it may also get a fake proximity-in event on enter). > > > Pointer and tablet/touch are separate. X11 integrated them, and _that_ was a > huge mistake. From our point of view, this is a closed topic. > > We've been over it time and time again, we've seen the ways the alternate > model - though it seems attractive at first, which is why we did it for X11 > - fails, and we're not going back there. > >> >> I really feel the cursor stuff is a huge mistake. It adds lots of >> complexity for almost no actual gain. Witness how much code you had to add >> to toytoolkit to support it. It adds complexity to clients as the client has >> to pass which tool to subroutines for no reason other than to allow them to >> change the correct cursor. The clients cannot assume the tool has the >> "right" cursor and therefore they are required to have code to change it, so >> this removes no complexity from clients. It is also hugely inconsistent with >> how normal pointer enter events are handled in Wayland. > > > It's not 'no actual gain', it's integral to the model. > >> >> The only argument you had was that the cursor is more likely to be >> correct, so when the proximity-in event happens, the cursor that appears has >> a higher chance of being the same as the one the client sets and there will >> be less blinking. However this can be implemented by the compositor without >> any client api. Just have the compositor remember what cursor was used and >> set that as a guess on the enter event. The client can remain completely >> unaware of whether a cursor is remembered per-tool, or per-surface, or per >> tool*surface, or whatever. > > > The reason the protocol does not do this, is because when the cursor is > different, you go from the other-surface cursor, to the old new-surface > cursor, to the new new-surface cursor, very rapidly. It's ugly, and a > bandaid for clients not responding quickly enough. It's probably worth pointing out that his concerns are moot, there is no blinking, or rather, has an easy solution in compositors. When a tool physically enters in proximity over a surface, the cursor should be effectively invisible, the client below it will emit wp_tablet_tool.set_cursor in response to proximity_in, and it will be set accordingly from the previous invisible state. If the tool moves across surfaces, the cursor won't be modified until the new focus surface calls wp_tablet_tool.set_cursor, just like it happens with wl_pointer.set_cursor and wl_pointer.enter. When the tool physically leaves proximity, the cursor would be made invisible, destroyed, or whatnot. Compositors may of course want to set a default cursor if the proximity_in happened outside a surface, so that there's something visible until the tool enters a surface, but this is easy enough to detect before even showing the cursor. AFAICS the only source of "blinking" would be compositors invariably setting a visible cursor before the client has an opportunity to do so, that sounds somewhat sloppy though. Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Bill, On Monday, 16 November 2015, Bill Spitzak wrote: > There is a need to distinguish proximity-out from exit events. It is quite > possible to move the stylus so that the focus enters another client without > doing a proximity-out. Clients are interested in distinguishing these. > This is true, hence my suggestion. > I really feel the best method is to say a "seat" has a keyboard focus and > a pointer focus, and let the stylus manipulate the pointer focus. Thus the > client will get enter/exit events as the stylus is moved around above the > tablet, and proximity in/out when it is moved toward/away from the tablet > (it may also get a fake proximity-in event on enter). > Pointer and tablet/touch are separate. X11 integrated them, and _that_ was a huge mistake. From our point of view, this is a closed topic. We've been over it time and time again, we've seen the ways the alternate model - though it seems attractive at first, which is why we did it for X11 - fails, and we're not going back there. > I really feel the cursor stuff is a huge mistake. It adds lots of > complexity for almost no actual gain. Witness how much code you had to add > to toytoolkit to support it. It adds complexity to clients as the client > has to pass which tool to subroutines for no reason other than to allow > them to change the correct cursor. The clients cannot assume the tool has > the "right" cursor and therefore they are required to have code to change > it, so this removes no complexity from clients. It is also hugely > inconsistent with how normal pointer enter events are handled in Wayland. > It's not 'no actual gain', it's integral to the model. > The only argument you had was that the cursor is more likely to be > correct, so when the proximity-in event happens, the cursor that appears > has a higher chance of being the same as the one the client sets and there > will be less blinking. However this can be implemented by the compositor > without any client api. Just have the compositor remember what cursor was > used and set that as a guess on the enter event. The client can remain > completely unaware of whether a cursor is remembered per-tool, or > per-surface, or per tool*surface, or whatever. > The reason the protocol does not do this, is because when the cursor is different, you go from the other-surface cursor, to the old new-surface cursor, to the new new-surface cursor, very rapidly. It's ugly, and a bandaid for clients not responding quickly enough. This line has been discussed to death, and we won't be pursuing it any further. I've enjoyed some of your more constructive contributions over the past year or so, but am sad to see you regress back into suggesting rewriting the entire protocol - overriding considered discussion made at the time - because you prefer the superficial aspects of an alternate approach. Please don't make a habit of this. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
There is a need to distinguish proximity-out from exit events. It is quite possible to move the stylus so that the focus enters another client without doing a proximity-out. Clients are interested in distinguishing these. I really feel the best method is to say a "seat" has a keyboard focus and a pointer focus, and let the stylus manipulate the pointer focus. Thus the client will get enter/exit events as the stylus is moved around above the tablet, and proximity in/out when it is moved toward/away from the tablet (it may also get a fake proximity-in event on enter). I really feel the cursor stuff is a huge mistake. It adds lots of complexity for almost no actual gain. Witness how much code you had to add to toytoolkit to support it. It adds complexity to clients as the client has to pass which tool to subroutines for no reason other than to allow them to change the correct cursor. The clients cannot assume the tool has the "right" cursor and therefore they are required to have code to change it, so this removes no complexity from clients. It is also hugely inconsistent with how normal pointer enter events are handled in Wayland. I would change this so the cursor remains the wl_pointer cursor, and exactly the same code is used by the client to change the cursor as it does for wl_pointer. The fact that you need to use the wl_pointer interface to deal with stylus events can be considered a historical artefact, they should have been on the wl_seat. The only argument you had was that the cursor is more likely to be correct, so when the proximity-in event happens, the cursor that appears has a higher chance of being the same as the one the client sets and there will be less blinking. However this can be implemented by the compositor without any client api. Just have the compositor remember what cursor was used and set that as a guess on the enter event. The client can remain completely unaware of whether a cursor is remembered per-tool, or per-surface, or per tool*surface, or whatever. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hi, On 16 November 2015 at 13:27, Carlos Garnacho wrote: > On Mon, Nov 16, 2015 at 12:21 PM, Daniel Stone wrote: >> Can we please enforce a strict bracketing of down/up occurring in >> matched pairs inside of proximity_in/out? So, the total event stream >> would be: >> - proximity_in >> - motion >> - down >> - motion/motion/button/... >> - up >> - proximity_out >> >> I assume the implementation does this, but it would be nice to have >> encoded in the protocol. > > It is worth noting that stylus button events can be obtained while in > proximity regardless of down/up state, so that'd roughly be: > > - proximity_in > - motion/button/... > - down > - motion/button/... > - up > - motion/button/... > - proximity_out Oh sure, that's fine, just as long as down/up is strictly bracketed such that you can't just get proximity_in -> down -> proximity_out -> [nothing]. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hey :), On Mon, Nov 16, 2015 at 12:21 PM, Daniel Stone wrote: > Peter, Stephen, > > On 6 November 2015 at 04:24, Peter Hutterer wrote: >> This is the revamped version of the tablet protocol for graphics tablets >> (e.g. Wacom tablets). Too many changes from the last version (a year ago or >> so), so I won't detail them, best to look at it with fresh eyes. > > Thanks a lot for doing this! Looks really good to me, and I think > getting it in wayland-protocols would be good. > > Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer > (ha) to those would be great. The branch in mutter corresponding to this last version is: https://git.gnome.org/browse/mutter/log/?h=wip/tablet-protocol-v3 There's also: https://git.gnome.org/browse/gtk+/log/?h=wip/wayland-tablet For GTK+, but that one hasn't caught up yet with wayland-protocols > > Obligatory nitpicks follow: > >> + >> + >> + >> +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. > > Yes, it turns out the wl_seat.get_* model was probably a pretty bad > anti-pattern. Oh well. To avoid too much object proliferation though, > how about something like: > > > > Add a seat of interest to this tablet manager. The client will > receive events for all tablets currently on this seat, as well as > tablets added to this seat in future. > > > > [inline wp_tablet_seat here ...] > > > Then you can just bin wp_tablet_seat. > > Not a pattern we've previously employed, but I think it's a good one > that avoids one extra step of indirection, as well as making it a bit > easier for clients to do the right thing. > >> +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 >> +internal/external/display type, 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. > > Is VID/PID in USB space? (Answers in diff form preferred.) > >> +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, followed >> +by button release events for any button still down. This signals to >> +the client that the buttons were held when the tool left proximity. >> +Those events are all sent within the same frame. > > Can we please enforce a strict bracketing of down/up occurring in > matched pairs inside of proximity_in/out? So, the total event stream > would be: > - proximity_in > - motion > - down > - motion/motion/button/... > - up > - proximity_out > > I assume the implementation does this, but it would be nice to have > encoded in the protocol. It is worth noting that stylus button events can be obtained while in proximity regardless of down/up state, so that'd roughly be: - proximity_in - motion/button/... - down - motion/button/... - up - motion/button/... - proximity_out Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hi Jonas, On 16 November 2015 at 11:59, Jonas Ådahl wrote: > On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: >> On 6 November 2015 at 04:24, Peter Hutterer wrote: >> > +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. >> >> Yes, it turns out the wl_seat.get_* model was probably a pretty bad >> anti-pattern. Oh well. To avoid too much object proliferation though, >> how about something like: >> >> >> >> Add a seat of interest to this tablet manager. The client will >> receive events for all tablets currently on this seat, as well as >> tablets added to this seat in future. >> >> >> >> [inline wp_tablet_seat here ...] >> >> >> Then you can just bin wp_tablet_seat. >> >> Not a pattern we've previously employed, but I think it's a good one >> that avoids one extra step of indirection, as well as making it a bit >> easier for clients to do the right thing. > > How would it be easier for clients to do the right thing? It'd just make > it easy to mix different seats' tools and tablets as there would be no > more separation (except if one would bind a tablet manager per seat). Or > should tools and tablets be considered on the same "super seat", i.e. > would it be possible to see tool A from seat X on tablet V on seat Y? It makes it easier, because right now we expect them to hold a wp_tablet_manager, respond to new seats by creating a new wp_tablet_seat, and having them respond to events on that as well. We already make people hold absolute piles of objects, so one less seems like it could be a good thing. > Seems to me that making it possible to shove all seats in one pile is > more error prone than having them clearly separated. Possibly. I guess it depends on the failure mode. I can see it either way. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote: > Peter, Stephen, > > On 6 November 2015 at 04:24, Peter Hutterer wrote: > > This is the revamped version of the tablet protocol for graphics tablets > > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > > so), so I won't detail them, best to look at it with fresh eyes. > > Thanks a lot for doing this! Looks really good to me, and I think > getting it in wayland-protocols would be good. > > Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer > (ha) to those would be great. > > Obligatory nitpicks follow: > > > + > > + > > + > > +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. > > Yes, it turns out the wl_seat.get_* model was probably a pretty bad > anti-pattern. Oh well. To avoid too much object proliferation though, > how about something like: > > > > Add a seat of interest to this tablet manager. The client will > receive events for all tablets currently on this seat, as well as > tablets added to this seat in future. > > > > [inline wp_tablet_seat here ...] > > > Then you can just bin wp_tablet_seat. > > Not a pattern we've previously employed, but I think it's a good one > that avoids one extra step of indirection, as well as making it a bit > easier for clients to do the right thing. How would it be easier for clients to do the right thing? It'd just make it easy to mix different seats' tools and tablets as there would be no more separation (except if one would bind a tablet manager per seat). Or should tools and tablets be considered on the same "super seat", i.e. would it be possible to see tool A from seat X on tablet V on seat Y? Seems to me that making it possible to shove all seats in one pile is more error prone than having them clearly separated. > > > +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 > > +internal/external/display type, 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. > > Is VID/PID in USB space? (Answers in diff form preferred.) > > > +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, followed > > +by button release events for any button still down. This signals to > > +the client that the buttons were held when the tool left proximity. > > +Those events are all sent within the same frame. > > Can we please enforce a strict bracketing of down/up occurring in > matched pairs inside of proximity_in/out? So, the total event stream > would be: > - proximity_in > - motion > - down > - motion/motion/button/... > - up > - proximity_out > > I assume the implementation does this, but it would be nice to have > encoded in the protocol. > > > +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. > > If no buttons are down, we'd _expect_ to just get a proximity_out > immediately, right? It almost seems like we'd want a subtype argument > here, enumerating what happened: did the user lift the tool entirely > (actually out of proximity), or is the tablet still in proximity but > just wandered off to another surface? > > The doc for proximity_out also doesn't contradict this, but reading > the two together is a bit jarring: > > + [wp_tablet_tool1::proximity_out] > > + When the tablet tool leaves proximity of the tablet, button release > > + events are sen
Re: [PATCH wayland-protocols] Add the tablet protocol
Peter, Stephen, On 6 November 2015 at 04:24, Peter Hutterer wrote: > This is the revamped version of the tablet protocol for graphics tablets > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > so), so I won't detail them, best to look at it with fresh eyes. Thanks a lot for doing this! Looks really good to me, and I think getting it in wayland-protocols would be good. Do you have other implementations, e.g. GTK+/Mutter? If so, a pointer (ha) to those would be great. Obligatory nitpicks follow: > + > + > + > +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. Yes, it turns out the wl_seat.get_* model was probably a pretty bad anti-pattern. Oh well. To avoid too much object proliferation though, how about something like: Add a seat of interest to this tablet manager. The client will receive events for all tablets currently on this seat, as well as tablets added to this seat in future. [inline wp_tablet_seat here ...] Then you can just bin wp_tablet_seat. Not a pattern we've previously employed, but I think it's a good one that avoids one extra step of indirection, as well as making it a bit easier for clients to do the right thing. > +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 > +internal/external/display type, 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. Is VID/PID in USB space? (Answers in diff form preferred.) > +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, followed > +by button release events for any button still down. This signals to > +the client that the buttons were held when the tool left proximity. > +Those events are all sent within the same frame. Can we please enforce a strict bracketing of down/up occurring in matched pairs inside of proximity_in/out? So, the total event stream would be: - proximity_in - motion - down - motion/motion/button/... - up - proximity_out I assume the implementation does this, but it would be nice to have encoded in the protocol. > +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. If no buttons are down, we'd _expect_ to just get a proximity_out immediately, right? It almost seems like we'd want a subtype argument here, enumerating what happened: did the user lift the tool entirely (actually out of proximity), or is the tablet still in proximity but just wandered off to another surface? The doc for proximity_out also doesn't contradict this, but reading the two together is a bit jarring: > + [wp_tablet_tool1::proximity_out] > + When the tablet tool leaves proximity of the tablet, button release > + events are sent for each button that was held down at the time of > + leaving proximity. These events are sent in the same wp_tablet.frame > + of the proximity_out event. It'd be nice to have discussion of the two cases - genuinely leaving proximity vs. retaining proximity but leaving surface focus - together. > +Moving a tool physically from one tablet to the other has no real effect > +on the protocol, since we already have the tool object from the "tool > +added" event. All the information is already there and the proximity_in > +is all a client needs to reconstruct what happened. ... also (up+)proximity_out from the old tablet. > + > + > + An unique object that represents a physical tool that has been, or is > + cu
Re: [PATCH wayland-protocols] Add the tablet protocol
On Sun, Nov 15, 2015 at 11:50:26PM +, Auke Booij wrote: > On 6 November 2015 at 04:24, Peter Hutterer wrote: > > Signed-off-by: Peter Hutterer > > --- > > This is the revamped version of the tablet protocol for graphics tablets > > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > > so), so I won't detail them, best to look at it with fresh eyes. > > Would it be possible to cross-reference definitions in s, > as was made possible by the introduction of the enum attribute > recently? E.g. > > > ... > > ... > > ... > > ... > thanks, I've added these locally and they'll be in the next revision (except the last, the tablet type was dropped). Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
On 6 November 2015 at 04:24, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > --- > This is the revamped version of the tablet protocol for graphics tablets > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > so), so I won't detail them, best to look at it with fresh eyes. Would it be possible to cross-reference definitions in s, as was made possible by the introduction of the enum attribute recently? E.g. ... ... ... ... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
On Fri, Nov 13, 2015 at 10:17:15PM +0100, Carlos Garnacho wrote: > Hey, > > On Fri, Nov 6, 2015 at 5:24 AM, Peter Hutterer > wrote: > > Signed-off-by: Peter Hutterer > > --- > > This is the revamped version of the tablet protocol for graphics tablets > > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > > so), so I won't detail them, best to look at it with fresh eyes. > > > > Makefile.am| 1 + > > unstable/tablet/README | 4 + > > unstable/tablet/tablet-unstable-v1.xml | 588 > > + > > 3 files changed, 593 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 4bcab32..588cb2c 100644 > > > > > + > > + > > + Describes the type of tablet > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + This event is sent in the initial burst of events before the > > + wp_tablet.done event. > > + > > + > > + > > I'm tbh wondering whether this is all that useful. I'm seeing the > fixme in your 01/13 weston patch where this is missing a dependency on > libwacom, and I've got a similar fixme in mutter. The protocol already > exports vid/pid and node file, that seems enough to poke libwacom on > the client side, and it's not like many clients need this to implement > different behavior (the only potential user I see on my side is > gnome-control-center). good point, and makes sense. sounds like a sensible one to drop from the protocol, if it really is required here we can add it in some later version. > I think that's my only nitpick at this stage. Consider this: > Reviewed-by: Carlos Garnacho > > And the weston series really, I could see nothing wrong with it, even > helped me spot a couple of bugs in my mutter branch. Thanks, the review is much appreciated Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hey, On Fri, Nov 6, 2015 at 5:24 AM, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > --- > This is the revamped version of the tablet protocol for graphics tablets > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > so), so I won't detail them, best to look at it with fresh eyes. > > Makefile.am| 1 + > unstable/tablet/README | 4 + > unstable/tablet/tablet-unstable-v1.xml | 588 > + > 3 files changed, 593 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 4bcab32..588cb2c 100644 > + > + > + Describes the type of tablet > + > + > + > + > + > + > + > + > + > + This event is sent in the initial burst of events before the > + wp_tablet.done event. > + > + > + I'm tbh wondering whether this is all that useful. I'm seeing the fixme in your 01/13 weston patch where this is missing a dependency on libwacom, and I've got a similar fixme in mutter. The protocol already exports vid/pid and node file, that seems enough to poke libwacom on the client side, and it's not like many clients need this to implement different behavior (the only potential user I see on my side is gnome-control-center). I think that's my only nitpick at this stage. Consider this: Reviewed-by: Carlos Garnacho And the weston series really, I could see nothing wrong with it, even helped me spot a couple of bugs in my mutter branch. Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
On Mon, Nov 09, 2015 at 02:33:39PM -0800, Jason Gerecke wrote:
> On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak wrote:
> > Having read this more carefully, the cursor scheme absolutely will not work.
> >
> > The main problem is that the client may want to choose a cursor for a tool
> > based on the location at which it came into proximity. It cannot set this
> > cursor until after it gets the proximity event. If this desired cursor is
> > different than the one the tool currently has set then that incorrect cursor
> > will be seen, at least briefly.
> >
> I'm afraid I don't understand what meaningful difference there is
> between the scheme here and wl_pointer. As you point out, there is a
> brief window of time when the incorrect cursor can be seen with _both_
> protocols. Its a simple result of the fact that a client _can't_ know
> that it needs to change the cursor until _after_ it receives some kind
> of focus event ('enter' or 'proximity_in'). I suppose the client could
> provide a reference to the surface over which a particular
> 'set_cursor' should take effect (and then have the compositor keep
> track of all those references) but I'm sure that has its own issues.
>
> > A further problem is that there has to be an easy transition between clients
> > that don't use the tablet api and those that do. Operation of gui widgets
> > that work equally well with mouse or tablet should not change just because
> > the client has decided to enable the tablet interface. The primary problem
> > is that the pointer position must move to the last tablet tool positiion
> > whether or not the client is using the tablet interface. This then means
> > there cannot be more than one cursor (since they would be right atop each
> > other).
> >
> While I absolutely agree that GUI widgets should work equally well
> with a tablet as a pointer, the "primary problem" is not that the
> pointer has to be moved; widgets can work just fine if they're aware
> of the tablet protocol. The fundamental problem that prevents things
> from "just working" is that tablets don't send wl_pointer events of
> any kind.
>
> There's certainly a compatibility benefit to having the tablet
> controlling the pointer, but it isn't always appropriate.
note that the protocol doesn't *prevent* a compositor from emulating
wl_pointer events for tablet events. the weston implementation here doesn't
do so because I think it's a bad idea (for the reasons you outlined anyway)
but in theory nothing stops anyone from doing so.
> Although you
> can get away with it in the most common case of a non-display tablet
> mapped to the entire desktop, it gets annoying _fast_ when a tablet
> which is mapped to just a portion of the desktop (e.g. a display
> tablet on a multi-head system) since you /don't/ generally want the
> mouse cursor to move: you just want the UI elements you click on to
> respond. Putting tablets into separate seats might be a solution to
> this, but it seems like its ripe for causing other unintended problems
> (e.g. clicking on a text box and then not being able to type since the
> keyboard focus isn't associated with the same seat as the tablet).
>
> Leaving support for the tablet protocol up to the client gives me
> pause, but its less frightening once you consider that practically any
> non-toy application will be written with the aid of a toolkit. As long
> as the toolkits do the right thing, so will applications built on
> them. Its the same situation with touch: authors who don't use a
> toolkit can write applications that don't function with a touchscreen,
> but most applications will work fine since toolkits know they need to
> handle wl_touch.
>
> > My recommendation:
> >
> > - Proximity-in jumps the cursor and pointer position to the location but
> > does not change the cursor. It will however send proximity-in events to the
> > client (it will also send proximity-out to other clients using the tablet
> > interface, and normal wl_pointer exit events to clients not using the tablet
> > interface).
> >
> > - Client should respond to proximity-in by setting the wl_pointer cursor to
> > whatever is desired. Notice this is identical to how clients not using the
> > tablet interface respond to wl_pointer::enter events.
> >
> > This will 'blink' still, as the current cursor is also possibly not equal to
> > the desired cursor. This could be fixed, but if so the exact same fix must
> > be done to enter events or you really are not solving anything. Also note
> > that hiding the cursor is not acceptable, it will be perceived as a blink if
> > the cursor was correct and near the location of the proximity-in.
> >
> Disagree with these two recommendations as outlined above.
>
> > - Proximity-in and enter events "freeze" the cursor at it's current
> > location, and it does not move until the client sets the cursor image.
> >
> Wouldn't this alone solve the issue of the wrong pointer being
> displayed for a split-second? I'm not sure if its th
Re: [PATCH wayland-protocols] Add the tablet protocol
On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak wrote:
> Having read this more carefully, the cursor scheme absolutely will not work.
>
> The main problem is that the client may want to choose a cursor for a tool
> based on the location at which it came into proximity. It cannot set this
> cursor until after it gets the proximity event. If this desired cursor is
> different than the one the tool currently has set then that incorrect cursor
> will be seen, at least briefly.
>
I'm afraid I don't understand what meaningful difference there is
between the scheme here and wl_pointer. As you point out, there is a
brief window of time when the incorrect cursor can be seen with _both_
protocols. Its a simple result of the fact that a client _can't_ know
that it needs to change the cursor until _after_ it receives some kind
of focus event ('enter' or 'proximity_in'). I suppose the client could
provide a reference to the surface over which a particular
'set_cursor' should take effect (and then have the compositor keep
track of all those references) but I'm sure that has its own issues.
> A further problem is that there has to be an easy transition between clients
> that don't use the tablet api and those that do. Operation of gui widgets
> that work equally well with mouse or tablet should not change just because
> the client has decided to enable the tablet interface. The primary problem
> is that the pointer position must move to the last tablet tool positiion
> whether or not the client is using the tablet interface. This then means
> there cannot be more than one cursor (since they would be right atop each
> other).
>
While I absolutely agree that GUI widgets should work equally well
with a tablet as a pointer, the "primary problem" is not that the
pointer has to be moved; widgets can work just fine if they're aware
of the tablet protocol. The fundamental problem that prevents things
from "just working" is that tablets don't send wl_pointer events of
any kind.
There's certainly a compatibility benefit to having the tablet
controlling the pointer, but it isn't always appropriate. Although you
can get away with it in the most common case of a non-display tablet
mapped to the entire desktop, it gets annoying _fast_ when a tablet
which is mapped to just a portion of the desktop (e.g. a display
tablet on a multi-head system) since you /don't/ generally want the
mouse cursor to move: you just want the UI elements you click on to
respond. Putting tablets into separate seats might be a solution to
this, but it seems like its ripe for causing other unintended problems
(e.g. clicking on a text box and then not being able to type since the
keyboard focus isn't associated with the same seat as the tablet).
Leaving support for the tablet protocol up to the client gives me
pause, but its less frightening once you consider that practically any
non-toy application will be written with the aid of a toolkit. As long
as the toolkits do the right thing, so will applications built on
them. Its the same situation with touch: authors who don't use a
toolkit can write applications that don't function with a touchscreen,
but most applications will work fine since toolkits know they need to
handle wl_touch.
> My recommendation:
>
> - Proximity-in jumps the cursor and pointer position to the location but
> does not change the cursor. It will however send proximity-in events to the
> client (it will also send proximity-out to other clients using the tablet
> interface, and normal wl_pointer exit events to clients not using the tablet
> interface).
>
> - Client should respond to proximity-in by setting the wl_pointer cursor to
> whatever is desired. Notice this is identical to how clients not using the
> tablet interface respond to wl_pointer::enter events.
>
> This will 'blink' still, as the current cursor is also possibly not equal to
> the desired cursor. This could be fixed, but if so the exact same fix must
> be done to enter events or you really are not solving anything. Also note
> that hiding the cursor is not acceptable, it will be perceived as a blink if
> the cursor was correct and near the location of the proximity-in.
>
Disagree with these two recommendations as outlined above.
> - Proximity-in and enter events "freeze" the cursor at it's current
> location, and it does not move until the client sets the cursor image.
>
Wouldn't this alone solve the issue of the wrong pointer being
displayed for a split-second? I'm not sure if its the compositor's
place to "freeze" the cursor until a client responds (that sounds a
little dicey, especially with hung clients), but it could be an
interesting approach.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours
> On Thu, Nov 5, 2015 at 8:24 PM, Peter Hutterer
> wrote:
>>
>> Signed-off-by: Peter Hutterer
>> ---
>> This is the
Re: [PATCH wayland-protocols] Add the tablet protocol
Having read this more carefully, the cursor scheme absolutely will not work. The main problem is that the client may want to choose a cursor for a tool based on the location at which it came into proximity. It cannot set this cursor until after it gets the proximity event. If this desired cursor is different than the one the tool currently has set then that incorrect cursor will be seen, at least briefly. A further problem is that there has to be an easy transition between clients that don't use the tablet api and those that do. Operation of gui widgets that work equally well with mouse or tablet should not change just because the client has decided to enable the tablet interface. The primary problem is that the pointer position must move to the last tablet tool positiion whether or not the client is using the tablet interface. This then means there cannot be more than one cursor (since they would be right atop each other). My recommendation: - Proximity-in jumps the cursor and pointer position to the location but does not change the cursor. It will however send proximity-in events to the client (it will also send proximity-out to other clients using the tablet interface, and normal wl_pointer exit events to clients not using the tablet interface). - Client should respond to proximity-in by setting the wl_pointer cursor to whatever is desired. Notice this is identical to how clients not using the tablet interface respond to wl_pointer::enter events. This will 'blink' still, as the current cursor is also possibly not equal to the desired cursor. This could be fixed, but if so the exact same fix must be done to enter events or you really are not solving anything. Also note that hiding the cursor is not acceptable, it will be perceived as a blink if the cursor was correct and near the location of the proximity-in. - Proximity-in and enter events "freeze" the cursor at it's current location, and it does not move until the client sets the cursor image. On Thu, Nov 5, 2015 at 8:24 PM, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > --- > This is the revamped version of the tablet protocol for graphics tablets > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > so), so I won't detail them, best to look at it with fresh eyes. > > Makefile.am| 1 + > unstable/tablet/README | 4 + > unstable/tablet/tablet-unstable-v1.xml | 588 > + > 3 files changed, 593 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 4bcab32..588cb2c 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -6,6 +6,7 @@ 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 = $(protocols) > 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..b07eccb > --- /dev/null > +++ b/unstable/tablet/tablet-unstable-v1.xml > @@ -0,0 +1,588 @@ > + > + > + > +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 > +internal/external/display type, 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. > + > +
Re: [PATCH wayland-protocols] Add the tablet protocol
On Thu, Nov 5, 2015 at 8:24 PM, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > --- > This is the revamped version of the tablet protocol for graphics tablets > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > so), so I won't detail them, best to look at it with fresh eyes. > > Makefile.am| 1 + > unstable/tablet/README | 4 + > unstable/tablet/tablet-unstable-v1.xml | 588 > + > 3 files changed, 593 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 4bcab32..588cb2c 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -6,6 +6,7 @@ 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 = $(protocols) > 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..b07eccb > --- /dev/null > +++ b/unstable/tablet/tablet-unstable-v1.xml > @@ -0,0 +1,588 @@ > + > + > + > +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 > +internal/external/display type, 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. Nitpick: Unnecessary paragraph break here :) > + > +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, followed > +by button release events for any button still down. This signals to > +the client that the buttons were held when the tool left proximity. > +Those events are all sent within the same frame. > + > +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, since we already have the t
