date:20151018

Re: [PATCH weston] input: use doubles in the interfaces to notify of input events

2015-10-18 Thread Jonas Ådahl

On Sat, Oct 17, 2015 at 06:07:06PM +0300, Giulio Camuffo wrote:
> Hi,
> git send-email has decided that it doesn't want to send this patch but
> likely format-patch is more reasonable so i've attached it.
> 
> --
> Giulio

> From 060186308dde03279f7a0659e7edec706a0f5123 Mon Sep 17 00:00:00 2001
> From: Giulio Camuffo 
> Date: Sat, 17 Oct 2015 17:36:08 +0300
> Subject: [PATCH] input: use doubles in the interfaces to notify of input
>  events
> 
> This patch is a further step in the wl_fixed_t internal sanitization.
> It changes the notify_* functions to take doubles instead of wl_fixed_t
> but does not change how these are stored in the various input structs
> yet. However this already allows to remove all wl_fixed_t usage in places
> like the libinput or the x11 backend.
> ---
>  src/compositor-rdp.c | 13 -
>  src/compositor-wayland.c | 20 ++--
>  src/compositor-x11.c | 18 +-
>  src/compositor.c | 12 ++--
>  src/compositor.h | 14 +++---
>  src/input.c  | 24 
>  src/libinput-device.c| 33 +
>  src/screen-share.c   |  5 +++--
>  tests/weston-test.c  |  4 ++--
>  9 files changed, 74 insertions(+), 69 deletions(-)
> 
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 7272f41..8d186fa 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -70,7 +70,7 @@
>  #include "pixman-renderer.h"
>  
>  #define MAX_FREERDP_FDS 32
> -#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
> +#define DEFAULT_AXIS_STEP_DISTANCE 10
>  #define RDP_MODE_FREQ 60 * 1000
>  
>  struct rdp_backend_config {
> @@ -943,7 +943,7 @@ static BOOL xf_peer_post_connect(freerdp_peer *client)
>  static FREERDP_CB_RET_TYPE
>  xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y)
>  {
> - wl_fixed_t wl_x, wl_y, axis;
> + double axis;
>   RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
>   struct rdp_output *output;
>   uint32_t button = 0;
> @@ -951,10 +951,8 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
> UINT16 y)
>   if (flags & PTR_FLAGS_MOVE) {
>   output = peerContext->rdpBackend->output;
>   if (x < output->base.width && y < output->base.height) {
> - wl_x = wl_fixed_from_int((int)x);
> - wl_y = wl_fixed_from_int((int)y);
>   notify_motion_absolute(>item.seat, 
> weston_compositor_get_time(),
> - wl_x, wl_y);
> + x, y);
>   }
>   }
>  
> @@ -993,16 +991,13 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
> UINT16 y)
>  static FREERDP_CB_RET_TYPE
>  xf_extendedMouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y)
>  {
> - wl_fixed_t wl_x, wl_y;
>   RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
>   struct rdp_output *output;
>  
>   output = peerContext->rdpBackend->output;
>   if (x < output->base.width && y < output->base.height) {
> - wl_x = wl_fixed_from_int((int)x);
> - wl_y = wl_fixed_from_int((int)y);
>   notify_motion_absolute(>item.seat, 
> weston_compositor_get_time(),
> - wl_x, wl_y);
> + x, y);
>   }
>  
>   FREERDP_CB_RETURN(TRUE);
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index 7b11ae4..8f039a9 100644
> --- a/src/compositor-wayland.c
> +++ b/src/compositor-wayland.c
> @@ -1273,6 +1273,7 @@ input_handle_pointer_enter(void *data, struct 
> wl_pointer *pointer,
>   struct wayland_input *input = data;
>   int32_t fx, fy;
>   enum theme_location location;
> + double dx, dy;
>  
>   /* XXX: If we get a modifier event immediately before the focus,
>*  we should try to keep the same serial. */
> @@ -1293,11 +1294,14 @@ input_handle_pointer_enter(void *data, struct 
> wl_pointer *pointer,
>   location = THEME_LOCATION_CLIENT_AREA;
>   }
>  
> - weston_output_transform_coordinate(>output->base, x, y, , );
> + dx = wl_fixed_to_double(x);
> + dy = wl_fixed_to_double(y);
> + weston_output_transform_coordinate(>output->base,
> +dx, dy, , );

dx/dy (d-prefixed x/y) usually mean deltas, but here they are absolute
numbers, which is quite confusing. I'd rather not use dx/dy for absolute
numbers. Same here and for all the other non-delta dx/dy's.

>  
>   if (location == THEME_LOCATION_CLIENT_AREA) {
>   input->focus = 1;
> - notify_pointer_focus(>base, >output->base, x, y);
> + notify_pointer_focus(>base, >output->base, dx, 
> dy);
>   wl_pointer_set_cursor(input->parent.pointer,
> input->enter_serial, NULL, 0, 0);
>   }

Re: [PATCH weston] input: use doubles in the interfaces to notify of input events

2015-10-18 Thread Peter Hutterer

On Sat, Oct 17, 2015 at 06:07:06PM +0300, Giulio Camuffo wrote:
> Hi,
> git send-email has decided that it doesn't want to send this patch but
> likely format-patch is more reasonable so i've attached it.
> 
> --
> Giulio

> From 060186308dde03279f7a0659e7edec706a0f5123 Mon Sep 17 00:00:00 2001
> From: Giulio Camuffo 
> Date: Sat, 17 Oct 2015 17:36:08 +0300
> Subject: [PATCH] input: use doubles in the interfaces to notify of input
>  events
> 
> This patch is a further step in the wl_fixed_t internal sanitization.
> It changes the notify_* functions to take doubles instead of wl_fixed_t
> but does not change how these are stored in the various input structs
> yet. However this already allows to remove all wl_fixed_t usage in places
> like the libinput or the x11 backend.

lgtm, Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  src/compositor-rdp.c | 13 -
>  src/compositor-wayland.c | 20 ++--
>  src/compositor-x11.c | 18 +-
>  src/compositor.c | 12 ++--
>  src/compositor.h | 14 +++---
>  src/input.c  | 24 
>  src/libinput-device.c| 33 +
>  src/screen-share.c   |  5 +++--
>  tests/weston-test.c  |  4 ++--
>  9 files changed, 74 insertions(+), 69 deletions(-)
> 
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 7272f41..8d186fa 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -70,7 +70,7 @@
>  #include "pixman-renderer.h"
>  
>  #define MAX_FREERDP_FDS 32
> -#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
> +#define DEFAULT_AXIS_STEP_DISTANCE 10
>  #define RDP_MODE_FREQ 60 * 1000
>  
>  struct rdp_backend_config {
> @@ -943,7 +943,7 @@ static BOOL xf_peer_post_connect(freerdp_peer *client)
>  static FREERDP_CB_RET_TYPE
>  xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y)
>  {
> - wl_fixed_t wl_x, wl_y, axis;
> + double axis;
>   RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
>   struct rdp_output *output;
>   uint32_t button = 0;
> @@ -951,10 +951,8 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
> UINT16 y)
>   if (flags & PTR_FLAGS_MOVE) {
>   output = peerContext->rdpBackend->output;
>   if (x < output->base.width && y < output->base.height) {
> - wl_x = wl_fixed_from_int((int)x);
> - wl_y = wl_fixed_from_int((int)y);
>   notify_motion_absolute(>item.seat, 
> weston_compositor_get_time(),
> - wl_x, wl_y);
> + x, y);
>   }
>   }
>  
> @@ -993,16 +991,13 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
> UINT16 y)
>  static FREERDP_CB_RET_TYPE
>  xf_extendedMouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y)
>  {
> - wl_fixed_t wl_x, wl_y;
>   RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
>   struct rdp_output *output;
>  
>   output = peerContext->rdpBackend->output;
>   if (x < output->base.width && y < output->base.height) {
> - wl_x = wl_fixed_from_int((int)x);
> - wl_y = wl_fixed_from_int((int)y);
>   notify_motion_absolute(>item.seat, 
> weston_compositor_get_time(),
> - wl_x, wl_y);
> + x, y);
>   }
>  
>   FREERDP_CB_RETURN(TRUE);
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index 7b11ae4..8f039a9 100644
> --- a/src/compositor-wayland.c
> +++ b/src/compositor-wayland.c
> @@ -1273,6 +1273,7 @@ input_handle_pointer_enter(void *data, struct 
> wl_pointer *pointer,
>   struct wayland_input *input = data;
>   int32_t fx, fy;
>   enum theme_location location;
> + double dx, dy;
>  
>   /* XXX: If we get a modifier event immediately before the focus,
>*  we should try to keep the same serial. */
> @@ -1293,11 +1294,14 @@ input_handle_pointer_enter(void *data, struct 
> wl_pointer *pointer,
>   location = THEME_LOCATION_CLIENT_AREA;
>   }
>  
> - weston_output_transform_coordinate(>output->base, x, y, , );
> + dx = wl_fixed_to_double(x);
> + dy = wl_fixed_to_double(y);
> + weston_output_transform_coordinate(>output->base,
> +dx, dy, , );
>  
>   if (location == THEME_LOCATION_CLIENT_AREA) {
>   input->focus = 1;
> - notify_pointer_focus(>base, >output->base, x, y);
> + notify_pointer_focus(>base, >output->base, dx, 
> dy);
>   wl_pointer_set_cursor(input->parent.pointer,
> input->enter_serial, NULL, 0, 0);
>   } else {
> @@ -1335,6 +1339,7 @@ input_handle_motion(void *data, struct wl_pointer 
> *pointer,
>   struct wayland_input

Re: [PATCH wayland v2] Remove protocol/wayland.dtd

2015-10-18 Thread Peter Hutterer

On Fri, Oct 16, 2015 at 11:42:21AM +0300, Pekka Paalanen wrote:
> On Fri, 16 Oct 2015 12:29:11 +1000
> Peter Hutterer  wrote:
> 
> > On Fri, Oct 09, 2015 at 01:16:49PM +0200, Nils Chr. Brause wrote:
> > > Hi,
> > > 
> > > Reviewed-by: Nils Christopher Brause 
> > > 
> > > I ran distcheck and it worked. :)
> > 
> > a bit late, but I would like to register my disagreement with this patch :)
> > 
> > Having the DTD is a much simpler and less bug-prone description of what the
> > protocol should look like. Having the scanner define the protocol means the
> > protocol is whatever the current version of the scanner supports, which is
> > not a good contract.
> 
> Hi Peter,
> 
> can't argue with that. It's just that the DTD was unused since
> 6292fe2af6a45decb7fd39090e74dd87bc4e22b2, Feb 2014.
> 
> > I'd argue for reverting this and fixing any mismatch if there is one. And
> > using the DTD to validate before the scanner even runs.
> 
> We talked in IRC about this, and came to the conclusion that maybe we
> could have wayland-scanner invoke a validity checker against a DTD or
> an XSD.

I played around with that. As a quick basic solution we can hook validation
with libxml2 into the scanner and print a warning if the xml doesn't
validate. That's less than 50 LOC and won't break things since it doesn't
touch the actual parsing. and it won't break existing protocols that use
"creative" tags, all it will do is warn, not fail. See the diff below (after
reverting 06fb8bd37.

it's an ugly solution though, but without scanner tests probably the best
thing we can do.

> If the original objection to a DTD was because it required manually
> writing a lint phase in every project build system using the XML files,
> then having wayland-scanner invoke the check automatically solves that.

the question that remains though is: the dtd must be an external file for
extensions to be validated. Which means we need to either pass the dtd as
argument to the scanner (requires makefile changes everywhere), or we
hardcode the path into wayland-scanner (issues with running the scanner from
within the source tree) or we add it as variable to pkgconfig (requires
makefile changes again). any other solutions to fix this are welcome.
even if all we do is call out to xmllint we still run into that issue.

Cheers,
   Peter

> Then it becomes a question of how to do that and what tools or
> libraries to rely on. Running an external lint program from scanner.c
> could be a start.
>
> Migrating scanner.c from expat to some validating XML parser library
> would be a big enough change that I would like to see some scanner
> tests written before that.
>
> I think this summarises our IRC discussion for the mailing list.


diff --git a/Makefile.am b/Makefile.am
index 9114d98..cd4d6b5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -24,8 +24,8 @@ pkgconfig_DATA =
 
 bin_PROGRAMS = wayland-scanner
 wayland_scanner_SOURCES = src/scanner.c
-wayland_scanner_CFLAGS = $(EXPAT_CFLAGS) $(AM_CFLAGS)
-wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la
+wayland_scanner_CFLAGS = $(EXPAT_CFLAGS) $(LIBXML_CFLAGS) $(AM_CFLAGS)
+wayland_scanner_LDADD = $(EXPAT_LIBS) $(LIBXML_LIBS) libwayland-util.la
 pkgconfig_DATA += src/wayland-scanner.pc
 
 if USE_HOST_SCANNER
diff --git a/configure.ac b/configure.ac
index ef26929..6630fbb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -105,6 +105,8 @@ PKG_CHECK_MODULES(EXPAT, [expat], [],
 AC_SUBST(EXPAT_LIBS)
])
 
+PKG_CHECK_MODULES(LIBXML, [libxml-2.0])
+
 AC_PATH_PROG(XSLTPROC, xsltproc)
 AM_CONDITIONAL([HAVE_XSLTPROC], [test "x$XSLTPROC" != "x"])
 
diff --git a/src/scanner.c b/src/scanner.c
index f456aa5..3685f7f 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #include "wayland-util.h"
 
@@ -59,6 +62,39 @@ usage(int ret)
exit(ret);
 }
 
