Wayland Relative Pointer API Progress

[Bill Spitzak]

On 04/24/2015 08:51 PM, x414e54 wrote:
> On Fri, Apr 24, 2015 at 6:22 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> Then apps would need to know what the accel paramaters mean, which
>> requires us to lock down the acceleration logic and mathematical
>> functions in the protocol specification. I don't think that is
>> something Wayland wants to specify.
>
> I intended acceleration would just be a bool on/off.
>
>> As a practical matter the applications that want a slow scrollbar want
>> *exactly* the same acceleration as before, just that the resulting position
>> is scaled down. Forcing them to replicate the code that the compositor is
>> doing seem mistaken.
>
> Speed would be as a scale/percent and does not effect acceleration.
> You could call it whatever, "movement scale", etc, so this should be
> acceptable?

I believe we are both questioning the idea that you use the raw device 
api to "grab" the mouse, as this would apparently bypass the 
acceleration code. It sounds like you are proposing keeping the 
acceleration result somehow accessable.

A boolean acceleration on/off will not work because it is asynchronous. 
Both the accelerated and unaccelerated positions must be available 
directly as events (though it is ok if you don't get the unaccelerated 
ones until you turn on grab and it then replays any missing ones since 
the grabbing event.

> On Sat, Apr 25, 2015 at 5:06 AM, Bill Spitzak <spitzak at gmail.com> wrote:
>> That is not sufficient as the application may want to put much more complex
>> rules on how the pointer moves (such as limiting it to a rectangle).
>
> Limiting to a specific rectangle is slightly different as you cannot
> do that by warping a cursor.

Sure you can. Clamp the x and y to be inside the rectangle and warp the 
cursor to that position.

Possibly you are thinking that the warped cursor position somehow 
effects the events? That may explain why the really simple api I am 
proposing seems to be confusing people.

What I want when a grab happens is the events continue UNCHANGED. You 
get exactly the same events including xy and relative motion, no matter 
how you move the cursor around. The cursor image is completely unrelated 
to the position being used to produce events.

> If you could change the cursor to drag including the scrollbar and
> then confine the cursor to an area, also including the speed settings
> this should allow the compositor todo everything.
>
> Something like all in one api call:
>
> wl_pointer::start_drag
>
> serial
>      uint - serial of the implicit grab on the origin
> surface
>      wl_surface - image to drag under the cursor
> speed
>      fixed_t - movement scale
> acceleration
>      enum - turn acceleration on off for this drag.
> confinement_region
>      wl_region - cursor movement region within the draggable surface
> (allows null)
> drag_region
>      wl_region - movement region of the draggable surface (allows null)

That is vastly too complicated. In particular it requires the client to 
draw the scrollbar slider using a subwindow, thus making support of this 
go deep into the low level drawing routines of the client, which is 
really painful. Also does not account for any kind of intermittent 
movement of the scrollbar.

> I think you would agree a uniform FPS is more important than in-sync scrollbars?

No, I absolutely 100% disagree.

Synchronized updating so things don't vibrate or shift is more important 
than FPS. It is even stated as part of Wayland's basic design criteria: 
"every frame is perfect".