Re: Kinetic scroll in libinput Xorg driver

2016-10-26 Thread The Rasterman 
On Wed, 26 Oct 2016 06:57:53 + "Alexis BRENON @Wayland"  said:

> Just to be sure that I understand clearly, what you call 'Toolkit' is
> libraries like GTK, Qt, and co. that are used by developers to build their
> apps, isn't it ?

yes. toolkit == EFL, Qt, GTK+ and others (SDL is kind of a toolkit), FLTK, ...
chromium/blink is basically a toolkit of its own etc.

at least looking at gtk3 here it doesn't do momentum with wheel/axis scrolling
(out of the box). maybe it needs enabling? qt - same story. (not in standard
scrollable regions like in the file selector) but efl's scrollable regions do
silky smooth scrolling with momentum out of the box when you scroll your wheel
around - also as long as thumbsrcoll is enabled (it is on mobile profile) click
and drag to do the same like on mobile devices - with momentum when releasing.

my point here is - if you go mess with the input events as they actually come
from a device, it will totally mess with this kind of code that is doing all
the smoothing, interpolation and animated momentum already. it isn't the job of
a low level input event to go and try and pretend to have events it does not to
try and produce these kinds of effects which are already done at the toolkit
level by at least 1 toolkit, and the input device doesn't have the context
information a toolkit has to know when to stop, bounce back, or just do this in
steps rather than with momentum (eg with a slider widget).

> Finally, do you know some tiling DE/WM Wayland compliant ?

yes. enlightenment with tiling module enabled will do this. tiling module is a
bit rough, but people do use it.

> Kind,
> Alexis.
> 
> Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler  a
> écrit :
> 
> > On Mon, 24 Oct 2016 18:42:31 + "Alexis BRENON @Wayland"  > +wayl...@gmail.com> said:
> >
> > > Hello everyone,
> > >
> > > I would like to implement kinetic scroll in the libinput driver for Xorg.
> > >
> > > I know that it's probably not the intended use of libinput ; as explained
> > > in the documentation, it's the client that have to manage that.
> > >
> > > However, as an Xorg user not happy with the synaptics driver, I would
> > like
> > > to add a similar feature (fixing small disagreements encountered with
> > > synaptics) to libinput, allowing Xorg users to easily move to libinput
> > > without losing this feature.
> > >
> > > My first idea is to implement the kinetic scroll using a thread that
> > sends
> > > axis events as long as there is no button event, key event or motion
> > event
> > > higher than a threshold.
> > >
> > > It makes some time since the last time I developed in C, and maybe it's
> > not
> > > the better way to do it. I would be happy to hear your advices.
> > >
> > > One thing I'm thinking of is then to add some options in the Xorg
> > > configuration file to enable/disable this feature, choose the events
> > > stopping the kinetic scroll and change some thresholds. This will allow
> > to
> > > easily disable this feature in the future in case the clients manage the
> > > kinetic scroll on their own.
> > >
> > > What do you think of this? Is there someone already working on it? Is my
> > > proposition a good way to implement it?
> > >
> > > Thanks for your attention.
> > >
> > > Kind regards,
> > > Alexis BRENON.
> >
> > we already do kinetic scrolling higher up in the toolkit. we do
> > acceleration
> > using these events and we do smooth animated scrolling in our scroller and
> > not
> > just stepping, as well as momentum as we slid with bouncing at the ends.
> > it's
> > already done in toolkit out of the box. if you try and hack this in at the
> > input layer this simply doubles the amount of this and likely makes the
> > user
> > experience worse. this would have to be off by default and if it's off by
> > default... you need ways of turning it on client by client ... and even
> > then
> > there are a pile of other problems you'll hit. so my suggestion is -
> > don't. add
> > to your favorite toolkits instead if they don't have it. they have far more
> > information about the context at the time and the use cases needed etc.
> >
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Kinetic scroll in libinput Xorg driver