+static int
+validate(void)
+{
+   int rc = 0;
+   xmlParserCtxtPtr ctx = NULL;
+   xmlDocPtr doc = NULL;
+   xmlDtdPtr dtd = NULL;
+   xmlValidCtxtPtr dtdctx;
+
+   dtdctx = xmlNewValidCtxt();
+
+   ctx = xmlNewParserCtxt();
+   if (!ctx)
+   return 1;
+
+   dtd = xmlParseDTD(NULL, (const xmlChar*)"protocol/wayland.dtd");
+   if (!dtd)
+   abort();
+
+   doc = xmlCtxtReadFd(ctx, 0, "blah", NULL, 0);
+   if (!doc)
+   rc = 1;
+
+   rc = !xmlValidateDtd(dtdctx, doc, dtd);
+
+   xmlFreeDoc(doc);
+   xmlFreeParserCtxt(ctx);
+   xmlFreeValidCtxt(dtdctx);
+
+   lseek(0, 0, SEEK_SET);
+   return rc;
+}
+
 #define XML_BUFFER_SIZE 4096
 
 struct location {
@@ -1547,6 +1583,16 @@ int main(int argc, char *argv[])
ctx.protocol = 
ctx.loc.filename = "";
 
+   /* validate the XML */
+   if (validate() != 0) {
+   fprintf(stderr,
+

Re: [PATCH weston] libinput: remove unused #define

2015-10-18 Thread Peter Hutterer

On Sat, Oct 17, 2015 at 06:00:35PM +0300, Giulio Camuffo wrote:
> ---
>  src/libinput-device.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/src/libinput-device.c b/src/libinput-device.c
> index 9fe1627..13440df 100644
> --- a/src/libinput-device.c
> +++ b/src/libinput-device.c
> @@ -40,8 +40,6 @@
>  #include "libinput-device.h"
>  #include "shared/helpers.h"
>  
> -#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
> -
>  void
>  evdev_led_update(struct evdev_device *device, enum weston_led weston_leds)
>  {
> -- 
> 2.6.1
> 

Reviewed-by: Peter Hutterer 

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

Re: [PATCH weston] libinput: remove unused #define

2015-10-18 Thread Jonas Ådahl

On Mon, Oct 19, 2015 at 06:59:46AM +1000, Peter Hutterer wrote:
> On Sat, Oct 17, 2015 at 06:00:35PM +0300, Giulio Camuffo wrote:
> > ---
> >  src/libinput-device.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/src/libinput-device.c b/src/libinput-device.c
> > index 9fe1627..13440df 100644
> > --- a/src/libinput-device.c
> > +++ b/src/libinput-device.c
> > @@ -40,8 +40,6 @@
> >  #include "libinput-device.h"
> >  #include "shared/helpers.h"
> >  
> > -#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
> > -
> >  void
> >  evdev_led_update(struct evdev_device *device, enum weston_led weston_leds)
> >  {
> > -- 
> > 2.6.1
> > 
> 
> Reviewed-by: Peter Hutterer 

Pushed:
   c6e6dc7..49da7ae  master -> master

Jonas

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

RE: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

2015-10-18 Thread 박성진

>At least based on this example, I think this is fixing the wrong problem.
>knowing which device sends a key is fairly meaningless unless you have direct 
>access to the devices anyway (which you >probably don't, at least not in the 
>default setups). And there are plenty of devices that have meaningless names 
>made >from the pid/vid hex codes or even worse - "USB Keyboard".

Sorry for replying late. :)

Actually, as you mentioned, there are many keyboards which has {bus} Keyboard 
something like that.
I'm not telling that we need distinguish between a keyboard device (which 
doesn't have any unique name) and the others.

We need to distinguish between a specific key device and the others,
of course, the key device will have the its exact name which can be used as an 
identifier.
Then, there are some applications in which separate behavior needs to be done 
for each of key device.
Even though these kinds of requirements seem to be relatively rare, it'll be 
wonderful if it exists in protocol.
I'm mentioning from this point of view.

>the source of your problem is IMO that you're treating the remote control like 
>a keyboard when it isn't one. This is >what we've been trying to solve with 
>the buttonset interface in libinput (still WIP and needs a wayland protocol 
>>extension). Those devices are merely sets of buttons and require their own 
>focus control and behaviour, separate to >(and more domain-specific
>than) keyboards. But it moves the issue into its own separate corner where it 
>can be handled correctly, rather than >papering over the issues.

Right, by adding 'buttonset' into wayland protocol and by assigning a device as 
a buttonset device, we will be ready to have separate interface between 
keyboard and buttonset. Will there be any identifier in the buttonset interface?
When it comes to identification between buttonsets, it'll be also needed to 
identify each of them, if required.

Thanks and regards,
Sung-Jin park

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Peter Hutterer
Sent: Tuesday, October 13, 2015 2:01 PM
To: �ڼ���
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH] Extending wayland protocol for helping a wayland client to 
identify the event source of device (pointer/keyboard)

On Fri, Sep 25, 2015 at 04:14:25PM +0900,  ڼwrote:
> Dear all,
> 
> Let me share a patch for extending wayland protocol for helping a 
> wayland client to identify which events are coming from which physical 
> keyboard/pointer device.
> 
> I  d like to discuss with you guys about this patch. : )
> 
> In this patch, I added   name   event both for wl_pointer and for 
> wl_keyboard.
> 
> Under wayland protocol applied this patch, a wayland compositor will 
> send the name event when a wayland client add a listener for 
> wl_pointer or wl_keyboard.
> 
> Then, the client can store the name of the keyboard or pointer and 
> will use it when it is required.
> 
>  
> 
> Usually in desktop environment, we don  t need to care the source 
> device name of events.
> 
> In vehicle, mobile and TV environment, there will be many input 
> devices and will be many special requirements for them.
> 
> For instance, in TV,   1   key in an usual keyboard will be used as a 
> character   1   and will be sent to the focus surface/window.
> 
> By the way   1   key in remote control for TV will be used as a action 
> key and will be sent to channel managing process which doesn  t have 
> any focus surface/window.
> 
> In addition to this example, there can be many examples.
> 
> Thus, I share this patch. Any ideas on this ? : )

At least based on this example, I think this is fixing the wrong problem.
knowing which device sends a key is fairly meaningless unless you have direct 
access to the devices anyway (which you probably don't, at least not in the 
default setups). And there are plenty of devices that have meaningless names 
made from the pid/vid hex codes or even worse - "USB Keyboard".

the source of your problem is IMO that you're treating the remote control like 
a keyboard when it isn't one. This is what we've been trying to solve with the 
buttonset interface in libinput (still WIP and needs a wayland protocol 
extension). Those devices are merely sets of buttons and require their own 
focus control and behaviour, separate to (and more domain-specific
than) keyboards. But it moves the issue into its own separate corner where it 
can be handled correctly, rather than papering over the issues.

Cheers,
   Peter

> 
> ==
> 
> From ceeb8e2a10dce59a3fda9aca113b64ea97a85746 Mon Sep 17 00:00:00 2001
> 
> From: Sung-Jin Park 
> 
> Date: Fri, 25 Sep 2015 14:01:57 +0900
> 
> Subject: [PATCH] Add name event for wl_pointer and wl_keyboard in 
> wayland
> 
> protocol
> 
>  
> 
> ---
> 
> protocol/wayland.xml | 38 --
> 
> 1 file

Re: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

2015-10-18 Thread Peter Hutterer

On Mon, Oct 19, 2015 at 01:17:57PM +0900, 박성진 wrote:
> >At least based on this example, I think this is fixing the wrong problem.
> >knowing which device sends a key is fairly meaningless unless you have 
> >direct access to the devices anyway (which you >probably don't, at least not 
> >in the default setups). And there are plenty of devices that have 
> >meaningless names made >from the pid/vid hex codes or even worse - "USB 
> >Keyboard".
> 
> Sorry for replying late. :)
> 
> Actually, as you mentioned, there are many keyboards which has {bus} Keyboard 
> something like that.
> I'm not telling that we need distinguish between a keyboard device (which 
> doesn't have any unique name) and the others.
> 
> We need to distinguish between a specific key device and the others,
> of course, the key device will have the its exact name which can be used as 
> an identifier.
> Then, there are some applications in which separate behavior needs to be done 
> for each of key device.
> Even though these kinds of requirements seem to be relatively rare, it'll be 
> wonderful if it exists in protocol.
> I'm mentioning from this point of view.
> 
> >the source of your problem is IMO that you're treating the remote control 
> >like a keyboard when it isn't one. This is >what we've been trying to solve 
> >with the buttonset interface in libinput (still WIP and needs a wayland 
> >protocol >extension). Those devices are merely sets of buttons and require 
> >their own focus control and behaviour, separate to >(and more domain-specific
> >than) keyboards. But it moves the issue into its own separate corner where 
> >it can be handled correctly, rather than >papering over the issues.
> 
> Right, by adding 'buttonset' into wayland protocol and by assigning a
> device as a buttonset device, we will be ready to have separate interface
> between keyboard and buttonset. Will there be any identifier in the
> buttonset interface?
> When it comes to identification between buttonsets, it'll be also needed
> to identify each of them, if required.

