Re: [PATCH] protocol: Add DnD actions

[Jonas Ådahl]

On Sat, Apr 18, 2015 at 04:53:46PM +0200, Carlos Garnacho wrote:
 Hey Jonas,

Hi,

Thanks for the explanations. I'll reply inline.

 
 On vie, 2015-04-17 at 15:50 +0800, Jonas Ådahl wrote:
 
 snip
  
   For the touch case, depending on how the grab is implemented, with 
   the
   current guidelines the only 2 choices are leave the client in
   inconsistent state or make the client still receives ongoing 
   touches
   despite the pointer grab (same applies if the grab is touch
   triggered, only with the other touches that didn't trigger the 
   grab).
   
   More on topic, keyboards are also funky if we keep focus on 
   clients,
   you can conceivably Esc/Ctrl-Q/... to close the app you're dragging
   from. IMO the way forward is precisely this, the compositor 
   becomes in
   control of the keyboard, and we offer the missing semantics to 
   cover
   for this.
  
  Meaning its the compositor that decides whether a drag is a copy or a
  move? I.e. either we hard code Ctrl to be copy in the protocol, or 
  DND
  will behave different on each compositor. Not sure I like any of 
  those
  options.
 
 Yes, this would be implementation-dependent in the compositor as my 
 proposal goes. We have 3 players here, whoever gets to handle the 
 modifier-action translation, there's room for confusion in cross-
 DE/toolkit cases.

The problem as I see it is that it'd be even confusing for DND within
the same application as it would be depending on the DE how it'd work.

 
 Focusing on actions, I see the following possible data flows here 
 (depicting the same situation on all: initial negotiation, changes on 
 the dest on say pointer motion, and a modifier change):
 
 1. If handled purely by the source:
 
 wl_data_source  compositorwl_data_offer
 ==  ===
  - notify_actions -
 dest_actions -
  - preferred_action
 action   -- action
 
 ...
   (pointer moves across widgets)
 notify_actions -
 dest_actions -
  - preferred_action
 action   -- action
 
 ...
 (modifiers change)
 modifiers-
  - preferred_action
 action   -- action
 
 
 2. If handled purely by the dest:
 
 wl_data_source  compositorwl_data_offer
 ==  ===
  - notify_actions
- source_actions
 notify_actions -
 preferred_action   -
 action   -- action
 
 ...
   (pointer moves across widgets)
 notify_actions -
 preferred_action   -
 action   -- action
 
 ...
 (modifiers change)
- modifiers
 preferred_action   -
 action   -- action
 
 
 3. If handled purely by the compositor:
 
 wl_data_source  compositorwl_data_offer
 ==  ===
  - notify_actions -
 action   -- action
 
 ...
   (pointer moves across widgets)
 notify_actions -
 action   -- action
 
 ...
 (modifiers change)
 action   -- action
 
 
 Options #1 and #2 involve roundtrips, option #3 doesn't. Options #1 
 and #2 would still need some validation on the compositor to avoid 
 picking options unknown to either side.

I think its wrong to refer to these as roundtrips. A roundtrip is
typically a client that need to wait for a reply from a server, but here
in any of the three options no one is waiting for anything, thus we have
no round trips at all. The main differences as I see it are:

In option 1 and 2 we pass an additional modifier state, and make either
side be responsible for choosing. In option 3 we move this and make it
compositor choose (either with hard coded policy in the protocol or some
arbitrary policy given some private state inside the compositor).

In option 1 and 2, we have a slightly longer delay in visual feedback
regarding the action (caused by the outsourcing of the decision making).
I'd say these delays are in most cases insignificantly small. In any
solution we end up with latency as we are dealing with 3 entities
communicating asynchronously. Note that option 3 has this delay as well,
but for chosen mime type visual feedback.

In option 2, actions would be handled identical to mime 

Re: Daily builds of wayland+weston (Ubuntu)

[Pekka Paalanen]

On Mon, 20 Apr 2015 17:46:59 -0700
Bryce Harrington br...@osg.samsung.com wrote:

 I've set up automatic builds of git snapshots of wayland, libinput, and
 weston via Canonical's recipe PPA system:
 
   https://launchpad.net/~wayland.admin/+archive/ubuntu/daily-builds
 
 Builds are done once a day, if there are upstream changes since the last
 build (so we've been getting about 1-2 builds per week typically.)  If
 there are build breakages, it emails a mailing list,
 wayland.ad...@lists.launchpad.net.
 
 Bryce
 
 P.S. I've also set up a similar build for cairo and pixman, which is
 accessible at the following url.  This one uses similar configuration
 and packaging as the stock Ubuntu package (i.e. no GL enabled):
 
   https://code.launchpad.net/~cairo.admin/+archive/ubuntu/cairo-daily/

Very cool!

How do I subscribe for Wayland, Weston, and Pixman build failures?

Are there any patches added in addition to what the upstream master
branch is?

What architectures do the builds cover?


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] Add enum attribute to arg elements

[Pekka Paalanen]