2016-10-26 Thread The Rasterman 
On Wed, 26 Oct 2016 14:14:13 +0200 Christian Stroetmann
 said:

> On 26.10.2016 08:57, Alexis BRENON @Wayland wrote:
> 
> @Raster: Thank you for your reminder.
> 
> Maybe Enlightenment with Tiling2 and kinetic scrolling is already what 
> you need.

yes. and then load the tiling module (and enable tiling for the desktops you
want it on etc. - in tiling settings).

> If I remember correctly I3 (www.i3wm.org) might work 
> together with Wayland as well.

possibly might work too.

> In general, I have seen at all major toolkits transistion efforts to 
> Wayland since around 2 years. Some have matured while others are 
> experimental so to say.

indeed.

> Best Regards
> Christian Stroetmann
> 
> > Just to be sure that I understand clearly, what you call 'Toolkit' is 
> > libraries like GTK, Qt, and co. that are used by developers to build 
> > their apps, isn't it ?
> >
> > Finally, do you know some tiling DE/WM Wayland compliant ?
> >
> > Kind,
> > Alexis.
> >
> > Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler  > > a écrit :
> >
> > On Mon, 24 Oct 2016 18:42:31 + "Alexis BRENON @Wayland"
> >  > +wayl...@gmail.com > said:
> >
> > > Hello everyone,
> > >
> > > I would like to implement kinetic scroll in the libinput driver
> > for Xorg.
> > >
> > > I know that it's probably not the intended use of libinput ; as
> > explained
> > > in the documentation, it's the client that have to manage that.
> > >
> > > However, as an Xorg user not happy with the synaptics driver, I
> > would like
> > > to add a similar feature (fixing small disagreements encountered
> > with
> > > synaptics) to libinput, allowing Xorg users to easily move to
> > libinput
> > > without losing this feature.
> > >
> > > My first idea is to implement the kinetic scroll using a thread
> > that sends
> > > axis events as long as there is no button event, key event or
> > motion event
> > > higher than a threshold.
> > >
> > > It makes some time since the last time I developed in C, and
> > maybe it's not
> > > the better way to do it. I would be happy to hear your advices.
> > >
> > > One thing I'm thinking of is then to add some options in the Xorg
> > > configuration file to enable/disable this feature, choose the events
> > > stopping the kinetic scroll and change some thresholds. This
> > will allow to
> > > easily disable this feature in the future in case the clients
> > manage the
> > > kinetic scroll on their own.
> > >
> > > What do you think of this? Is there someone already working on
> > it? Is my
> > > proposition a good way to implement it?
> > >
> > > Thanks for your attention.
> > >
> > > Kind regards,
> > > Alexis BRENON.
> >
> > we already do kinetic scrolling higher up in the toolkit. we do
> > acceleration
> > using these events and we do smooth animated scrolling in our
> > scroller and not
> > just stepping, as well as momentum as we slid with bouncing at the
> > ends. it's
> > already done in toolkit out of the box. if you try and hack this
> > in at the
> > input layer this simply doubles the amount of this and likely
> > makes the user
> > experience worse. this would have to be off by default and if it's
> > off by
> > default... you need ways of turning it on client by client ... and
> > even then
> > there are a pile of other problems you'll hit. so my suggestion is
> > - don't. add
> > to your favorite toolkits instead if they don't have it. they have
> > far more
> > information about the context at the time and the use cases needed
> > etc.
> >
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am"
> > --
> > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > 
> >
> >
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Update libinput to support evdev driver v1.2

