Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Thu, Oct 4, 2012 at 12:47 AM, Daniel Stone dan...@fooishbar.org wrote: Hi, On 29 September 2012 19:31, Jonas Ådahl jad...@gmail.com wrote: Ok, so what I'm trying to do is to enable what people call smooth scrolling on an input level, meaning that scrolling is not based on discrete arbitrary steps but on a more fluid motion. These types of events makes most sense for certain types of step-less scroll wheels and touchpads and I'll try to explain why. I agree it makes perfect sense, but note that axis events are already fixed-point, so you already get fairly fluid motion (motion in units of 1/256th of a wheel 'chunk', i.e. already subpixel). The only advantage of making it pixel-based is that clients no longer have to do the multiplication. But some applications don't want to smoothly scroll by pixels, and instead just want to, e.g, flip a page, every time the scroll motion passes a certain threshold. When axis events are discrete steps, there is indeed little need to relate to any kind of coordinate space except knowing what is up and what is down. A step can only be 1 or -1, thats it. This is how it traditionally works in X11 (except XI2 I think supports non-discrete axis events). XI2 follows exactly the same approach of offering scroll events in units of wheel chunks, except with a little more precision (using 16.16 fixed-point rather than 24.8). If one wants to have axis events that more resemble smooth motions, such as the ones emitted by those step-less scroll wheels or touchpads, one needs to specify what the events actually mean, since they are no longer only limited to 1 and -1. To do this, if we specify an axis event to be a vector along an axis in a coordinate space identical to motion events, we can create axis events that relate to some measurement already known to both the compositor and client. A step-less scroll wheel would transform its scroll events to a motion vector measured in pixels and a touchpad would simply emit an axis event as it would emit a motion event when scrolling. A client could then read these events and can scroll its view by that amount of pixels specified by the value parameter. I don't think this change makes much difference; the key is really just tuning the acceleration in the server (usually so it has a little more initial resistance and dampens low speeds, but accelerates dramatically at high speeds). I'm pretty ambivalent about this. The major difference between the (even smooth) step-based approach is that it makes it possible to have scroll events that feel the same as motion events (again, talking about touchpads here). By scaling down the motion vector it would make it more or less impossible without communicating factors to get axis events as if they were motion events. I think step based scrolling can be useful as well, but I think its use cases are different from scrolling view ports. For example games probably want to make use of scroll steps to change some state, but wont do so with a the fractional steps. I'd say that having another type of axis (say horizontal/vertical step) for those types would make more sense. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
Hi, On 4 October 2012 17:06, Jonas Ådahl jad...@gmail.com wrote: On Thu, Oct 4, 2012 at 12:47 AM, Daniel Stone dan...@fooishbar.org wrote: I agree it makes perfect sense, but note that axis events are already fixed-point, so you already get fairly fluid motion (motion in units of 1/256th of a wheel 'chunk', i.e. already subpixel). The only advantage of making it pixel-based is that clients no longer have to do the multiplication. But some applications don't want to smoothly scroll by pixels, and instead just want to, e.g, flip a page, every time the scroll motion passes a certain threshold. The major difference between the (even smooth) step-based approach is that it makes it possible to have scroll events that feel the same as motion events (again, talking about touchpads here). By scaling down the motion vector it would make it more or less impossible without communicating factors to get axis events as if they were motion events. As I said, you don't want scrolling to have the same acceleration as pointer motion anyway - at least IMHO. I think step based scrolling can be useful as well, but I think its use cases are different from scrolling view ports. For example games probably want to make use of scroll steps to change some state, but wont do so with a the fractional steps. I'd say that having another type of axis (say horizontal/vertical step) for those types would make more sense. I still think the current approach makes the most sense though, as it makes both possible. Though for touchpad scrolling where you want chunks, you probably want to know when the scroll motion started and when it stopped, rather than how many chunks it progressed through. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Thu, Oct 4, 2012 at 1:33 PM, Daniel Stone dan...@fooishbar.org wrote: Hi, On 4 October 2012 17:06, Jonas Ådahl jad...@gmail.com wrote: On Thu, Oct 4, 2012 at 12:47 AM, Daniel Stone dan...@fooishbar.org wrote: I agree it makes perfect sense, but note that axis events are already fixed-point, so you already get fairly fluid motion (motion in units of 1/256th of a wheel 'chunk', i.e. already subpixel). The only advantage of making it pixel-based is that clients no longer have to do the multiplication. But some applications don't want to smoothly scroll by pixels, and instead just want to, e.g, flip a page, every time the scroll motion passes a certain threshold. The major difference between the (even smooth) step-based approach is that it makes it possible to have scroll events that feel the same as motion events (again, talking about touchpads here). By scaling down the motion vector it would make it more or less impossible without communicating factors to get axis events as if they were motion events. As I said, you don't want scrolling to have the same acceleration as pointer motion anyway - at least IMHO. Acceleration or not, that's (in this case) a detail of the touchpad implementation and unrelated to the axis protocol itself. I think step based scrolling can be useful as well, but I think its use cases are different from scrolling view ports. For example games probably want to make use of scroll steps to change some state, but wont do so with a the fractional steps. I'd say that having another type of axis (say horizontal/vertical step) for those types would make more sense. I still think the current approach makes the most sense though, as it makes both possible. Though for touchpad scrolling where you want chunks, you probably want to know when the scroll motion started and when it stopped, rather than how many chunks it progressed through. For touchpad scrolling, chunks is what you want to avoid. You want the scrolling to be as smooth as moving the pointer, and you want it to behave similar, IMHO. If scrolling is measured in arbitrary steps, it is impossible for the client to behave as one would expect in the mentioned case since the toolkit is unaware of what factor touchpad driver used to generate the steps. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
Hi, On 29 September 2012 19:31, Jonas Ådahl jad...@gmail.com wrote: Ok, so what I'm trying to do is to enable what people call smooth scrolling on an input level, meaning that scrolling is not based on discrete arbitrary steps but on a more fluid motion. These types of events makes most sense for certain types of step-less scroll wheels and touchpads and I'll try to explain why. I agree it makes perfect sense, but note that axis events are already fixed-point, so you already get fairly fluid motion (motion in units of 1/256th of a wheel 'chunk', i.e. already subpixel). The only advantage of making it pixel-based is that clients no longer have to do the multiplication. But some applications don't want to smoothly scroll by pixels, and instead just want to, e.g, flip a page, every time the scroll motion passes a certain threshold. When axis events are discrete steps, there is indeed little need to relate to any kind of coordinate space except knowing what is up and what is down. A step can only be 1 or -1, thats it. This is how it traditionally works in X11 (except XI2 I think supports non-discrete axis events). XI2 follows exactly the same approach of offering scroll events in units of wheel chunks, except with a little more precision (using 16.16 fixed-point rather than 24.8). If one wants to have axis events that more resemble smooth motions, such as the ones emitted by those step-less scroll wheels or touchpads, one needs to specify what the events actually mean, since they are no longer only limited to 1 and -1. To do this, if we specify an axis event to be a vector along an axis in a coordinate space identical to motion events, we can create axis events that relate to some measurement already known to both the compositor and client. A step-less scroll wheel would transform its scroll events to a motion vector measured in pixels and a touchpad would simply emit an axis event as it would emit a motion event when scrolling. A client could then read these events and can scroll its view by that amount of pixels specified by the value parameter. I don't think this change makes much difference; the key is really just tuning the acceleration in the server (usually so it has a little more initial resistance and dampens low speeds, but accelerates dramatically at high speeds). I'm pretty ambivalent about this. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Fri, Sep 28, 2012 at 9:58 PM, Scott Moreau ore...@gmail.com wrote: On Fri, Sep 28, 2012 at 7:09 AM, Jonas Ådahl jad...@gmail.com wrote: On Fri, Sep 28, 2012 at 2:47 PM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 28 Sep 2012 14:30:18 +0200 Jonas Ådahl jad...@gmail.com wrote: On Fri, Sep 28, 2012 at 2:13 PM, Pekka Paalanen ppaala...@gmail.com wrote: I have an old discrete-stepped mouse wheel, it reports: Event: time 1348834027.330811, type 2 (EV_REL), code 8 (REL_WHEEL), value 1 Event: time 1348834027.330812, -- SYN_REPORT and the other direction: Which one did you scroll downward? Negative is down, positive is up. Event: time 1348834027.906825, type 2 (EV_REL), code 8 (REL_WHEEL), value -1 Event: time 1348834027.906827, -- SYN_REPORT So it reports literally the number of steps it rotates. In urxvt on X, each step seems to scroll 5 lines. Ok, so to emulate the axis movement for the event it needs to move a number of pixels per event. For the X11 compositor I made it move 10 pixels units per step, maybe can do the same with evdev. Is it worth having discrete scroll events handled separately in another way (or even both ways) as it could be good to be able to detect discrete scroll movements correctly as well? Do you mean adding more protocol for discrete axis motion? I don't know. At first thought it seems just emitting motion in steps of 10 or whatever is good enough. Btw. the clarify pointer axis event -commit didn't make too much sense until I thought of touchpads. Yes, I was also confused by this until considering touchpads. It still does not make sense when considering both, however. On mice, the motion and wheel are inherently in different, arbitrary units. One might even argue, that for wheels, the motion is an angle instead of a length. I don't have any strong opinions here, and I don't know how existing smooth scrolling works. It makes most sense on touchpads indeed, but it is more or less the only coordinate space we can relate to, as I see it. Axis events have nothing to do with a coordinate system really. The other way to make it more like the traditional protocols is to have 1 step be 1 unit, and have smooth scroll wheels or touchpads use fractions of 1 to step smaller steps. This would however make the coordinate space of the axis event harder to relate to a surface, and I don't think it's better. Jonas Can you please explain in more detail, why the current code needs changing, so that people without a touch device can understand the problem better? Ok, so what I'm trying to do is to enable what people call smooth scrolling on an input level, meaning that scrolling is not based on discrete arbitrary steps but on a more fluid motion. These types of events makes most sense for certain types of step-less scroll wheels and touchpads and I'll try to explain why. When axis events are discrete steps, there is indeed little need to relate to any kind of coordinate space except knowing what is up and what is down. A step can only be 1 or -1, thats it. This is how it traditionally works in X11 (except XI2 I think supports non-discrete axis events). If one wants to have axis events that more resemble smooth motions, such as the ones emitted by those step-less scroll wheels or touchpads, one needs to specify what the events actually mean, since they are no longer only limited to 1 and -1. To do this, if we specify an axis event to be a vector along an axis in a coordinate space identical to motion events, we can create axis events that relate to some measurement already known to both the compositor and client. A step-less scroll wheel would transform its scroll events to a motion vector measured in pixels and a touchpad would simply emit an axis event as it would emit a motion event when scrolling. A client could then read these events and can scroll its view by that amount of pixels specified by the value parameter. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
Ok, so what I'm trying to do is to enable what people call smooth scrolling on an input level, meaning that scrolling is not based on discrete arbitrary steps but on a more fluid motion. These types of events makes most sense for certain types of step-less scroll wheels and touchpads and I'll try to explain why. When axis events are discrete steps, there is indeed little need to relate to any kind of coordinate space except knowing what is up and what is down. A step can only be 1 or -1, thats it. This is how it traditionally works in X11 (except XI2 I think supports non-discrete axis events). If one wants to have axis events that more resemble smooth motions, such as the ones emitted by those step-less scroll wheels or touchpads, one needs to specify what the events actually mean, since they are no longer only limited to 1 and -1. To do this, if we specify an axis event to be a vector along an axis in a coordinate space identical to motion events, we can create axis events that relate to some measurement already known to both the compositor and client. A step-less scroll wheel would transform its scroll events to a motion vector measured in pixels and a touchpad would simply emit an axis event as it would emit a motion event when scrolling. A client could then read these events and can scroll its view by that amount of pixels specified by the value parameter. Jonas This makes it much clearer. I saw there was some discussion in IRC a few days ago too. Perhaps you could put the key points you've made here, in the protocol description. I guess the only thing is now, evdev needs fixing to emit the same expected format. Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Sat, Sep 29, 2012 at 12:01 PM, Scott Moreau ore...@gmail.com wrote: Ok, so what I'm trying to do is to enable what people call smooth scrolling on an input level, meaning that scrolling is not based on discrete arbitrary steps but on a more fluid motion. These types of events makes most sense for certain types of step-less scroll wheels and touchpads and I'll try to explain why. When axis events are discrete steps, there is indeed little need to relate to any kind of coordinate space except knowing what is up and what is down. A step can only be 1 or -1, thats it. This is how it traditionally works in X11 (except XI2 I think supports non-discrete axis events). If one wants to have axis events that more resemble smooth motions, such as the ones emitted by those step-less scroll wheels or touchpads, one needs to specify what the events actually mean, since they are no longer only limited to 1 and -1. To do this, if we specify an axis event to be a vector along an axis in a coordinate space identical to motion events, we can create axis events that relate to some measurement already known to both the compositor and client. A step-less scroll wheel would transform its scroll events to a motion vector measured in pixels and a touchpad would simply emit an axis event as it would emit a motion event when scrolling. A client could then read these events and can scroll its view by that amount of pixels specified by the value parameter. Jonas This makes it much clearer. I saw there was some discussion in IRC a few days ago too. Perhaps you could put the key points you've made here, in the protocol description. I guess the only thing is now, evdev needs fixing to emit the same expected format. Sure, I'll submit another patch with more description, and another one updating evdev according to Pekka's evdev output. Thanks for the input; much appreciated. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Thu, Sep 27, 2012 at 11:04 AM, Jonas Ådahl jad...@gmail.com wrote:
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index e2715d6..6193bd2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2361,7 +2361,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t
axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2373,7 @@ surface_opacity_binding(struct wl_seat *seat,
uint32_t time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2403,9 @@ do_zoom(struct wl_seat *seat, uint32_t time,
uint32_t key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) /
20.0;
else
increment = 0;
--
1.7.9.5
Can you possibly elaborate on why this is necessary? I'm guessing it has
something to do with
http://lists.freedesktop.org/archives/wayland-devel/2012-September/005536.htmlsomehow?
I'm not seeing a clear direction here.
Thanks,
Scott
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Thu, Sep 27, 2012 at 11:04 AM, Jonas Ådahl jad...@gmail.com wrote:
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index e2715d6..6193bd2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2361,7 +2361,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t
axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2373,7 @@ surface_opacity_binding(struct wl_seat *seat,
uint32_t time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2403,9 @@ do_zoom(struct wl_seat *seat, uint32_t time,
uint32_t key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) /
20.0;
else
increment = 0;
--
1.7.9.5
This patch effectively breaks surface_opacity_binding for the desktop mouse
case. It reverses the order and makes the increment far too small. Maybe if
you can explain what you are trying to do here, we can find a solution that
doesn't break the current behaviour.
Scott
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Thu, Sep 27, 2012 at 11:04 AM, Jonas Ådahl jad...@gmail.com wrote:
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index e2715d6..6193bd2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2361,7 +2361,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t
axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2373,7 @@ surface_opacity_binding(struct wl_seat *seat,
uint32_t time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2403,9 @@ do_zoom(struct wl_seat *seat, uint32_t time,
uint32_t key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) /
20.0;
else
increment = 0;
--
1.7.9.5
I see now you changed the x11 backend in an earlier patch and account for
it here. Unless I'm missing something, that leaves backends using evdev for
input, broken.
Scott
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Fri, 28 Sep 2012 04:38:52 -0600
Scott Moreau ore...@gmail.com wrote:
On Thu, Sep 27, 2012 at 11:04 AM, Jonas Ådahl jad...@gmail.com wrote:
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index e2715d6..6193bd2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2361,7 +2361,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t
axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2373,7 @@ surface_opacity_binding(struct wl_seat *seat,
uint32_t time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2403,9 @@ do_zoom(struct wl_seat *seat, uint32_t time,
uint32_t key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) /
20.0;
else
increment = 0;
--
1.7.9.5
I see now you changed the x11 backend in an earlier patch and account for
it here. Unless I'm missing something, that leaves backends using evdev for
input, broken.
..for mouse wheels. Maybe it's ok for touchpads, though?
thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Fri, Sep 28, 2012 at 12:46 PM, Pekka Paalanen ppaala...@gmail.com wrote:
On Fri, 28 Sep 2012 04:38:52 -0600
Scott Moreau ore...@gmail.com wrote:
On Thu, Sep 27, 2012 at 11:04 AM, Jonas Ådahl jad...@gmail.com wrote:
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index e2715d6..6193bd2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2361,7 +2361,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t
axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2373,7 @@ surface_opacity_binding(struct wl_seat *seat,
uint32_t time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2403,9 @@ do_zoom(struct wl_seat *seat, uint32_t time,
uint32_t key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) /
20.0;
else
increment = 0;
--
1.7.9.5
I see now you changed the x11 backend in an earlier patch and account for
it here. Unless I'm missing something, that leaves backends using evdev for
input, broken.
..for mouse wheels. Maybe it's ok for touchpads, though?
Touchpad just got the axis feature in one of the commits in this series.
Regarding regular mouse wheels, reading the documentation[0] I'm not
sure about the expected behavior and cannot test it my self yet due to
lack of hardware. Considering that REL_WHEEL/REL_HWEEL events are
grouped together with other REL_* events one can think that they
should have the same measurement, or if not it should be documented
what they do. This might not be the case though. If the wheel events
behave as the wayland axis ones does it should work out of the box and
would have been broken before, otherwise they need to be addressed as
well. I'll get myself a mouse and test it sooner or later to see
what's actually going on.
There are also different kinds of scroll wheels out there, both the
discrete stepped one, and the smooth ones. Would be interesting to
see how these behave differently from an evdev point of view.
Jonas
[0] http://www.kernel.org/doc/Documentation/input/event-codes.txt
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Fri, 28 Sep 2012 13:46:05 +0200 Jonas Ådahl jad...@gmail.com wrote: Regarding regular mouse wheels, reading the documentation[0] I'm not sure about the expected behavior and cannot test it my self yet due to lack of hardware. Considering that REL_WHEEL/REL_HWEEL events are grouped together with other REL_* events one can think that they should have the same measurement, or if not it should be documented what they do. This might not be the case though. If the wheel events behave as the wayland axis ones does it should work out of the box and would have been broken before, otherwise they need to be addressed as well. I'll get myself a mouse and test it sooner or later to see what's actually going on. There are also different kinds of scroll wheels out there, both the discrete stepped one, and the smooth ones. Would be interesting to see how these behave differently from an evdev point of view. I have an old discrete-stepped mouse wheel, it reports: Event: time 1348834027.330811, type 2 (EV_REL), code 8 (REL_WHEEL), value 1 Event: time 1348834027.330812, -- SYN_REPORT and the other direction: Event: time 1348834027.906825, type 2 (EV_REL), code 8 (REL_WHEEL), value -1 Event: time 1348834027.906827, -- SYN_REPORT So it reports literally the number of steps it rotates. In urxvt on X, each step seems to scroll 5 lines. I don't have a smooth one to test. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Fri, Sep 28, 2012 at 2:13 PM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 28 Sep 2012 13:46:05 +0200 Jonas Ådahl jad...@gmail.com wrote: Regarding regular mouse wheels, reading the documentation[0] I'm not sure about the expected behavior and cannot test it my self yet due to lack of hardware. Considering that REL_WHEEL/REL_HWEEL events are grouped together with other REL_* events one can think that they should have the same measurement, or if not it should be documented what they do. This might not be the case though. If the wheel events behave as the wayland axis ones does it should work out of the box and would have been broken before, otherwise they need to be addressed as well. I'll get myself a mouse and test it sooner or later to see what's actually going on. There are also different kinds of scroll wheels out there, both the discrete stepped one, and the smooth ones. Would be interesting to see how these behave differently from an evdev point of view. I have an old discrete-stepped mouse wheel, it reports: Event: time 1348834027.330811, type 2 (EV_REL), code 8 (REL_WHEEL), value 1 Event: time 1348834027.330812, -- SYN_REPORT and the other direction: Which one did you scroll downward? Event: time 1348834027.906825, type 2 (EV_REL), code 8 (REL_WHEEL), value -1 Event: time 1348834027.906827, -- SYN_REPORT So it reports literally the number of steps it rotates. In urxvt on X, each step seems to scroll 5 lines. Ok, so to emulate the axis movement for the event it needs to move a number of pixels per event. For the X11 compositor I made it move 10 pixels units per step, maybe can do the same with evdev. Is it worth having discrete scroll events handled separately in another way (or even both ways) as it could be good to be able to detect discrete scroll movements correctly as well? Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Fri, 28 Sep 2012 14:30:18 +0200 Jonas Ådahl jad...@gmail.com wrote: On Fri, Sep 28, 2012 at 2:13 PM, Pekka Paalanen ppaala...@gmail.com wrote: I have an old discrete-stepped mouse wheel, it reports: Event: time 1348834027.330811, type 2 (EV_REL), code 8 (REL_WHEEL), value 1 Event: time 1348834027.330812, -- SYN_REPORT and the other direction: Which one did you scroll downward? Negative is down, positive is up. Event: time 1348834027.906825, type 2 (EV_REL), code 8 (REL_WHEEL), value -1 Event: time 1348834027.906827, -- SYN_REPORT So it reports literally the number of steps it rotates. In urxvt on X, each step seems to scroll 5 lines. Ok, so to emulate the axis movement for the event it needs to move a number of pixels per event. For the X11 compositor I made it move 10 pixels units per step, maybe can do the same with evdev. Is it worth having discrete scroll events handled separately in another way (or even both ways) as it could be good to be able to detect discrete scroll movements correctly as well? Do you mean adding more protocol for discrete axis motion? I don't know. At first thought it seems just emitting motion in steps of 10 or whatever is good enough. Btw. the clarify pointer axis event -commit didn't make too much sense until I thought of touchpads. On mice, the motion and wheel are inherently in different, arbitrary units. One might even argue, that for wheels, the motion is an angle instead of a length. I don't have any strong opinions here, and I don't know how existing smooth scrolling works. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Fri, Sep 28, 2012 at 7:09 AM, Jonas Ådahl jad...@gmail.com wrote: On Fri, Sep 28, 2012 at 2:47 PM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 28 Sep 2012 14:30:18 +0200 Jonas Ådahl jad...@gmail.com wrote: On Fri, Sep 28, 2012 at 2:13 PM, Pekka Paalanen ppaala...@gmail.com wrote: I have an old discrete-stepped mouse wheel, it reports: Event: time 1348834027.330811, type 2 (EV_REL), code 8 (REL_WHEEL), value 1 Event: time 1348834027.330812, -- SYN_REPORT and the other direction: Which one did you scroll downward? Negative is down, positive is up. Event: time 1348834027.906825, type 2 (EV_REL), code 8 (REL_WHEEL), value -1 Event: time 1348834027.906827, -- SYN_REPORT So it reports literally the number of steps it rotates. In urxvt on X, each step seems to scroll 5 lines. Ok, so to emulate the axis movement for the event it needs to move a number of pixels per event. For the X11 compositor I made it move 10 pixels units per step, maybe can do the same with evdev. Is it worth having discrete scroll events handled separately in another way (or even both ways) as it could be good to be able to detect discrete scroll movements correctly as well? Do you mean adding more protocol for discrete axis motion? I don't know. At first thought it seems just emitting motion in steps of 10 or whatever is good enough. Btw. the clarify pointer axis event -commit didn't make too much sense until I thought of touchpads. Yes, I was also confused by this until considering touchpads. It still does not make sense when considering both, however. On mice, the motion and wheel are inherently in different, arbitrary units. One might even argue, that for wheels, the motion is an angle instead of a length. I don't have any strong opinions here, and I don't know how existing smooth scrolling works. It makes most sense on touchpads indeed, but it is more or less the only coordinate space we can relate to, as I see it. Axis events have nothing to do with a coordinate system really. The other way to make it more like the traditional protocols is to have 1 step be 1 unit, and have smooth scroll wheels or touchpads use fractions of 1 to step smaller steps. This would however make the coordinate space of the axis event harder to relate to a surface, and I don't think it's better. Jonas Can you please explain in more detail, why the current code needs changing, so that people without a touch device can understand the problem better? Thanks, Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index 06d8684..ceea607 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1860,9 +1860,10 @@ shell_map_popup(struct shell_surface *shsurf)
}
wl_list_insert(es-geometry.transformation_list.prev,
shsurf-popup.parent_transform.link);
- weston_surface_set_position(es, shsurf-popup.x, shsurf-popup.y);
shsurf-popup.initial_up = 0;
+ weston_surface_set_position(es, shsurf-popup.x, shsurf-popup.y);
+ weston_surface_update_transform(es);
/* We don't require the grab to still be active, but if another
* grab has started in the meantime, we end the popup now. */
@@ -2361,7 +2362,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2374,7 @@ surface_opacity_binding(struct wl_seat *seat, uint32_t
time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2404,9 @@ do_zoom(struct wl_seat *seat, uint32_t time, uint32_t
key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) / 20.0;
else
increment = 0;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On 09/27/2012 07:40 PM, Jonas Ådahl wrote:
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index 06d8684..ceea607 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1860,9 +1860,10 @@ shell_map_popup(struct shell_surface *shsurf)
}
wl_list_insert(es-geometry.transformation_list.prev,
shsurf-popup.parent_transform.link);
- weston_surface_set_position(es, shsurf-popup.x, shsurf-popup.y);
shsurf-popup.initial_up = 0;
+ weston_surface_set_position(es, shsurf-popup.x, shsurf-popup.y);
+ weston_surface_update_transform(es);
is this snip really belongs to patch? I can't see how.
/* We don't require the grab to still be active, but if another
* grab has started in the meantime, we end the popup now. */
@@ -2361,7 +2362,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2374,7 @@ surface_opacity_binding(struct wl_seat *seat, uint32_t
time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2404,9 @@ do_zoom(struct wl_seat *seat, uint32_t time, uint32_t
key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) / 20.0;
else
increment = 0;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
On Thu, Sep 27, 2012 at 6:50 PM, Tiago Vignatti tiago.vigna...@linux.intel.com wrote: On 09/27/2012 07:40 PM, Jonas Ådahl wrote: Signed-off-by: Jonas Ådahl jad...@gmail.com --- src/shell.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/shell.c b/src/shell.c index 06d8684..ceea607 100644 --- a/src/shell.c +++ b/src/shell.c @@ -1860,9 +1860,10 @@ shell_map_popup(struct shell_surface *shsurf) } wl_list_insert(es-geometry.transformation_list.prev, shsurf-popup.parent_transform.link); - weston_surface_set_position(es, shsurf-popup.x, shsurf-popup.y); shsurf-popup.initial_up = 0; + weston_surface_set_position(es, shsurf-popup.x, shsurf-popup.y); + weston_surface_update_transform(es); is this snip really belongs to patch? I can't see how. You are right. The patch is based on an older commit. Think most patches shouldn't be affected but I'll have a look to see if any other needs resubmitting. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/shell.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index e2715d6..6193bd2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2361,7 +2361,7 @@ static void
surface_opacity_binding(struct wl_seat *seat, uint32_t time, uint32_t axis,
wl_fixed_t value, void *data)
{
- float step = 0.05;
+ float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *surface =
(struct weston_surface *) seat-pointer-focus;
@@ -2373,7 +2373,7 @@ surface_opacity_binding(struct wl_seat *seat, uint32_t
time, uint32_t axis,
if (!shsurf)
return;
- surface-alpha += wl_fixed_to_double(value) * step;
+ surface-alpha -= wl_fixed_to_double(value) * step;
if (surface-alpha 1.0)
surface-alpha = 1.0;
@@ -2403,8 +2403,9 @@ do_zoom(struct wl_seat *seat, uint32_t time, uint32_t
key, uint32_t axis,
else if (key == KEY_PAGEDOWN)
increment = -output-zoom.increment;
else if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL)
+ /* For every pixel zoom 20th of a step */
increment = output-zoom.increment *
- wl_fixed_to_double(value);
+ -wl_fixed_to_double(value) / 20.0;
else
increment = 0;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
