Hi, No real opinion on the angles/units thing, and indeed we can't really add native 64-bit integers now (even if we did, it rapidly descends into a padding/alignment nightmare; much easier to keep _everything_ on the wire as 32-bit units for that reason). Aside from that:
On 29 January 2016 at 04:32, Peter Hutterer <peter.hutte...@who-t.net> wrote: > + 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. This took me a couple of reads to convince myself; it might be useful to explicitly make the difference between physically out of proximity, and a logical event (for the second paragraph) here. But it seems fine. > + <interface name="zwp_tablet_manager_v1" version="1"> > + <description summary="controller object for graphic tablet devices"> > + An object that provides access to the graphics tablets available on > this > + system. Any tablet is associated with a seat, to get access to the > + actual tablets, use wp_tablet_manager.get_tablet_seat. > + </description> > + > + <request name="get_tablet_seat"> > + <description summary="get the tablet seat"> > + Get the wp_tablet_seat object for the given seat. This object > + provides access to all graphics tablets in this seat. > + </description> > + <arg name="tablet_seat" type="new_id" interface="zwp_tablet_seat_v1"/> > + <arg name="seat" type="object" interface="wl_seat" summary="The > wl_seat object to retrieve the tablets for" /> > + </request> > + > + <request name="destroy" type="destructor"> > + <description summary="release the memory for the tablet manager > object"> > + This destroys the resources associated with the tablet manager. Which associated resources? Does it imply that all tablet_seats will (by the server) or should (by the client) be destroyed by this point? Or is it just purely the object itself? > + <interface name="zwp_tablet_seat_v1" version="1"> > + <description summary="controller object for graphic tablet devices of a > seat"> > + An object that provides access to the graphics tablets available on > this > + seat. After binding to this interface, the compositor sends a set of > + wp_tablet_seat.tablet_added and wp_tablet_seat.tool_added events. > + </description> > + > + <request name="destroy" type="destructor"> > + <description summary="release the memory for the tablet seat object"> > + This destroys the resources associated with the tablet seat. Same question, but for tablet/tablet_tools. > + <request name="destroy" type="destructor"> > + <description summary="destroy the tool object"> > + This destroys the client's resource for this tool object. > + > + A client must not issue this request until it receives a > + wp_tablet_tool.remove event. > + </description> > + </request> From last time (two levels in me, one level in you): > > Egads. What happens when a client no longer wants to know about tablet > > events (e.g. you have an embedded drawing program in a browser but > > then close the tab): it just has to ignore the stream of events > > forever? A bit hostile. > > you can drop the tablet manager and re-bind. I think filtering specific > devices at the protocol level is a bit of a niche usecase and better handled > in the toolkit. So, this ties in with the questions above, about what gets destroyed / is required to have been destroyed. For me, it's less about filtering/ignoring particular tools, than a clean takedown sequence. Say you switch from a mode where tablet events are useful/important (you're in a browser and drawing sequence diagrams) to not (sequence diagrams are really boring so you're watching highlights of the 1990 World Cup on YouTube). What's - ideally described in $WAYLAND_DEBUG form - the sequence for a client cleanly exiting from all tablet events? (Assuming that destroy before removed is supported, presumably it'd need to follow the same proximity_out+up+frame sequence so the client knew when it would no longer receive any events.) > + <enum name="capability"> > + [...] > + <entry name="slider" value="5" summary="Slider axis"/> > + <entry name="wheel" value="6" summary="Slider axis"/> Whoops. :) > + <event name="removed"> > + <description summary="tool removed"> > + This event is sent when the tool is removed from the system and will > + send no further events. Should the physical tool comes back into > + proximity later, a new wp_tablet_tool object will be created. > + > + It is compositor-dependent when a tool is removed. A compositor may > + remove a tool on proximity out, tablet removal or any other reason. > + A compositor may also keep a tool alive until shutdown. > + > + If the tool is currently in proximity, a proximity_out event will be > + sent before the removed event. ... and an up event? > + <enum name="error"> > + <entry name="role" value="0" summary="given wl_surface has another > role"/> > + </enum> ?! > + <request name="destroy" type="destructor"> > + <description summary="destroy the tablet object"> > + This destroys the client's resource for this tablet object. > + > + A client must not issue this request until it receives a > + wp_tablet.remove event. > + </description> > + </request> All the same questions apply. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