2016-10-26 Thread Peter Hutterer 
On Wed, Oct 19, 2016 at 07:05:13PM -0700, Deepa Dinamani wrote:
> Update input event structures read from the kernel to match
> the 1.2 version of the driver.
> 
> There are no changes to the exposed interfaces of libinput.
> 
> Note that the patch goes along with the changes to libevdev
> and mtdev to support the updated kernel driver.
> 
> The associated kernel driver change is proposed at
> https://lkml.org/lkml/2016/10/17/1146 .
> 
> Signed-off-by: Deepa Dinamani 
> ---
>  include/linux/input.h | 49 +++--
>  src/evdev.c   |  4 ++--
>  2 files changed, 49 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 4bf3d6d..202798a 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -13,10 +13,29 @@
>  #include 
>  #include 
>  
> -/*
> - * The event structure itself
> +/* The time structure for y2038 safe raw_input_event.
> + * The fields use unsigned types to extend times until
> + * year 2106 rather than 2038.
>   */
> +struct input_timeval {
> + __kernel_ulong_t tv_sec;
> + __kernel_ulong_t tv_usec;
> +};
> +
> +struct raw_input_event {
> + struct input_timeval time;
> + __u16 type;
> + __u16 code;
> + __s32 value;
> +};
> +
> +#ifndef __KERNEL__
>  
> +/* Userspace structure.
> + * Definition maintained here for userspace that is not yet updated to use
> + * struct raw_input_event.
> + * Not to be used anywhere within the kernel.
> + */
>  struct input_event {
>   struct timeval time;
>   __u16 type;
> @@ -24,11 +43,37 @@ struct input_event {
>   __s32 value;
>  };
>  
> +
> +static inline void
> +raw_input_to_input_event(const struct raw_input_event *raw, struct 
> input_event *ev)
> +{
> + ev->time.tv_sec = raw->time.tv_sec;
> + ev->time.tv_usec = raw->time.tv_usec;
> + ev->type = raw->type;
> + ev->code = raw->code;
> + ev->value = raw->value;
> +}
> +
> +static inline void
> +input_to_raw_event(const struct input_event *ev, struct raw_input_event *raw)
> +{
> + raw->time.tv_sec = ev->time.tv_sec;
> + raw->time.tv_usec = ev->time.tv_usec;
> + raw->type = ev->type;
> + raw->code = ev->code;
> + raw->value = ev->value;
> +}
> +
> +#endif
> +
> +
>  /*
>   * Protocol version.
>   */
>  
>  #define EV_VERSION   0x010001
> +#define EV_VERSION_1_2 0x010002
> +
>  
>  /*
>   * IOCTLs (0x00 - 0x7f)
> diff --git a/src/evdev.c b/src/evdev.c
> index f7f7230..5d47119 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -256,7 +256,7 @@ evdev_device_led_update(struct evdev_device *device, enum 
> libinput_led leds)
>   { LIBINPUT_LED_CAPS_LOCK, LED_CAPSL },
>   { LIBINPUT_LED_SCROLL_LOCK, LED_SCROLLL },
>   };
> - struct input_event ev[ARRAY_LENGTH(map) + 1];
> + struct raw_input_event ev[ARRAY_LENGTH(map) + 1];
>   unsigned int i;
>  
>   if (!(device->seat_caps & EVDEV_DEVICE_KEYBOARD))
> @@ -2665,7 +2665,7 @@ evdev_set_device_group(struct evdev_device *device,
>  static inline void
>  evdev_drain_fd(int fd)
>  {
> - struct input_event ev[24];
> + struct raw_input_event ev[24];

don't we need some version detection here? what's the effect of writing new
structs to old kernels, other than lighting up LEDs that shouldn't be lit?

Cheers,
   Peter

>   size_t sz = sizeof ev;
>  
>   while (read(fd, , sz) == (int)sz) {
> -- 
> 2.7.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v2 2/2] config-parser-test: test support for more color formats

2016-10-26 Thread Eric Engestrom 
Add tests for all the supported colour formats

Cc: Bryce Harrington 
Cc: Quentin Glidic 
Signed-off-by: Eric Engestrom 
---
v2: reduce the number of formats supported
read #-prefixed values the same way CSS would
---
 tests/config-parser-test.c | 96 ++
 1 file changed, 96 insertions(+)

diff --git a/tests/config-parser-test.c b/tests/config-parser-test.c
index 1cd..e35e2b8 100644
--- a/tests/config-parser-test.c
+++ b/tests/config-parser-test.c
@@ -127,6 +127,12 @@ static struct zuc_fixture config_test_t1 = {
"oct=01234567\n"
"dec=12345670\n"
"short=1234567\n"
+   "hex6=0x123456\n"
+   "hex8=0x12345678\n"
+   "css3=#123\n"
+   "css4=#1234\n"
+   "css6=#123456\n"
+   "css8=#12345678\n"
"\n"
"[stuff]\n"
"flag= true \n"
@@ -609,6 +615,96 @@ ZUC_TEST_F(config_test_t1, test028, data)
ZUC_ASSERT_EQ(ERANGE, errno);
 }
 
+ZUC_TEST_F(config_test_t1, test029, data)
+{
+   int r;
+   uint32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "colors", NULL, NULL);
+   r = weston_config_section_get_color(section, "hex6", , 0xff336699);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0xff123456, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
+ZUC_TEST_F(config_test_t1, test030, data)
+{
+   int r;
+   uint32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "colors", NULL, NULL);
+   r = weston_config_section_get_color(section, "hex8", , 0xff336699);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0x12345678, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
+ZUC_TEST_F(config_test_t1, test031, data)
+{
+   int r;
+   uint32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "colors", NULL, NULL);
+   r = weston_config_section_get_color(section, "css3", , 0xff336699);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0xff112233, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
+ZUC_TEST_F(config_test_t1, test032, data)
+{
+   int r;
+   uint32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "colors", NULL, NULL);
+   r = weston_config_section_get_color(section, "css4", , 0xff336699);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0x44112233, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
+ZUC_TEST_F(config_test_t1, test033, data)
+{
+   int r;
+   uint32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "colors", NULL, NULL);
+   r = weston_config_section_get_color(section, "css6", , 0xff336699);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0xff123456, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
+ZUC_TEST_F(config_test_t1, test034, data)
+{
+   int r;
+   uint32_t n;
+   struct weston_config_section *section;
+   struct weston_config *config = data;
+
+   section = weston_config_get_section(config, "colors", NULL, NULL);
+   r = weston_config_section_get_color(section, "css8", , 0xff336699);
+
+   ZUC_ASSERT_EQ(0, r);
+   ZUC_ASSERT_EQ(0x78123456, n);
+   ZUC_ASSERT_EQ(0, errno);
+}
+
 ZUC_TEST_F(config_test_t2, doesnt_parse, data)
 {
struct weston_config *config = data;
-- 
Cheers,
  Eric
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v2 1/2] config-parser: add support for more color formats

2016-10-26 Thread Eric Engestrom 
Supported colour formats are:
- (0x)(AA)RRGGBB
- #RGB(A)
- #RRGGBB(AA)

Cc: Bryce Harrington 
Cc: Quentin Glidic 
Signed-off-by: Eric Engestrom 
---
v2: reduce the number of formats supported
read #-prefixed values the same way CSS would
---
 shared/config-parser.c | 54 ++
 1 file changed, 46 insertions(+), 8 deletions(-)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index e2b5fa2..b3848a2 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -215,6 +215,12 @@ weston_config_section_get_uint(struct 
weston_config_section *section,
return 0;
 }
 
+/*
+ * Supported colour formats:
+ * - (0x)(AA)RRGGBB
+ * - #RGB(A)
+ * - #RRGGBB(AA)
+ */
 WL_EXPORT
 int
 weston_config_section_get_color(struct weston_config_section *section,
@@ -224,6 +230,10 @@ weston_config_section_get_color(struct 
weston_config_section *section,
struct weston_config_entry *entry;
int len;
char *end;
+   const char alpha[] = "FF"; /* Default alpha when unspecified */
+   const char *val;
+   const char *color_string;
+   enum { hex, css } colour_type;
 
entry = config_section_get_entry(section, key);
if (entry == NULL) {
@@ -232,19 +242,47 @@ weston_config_section_get_color(struct 
weston_config_section *section,
return -1;
}
 
+   val = entry->value;
+   len = strlen(val);
-   len = strlen(entry->value);
+
-   if (len == 1 && entry->value[0] == '0') {
+   if (len == 1 && val[0] == '0') {
*color = 0;
return 0;
-   } else if (len != 8 && len != 10) {
-   *color = default_color;
-   errno = EINVAL;
-   return -1;
}
 
+   if (len > 2 && val[0] == '0' && val[1] == 'x') {
+   val += 2;
+   len -= 2;
+   colour_type = hex;
+   }
+   else if (len > 1 && val[0] == '#') {
+   val += 1;
+   len -= 1;
+   colour_type = css;
+   }
+   else
+   colour_type = hex;
+
+   if (colour_type == hex)
+   switch (len) {
+   case 8: color_string = (char[]){   val[0],   val[1], val[2], 
val[3], val[4], val[5], val[6], val[7], '\0' }; break; /* (0x)AARRGGBB */
+   case 6: color_string = (char[]){ alpha[0], alpha[1], val[0], 
val[1], val[2], val[3], val[4], val[5], '\0' }; break; /*   (0x)RRGGBB */
+   default: goto invalid;
+   }
+
+   if (colour_type == css)
+   switch (len) {
+   case 8: color_string = (char[]){   val[6],   val[7], val[0], 
val[1], val[2], val[3], val[4], val[5], '\0' }; break; /* #RRGGBBAA */
+   case 6: color_string = (char[]){ alpha[0], alpha[1], val[0], 
val[1], val[2], val[3], val[4], val[5], '\0' }; break; /* #RRGGBB   */
+   case 4: color_string = (char[]){   val[3],   val[3], val[0], 
val[0], val[1], val[1], val[2], val[2], '\0' }; break; /* # R G B A */
+   case 3: color_string = (char[]){ alpha[0], alpha[1], val[0], 
val[0], val[1], val[1], val[2], val[2], '\0' }; break; /* # R G B   */
+   default: goto invalid;
+   }
+
errno = 0;
-   *color = strtoul(entry->value, , 16);
+   *color = strtoul(color_string, , 16);
-   if (errno != 0 || end == entry->value || *end != '\0') {
+   if (errno != 0 || end == color_string || *end != '\0') {
+invalid:
*color = default_color;
errno = EINVAL;
return -1;
-- 
Cheers,
  Eric
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Kinetic scroll in libinput Xorg driver

2016-10-26 Thread Christian Stroetmann 

On 26.10.2016 08:57, Alexis BRENON @Wayland wrote:

@Raster: Thank you for your reminder.

Maybe Enlightenment with Tiling2 and kinetic scrolling is already what 
you need.


If I remember correctly I3 (www.i3wm.org) might work 
together with Wayland as well.


In general, I have seen at all major toolkits transistion efforts to 
Wayland since around 2 years. Some have matured while others are 
experimental so to say.




Best Regards
Christian Stroetmann

Just to be sure that I understand clearly, what you call 'Toolkit' is 
libraries like GTK, Qt, and co. that are used by developers to build 
their apps, isn't it ?


Finally, do you know some tiling DE/WM Wayland compliant ?

Kind,
Alexis.

Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler > a écrit :


On Mon, 24 Oct 2016 18:42:31 + "Alexis BRENON @Wayland"
mailto:wayl...@gmail.com>> said:

> Hello everyone,
>
> I would like to implement kinetic scroll in the libinput driver
for Xorg.
>
> I know that it's probably not the intended use of libinput ; as
explained
> in the documentation, it's the client that have to manage that.
>
> However, as an Xorg user not happy with the synaptics driver, I
would like
> to add a similar feature (fixing small disagreements encountered
with
> synaptics) to libinput, allowing Xorg users to easily move to
libinput
> without losing this feature.
>
> My first idea is to implement the kinetic scroll using a thread
that sends
> axis events as long as there is no button event, key event or
motion event
> higher than a threshold.
>
> It makes some time since the last time I developed in C, and
maybe it's not
> the better way to do it. I would be happy to hear your advices.
>
> One thing I'm thinking of is then to add some options in the Xorg
> configuration file to enable/disable this feature, choose the events
> stopping the kinetic scroll and change some thresholds. This
will allow to
> easily disable this feature in the future in case the clients
manage the
> kinetic scroll on their own.
>
> What do you think of this? Is there someone already working on
it? Is my
> proposition a good way to implement it?
>
> Thanks for your attention.
>
> Kind regards,
> Alexis BRENON.

we already do kinetic scrolling higher up in the toolkit. we do
acceleration
using these events and we do smooth animated scrolling in our
scroller and not
just stepping, as well as momentum as we slid with bouncing at the
ends. it's
already done in toolkit out of the box. if you try and hack this
in at the
input layer this simply doubles the amount of this and likely
makes the user
experience worse. this would have to be off by default and if it's
off by
default... you need ways of turning it on client by client ... and
even then
there are a pile of other problems you'll hit. so my suggestion is
- don't. add
to your favorite toolkits instead if they don't have it. they have
far more
information about the context at the time and the use cases needed
etc.



--
- Codito, ergo sum - "I code, therefore I am"
--
The Rasterman (Carsten Haitzler) ras...@rasterman.com




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Kinetic scroll in libinput Xorg driver

2016-10-26 Thread Alexis BRENON @Wayland 
Just to be sure that I understand clearly, what you call 'Toolkit' is
libraries like GTK, Qt, and co. that are used by developers to build their
apps, isn't it ?

Finally, do you know some tiling DE/WM Wayland compliant ?

Kind,
Alexis.

Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler  a
écrit :

> On Mon, 24 Oct 2016 18:42:31 + "Alexis BRENON @Wayland"  +wayl...@gmail.com> said:
>
> > Hello everyone,
> >
> > I would like to implement kinetic scroll in the libinput driver for Xorg.
> >
> > I know that it's probably not the intended use of libinput ; as explained
> > in the documentation, it's the client that have to manage that.
> >
> > However, as an Xorg user not happy with the synaptics driver, I would
> like
> > to add a similar feature (fixing small disagreements encountered with
> > synaptics) to libinput, allowing Xorg users to easily move to libinput
> > without losing this feature.
> >
> > My first idea is to implement the kinetic scroll using a thread that
> sends
> > axis events as long as there is no button event, key event or motion
> event
> > higher than a threshold.
> >
> > It makes some time since the last time I developed in C, and maybe it's
> not
> > the better way to do it. I would be happy to hear your advices.
> >
> > One thing I'm thinking of is then to add some options in the Xorg
> > configuration file to enable/disable this feature, choose the events
> > stopping the kinetic scroll and change some thresholds. This will allow
> to
> > easily disable this feature in the future in case the clients manage the
> > kinetic scroll on their own.
> >
> > What do you think of this? Is there someone already working on it? Is my
> > proposition a good way to implement it?
> >
> > Thanks for your attention.
> >
> > Kind regards,
> > Alexis BRENON.
>
> we already do kinetic scrolling higher up in the toolkit. we do
> acceleration
> using these events and we do smooth animated scrolling in our scroller and
> not
> just stepping, as well as momentum as we slid with bouncing at the ends.
> it's
> already done in toolkit out of the box. if you try and hack this in at the
> input layer this simply doubles the amount of this and likely makes the
> user
> experience worse. this would have to be off by default and if it's off by
> default... you need ways of turning it on client by client ... and even
> then
> there are a pile of other problems you'll hit. so my suggestion is -
> don't. add
> to your favorite toolkits instead if they don't have it. they have far more
> information about the context at the time and the use cases needed etc.
>
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel