Wayland Relative Pointer API Progress

[x414e54]

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?

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.

You do need an actual "confinement" for this.

On Sat, Apr 25, 2015 at 5:10 AM, Bill Spitzak <spitzak at gmail.com> wrote:
>
>
> On 04/24/2015 02:22 AM, Pekka Paalanen wrote:
>
>> If you have the compositor in charge of moving the cursor, and the app
>> in charge of scrolling and drawing the contents, you would get a lag
>> between the cursor moving and the content/scrollbar moving. Granted,
>> this is probably a minor issue and can happen in other scenarios. We
>> did manage to avoid the unsync with window moves, though.
>

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)


Obviously it is a bit over the top but would allow the compositor to
draw the pointer without having to rely on the application's render
and input loops.

> That's a good point: it means applications want to be able to control the
> cursor position during a drag even if they are *not* doing a "slow
> scrollbar". This is the only way to make sure the cursor stays in sync with
> the graphic being moved.

It is a trade off between a uniform cursor movement and FPS across all
applications and un-synced scrollbars. Or a cursor in sync with
scrollbars but really slow and jerky fps "software" cursor (like in
GNOME shell Wayland backend).

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