protocol questions

[Kristian Høgsberg]

On Sat, Mar 30, 2013 at 01:31:34AM -0400, Matthias Clasen wrote:
> Here are a few questions/observations I had while studying the protocol docs:

Most of these have been covered in responses, but let me sum up.

> - The use of serials in events seems a bit inconsistent. Most
> wl_pointer events have serials, but axis doesn't. wl_keyboard
> enter/leave events do. wl_data_offer.enter does, but the corresponding
> leave/motion events don't. Is there a rationale for this ?

First of all - yes, we need to document which serial is expected
whenever a requests takes a serial.  Now, as for when to use a serial
in an event: if the event signals a change in compositor state that
makes the compositor handle requests differently.  Which sounds a
little abstract or vauge, but for example, a wl_pointer entering a
window means that the client that owns the window can now set the
cursor.  A button press starts an implicit grab and while that's
active the client can ask the compositor to start moving or resizing
its window.

Conversely, the pointer moving around within a surface doesn't affect
how the compositor makes decisions about incoming requests and as such
we don't have serials in those events.

> - Various input events have a time field. The spec doesn't really say
> anything about this. What is it good for, and what units are these -
> monotonic time ?

The units are miliseconds, but the timestamp base is undefined and
they're only good for comparing against other input event timestamps.
They are only available for input events that actually correspond to
user activity (moving the mouse, clicking a button or key) as opposed
to side-effect events suchs as enter/leave, which can happen without
user interaction (a surface goes away spontaneously and the underlying
surface receives a wl_pointer enter event).

They're useful for determining double click speed, typing speed (if
that's ever useful) or as Thiago suggests, for determining if a key
press came before a mouse button click.  Other uses are determining
pointer speed or gesture recognition, where accurate timestamps for
touch motion events are required.

> - It looks like I can't trigger a popup from a key or touch event,
> because set_popup requires a serial that corresponds to an implicit
> pointer grab. That is sad, I like the menu key...

Yes, it looks like we'll need new protocol for that.  It's also not
possible to trigger keyboard move or resize of windows.

> - Still on popups, I don't see a way for the client to dismiss the
> popup, or is that handled by just destroying the surface ?

Yes, just destroy the surface.  The first popup starts the grab,
adding more popups will keep the grab in place, but once all popups
are gone, the grab is terminated.  So it's possible to popup window A,
then window B and then destroy A, and keep the grab.  Once B is
destroyed, the grab terminates.  There is no way for a client to
terminate the grab and keep the windows in place.

> - Buffer transformations - fun. How do these relate to each of the following ?
>    - resize edges
>    - transient offset
>    - buffer attach x/y
>    - input/opaque/damage regions
>    - surface x/y in motion events

All these are in the surface coordinate system and aren't affect by
buffer transformations.  The buffer transforms lets a client indicate
that buffer contents has been renderered according to one of the 8
rotation/flip combinations.  The intention is that a client can render
the buffer contents according to the output transform of the output
it's displaying on.  This allows the compositor to pageflip to client
buffers even on displays that are transformed in one of these ways.

> - What is a wl_touch.frame event ? Weston doesn't seem to generate those...

Daniel covered this.

> - Various strings in the protocol: title, class, output model/make.
> Are all of these required/known to be UTF-8 ? The class is documented
> as being a file path, which is bad news wrt to encodings...

Yes, all are UTF-8.  What would you recommend for the class property?

> - The wl_pointer interface seems to be a bit weak wrt to device
> properties. I would at least expect to learn about the number of
> buttons and right-handed vs left-handed, etc.

Daniel covered this, though I do think that we should be able to
determine the set of all buttons supported by all mice and communicate
to the client if there's a case for that.

Kristian