On Mon, 20 Apr 2015 15:54:59 +
Jeroen Bollen jbin...@gmail.com wrote:

 On Mon, 20 Apr 2015 at 09:03 Pekka Paalanen ppaala...@gmail.com wrote:
 
  Also, adding the strict type information to the XML spec has no benefit
  for C, which is the de facto language for Wayland core developers. A C
  compiler also does not raise errors if you violate the rules. This and
  all the above are the likely reasons why adding the strict type
  information is not interesting, at least for me.
 
  Making the enum rules more strict has a possibility to break existing
  users, but to me it is unclear if the benefit would outweigh that
  con or the freedom.
 
  On the wire, an enum or bitfield is still just an uint (or int), and a
  buggy client or server may cause the other to receive illegal values.
  Do the strongly typed languages have checks against that? Can you
  define what happens if the value is illegal for an enum? Or do you have
  to write that check manually in any case?
 
  So, the big question here is: do we even want to have strict enum types?
 
 
 It does indeed not provide any benefit for C, but if C is the only language
 to be targeted, there is not much use in there being an XML specification
 at all. It could've just been written out in C. I do agree that any changes
 should be compatible with C.
 
 I know in Rust, conversion from the `uint` to the `enum` type would have to
 be done manually, and error checking happens here. It does stop the user
 from passing illegal values to other servers however. It also makes it more
 clear what `enum`s are to be used with which arguments, and enforces this.
 
 I don't really see why adding that to the specification is an issue. If
 some `enum` types aren't complete, as in, they aren't the only valid
 values, then I see little value in having the `enum` in the specification
 in the first place.

The foremost purpose of the enum is to let the generator create named
constants in a namespace. This is something that has to stay due to
API stability guarantees.

I had some discussion in IRC, and I'm coming around. It does seem a
useful addition, but you have to be clear in specifying what it all
means. For instance, saying an attribute referencing an enum in an
arg for purely documentation linkage would be fine. We don't have
docs for the XML language, but at least define it in a commit message.

If such annotation is intended to be useful for code generation on
relevant languages, you need to define clearly what it means. I'm not
familiar with those languages you are interested in, so I cannot judge
that.

What I would want, is patches to wayland-scanner to use these
additional annotations, if only for syntax checking the XML and maybe
generating one more comment for an arg or whatever. Unfortunately
wayland-scanner still is the definition of the Wayland XML language.
It should be kept updated in any case.

Two things I came up with in the IRC discussion was that only arg
types of int an uint are eligible for enums, and only uint for
bitfields. I think wayland-scanner should enforce that.

One question was about whether bitfield values should be limited to
single bits (powers of two). I think that would be an artificial
restriction, and it would not allow using short-hand names for sets of
bits. I see no reason to deny those.

Another is the question about incomplete enumerations. I don't think we
can deny their existence. Therefore they must be supported. If that
means you cannot put the enum attribute in such an arg, then so be
it; but you lose also the doc linkage. Extending value or bit
enumerations is something that happens, and with the expectation that
it doesn't break anything. An interface that expects to see new entries
in an enumeration in the future will specify how unknown values should
be dealt with. You maybe have your code generated according to an old
specification, while the other party is using a new specification, and
you need to obey the interface specification regarding unknown values.
This has to work.

Btw. the wayland.dtd is abandoned. The rationale was that if it catches
errors that wayland-scanner doesn't, then wayland-scanner should be
fixed. We should probably remove that file, and preferably replace it
with documentation that agrees with wayland-scanner. If only had the
time...


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 1/5] tools: add --set-scroll-method commandline flag

[Hans de Goede]

Hi,

Series looks good and is:

Reviewed-by: Hans de Goede hdego...@redhat.com

Regards,

Hans


On 21-04-15 07:28, Peter Hutterer wrote:

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
  tools/shared.c | 29 +
  tools/shared.h |  1 +
  2 files changed, 30 insertions(+)

diff --git a/tools/shared.c b/tools/shared.c
index d8d23a7..e4d2804 100644
--- a/tools/shared.c
+++ b/tools/shared.c
@@ -46,6 +46,7 @@ enum options {
OPT_MIDDLEBUTTON_ENABLE,
OPT_MIDDLEBUTTON_DISABLE,
OPT_CLICK_METHOD,
+   OPT_SCROLL_METHOD,
OPT_SPEED,
  };

@@ -76,6 +77,7 @@ tools_usage()
   --enable-middlebutton\n
   --disable-middlebutton enable/disable middle button 
emulation\n
   --set-click-method=[none|clickfinger|buttonareas]  set the 
desired click method\n
+  --set-scroll-method=[none|twofinger|edge|button] ... set the desired 
scroll method\n
   --set-speed=value set pointer acceleration speed\n
   \n
   These options apply to all applicable devices, if a feature\n
