Wayland Relative Pointer API Progress
spitzak at gmail.com
Mon Apr 27 11:46:59 PDT 2015
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
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:
> uint - serial of the implicit grab on the origin
> wl_surface - image to drag under the cursor
> fixed_t - movement scale
> enum - turn acceleration on off for this drag.
> wl_region - cursor movement region within the draggable surface
> (allows null)
> 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".
More information about the wayland-devel