Re: [compiz] status of input redirection
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 {
+CompTriangl
Re: [compiz] Matrox G450 and other matrox chips - do they work with compiz?
On Thu, 2007-05-31 at 13:18 +0200, Valent Turkovic wrote: > Hi, > can you please tell me if Matrox cards/chips have support for compiz, > or vice versa; does compiz support Matrox chips/cards? I think that most matrox cards are missing support for some kind of non-power-of-two textures, which is something that compiz requires. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] window walking interface
I had a look at the interface that allows plugins to affect the stacking of windows during rendering. Just adding first, next, prev, etc. function pointers that can be wrapped didn't seem very appropriate as it doesn't make sense to allow plugins to just wrap some of those functions and the overhead from going through the whole wrapping chain every time next or prev is called is unnecessary. I've added a simple window walking interface that should be sufficient. It should be easy to tell how it works from the changes to screen.c and paint.c. We still have to do something about the clip planes, right? I guess a wrap-able setOutputClipPlanes function will do for now. I'll make this change next unless you've got a better idea. It should be fairly easy to properly integrate any 3D window elevation, translucent cube and sticky window mode now that plugins can hook into the cube plugins structures. Just add whatever hooks you need to the cube plugin. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Matrox G450 and other matrox chips - do they work with compiz?
On 5/31/07, Valent Turkovic <[EMAIL PROTECTED]> wrote: > Hi, > can you please tell me if Matrox cards/chips have support for compiz, > or vice versa; does compiz support Matrox chips/cards? > > Thank you > > Valent. Did anybody try making it work on Matrox cards? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] status of input redirection
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] [PATCH] add 'sticky' mode to cube to allow sticky+not-on-bottom windows to stick to the screen when the screen is transformed
On Fri, 2007-06-01 at 08:22 +0800, Sam Spilsbury wrote: > Does this mean that cube zoom will be implimented? > I remember a while back it was implimented using switchers zoom > functionality, probably not implimented the right way. > > 3D still requires PAINT_WINDOW_FRONT_TO_BACK_MASK to work properly > however. Is there a chance that anyone can get this and transcube > fixed up? PAINT_WINDOW_FRONT_TO_BACK_MASK is not going to be added but I definitely like to see both the window elevation and translucent cube functionality supported sometime soon. It should be a lot easier to get this working properly now that the cube plugin can export any hooks we find useful. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Zoom plugin changes
On 5/31/07, Mike Dransfield <[EMAIL PROTECTED]> wrote: > Kristian Lyngstøl wrote: > > I posted a few weeks ago that I was going to be working on zoom over > > the summer to improve the accessibility, and I have already begun to > > do that. Every step of the way I have made frequent commits to > > opencompositing.org and described the progress in my blog. > > > > I asked for information about what your (David) plans was, you thanked > > me for informing me on what I was going to work on and said you'd get > > back to me. You never did. > > > > Now today you commit "11fe37b7673b15e5cbd4be21759311087d9d8694" which > > introduce major changes to the zoom plugin. You did NOT give a heads > > up on this, even though you should have known I was working on this. > > > > To be fair he did mention that he was going to add > this functionality months ago, it was also demonstrated > at brainshare recently (before your initial email). > > Also your email (from what I understand) just related to > orca integration and input redirection, it didn't seem to have > anything to do with todays changes. I asked for an explanation of the features David wanted. He said he would get back to me. He didn't. Then he drops a big diff. My work will use at-spi but there were other important things to consider too. The diff is pretty much a total rewrite of the original which I have based my work on. > Also from what I understand, you have forked zoom.c which > lost all the git history? If this is the case then you should > have branched it so that these changes would be merged. I > dont think they impact your changes, do they? My point here is twofold: 1. I informed that I would work on zoom and requested information on it. David confirmed, and posted that he would get back to me. 2. Our users now have to choose between two different feature sets. As for if it should be a branch or not; maybe so. I'll have no problems re-playing my diffs to retain the history. I'm prepared to do that extra work, as it's my own folly for not keeping the history. This is sort of beside the point here. > > When you are going to make changes and people have already told you > > they are working on that code, you have to actually communicate with > > them, not drop a 1k diff on them. It's not just your time that matters > > here, but ours too. This is not how people are supposed to co-operate. > > > > And also, when you write something, you have to document it. > > > > The question of documentation was discussed very recently > (and before that too). > > Davids position is that HE is not prepared to spend a lot of time > documenting things because there is a good chance his > efforts will be wasted if the code changes, personally I'd rather > he spent time coding rather than documenting. Someone else > could document things. It takes little to no time to document your own code, but it takes a lot of time to document someone else's code. It is the individual developers responsibility to document their OWN code. This helps the community at large because if you spend 1% of your time documenting, the time save in the other end is huge. By not documenting the code, it forces other people to reverse engineer his code when they want to work on it. A few comments on each function is the difference between using 15 minutes to understand the code, and an HOUR and 15 minutes. And then you multiply by the number of readers. > That does not stop anyone from submitting patches to document > certain functions which might not be clear. I did exactly that a > few weeks ago. Should not be necessary. It does not take a lot of time to document your own code, and it is a sign of a good programmer. I know projects that will just say "sorry, try again." if you attempt to submit undocumented code. Not documenting your code is two things, whether that is the intent or not: - Lazy. - A slap in the face of the other developers. > > A few lines for each function, explaining what it does. You don't have > > to explain how or why, just WHAT. This is a common practice that I > > should NOT have to explain to an experience developer. > > > > Its not common developer practice to document each > function. Most people do not seem to have much problem > understanding whats what, and David is always prepared > to answer questions. The documentation is by example at > the moment, I have 3 example plugins, the helloworld one > is documented as well as I can, and I try to keep it up to > date. ... Your help plugins are a great help for new Compiz developers and all though I have not used your work on them myself (By the time you wrote them, I didn't need them), I am grateful for the work you've put into them. However, this doesn't void the need for documenting the rest of the code. And it does not help me at all. And I doubt most people know up from down in half of the code David has written. Sure, you can read the individual parts, but to trace the flow of the code, to know
Re: [compiz] Extensible logging framework
David Reveman wrote: > On Thu, 2007-05-24 at 19:40 +0100, Mike Dransfield wrote: > >> Attached is a quick patch which adds a logging framework to compiz. >> I think it should be fairly self explanitory. >> >> I think it should allow plugin writers to extend it for any purpose, but >> I would appreciate any feedback or comments before going any further. >> > > Looks good to me. Feel free to commit it if there's no objections. > OK - Thats in, I can tweak it if needs be but I think is good in its simple state. I have put the notification plugin into git here. git://people.freedesktop.org/~mike/notification If you use notification-daemon>=0.3.7 (and libnotify>=0.4.4) then you will see nice slightly transparent popups. > -David > > ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] run compiz error: No GLXFBConfig for default depth
What is your default depth? AFAIR, XGL only works on 24 bit and sometimes 32 bit colour On 6/1/07, Zhu, Jack <[EMAIL PROTECTED]> wrote: > > > > > Compile compiz and run it on MID, met the following error, who can give me > some suggestion? > > > > compiz: No GLXFBConfig for default depth, this isn't going to work. > > compiz: Failed to manage screen: 0 > > compiz: No manageable screens found on display 0:0 > > > ___ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz > > ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] run compiz error: No GLXFBConfig for default depth
Compile compiz and run it on MID, met the following error, who can give me some suggestion? compiz: No GLXFBConfig for default depth, this isn't going to work. compiz: Failed to manage screen: 0 compiz: No manageable screens found on display 0:0 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Fix imageBufferToTexture for MSBFirst platforms.
On Thu, 2007-05-31 at 13:38 -0400, David Reveman wrote: > On Wed, 2007-05-23 at 15:37 +0200, Michel Dänzer wrote: > > Fixes icon colours on my PowerBook. > > > > Given that the preprocessor test was reversed when the code was reorganized > > and > > nobody on !MSBFirst platforms complained, one code path should suffice. > > Hm, I'm not sure what's going on here. I fixed the mistake from the > reorganization. Thanks. > If byte order doesn't actually matter for the icon data > then I think the iconToTexture function should be changed to reflect > that and not imageBufferToTexture. BTW, I failed to mention (or hadn't noticed yet) that other textures such as the cube top image are affected in the same way. Does that change the situation? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