@@ -96,6 +98,7 @@ tools_init_options(struct tools_options *options)
options-left_handed = -1;
options-middlebutton = -1;
options-click_method = -1;
+   options-scroll_method = -1;
options-backend = BACKEND_UDEV;
options-seat = seat0;
options-speed = 0.0;
@@ -121,6 +124,7 @@ tools_parse_args(int argc, char **argv, struct 
tools_options *options)
{ enable-middlebutton, 0, 0, OPT_MIDDLEBUTTON_ENABLE 
},
{ disable-middlebutton, 0, 0, 
OPT_MIDDLEBUTTON_DISABLE },
{ set-click-method, 1, 0, OPT_CLICK_METHOD },
+   { set-scroll-method, 1, 0, OPT_SCROLL_METHOD },
{ speed, 1, 0, OPT_SPEED },
{ 0, 0, 0, 0}
};
@@ -193,6 +197,27 @@ tools_parse_args(int argc, char **argv, struct 
tools_options *options)
return 1;
}
break;
+   case OPT_SCROLL_METHOD:
+   if (!optarg) {
+   tools_usage();
+   return 1;
+   }
+   if (strcmp(optarg, none) == 0) {
+   options-scroll_method =
+   
LIBINPUT_CONFIG_SCROLL_NO_SCROLL;
+   } else if (strcmp(optarg, twofinger) == 0) {
+   options-scroll_method =
+   LIBINPUT_CONFIG_SCROLL_2FG;
+   } else if (strcmp(optarg, edge) == 0) {
+   options-scroll_method =
+   LIBINPUT_CONFIG_SCROLL_EDGE;
+   } else if (strcmp(optarg, button) == 0) {
+   options-scroll_method =
+   
LIBINPUT_CONFIG_SCROLL_ON_BUTTON_DOWN;
+   } else {
+   tools_usage();
+   return 1;
+   }
case OPT_SPEED:
if (!optarg) {
tools_usage();
@@ -317,6 +342,10 @@ tools_device_apply_config(struct libinput_device *device,
if (options-click_method != -1)
libinput_device_config_click_set_method(device, 
options-click_method);

+   if (options-scroll_method != -1)
+   libinput_device_config_scroll_set_method(device,
+
options-scroll_method);
+
if (libinput_device_config_accel_is_available(device))
libinput_device_config_accel_set_speed(device,
   options-speed);
diff --git a/tools/shared.h b/tools/shared.h
index 01edffc..7b03788 100644
--- a/tools/shared.h
+++ b/tools/shared.h
@@ -41,6 +41,7 @@ struct tools_options {
int left_handed;
int middlebutton;
enum libinput_config_click_method click_method;
+   enum libinput_config_scroll_method scroll_method;
double speed;
  };



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

Weird dispatch ordering of display events

[Alexander Larsson]

I just spent some time debugging the wrong thing due to a weird change
in wayland 1.5. A new queue was introduced for the display itself,
handling things like delete_id. This queue is always dispatched,
independent of what other queues are dispatched.

However, it is always dispatched *before* the regular queue. This can
look pretty weird in the client side WAYLAND_DEBUG output, because if
you do an operation like bind()+display_roundtrip, you will see the
delete_id for the roundtrip callback before you see any results from the
bind.

This doesn't seem to be a problem in practice, because we resolve the
ids at event queue time, not dispatch time, so the events dispatch to
the right place anyway, but it is very confusing when debugging.

Maybe we can move the dispatching of the display queue to after
dispatching the regular queue in wayland-client.c:dispatch_queue(), to
make this a bit less confusing?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a Nobel prize-winning neurotic dwarf with a winning smile and a way 
with the ladies. She's a radical insomniac bounty hunter who inherited a 
spooky stately manor from her late maiden aunt. They fight crime! 

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

Re: Weird dispatch ordering of display events

[Alexander Larsson]

On tis, 2015-04-21 at 14:23 +0300, Pekka Paalanen wrote:
 On Tue, 21 Apr 2015 11:17:17 +0200
 Alexander Larsson al...@redhat.com wrote:
 
  I just spent some time debugging the wrong thing due to a weird change
  in wayland 1.5. A new queue was introduced for the display itself,
  handling things like delete_id. This queue is always dispatched,
  independent of what other queues are dispatched.
  
  However, it is always dispatched *before* the regular queue. This can
  look pretty weird in the client side WAYLAND_DEBUG output, because if
  you do an operation like bind()+display_roundtrip, you will see the
  delete_id for the roundtrip callback before you see any results from the
  bind.
  
  This doesn't seem to be a problem in practice, because we resolve the
  ids at event queue time, not dispatch time, so the events dispatch to
  the right place anyway, but it is very confusing when debugging.
  
  Maybe we can move the dispatching of the display queue to after
  dispatching the regular queue in wayland-client.c:dispatch_queue(), to
  make this a bit less confusing?
 
 Hi,
 
 but that would only solve it for the default queue, right? If you had
 another user wl_event_queue, then looking at those events would still
 be confusing.

True. And it would still reorder the events, just move delete_id later
rather than earlier.

 I can't say off-hand whether that change would be ok. Instead, I'd like
 to suggest other forms of protocol dumping (see to the end):
 http://wayland.freedesktop.org/extras.html

Yeah, i'll use these from now on instead. Thanks.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a short-sighted umbrella-wielding vagrant plagued by the memory of 
his family's brutal murder. She's a scantily clad antique-collecting 
archaeologist who believes she is the reincarnation of an ancient 
Egyptian queen. They fight crime! 

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

[PATCH libinput 1.5/5] tools: add --set-scroll-button as option

[Peter Hutterer]

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Sorry, should've been part of 1/5, I only just noticed that enabling
button scrolling isn't overly useful without setting the button too.

 tools/Makefile.am |  2 ++
 tools/shared.c| 24 
 tools/shared.h|  1 +
 3 files changed, 27 insertions(+)

diff --git a/tools/Makefile.am b/tools/Makefile.am
index b8cc218..707e952 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -9,6 +9,8 @@ AM_CPPFLAGS = -I$(top_srcdir)/include \
 libshared_la_SOURCES = \
   shared.c \
   shared.h
+libshared_la_CFLAGS = $(LIBEVDEV_CFLAGS)
+libshared_la_LIBADD = $(LIBEVDEV_LIBS)
 
 event_debug_SOURCES = event-debug.c
 event_debug_LDADD = ../src/libinput.la libshared.la $(LIBUDEV_LIBS)
diff --git a/tools/shared.c b/tools/shared.c
index 15ba8bc..9ccd5dd 100644
--- a/tools/shared.c
+++ b/tools/shared.c
@@ -30,6 +30,8 @@
 #include string.h
 #include libudev.h
 
+#include libevdev/libevdev.h
+
 #include shared.h
 
 enum options {
@@ -47,6 +49,7 @@ enum options {
OPT_MIDDLEBUTTON_DISABLE,
OPT_CLICK_METHOD,
OPT_SCROLL_METHOD,
+   OPT_SCROLL_BUTTON,
OPT_SPEED,
 };
 
@@ -78,6 +81,7 @@ tools_usage()
   --disable-middlebutton enable/disable middle button 
emulation\n
   --set-click-method=[none|clickfinger|buttonareas]  set the 
desired click method\n
   --set-scroll-method=[none|twofinger|edge|button] ... set the 
desired scroll method\n
+  --set-scroll-button=BTN_MIDDLE ... set the button to the given 
button code\n
   --set-speed=value set pointer acceleration speed\n
   \n
   These options apply to all applicable devices, if a feature\n
@@ -99,6 +103,7 @@ tools_init_options(struct tools_options *options)
options-middlebutton = -1;
options-click_method = -1;
options-scroll_method = -1;
+   options-scroll_button = -1;
options-backend = BACKEND_UDEV;
options-seat = seat0;
options-speed = 0.0;
@@ -125,6 +130,7 @@ tools_parse_args(int argc, char **argv, struct 
tools_options *options)
{ disable-middlebutton, 0, 0, 
OPT_MIDDLEBUTTON_DISABLE },
{ set-click-method, 1, 0, OPT_CLICK_METHOD },
{ set-scroll-method, 1, 0, OPT_SCROLL_METHOD },
+   { set-scroll-button, 1, 0, OPT_SCROLL_BUTTON },
{ speed, 1, 0, OPT_SPEED },
{ 0, 0, 0, 0}
};
@@ -219,6 +225,21 @@ tools_parse_args(int argc, char **argv, struct 
tools_options *options)
return 1;
}
break;
+   case OPT_SCROLL_BUTTON:
+   if (!optarg) {
+   tools_usage();
+   return 1;
+   }
+   options-scroll_button =
+   libevdev_event_code_from_name(EV_KEY,
+ optarg);
+   if (options-scroll_button == -1) {
+   fprintf(stderr,
+   Invalid button %s\n,
+   optarg);
+   return 1;
+   }
+   break;
case OPT_SPEED:
if (!optarg) {
tools_usage();
@@ -346,6 +367,9 @@ tools_device_apply_config(struct libinput_device *device,
if (options-scroll_method != -1)
libinput_device_config_scroll_set_method(device,
 
options-scroll_method);
+   if (options-scroll_button != -1)
+   libinput_device_config_scroll_set_button(device,
+
options-scroll_button);
 
if (libinput_device_config_accel_is_available(device))
libinput_device_config_accel_set_speed(device,
diff --git a/tools/shared.h b/tools/shared.h
index 7b03788..a1aec46 100644
--- a/tools/shared.h
+++ b/tools/shared.h
@@ -42,6 +42,7 @@ struct tools_options {
int middlebutton;
enum libinput_config_click_method click_method;
enum libinput_config_scroll_method scroll_method;
+   int scroll_button;
double speed;
 };
 
-- 
2.3.5

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

Re: Daily builds of wayland+weston (Ubuntu)

[Bryce Harrington]

On Tue, Apr 21, 2015 at 10:27:24AM +0300, Pekka Paalanen wrote:
 On Mon, 20 Apr 2015 17:46:59 -0700
 Bryce Harrington br...@osg.samsung.com wrote:
 
  I've set up automatic builds of git snapshots of wayland, libinput, and
  weston via Canonical's recipe PPA system:
  
https://launchpad.net/~wayland.admin/+archive/ubuntu/daily-builds
  
  Builds are done once a day, if there are upstream changes since the last
  build (so we've been getting about 1-2 builds per week typically.)  If
  there are build breakages, it emails a mailing list,
  wayland.ad...@lists.launchpad.net.
  
  Bryce
  
  P.S. I've also set up a similar build for cairo and pixman, which is
  accessible at the following url.  This one uses similar configuration
  and packaging as the stock Ubuntu package (i.e. no GL enabled):
  
https://code.launchpad.net/~cairo.admin/+archive/ubuntu/cairo-daily/
 
 Very cool!
 
 How do I subscribe for Wayland, Weston, and Pixman build failures?

For the first two, join the wayland.admin team and then subscribe via
the team page:

  https://launchpad.net/~wayland.admin

For pixman, join the cairo.admin team:

  https://launchpad.net/~cairo.admin

 Are there any patches added in addition to what the upstream master
 branch is?

Ubuntu doesn't carry any patches for wayland or weston.  For pixman
there's one patch which increases the testsuite timeout from 5 to 50
seconds; seemed innocuous so I left it.

For cairo, I kept all the patches except for two already upstream.  Four
of the five patches are really there to fix packaging deficiencies.
The fifth patch turns off server-side gradients; I should probably drop
it too.
 
 What architectures do the builds cover?

Just AMD64 and i386 right now.

I can try requesting doing ARM builds as well, if that would be of
interest.  (https://dev.launchpad.net/CommunityARMBuilds)

Bryce

 Thanks,
 pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 1.5/5] tools: add --set-scroll-button as option

[Hans de Goede]

Hi,

On 21-04-15 10:30, Peter Hutterer wrote:

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Sorry, should've been part of 1/5, I only just noticed that enabling
button scrolling isn't overly useful without setting the button too.


Looks good: Reviewed-by: Hans de Goede hdego...@redhat.com

Regards,

Hans



  tools/Makefile.am |  2 ++
  tools/shared.c| 24 
  tools/shared.h|  1 +
  3 files changed, 27 insertions(+)

diff --git a/tools/Makefile.am b/tools/Makefile.am
index b8cc218..707e952 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -9,6 +9,8 @@ AM_CPPFLAGS = -I$(top_srcdir)/include \
  libshared_la_SOURCES = \
   shared.c \
   shared.h
+libshared_la_CFLAGS = $(LIBEVDEV_CFLAGS)
+libshared_la_LIBADD = $(LIBEVDEV_LIBS)

  event_debug_SOURCES = event-debug.c
  event_debug_LDADD = ../src/libinput.la libshared.la $(LIBUDEV_LIBS)
diff --git a/tools/shared.c b/tools/shared.c
index 15ba8bc..9ccd5dd 100644
--- a/tools/shared.c
+++ b/tools/shared.c
@@ -30,6 +30,8 @@
  #include string.h
  #include libudev.h

+#include libevdev/libevdev.h
+
  #include shared.h

  enum options {
@@ -47,6 +49,7 @@ enum options {
OPT_MIDDLEBUTTON_DISABLE,
OPT_CLICK_METHOD,
OPT_SCROLL_METHOD,
+   OPT_SCROLL_BUTTON,
OPT_SPEED,
  };

@@ -78,6 +81,7 @@ tools_usage()
   --disable-middlebutton enable/disable middle button 
emulation\n
   --set-click-method=[none|clickfinger|buttonareas]  set the 
desired click method\n
   --set-scroll-method=[none|twofinger|edge|button] ... set the desired 
scroll method\n
+  --set-scroll-button=BTN_MIDDLE ... set the button to the given 
button code\n
   --set-speed=value set pointer acceleration speed\n
   \n
   These options apply to all applicable devices, if a feature\n
@@ -99,6 +103,7 @@ tools_init_options(struct tools_options *options)
options-middlebutton = -1;
options-click_method = -1;
options-scroll_method = -1;
+   options-scroll_button = -1;
options-backend = BACKEND_UDEV;
options-seat = seat0;
options-speed = 0.0;
@@ -125,6 +130,7 @@ tools_parse_args(int argc, char **argv, struct 
tools_options *options)
{ disable-middlebutton, 0, 0, 
OPT_MIDDLEBUTTON_DISABLE },
{ set-click-method, 1, 0, OPT_CLICK_METHOD },
{ set-scroll-method, 1, 0, OPT_SCROLL_METHOD },
+   { set-scroll-button, 1, 0, OPT_SCROLL_BUTTON },
{ speed, 1, 0, OPT_SPEED },
{ 0, 0, 0, 0}
};
@@ -219,6 +225,21 @@ tools_parse_args(int argc, char **argv, struct 
tools_options *options)
return 1;
}
break;
+   case OPT_SCROLL_BUTTON:
+   if (!optarg) {
+   tools_usage();
+   return 1;
+   }
+   options-scroll_button =
+   libevdev_event_code_from_name(EV_KEY,
+ optarg);
+   if (options-scroll_button == -1) {
+   fprintf(stderr,
+   Invalid button %s\n,
+   optarg);
+   return 1;
+   }
+   break;
case OPT_SPEED:
if (!optarg) {
tools_usage();
@@ -346,6 +367,9 @@ tools_device_apply_config(struct libinput_device *device,
if (options-scroll_method != -1)
libinput_device_config_scroll_set_method(device,
 
options-scroll_method);
+   if (options-scroll_button != -1)
+   libinput_device_config_scroll_set_button(device,
+
options-scroll_button);

if (libinput_device_config_accel_is_available(device))
libinput_device_config_accel_set_speed(device,
diff --git a/tools/shared.h b/tools/shared.h
index 7b03788..a1aec46 100644
--- a/tools/shared.h
+++ b/tools/shared.h
@@ -42,6 +42,7 @@ struct tools_options {
int middlebutton;
enum libinput_config_click_method click_method;
enum libinput_config_scroll_method scroll_method;
+   int scroll_button;
double speed;
  };



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

Re: Wayland Relative Pointer API Progress

[x414e54]

On Wed, Apr 22, 2015 at 10:05 AM, Bill Spitzak spit...@gmail.com wrote:
 If a client opens a device, will that interfere with wayland's reading of
 the device? For instance if the client opens the mouse, will wayland still
 get the mouse position such that it can revoke access when the cursor moves
 out of the window?

Multiple read access to the same device should work fine.

I think it is the writing that is the main issue. If the hardware has
a setting that either the compositor is not aware of (so cannot reset)
and could confuse the compositor's handling of the device in some way.

But this applies to all devices even on non Wayland systems so
probably should be done at a separate level.

I guess you could advise that all drivers support context switching,
where the entire device state is stored in the context which the
compositor can just switch to/from without caring what it is actually
changing. Then it is just up to the driver vendor or evdev to make
their implementation secure.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 5/6] compositor-drm: Fix refresh rate selection in drm_output_switch_mode

[Mario Kleiner]

On 04/16/2015 07:14 PM, Derek Foreman wrote:

On 02/04/15 12:10 AM, Mario Kleiner wrote:

The matching logic in choose_mode() compared refresh rate
of a drm_mode candidate mode expressed in Hz against the
requested refresh rate of the target weston_mode expressed
in milliHz, so the match always failed and the logic always
ended up the mode with the highest refresh rate for a given
resolution, instead of the one matching the requested rate.

Match proper fields to fix this.

Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
---
  src/compositor-drm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 9ddb6d6..396938f 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1270,7 +1270,7 @@ choose_mode (struct drm_output *output, struct 
weston_mode *target_mode)
wl_list_for_each(mode, output-base.mode_list, base.link) {
if (mode-mode_info.hdisplay == target_mode-width 
mode-mode_info.vdisplay == target_mode-height) {
-   if (mode-mode_info.vrefresh == target_mode-refresh ||
+   if (mode-base.refresh == target_mode-refresh ||


Definitely wrong in the current form, but I'm mildly concerned that the
math used to calculate mode-base.refresh is not just 1000 *
mode_info.vdisplay.

For my monitor, 1280x1024 with vrefresh = 60 has a refresh = 60020
1440x900@60 - 59901

Should we be trying to do a nearest match instead of an exact match?



This specific patch is a bug-fix for the current wrong behaviour.

If we want the nearest match behaviour i'd probably write a separate 
patch with the find mode with identical resolution but nearest refresh 
rate on top of this one?


The way my app uses it is it enumerates all video modes from the 
wl_output listener, selects the best matching mode for its purpose, then 
passes in the exact parameters from that mode, because what it needs is 
exact mode selection. But a nearest match wrt. refresh rate would make 
sense and not prevent that use.


thanks,
-mario
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 4/6] compositor-drm/shell: Allow restore_output_mode() to work properly.

[Mario Kleiner]

On 04/16/2015 06:43 PM, Derek Foreman wrote:

On 02/04/15 12:10 AM, Mario Kleiner wrote:

Initialize output-native_mode with the initially chosen
mode for an output, so restore_output_mode() has something
to work with and can switch back from temporary selected modes
to the outputs native mode. Before, this was a no-op.

This allows an output to switch back to its default mode if
a former toplevel fullscreen shell surface created via method
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER gets destroyed, or
demoted to non-fullscreen, or if modesetting on the output
failed.

Also fix desktop-shell's activate method to only restore
output mode on the output on which a shell surface gets
activated. This way fullscreen windows can mode switch their
output, but window switching and exposay still works in the
expected way.

Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
---
  desktop-shell/shell.c | 3 ++-
  src/compositor-drm.c  | 4 
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 7d0e403..68846ed 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2962,6 +2962,7 @@ shell_configure_fullscreen(struct shell_surface *shsurf)
 output-y - surf_y);
break;
} else {
+   weston_log(shell: Can't switch to temporary 
mode.\n);
restore_output_mode(output);
center_on_output(shsurf-view, output);
}
@@ -5089,7 +5090,7 @@ activate(struct desktop_shell *shell, struct 
weston_surface *es,
if (shsurf-state.fullscreen  configure)
shell_configure_fullscreen(shsurf);
else
-   restore_all_output_modes(shell-compositor);
+   restore_output_mode(shsurf-output);

/* Update the surface’s layer. This brings it to the top of the stacking
 * order as appropriate. */


I think above and below this point should be two separate patches.


Yes, makes sense. I'll split it into separate patches.




diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 4a7baa1..9ddb6d6 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2209,6 +2209,10 @@ create_output_for_connector(struct drm_compositor *ec,
connector-count_modes == 0 ?
, built-in : );

+   /* Initialize output-native_mode field, so restore_output_mode() 
works. */
+   weston_output_mode_set_native(output-base, output-base.current_mode,
+ 
output-base.current_scale);
+
return 0;

  err_output:



I'm not sure this is right - I think just setting
output-base.native_mode = output-base.current_mode would have the same
end result without triggering all the mode switch related machinery?



Yes, it would do the same thing. weston_output_mode_set_native() is a 
no-op apart from that native_mode assignment if current_mode gets set. I 
can change it into that simple assignment if that appears more clean.


thanks,
-mario
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland Relative Pointer API Progress

[Peter Hutterer]

On Sun, Apr 19, 2015 at 12:45:09PM +0100, Steven Newbury wrote:
 On Sun, 2015-04-19 at 15:29 +0900, x414e54 wrote:
  
  
  The way todo this seems to be for the compositor and client to 
  negotiate an event type they both can understand such as
  libinput_event or hid events and then a way to request a revokable 
  fd to the evdev directly so it can control LEDS and force feedback 
  etc. This allows for applications and compositors to grow separately 
  of the wayland protocol so it does not need updating every time 
  someone invents some new mouse device which needs 128bit integers 
  instead of doubles, has a z axis, thumbstick or tiny projector built 
  in, etc.
  
 
 There's also the point that nothing stops games or sdl-like layers 
 from using libinput to interpret the evdev stream, there's no need to 
 keep re-implementing device handlers for each client, that way new 
 devices supported by Wayland are automaticaly supported.

there is a minor problem: libinput can't open a device based on the fd
alone. there's a clunky workaround in the xorg libinput driver (see the
open_restricted implementation there). 

I'm willing to consider an API that passes an fd to libinput instead of a
path though. Pls file a bug whenever we're at the point where we really need
it, iirc I even had that implemented or at least partially implemented at
some point.

Cheers,
   Peter


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

[ANNOUNCE] libinput 0.14.1

[Peter Hutterer]

A new release of libinput, 0.14.1, is now available. 

This is a brown paper bag release, 0.14.0 failed distcheck. Oops. Only one
single patch to include the new man page for libinput-list-devices in the
tarball, the rest is identical. For a full list of changes between 0.13 and
0.14 please see:
http://lists.freedesktop.org/archives/wayland-devel/2015-April/021484.html

Peter Hutterer (2):
  tools: distribute the new man page
  configure.ac: libinput 0.14.1

git tag: 0.14.1

http://www.freedesktop.org/software/libinput/libinput-0.14.1.tar.xz
MD5:  18f6e1d6ab58db9a66c5ee8ca20aa876  libinput-0.14.1.tar.xz
SHA1: 769e67edb6c158e88feb21963790902a32aa5b4c  libinput-0.14.1.tar.xz
SHA256: 2bed202ebe2d5026950d6f9d2ac0f0160d12f61c5a0f6d0d6ef671bbb02c1b64  
libinput-0.14.1.tar.xz
PGP:  http://www.freedesktop.org/software/libinput/libinput-0.14.1.tar.xz.sig



pgpCK5JhaAQ7m.pgp
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland Relative Pointer API Progress

[Bill Spitzak]

Interesting. It does seem like a good idea to do remote by providing 
identical device api's. This probably applies to sound output too. There 
will have to be simple and obvious methods to figure out the remote 
machine so that all other devices besides the display go to the same 
one, and there will have to be network apis designed for each of them. 
But this may be a way to avoid having every aspect of remote hardware 
encoded into wayland messages.


If a client opens a device, will that interfere with wayland's reading 
of the device? For instance if the client opens the mouse, will wayland 
still get the mouse position such that it can revoke access when the 
cursor moves out of the window?


On 04/20/2015 06:14 PM, x414e54 wrote:


2015/04/21 5:42 Bill Spitzak spit...@gmail.com
mailto:spit...@gmail.com:
 
  On 04/18/2015 03:20 AM, Hans de Goede wrote:
 
  This has been discussed before, and as mentioned before I really
  believe that we should not define a joystick API at all,
  rather we should define an API which will allow an app to:
 
  1) List devices which it can get raw access to
  2) Request raw access, if this succeeds the app will be handled
  an evdev fd for the device
  3) Notify the app that the compositor is revoking access (e.g.
  because the app lost focus), when this happens the compositor
  will do a revoke ioctl on the evdev fd rendering it useless
  to the app, so the app cannot keep using this (so no security
  issue).
  4) Hand a new evdev fd to the app when it regains access.


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

[ANNOUNCE] libinput 0.14.0

[Peter Hutterer]

A new release of libinput, 0.14.0, is now available. 

libinput now provides middle button emulation for physical buttons and, for
some devices, a configuration interface to enable said emulation.
The API is the usual quartett of configuration queries:
libinput_device_config_middle_emulation_is_available()
libinput_device_config_middle_emulation_set_enabled()
libinput_device_config_middle_emulation_get_enabled()
libinput_device_config_middle_emulation_get_default_enabled()

A new tool libinput-list-devices was added. This tool lists the locally
recognised devices and their respective configuration options and
configuration defaults. Example output:

Device: SynPS/2 Synaptics TouchPad
Kernel: /dev/input/event4
Group:  9
Seat:   seat0, default
Size:   97.33x62.40mm
Capabilities:   pointer
Tap-to-click:   disabled
Left-handed:disabled
Nat.scrolling:  disabled
Calibration:n/a
Scroll methods: *two-finger
Click methods:  *button-areas clickfinger

Note that due to the design of libinput, this tool can only show the
_default_ configurations, not the _current_ configuration of each device.

The pointer acceleration range has been widened to allow for greater
deceleration and greater acceleration. Since we retain the [-1, 1] range,
you may see a slight slowdown or speedup. To get the previous behaviour,
use the value: current setting * 2.0/3.0.

Five (or more) finger tapping is now handled correctly, though note we only
send events for up to three fingers. libinput now supports multi-tap and
drag, so e.g. three taps will execute a triple-click.

Palm detection now avoids accidental tapping, see
http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

And of course the usual bugfixing, including letting libinput handle more
devices such as keyboards with scroll wheels or devices that only consist of
a wheel.

As usual, the shortlog is below.

Hans de Goede (8):
  Fix scroll-threshold check for edge-scrolling to use normalized 
coordinates
  Add a delta_coords type and use it were applicable
  Add a normalized_length helper function and use this where applicable
  Add a normalized_is_zero helper function
  Change tp_filter_motion to normalized_coords
  Rename delta_coords to device_float_coords
  Change vector_get_direction input to a normalized_coords struct
  filter: Make acceleration range wider

Peter Hutterer (50):
  include: update to v3.18 header
  evdev: fix crash for missing ABS_X/Y
  evdev: fix handling of fake MT devices without ABS_X/Y
  test: adjust scroll wheel test for HWHEEL-only devices
  evdev: if a keyboard has a scroll wheel, allow natural scrolling
  test: add the Razer BlackWidow keyboard device
  touchpad: count the tapping fingers separately from the main touchpad code
  evdev: fix inverted mouse normalization
  touchpad: remove trailing semicolon from macro
  touchpad: add state debugging to the edge scroll state machine
  touchpad: delay fake finger processing until the EV_SYN
  evdev: reject devices with only one of x/y resolution
  touchpad: detect fake finger overflow after BTN_TOOL_QUINTTAB
  touchpad: a touch in TOUCH_NONE doesn't need to be ended
  touchpad: rename real_touches to num_slots
  tools: apply the config options for the event-gui helper too
  tools: add commandline flag to control the pointer accel speed
  tools: add a tool for printing pointer acceleration parameters
  evdev: any scroll device must have CAP_POINTER
  Don't post a events for a missing capability
  test: add a scrollwheel-only device
  Return INVALID before UNSUPPORTED for click methods
  evdev: add a event-debugging log statement (ifdef'd out)
  evdev: merge two conditions into one with a sub condition
  touchpad: extend two debug messages
  tools: add a tool to list local devices and the default configurations
  touchpad: only pair internal trackpoint devices with internal touchpads
  touchpad: don't allow taps in the top half of the palm exclusion zone.
  touchpad: reduce palm detection threshold to 70mm
  toucphad: fix a comment for the new min touchpad palm detection size
  evdev: add evdev_pointer_notify_physical_button
  Add middle mouse button emulation config options
  evdev: add support for middle button emulation
  evdev: enable middle button configuration on some devices
  touchpad: enable middle button emulation on some touchpads
  test: middle button emulation tests
  test: add litest_is_button_event
  touchpad: introduce MULTITAP for multi-tap-and-drag
  evdev: accept but disable ABS_MISC and above for min/max == 0
  tools: add --set-scroll-method commandline flag
  test: enable edge scrolling in all edge scroll tests
  test: extend edge scrolling tests to 

Re: [PATCH wayland] Add enum attribute to arg elements

[Jeroen Bollen]

I think I have thought out a solution.

The scanner should be able to parse multiple specification files. There
would be the default wayland.xml, and for example a gnome.xml, which is an
extension to the wayland.xml. It does only contain things like added
interfaces, added requests, added events and added enum variants. The
scanner would merge all these files together.

This means that enums can be complete. If a user wants to have additional
values, they should simply add an XML for the extended feature set. This
would also reduce and fragmentation, as extensions to the protocol don't
require one to maintain an entire wayland.xml file anymore. It also allows
people to use multiple protocol extensions at once, without merging
multiple, already-forked specifications.

What are the opinions on this?

On Tue, 21 Apr 2015 at 09:18 Pekka Paalanen ppaala...@gmail.com wrote:

 On Mon, 20 Apr 2015 15:54:59 +
 Jeroen Bollen jbin...@gmail.com wrote:

  On Mon, 20 Apr 2015 at 09:03 Pekka Paalanen ppaala...@gmail.com wrote:
  
   Also, adding the strict type information to the XML spec has no benefit
   for C, which is the de facto language for Wayland core developers. A C
   compiler also does not raise errors if you violate the rules. This and
   all the above are the likely reasons why adding the strict type
   information is not interesting, at least for me.
  
   Making the enum rules more strict has a possibility to break existing
   users, but to me it is unclear if the benefit would outweigh that
   con or the freedom.
  
   On the wire, an enum or bitfield is still just an uint (or int), and a
   buggy client or server may cause the other to receive illegal values.
   Do the strongly typed languages have checks against that? Can you
   define what happens if the value is illegal for an enum? Or do you have
   to write that check manually in any case?
  
   So, the big question here is: do we even want to have strict enum
 types?
  
 
  It does indeed not provide any benefit for C, but if C is the only
 language
  to be targeted, there is not much use in there being an XML specification
  at all. It could've just been written out in C. I do agree that any
 changes
  should be compatible with C.
 
  I know in Rust, conversion from the `uint` to the `enum` type would have
 to
  be done manually, and error checking happens here. It does stop the user
  from passing illegal values to other servers however. It also makes it
 more
  clear what `enum`s are to be used with which arguments, and enforces
 this.
 
  I don't really see why adding that to the specification is an issue. If
  some `enum` types aren't complete, as in, they aren't the only valid
  values, then I see little value in having the `enum` in the specification
  in the first place.

 The foremost purpose of the enum is to let the generator create named
 constants in a namespace. This is something that has to stay due to
 API stability guarantees.

 I had some discussion in IRC, and I'm coming around. It does seem a
 useful addition, but you have to be clear in specifying what it all
 means. For instance, saying an attribute referencing an enum in an
 arg for purely documentation linkage would be fine. We don't have
 docs for the XML language, but at least define it in a commit message.

 If such annotation is intended to be useful for code generation on
 relevant languages, you need to define clearly what it means. I'm not
 familiar with those languages you are interested in, so I cannot judge
 that.

 What I would want, is patches to wayland-scanner to use these
 additional annotations, if only for syntax checking the XML and maybe
 generating one more comment for an arg or whatever. Unfortunately
 wayland-scanner still is the definition of the Wayland XML language.
 It should be kept updated in any case.

 Two things I came up with in the IRC discussion was that only arg
 types of int an uint are eligible for enums, and only uint for
 bitfields. I think wayland-scanner should enforce that.

 One question was about whether bitfield values should be limited to
 single bits (powers of two). I think that would be an artificial
 restriction, and it would not allow using short-hand names for sets of
 bits. I see no reason to deny those.

 Another is the question about incomplete enumerations. I don't think we
 can deny their existence. Therefore they must be supported. If that
 means you cannot put the enum attribute in such an arg, then so be
 it; but you lose also the doc linkage. Extending value or bit
 enumerations is something that happens, and with the expectation that
 it doesn't break anything. An interface that expects to see new entries
 in an enumeration in the future will specify how unknown values should
 be dealt with. You maybe have your code generated according to an old
 specification, while the other party is using a new specification, and
 you need to obey the interface specification regarding unknown values.
 This has to work.