Re: [compiz] status of input redirection

[Daniel Stone]

On Fri, Jun 01, 2007 at 03:47:17PM -0400, David Reveman wrote:
 + switch (events[i].u.u.type) {
 + case MotionNotify:
 + case ButtonPress:
 + case ButtonRelease:
 + case KeyPress:
 + case KeyRelease:
 + case EnterNotify:
 + case LeaveNotify:

Hi,
This needs to be aware of Xi events.

Cheers,
Daniel


signature.asc
Description: Digital signature
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] status of input redirection

[Daniel Stone]

On Mon, Jun 04, 2007 at 05:06:20PM -0400, David Reveman wrote:
 On Sat, 2007-06-02 at 04:29 +0300, Daniel Stone wrote:
  On Fri, Jun 01, 2007 at 03:47:17PM -0400, David Reveman wrote:
   + switch (events[i].u.u.type) {
   + case MotionNotify:
   + case ButtonPress:
   + case ButtonRelease:
   + case KeyPress:
   + case KeyRelease:
   + case EnterNotify:
   + case LeaveNotify:
  
  Hi,
  This needs to be aware of Xi events.
 
 Yea, I forgot about that. Will the attached patch work or are those
 device events not using the keyButtonPointer structure?

Unfortunately, they're not using keyButtonPointer, and you can't put it
in a case, as the event numbers are non-constant.  They use
deviceKeyButtonPointer, but you also need to check deviceValuator.  See
dix/getevents.c, and mi/mieq.c.

Cheers,
Daniel


signature.asc
Description: Digital signature
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] status of input redirection

[Daniel Stone]

On Tue, Jun 05, 2007 at 02:41:59PM -0400, David Reveman wrote:
 On Tue, 2007-06-05 at 00:17 +0300, Daniel Stone wrote: 
  On Mon, Jun 04, 2007 at 05:06:20PM -0400, David Reveman wrote:
   Yea, I forgot about that. Will the attached patch work or are those
   device events not using the keyButtonPointer structure?
  
  Unfortunately, they're not using keyButtonPointer, and you can't put it
  in a case, as the event numbers are non-constant.  They use
  deviceKeyButtonPointer, but you also need to check deviceValuator.  See
  dix/getevents.c, and mi/mieq.c.
 
 I've adjusted the patch for deviceKeyButtonPointer. Like in my previous
 patch, device events are checked for in the default so that they are not
 constant should already be handled fine. Not sure exactly what to do
 about deviceValuator events yet.

Looks good to me.  I can't remember if you get all the events stacked
together by the time WriteEventsToClient comes around, or if you get
them individually.  If the latter, you need to keep a cache -- ugh.  If
the former, then it becomes pretty easy.

Cheers,
Daniel


signature.asc
Description: Digital signature
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] status of input redirection

[David Reveman]

On Tue, 2007-06-05 at 00:17 +0300, Daniel Stone wrote: 
 On Mon, Jun 04, 2007 at 05:06:20PM -0400, David Reveman wrote:
  On Sat, 2007-06-02 at 04:29 +0300, Daniel Stone wrote:
   On Fri, Jun 01, 2007 at 03:47:17PM -0400, David Reveman wrote:
+   switch (events[i].u.u.type) {
+   case MotionNotify:
+   case ButtonPress:
+   case ButtonRelease:
+   case KeyPress:
+   case KeyRelease:
+   case EnterNotify:
+   case LeaveNotify:
   
   Hi,
   This needs to be aware of Xi events.
  
  Yea, I forgot about that. Will the attached patch work or are those
  device events not using the keyButtonPointer structure?
 
 Unfortunately, they're not using keyButtonPointer, and you can't put it
 in a case, as the event numbers are non-constant.  They use
 deviceKeyButtonPointer, but you also need to check deviceValuator.  See
 dix/getevents.c, and mi/mieq.c.

I've adjusted the patch for deviceKeyButtonPointer. Like in my previous
patch, device events are checked for in the default so that they are not
constant should already be handled fine. Not sure exactly what to do
about deviceValuator events yet.

-David
--- a/dix/events.c
+++ b/dix/events.c
@@ -4686,8 +4686,9 @@ WriteEventsToClient(ClientPtr pClient, int count, xEvent *events)
 
 for (i = 0; i  count; i++)
 {
-	WindowPtr pWin;
-	int	  x, y, dx, dy;
+	deviceKeyButtonPointer *deviceEvent;
+	WindowPtr	   pWin;
+	int		   x, y, dx, dy;
 
 	switch (events[i].u.u.type) {
 	case MotionNotify:
@@ -4720,6 +4721,34 @@ WriteEventsToClient(ClientPtr pClient, int count, xEvent *events)
 		events[i].u.keyButtonPointer.eventY += dy;
 	}
 	break;
+	default:
+	if (events[i].u.u.type == DeviceMotionNotify  ||
+		events[i].u.u.type == DeviceButtonPress	  ||
+		events[i].u.u.type == DeviceButtonRelease ||
+		events[i].u.u.type == DeviceKeyPress	  ||
+		events[i].u.u.type == DeviceKeyRelease)
+	{
+		deviceEvent = (deviceKeyButtonPointer *) events[i];
+
+		pWin = LookupIDByType (deviceEvent-event, RT_WINDOW);
+		if (pWin)
+		{
+		x = deviceEvent-root_x;
+		y = deviceEvent-root_y;
+
+		CompositeXYScreenToWindowRootCoordinate (pWin, x, y,
+			 x, y);
+
+		dx = x - deviceEvent-root_x;
+		dy = y - deviceEvent-root_y;
+
+		deviceEvent-root_x  += dx;
+		deviceEvent-root_y  += dy;
+		deviceEvent-event_x += dx;
+		deviceEvent-event_y += dy;
+		}
+	}
+	break;
 	}
 }
 #endif
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] status of input redirection

[David Reveman]

On Sun, 2007-06-03 at 05:26 +0200, Dennis Kasprzyk wrote:
 Am Freitag, 1. Juni 2007 21:47:17 schrieb David Reveman:
  On Fri, 2007-06-01 at 13:28 -0400, Kristian Høgsberg wrote:
   On 5/31/07, David Reveman [EMAIL PROTECTED] wrote:
On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
 There where some patches to implement input redirection in xorg a
 while ago...
 what happend to them? are they still beeing worked on?
   
The attached patches work well. The server patch needs some more work
if we want to allow different pickers and I haven't had time to do that
yet.
  
   Can we merge the server patch as is and punt on the pluggable picker
   idea for now?  I mean, can we do this in a way that lets the
   interested parties add this support in a second step without breaking
   backwards compatibility?  If that's doable, I don't think we need to
   block on the pluggable picker idea now.
 
  I've attached a new patch with a more appropriate change to
  WriteEventsToClient.
 
  I'm OK with merging the patch in it's current state. Pluggable pickers
  can definitely be added later without breaking backwards compatibility.
 
  There's a few things that needs to be improved but I think the current
  patch is good enough for common use in compositing managers.
 
  TODO:
 
  I've tried to move the event coordinate transformation into
  FixUpEventFromWindow, which means making copies of events in a lot of
  places as FixUpEventFromWindow is sometimes called multiple times with
  the same xEvent. However, I never got that to work correctly and I
  haven't had time to figure out exactly why yet.
 
  The pointer grab code might need some more work but the patch should of
  course not affect non-transformed input in any way.
 
  I think that transformed input of non top-level windows isn't working
  correctly. This should be easy to fix though, I just need to write a
  good test app.
 
  -David
 
 After playing with this patches I thought that maybe this interface could 
 also 
 be extended to some basic real input redirection. Instead of a mapping from 
 the transformed coordinate space to the real window coordinate space, 
 there could be an additional value, that tells the xserver to redirect and 
 transform the input from the transformed coordinate space to another window 
 coordinate space. With something like this we could realize something like 
 cloned windows in different stack positions (using input only windows and 
 the composite manager).
 
 I think about somethink like this:
 XCompositeSetTriangularCoordinateMesh(Display *dpy, Window source, Window 
 destination, XTriangle *triangle, int ntriangle);
 
 I don't know enough about the xserver internals to tell if something like 
 this 
 is possible, but I think that this could extend the range for possible 
 effects. 

It might be a good idea to add a destination window. It shouldn't be
very hard to implement. The destination window can't be an ancestor,
though.

-David

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] status of input redirection

[Dennis Kasprzyk]

Am Freitag, 1. Juni 2007 21:47:17 schrieb David Reveman:
 On Fri, 2007-06-01 at 13:28 -0400, Kristian Høgsberg wrote:
  On 5/31/07, David Reveman [EMAIL PROTECTED] wrote:
   On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
There where some patches to implement input redirection in xorg a
while ago...
what happend to them? are they still beeing worked on?
  
   The attached patches work well. The server patch needs some more work
   if we want to allow different pickers and I haven't had time to do that
   yet.
 
  Can we merge the server patch as is and punt on the pluggable picker
  idea for now?  I mean, can we do this in a way that lets the
  interested parties add this support in a second step without breaking
  backwards compatibility?  If that's doable, I don't think we need to
  block on the pluggable picker idea now.

 I've attached a new patch with a more appropriate change to
 WriteEventsToClient.

 I'm OK with merging the patch in it's current state. Pluggable pickers
 can definitely be added later without breaking backwards compatibility.

 There's a few things that needs to be improved but I think the current
 patch is good enough for common use in compositing managers.

 TODO:

 I've tried to move the event coordinate transformation into
 FixUpEventFromWindow, which means making copies of events in a lot of
 places as FixUpEventFromWindow is sometimes called multiple times with
 the same xEvent. However, I never got that to work correctly and I
 haven't had time to figure out exactly why yet.

 The pointer grab code might need some more work but the patch should of
 course not affect non-transformed input in any way.

 I think that transformed input of non top-level windows isn't working
 correctly. This should be easy to fix though, I just need to write a
 good test app.

 -David

After playing with this patches I thought that maybe this interface could also 
be extended to some basic real input redirection. Instead of a mapping from 
the transformed coordinate space to the real window coordinate space, 
there could be an additional value, that tells the xserver to redirect and 
transform the input from the transformed coordinate space to another window 
coordinate space. With something like this we could realize something like 
cloned windows in different stack positions (using input only windows and 
the composite manager).

I think about somethink like this:
XCompositeSetTriangularCoordinateMesh(Display *dpy, Window source, Window 
destination, XTriangle *triangle, int ntriangle);

I don't know enough about the xserver internals to tell if something like this 
is possible, but I think that this could extend the range for possible 
effects. 

Dennis

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] status of input redirection

[Kristian Høgsberg]

On 5/31/07, David Reveman [EMAIL PROTECTED] wrote:
 On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
  There where some patches to implement input redirection in xorg a while
  ago...
  what happend to them? are they still beeing worked on?

 The attached patches work well. The server patch needs some more work if
 we want to allow different pickers and I haven't had time to do that
 yet.

Can we merge the server patch as is and punt on the pluggable picker
idea for now?  I mean, can we do this in a way that lets the
interested parties add this support in a second step without breaking
backwards compatibility?  If that's doable, I don't think we need to
block on the pluggable picker idea now.

cheers,
Kristian
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] status of input redirection

[David Reveman]

On Fri, 2007-06-01 at 13:28 -0400, Kristian Høgsberg wrote:
 On 5/31/07, David Reveman [EMAIL PROTECTED] wrote:
  On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
   There where some patches to implement input redirection in xorg a while
   ago...
   what happend to them? are they still beeing worked on?
 
  The attached patches work well. The server patch needs some more work if
  we want to allow different pickers and I haven't had time to do that
  yet.
 
 Can we merge the server patch as is and punt on the pluggable picker
 idea for now?  I mean, can we do this in a way that lets the
 interested parties add this support in a second step without breaking
 backwards compatibility?  If that's doable, I don't think we need to
 block on the pluggable picker idea now.

I've attached a new patch with a more appropriate change to
WriteEventsToClient.

I'm OK with merging the patch in it's current state. Pluggable pickers
can definitely be added later without breaking backwards compatibility.

There's a few things that needs to be improved but I think the current
patch is good enough for common use in compositing managers.

TODO:

I've tried to move the event coordinate transformation into
FixUpEventFromWindow, which means making copies of events in a lot of
places as FixUpEventFromWindow is sometimes called multiple times with
the same xEvent. However, I never got that to work correctly and I
haven't had time to figure out exactly why yet.

The pointer grab code might need some more work but the patch should of
course not affect non-transformed input in any way.

I think that transformed input of non top-level windows isn't working
correctly. This should be easy to fix though, I just need to write a
good test app.

-David
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -141,6 +141,7 @@ compRedirectWindow (ClientPtr pClient, WindowPtr pWin, int update)
 	cw-oldy = COMP_ORIGIN_INVALID;
 	cw-damageRegistered = FALSE;
 	cw-damaged = FALSE;
+	cw-pInputMesh = NULL;
 	pWin-devPrivates[CompWindowPrivateIndex].ptr = cw;
 }
 ccw-next = cw-clients;
--- a/composite/compext.c
+++ b/composite/compext.c
@@ -512,6 +512,45 @@ ProcCompositeReleaseOverlayWindow (ClientPtr client)
 return client-noClientException;
 }
 
+static int
+ProcCompositeSetTriangularCoordinateMesh (ClientPtr client)
+{
+CompWindowPtr cw;
+WindowPtr	  pWin;
+int		  n, status;
+
+REQUEST (xCompositeSetTriangularCoordinateMeshReq);
+REQUEST_AT_LEAST_SIZE (xCompositeSetTriangularCoordinateMeshReq);
+
+pWin = (WindowPtr) LookupIDByType (stuff-window, RT_WINDOW);
+if (!pWin || !pWin-parent)
+{
+	client-errorValue = stuff-window;
+	return BadWindow;
+}
+
+cw = GetCompWindow (pWin);
+if (!cw)
+{
+	client-errorValue = stuff-window;
+	return BadWindow;
+}
+
+n = (client-req_len  2) -
+	sizeof (xCompositeSetTriangularCoordinateMeshReq);
+if (n  (n % (sizeof (xTriangle) * 2)))
+	return BadLength;
+
+n /= sizeof (xTriangle);
+
+status = CompositeSetTriangularCoordinateMesh (client, pWin, n,
+		   (xTriangle *) stuff[1]);
+if (status)
+	return status;
+
+return client-noClientException;
+}
+
 int (*ProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 ProcCompositeQueryVersion,
 ProcCompositeRedirectWindow,
@@ -522,6 +561,7 @@ int (*ProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 ProcCompositeNameWindowPixmap,
 ProcCompositeGetOverlayWindow,
 ProcCompositeReleaseOverlayWindow,
+ProcCompositeSetTriangularCoordinateMesh
 };
 
 static int
@@ -646,6 +686,19 @@ SProcCompositeReleaseOverlayWindow (ClientPtr client)
 return (*ProcCompositeVector[stuff-compositeReqType]) (client);
 }
 