yep, the plan is to have identifiers. How exactly they'll look like I don't
know yet, we'll take some hints from the wl_tablet interface though and go
from there.

Cheers,
   Peter

 
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
> Behalf Of Peter Hutterer
> Sent: Tuesday, October 13, 2015 2:01 PM
> To: �ڼ���
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: [PATCH] Extending wayland protocol for helping a wayland client 
> to identify the event source of device (pointer/keyboard)
> 
> On Fri, Sep 25, 2015 at 04:14:25PM +0900,  ڼwrote:
> > Dear all,
> > 
> > Let me share a patch for extending wayland protocol for helping a 
> > wayland client to identify which events are coming from which physical 
> > keyboard/pointer device.
> > 
> > I  d like to discuss with you guys about this patch. : )
> > 
> > In this patch, I added   name   event both for wl_pointer and for 
> > wl_keyboard.
> > 
> > Under wayland protocol applied this patch, a wayland compositor will 
> > send the name event when a wayland client add a listener for 
> > wl_pointer or wl_keyboard.
> > 
> > Then, the client can store the name of the keyboard or pointer and 
> > will use it when it is required.
> > 
> >  
> > 
> > Usually in desktop environment, we don  t need to care the source 
> > device name of events.
> > 
> > In vehicle, mobile and TV environment, there will be many input 
> > devices and will be many special requirements for them.
> > 
> > For instance, in TV,   1   key in an usual keyboard will be used as a 
> > character   1   and will be sent to the focus surface/window.
> > 
> > By the way   1   key in remote control for TV will be used as a action 
> > key and will be sent to channel managing process which doesn  t have 
> > any focus surface/window.
> > 
> > In addition to this example, there can be many examples.
> > 
> > Thus, I share this patch. Any ideas on this ? : )
> 
> At least based on this example, I think this is fixing the wrong problem.
> knowing which device sends a key is fairly meaningless unless you have direct 
> access to the devices anyway (which you probably don't, at least not in the 
> default setups). And there are plenty of devices that have meaningless names 
> made from the pid/vid hex codes or even worse - "USB Keyboard".
> 
> the source of your problem is IMO that you're treating the remote control 
> like a keyboard when it isn't one. This is what we've been trying to solve 
> with the buttonset interface in libinput (still WIP and needs a wayland 
> protocol extension). Those devices are merely sets of buttons and require 
> their own focus control and behaviour, separate to (and more domain-specific
> than) keyboards. But it moves the issue into its own separate corner where it 
> can be handled correctly, rather than papering over the issues.
> 
> Cheers,
>Peter
> 
> > 
> >

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

2015-10-18 Thread Bill Spitzak


On 10/17/2015 08:59 AM, Michael Catanzaro wrote:

On Fri, 2015-10-16 at 18:43 -0700, Bill Spitzak wrote:

I think you misunderstood. The *destination* (if the cursor is still
pointing at it) is what sets the cursor.


To clarify: you mean the destination sets the cursor as soon as the
drop completes, correct? (Currently the source controls the cursor
until the drop is performed.) I don't see any disagreement on that
point: Carlos says that in drop_performed, the source "should reset its
internal current cursor to the regular one for the next time the
pointer enters the surface."


Did not see the word "internal" before, I misread the statement.

It does sound like you are relying on a client responding to an Enter 
event to change the cursor from whatever the DnD left it as to a normal 
pointer. This is (imho) correct.


Not sure if this should be mentioned as the statement is misleading. I 
don't think it is how a lot of clients will work, they will instead 
calculate the desired cursor at the moment they get the mouse-enter 
event. There is no "current cursor" to be "reset".


It seems you are assuming clients are written like this:

   static current_cursor;
   startDnD() { current_cursor = dnd_cursor; }
   endDnD() { current_cursor = normal_cursor; }
   on_mouse_enter() { wl_set_cursor(current_cursor); }

I expect it to work more like this:

   on_mouse_enter() {
 wl_set_cursor(is_dnd_running ? dnd_cursor : normal_cursor);
   }


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

Re: [PATCH weston] input: use doubles in the interfaces to notify of input events

Re: [PATCH weston] input: use doubles in the interfaces to notify of input events

Re: [PATCH wayland v2] Remove protocol/wayland.dtd

Re: [PATCH weston] libinput: remove unused #define

Re: [PATCH weston] libinput: remove unused #define

RE: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

Re: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

8 matches

Site Navigation

Mail list logo

Footer information