+int
+SProcCompositeSetTriangularCoordinateMesh (ClientPtr client)
+{
+int n;
+REQUEST(xCompositeSetTriangularCoordinateMeshReq);
+
+swaps (stuff-length, n);
+REQUEST_AT_LEAST_SIZE(xCompositeSetTriangularCoordinateMeshReq);
+swapl (stuff-window, n);
+SwapRestL (stuff);
+return (*ProcCompositeVector[stuff-compositeReqType]) (client);
+}
+
 int (*SProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 SProcCompositeQueryVersion,
 SProcCompositeRedirectWindow,
@@ -656,6 +709,7 @@ int (*SProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 SProcCompositeNameWindowPixmap,
 SProcCompositeGetOverlayWindow,
 SProcCompositeReleaseOverlayWindow,
+SProcCompositeSetTriangularCoordinateMesh
 };
 
 static int
--- a/composite/compint.h
+++ b/composite/compint.h
@@ -85,6 +85,21 @@ typedef struct _CompClientWindow {
 intupdate;
 }  CompClientWindowRec, *CompClientWindowPtr;
 
+typedef struct _CompTriangle {
+xTriangletri;
+xFixed_48_16 area;
+} CompTriangle;
+
+typedef struct _CompTriangleMap {
+CompTriangle parent;
+CompTriangle child;
+} CompTriangleMap;
+
+typedef struct _CompTriangularMesh {
+CompTriangleMap *map;
+int		nMap;
+} 

Re: [compiz] status of input redirection

[David Reveman]

On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
 There where some patches to implement input redirection in xorg a while 
 ago...
 what happend to them? are they still beeing worked on?

The attached patches work well. The server patch needs some more work if
we want to allow different pickers and I haven't had time to do that
yet.

-David
--- a/composite.h
+++ b/composite.h
@@ -63,8 +63,9 @@
 #define X_CompositeNameWindowPixmap		6
 #define X_CompositeGetOverlayWindow 7
 #define X_CompositeReleaseOverlayWindow 8
-#define X_CompositeRedirectCoordinate		9
-#define X_CompositeTransformCoordinate		10
+#define X_CompositeSetTriangularCoordinateMesh	9
+#define X_CompositeRedirectCoordinate		10
+#define X_CompositeTransformCoordinate		11
 
 #define CompositeNumberRequests	(X_CompositeTransformCoordinate + 1)
 
--- a/compositeproto.h
+++ b/compositeproto.h
@@ -192,6 +192,15 @@ typedef struct {
 CARD8   compositeReqType;
 CARD16  length;
 Window  window B32;
+} xCompositeSetTriangularCoordinateMeshReq;
+
+#define sz_xCompositeSetTriangularCoordinateMeshReq	8
+
+typedef struct {
+CARD8   reqType;
+CARD8   compositeReqType;
+CARD16  length;
+Window  window B32;
 BOOLredirect;
 BYTEunused1;
 CARD16  unused2 B16;
--- a/configure.ac
+++ b/configure.ac
@@ -24,7 +24,7 @@ dnl
 dnl Process this file with autoconf to create configure.
 
 AC_PREREQ([2.57])
-AC_INIT([CompositeProto], [0.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([CompositeProto], [0.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 
--- a/configure.ac
+++ b/configure.ac
@@ -34,7 +34,7 @@ dnl protocol, so Xcomposite version l.n.m corresponds to protocol version l.n
 dnl that 'revision' number appears in Xcomposite.h and has to be manually
 dnl synchronized.
 dnl
-AC_INIT(libXcomposite, 0.3.1, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXcomposite)
+AC_INIT(libXcomposite, 0.4.0, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXcomposite)
 AM_INIT_AUTOMAKE([dist-bzip2])
 AM_MAINTAINER_MODE
 
@@ -52,7 +52,7 @@ if test $VERSION =  ; then
 fi
 COMPOSITEEXT_VERSION=[`echo $VERSION | sed 's/^\([0-9][0-9]*\.[0-9][0-9]*\).*$/\1/'`]
 AC_SUBST(COMPOSITEEXT_VERSION)
-PKG_CHECK_MODULES(XCOMPOSITE, [compositeproto = $COMPOSITEEXT_VERSION] x11 xfixes xext fixesproto)
+PKG_CHECK_MODULES(XCOMPOSITE, [compositeproto = $COMPOSITEEXT_VERSION] x11 xfixes xext fixesproto xrender renderproto)
 AC_SUBST(XCOMPOSITE_CFLAGS)
 AC_SUBST(XCOMPOSITE_LIBS)
 
--- a/include/X11/extensions/Xcomposite.h
+++ b/include/X11/extensions/Xcomposite.h
@@ -47,6 +47,7 @@
 
 #include X11/extensions/composite.h
 #include X11/extensions/Xfixes.h
+#include X11/extensions/Xrender.h
 #include X11/Xfuncproto.h
 
 /*
@@ -92,6 +93,12 @@ XCompositeGetOverlayWindow (Display *dpy, Window window);
 void
 XCompositeReleaseOverlayWindow (Display *dpy, Window window);
 
+void
+XCompositeSetTriangularCoordinateMesh (Display		  *dpy,
+   Window		  window,
+   _Xconst XTriangle *triangle,
+   int		  nTriangle);
+
 _XFUNCPROTOEND
 
 #endif /* _XCOMPOSITE_H_ */
--- a/src/Xcomposite.c
+++ b/src/Xcomposite.c
@@ -391,3 +391,40 @@ XCompositeReleaseOverlayWindow (Display *dpy, Window window)
 UnlockDisplay (dpy);
 SyncHandle ();
 }
+
+void
+XCompositeSetTriangularCoordinateMesh (Display		  *dpy,
+   Window		  window,
+   _Xconst XTriangle *triangle,
+   int		  nTriangle)
+{
+XCompositeExtDisplayInfo *info = XCompositeFindDisplay (dpy);
+xCompositeSetTriangularCoordinateMeshReq *req;
+int	 n;
+long len;
+
+XCompositeSimpleCheckExtension (dpy, info);
+LockDisplay (dpy);
+while (nTriangle)
+{
+	GetReq (CompositeSetTriangularCoordinateMesh, req);
+	req-reqType = info-codes-major_opcode;
+	req-compositeReqType = X_CompositeSetTriangularCoordinateMesh;
+	req-window = window;
+	n = nTriangle;
+	len = ((long) n) * (SIZEOF (xTriangle)  2);
+	if (!dpy-bigreq_size  len  (dpy-max_request_size - req-length))
+	{
+	n = (dpy-max_request_size - req-length) /
+		(SIZEOF (xTriangle)  2);
+	len = ((long) n) * (SIZEOF (xTriangle)  2);
+	}
+	SetReqLen (req, len, len);
+	len = 2;
+	DataInt32 (dpy, (int *) triangle, len);
+	nTriangle -= n;
+	triangle  += n;
+}
+UnlockDisplay (dpy);
+SyncHandle ();
+}
--- a/src/xcompositeint.h
+++ b/src/xcompositeint.h
@@ -51,6 +51,7 @@
 #include X11/Xlib.h
 #include X11/Xlibint.h
 #include X11/Xutil.h
+#include X11/extensions/renderproto.h
 #include X11/extensions/compositeproto.h
 #include X11/extensions/Xcomposite.h
 
@@ -83,4 +84,16 @@ XCompositeFindDisplay (Display *dpy);
 #define XCompositeSimpleCheckExtension(dpy,i) \
   if (!XCompositeHasExtension(i)) { return; }
 
+/*
+ * Xlib uses long for 32-bit values.  Xcomposite uses int.  This
+ * matters on alpha.  Note that this macro assumes 

[compiz] status of input redirection

[dragoran]

There where some patches to implement input redirection in xorg a while 
ago...
what happend to them? are they still beeing worked on?
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz