Re: Ubuntu with DisplayLink
On Sun, Mar 7, 2010 at 1:52 PM, don donn...@gmail.com wrote: I found your forum online, and hope that you'll be able to help. I'm a life-long Windows user who just recently took the plunge and switched to Ubuntu 9.1 . All is fine except that I have been unable to get my Atlona HDPIX to work correctly with Displaylink drivers for Linux/Ubuntu 9.1. Congratulations on switching! I'm sorry to hear that it hasn't been the perfect experience every developer aspires to. I don't know anything about libdlo, but I wanted to let you know that you may have better luck asking this question elsewhere. I see that http://libdlo.freedesktop.org/wiki/ asks that support requests go to the libdlo mailing list (http://lists.freedesktop.org/mailman/listinfo/libdlo/). Although it probably isn't an Ubuntu-specific problem, you might find that people in Ubuntu forums are even better prepared to help you, so I'd suggest trying there as well. Good luck! Jamey ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xkeyboard-config: updated geometry description of model pc105
Mostly depends on language of keyboard. Yes, obviously. It makes sense to create separate keyboard layout. Some of such keyboards have backslash to the left of Backspace button, which is is square, not rectangular in this situation. OK, I counted the layouts depicted in the Wikipedia article I linked to in my first mail. regular 105 keys, fitting my patch: 26 layouts 105 keys with single-row Return key, fitting the geometry description currently in xkeyboard-config: 2 layouts (Dutch and Tibetan) 105 keys with BKSL left of Backspace: 0 layouts For completeness' sake: 104 keys, US style: 8 layouts 104 keys, BKSL left of Backspace: 6 layouts Note that 104 key models are not affected by my patch, as pc104 is a separate model anyway. (For details, see http://pastebin.ca/1827712 .) I'm fully aware that Wikipedia's list of layouts is probably neither complete nor completely accurate; but since I don't have a collection of international keyboards in my basement and don't know any more complete or more accurate listing, it's the best source of data I have available. 26 to 2 is what I consider a large enough majority to change the default geometry description. Regards, Jakob ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xkeyboard-config: updated geometry description of model pc105
I possess Russian 104-key keyboards with all the variants discussed: As I said, 104 key keyboards are not affected by changes to the pc105 model. Given this experience layouts in wikipedia article look random for me (especially 105 vs. 104 when 105th key is just / keys). The 105th key is the one to the right of the left Shift key. The symbol printed on it (or typed when you press the key, for that matter) is irrelevant; the geometry description is only about the physical shape and position of the keys. I know from personal experience that usually French, German, Spanish, Swiss and UK keyboards have 105 keys with a tall Return key (as in the Wiki article). Did you count frequency of each keyboard? I bet US keyboards are much more common than the Albanian or Turkish. US keyboards have 104 keys. Again, they are not affected. And wrt frequency: Yes, I do believe that the 26 105 / tall layouts summed up are used far more frequently than the 2 105 / single-row layouts. Also, let me emphasize the fact that normal usage of the keyboard is in no way affected by the geometry description anyway. It is only relevant for applications that generate and draw images of the keyboard. Regards, Jakob ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Improving VT switching with KMS
- Eric Anholt e...@anholt.net wrote: Beyond master setting, there's nothing left in my Enter/LeaveVT. Hide cursors on Leave, set video mode on Enter. There are two other function calls left in there, but I don't think they particularly deserve to live. Is your VT switching code going to handle resetting my modes correctly? I don't think that's the case today. The signals which are sent on VT switch are still there, so stuff can still be executed on VT switch. The question is whether that stuff has to be executed at a particular time or not. It seems clear that the master stuff DOES have to be executed at exactly the right time. But what about the other stuff? In particular, would it matter if the other stuff in the LeaveVT callback of a frozen server were not executed when switching away from that server? Ari ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Regarding how to use MPX in case of xoo device
Hello all, I am an undergraduate student of final year engineering.I have configured X server with Multi-pointer support(MPX) on my machine with Ubuntu 8.10 as a part of my final year project.In that I want to use MPX in xoo. I tried to set path for X server in preferences as /opt/mpx/bin/Xnest (as I have configured MPX in /opt directory) but it didn't work.So please can anybody suggest where I am doing mistake if any and how to use MPX in xoo device's display? Thanks in advance . Amey. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: fixup handling of last_swap_target
On Sun, 7 Mar 2010 21:16:21 +0100 Florian Mickler flor...@mickler.org wrote: On Sun, 7 Mar 2010 09:10:51 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Sun, 7 Mar 2010 08:44:51 +0100 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: Yeah, this could also happen without OML I think, if a few swaps were queued (resulting in a block) and then a SGI_video_sync call occurred. I'll fix it up. Thanks, could this also happen with a single glxgears instance and no other 3d clients running? I don't *think* glxgears does this; it's been running fine for me at least. But you could definitely be hitting one of the MSC races; you can add some debug output to I830DRI2ScheduleSwap in src/i830_dri.c in the DDX driver to see what's going on. Presumably one of the paths there is putting the client to sleep and never waking it. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: fixup handling of last_swap_target
On Mar 8, 2010, at 6:07 PM, Jesse Barnes wrote: On Sun, 7 Mar 2010 21:16:21 +0100 Florian Mickler flor...@mickler.org wrote: On Sun, 7 Mar 2010 09:10:51 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Sun, 7 Mar 2010 08:44:51 +0100 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: Yeah, this could also happen without OML I think, if a few swaps were queued (resulting in a block) and then a SGI_video_sync call occurred. I'll fix it up. Thanks, could this also happen with a single glxgears instance and no other 3d clients running? I don't *think* glxgears does this; it's been running fine for me at least. But you could definitely be hitting one of the MSC races; you can add some debug output to I830DRI2ScheduleSwap in src/i830_dri.c in the DDX driver to see what's going on. Presumably one of the paths there is putting the client to sleep and never waking it. The glxgears.c of mesa only does draw - glXSwapBuffers - draw - glXSwapBuffers - ... It doesn't use any of the new api's, so the only way it can block is probably via the DRI2ThrottleClient call when requesting a new backbuffer. I see at least one problematic thing. In the xserver's dri2.c file in DRI2SwapBuffers(), the pPriv-swapsPending++ statement is *after* the call into the ddx's I830DRI2ScheduleSwap() function, instead of *before* it. If a swap completes inside the ddx, it will call DRI2SwapComplete() which will do a pPriv-swapsPending-- before it was incremented to mark a swap as pending. That is, if swapsPending was zero before, it will now wrap around to 0x. This will happen if the fallback_blit path inside the ddx is used, e.g., if the drawable is not visible (yet). Not sure if this by itself is sufficient for the hang, because the call to pPriv-swapsPending++ after return from I830DRI2ScheduleSwap () should fix this, but if something else goes wrong and an error path is taken or an event not delivered, then swapsPending could get stuck at 0x or a similar high number, which would trigger DRI2ThrottleClient and block the client connection without ever waking it up again, as clients are only woken up if a swap completes, which can't happen if no swap is pending. - hang in _XReply on the client side. So we should probable move pPriv-swapsPending++ before the call to... ret = (*ds-ScheduleSwap)(client, pDraw, pDestBuffer, pSrcBuffer, swap_target, divisor, remainder, func, data); ... in DRI2SwapBuffers() and probably add a pPriv-swapsPending-- into the error handling path directly after the call to ds- ScheduleSwap. -mario ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: fixup handling of last_swap_target
On Mon, 8 Mar 2010 20:13:21 +0100 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: The glxgears.c of mesa only does draw - glXSwapBuffers - draw - glXSwapBuffers - ... It doesn't use any of the new api's, so the only way it can block is probably via the DRI2ThrottleClient call when requesting a new backbuffer. I see at least one problematic thing. In the xserver's dri2.c file in DRI2SwapBuffers(), the pPriv-swapsPending++ statement is *after* the call into the ddx's I830DRI2ScheduleSwap() function, instead of *before* it. If a swap completes inside the ddx, it will call DRI2SwapComplete() which will do a pPriv-swapsPending-- before it was incremented to mark a swap as pending. That is, if swapsPending was zero before, it will now wrap around to 0x. This will happen if the fallback_blit path inside the ddx is used, e.g., if the drawable is not visible (yet). Or if composited; it may be offscreen. Not sure if this by itself is sufficient for the hang, because the call to pPriv-swapsPending++ after return from I830DRI2ScheduleSwap () should fix this, but if something else goes wrong and an error path is taken or an event not delivered, then swapsPending could get stuck at 0x or a similar high number, which would trigger DRI2ThrottleClient and block the client connection without ever waking it up again, as clients are only woken up if a swap completes, which can't happen if no swap is pending. - hang in _XReply on the client side. So we should probable move pPriv-swapsPending++ before the call to... ret = (*ds-ScheduleSwap)(client, pDraw, pDestBuffer, pSrcBuffer, swap_target, divisor, remainder, func, data); ... in DRI2SwapBuffers() and probably add a pPriv-swapsPending-- into the error handling path directly after the call to ds- ScheduleSwap. Yep, that's the safer thing to do. Florian, can you give that a try and see if it helps your situation? Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-intel 2/2] Fix handling of target_msc, divisor, remainder in I830DRI2ScheduleSwap()
On Mon, 8 Mar 2010 01:23:11 +0100 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: On Mar 7, 2010, at 6:18 PM, Jesse Barnes wrote: Arg, I did botch that patch. And of course I only tested the swap buffers behavior and not OML's WaitMSC so I didn't catch it. I'll improve the test and push the fix. No problem. Just fyi: I noticed you added a test in I830DRI2ScheduleSwap() that outputs X_Warnings if a swap is scheduled more than 100 vblanks ahead. At least for the users of my toolkit, scheduling a swap more than 100 vblanks ahead wouldn't be something noteworthy but quite a typical case of normal use of the system. At the end of a work day some users would probably find ten thousands of such warnings in some log, assuming those warnings get logged at the normal log level. So this usage case is less weird than one would think :-) Ok just pushed these fixes; omlsync seems to do the right thing now with both waits and swaps. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Minor bug-fixes discovered by static analysis.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Hutterer wrote: fwiw, I find it a lot easier to review patches that land on the mailing list than a pull request where I have to go off, pull into my tree, review and then copy/paste segments from the patch to be able to add comments. it also makes it harder to track when something has changed, since a tree doesn't usually contain the Patch v3 part of it. Right. I was under the impression that pull requests were for code that had been reviewed and was ready to go. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuVYckACgkQX1gOwKyEAw+6AQCdHuNxNFe3oqD/fwomEF778pXF SfoAn1EeOI6X1fMayB2tOW8XyEQd5PYy =nh7y -END PGP SIGNATURE- ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-intel 2/2] Fix handling of target_msc, divisor, remainder in I830DRI2ScheduleSwap()
On Mar 8, 2010, at 8:34 PM, Jesse Barnes wrote:
Ok just pushed these fixes; omlsync seems to do the right thing now
with both waits and swaps.
Sorry to torture you further, almost there ;-) -- the devil is in the
details.
In I830DRI2ScheduleWaitMSC():
At the end, in this if statement...
if ((current_msc % divisor) remainder)
vbl.request.sequence += divisor;
... the comparison should be = instead of , that is:
if ((current_msc % divisor) = remainder)
I reread the spec and realized the true meaning of this little
snippet ...Otherwise, the function will block until the MSC value is
incremented to a value such that MSC % divisor = remainder...
It doesn't say until the msc *is* such that msc % divisor =
remainder, but it says until the *msc is **incremented** to a
value*. That means they don't want it to return immediately if the
current msc already satisfies the constraint, but they want it to
return basically at the start of the vblank interval when the msc
reaches a value that satisfies the constraint. The idea is to
synchronize the client's execution to the vblank interval. If a
client just wants to wait for a certain msc without precise sync to
the vblank interval, it can simply pass a divisor==0 and then will
get that behaviour.
Changing the comparison from a to a = above achieves that goal.
This makes lots of sense if i think about how i would actually use
that function in my toolkit or similar apps. I'd mostly want it to
synchronize to the exact *start* of certain video refesh cycles.
Then we should add this check to the if(divisor == 0 || current_msc
target_msc) { } branch:
if (current_msc = target_msc)
target_msc = current_msc;
This is similar to the check in I830DRI2ScheduleSwap. It guarantees
that the target_msc can't fall behind the current_msc. This is
important for all scheduled vblank events because the DRM will do the
wrong thing if the requested vblank count is more than 2^23 counts
behind the current vblank count. Events would get stuck forever if
this happened due to a 32 bit wraparound, not good.
What else? I rethought the idea of virtualizing the msc into a 64 bit
value from the 32 count of the kernel. It is a bit more tricky than
one would expect, so probably not a quick thing do to correctly - and
not a thing to do now.
But we could add some simple masking to the very top of
I830DRI2ScheduleSwap() and I830DRI2ScheduleWaitMSC() to truncate all
msc related input values from the server to 32 bits, ie.
in I830DRI2ScheduleWaitMSC()
target_msc = 0x;
divisor = 0x;
remainder = 0x;
in I830DRI2ScheduleSwap()
*target_msc = 0x;
divisor = 0x;
remainder = 0x;
At least the few simple cases my brain can handle with paper
pencil testing seem to do the right thing if a 32 bit vblank counter
wraparound happens. At worst, there would be a small glitch every
time the counter wraps around - about once every 4-12 months.
Inbetween everything should work. I doubt that an app will regularly
schedule swaps or waits multiple months ahead of time and still
expect it to work perfectly ;-).
Finally in I830DRI2ScheduleWaitMSC() the error handling is a bit
inconsistent. Sometimes it returns failure to calling code, which
would provoke a client hang due to a missing _XReply, sometimes it
recovers and unstucks the client by providing a fake response.
Similar to the blit_fallback: path in I830DRI2ScheduleSwap() you
could maybe have a common error handler that at least calls
DRI2WaitMSCComplete(client, draw, 0, 0, 0); to prevent the client
from hanging?
Ok, i'm hopefully running out of more ideas for now ;-)
-mario
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] xorg-server 1.7.5.901
On 03/05/2010 11:45 AM, Dan Nicholson wrote:
On Fri, Mar 5, 2010 at 8:15 AM, Alan Coopersmith
alan.coopersm...@sun.com wrote:
Dan Nicholson wrote:
Is X at least linked to the right libraries? If not, then I think what
we need to do is add them Xext/libXextmodule.la. Something like the
attached patch should work, but I'm not sure it's the right thing.
I can confirm that libXext should be the only place that references
libselinux symbols.
I modified the patch to use _LIBADD instead of _LIBS (based on
Alan's example) and to remove SELINUX_LIBS from XSERVER_SYS_LIBS because
that should not be necessary with this fix.
Please review...hopefully this finally fixes the issues.
--
Eamon Walsh
National Security Agency
From f1a3ef1976e9a690c8d6f8858e96cfee0bbb8914 Mon Sep 17 00:00:00 2001
From: Eamon Walsh ewa...@tycho.nsa.gov
Date: Mon, 8 Mar 2010 16:33:37 -0500
Subject: [PATCH] Xext: Link to external libraries when necessary.
Although the DDX should be linked to the necessary libraries, we may
also need to pull them in directly to the module to ensure the symbols
are resolved at runtime. Should fix this bug with XSELINUX:
/usr/bin/X: symbol lookup error:
/usr/lib64/xorg/modules/extensions/libextmod.so: undefined symbol:
is_selinux_enabled
-v2: use _LIBADD instead of _LIBS; remove SELINUX_LIBS from
XSERVER_SYS_LIBS as it should only be needed in extmod.
Signed-off-by: Dan Nicholson dbn.li...@gmail.com
Signed-off-by: Eamon Walsh ewa...@tycho.nsa.gov
---
Xext/Makefile.am |4
configure.ac |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Xext/Makefile.am b/Xext/Makefile.am
index 7287c4a..193d6e5 100644
--- a/Xext/Makefile.am
+++ b/Xext/Makefile.am
@@ -32,6 +32,7 @@ BUILTIN_SRCS = \
# Sources always included in libXextmodule.la libXext.la. That's right, zero.
MODULE_SRCS =
+MODULE_LIBS =
# Optional sources included if extension enabled by configure.ac rules
@@ -83,6 +84,7 @@ endif
XSELINUX_SRCS = xselinux_ext.c xselinux_hooks.c xselinux_label.c xselinux.h xselinuxint.h
if XSELINUX
MODULE_SRCS += $(XSELINUX_SRCS)
+MODULE_LIBS += $(SELINUX_LIBS)
endif
# Security extension: multi-level security to protect clients from each other
@@ -119,11 +121,13 @@ endif
# Now take all of the above, mix well, bake for 10 minutes and get libXext*.la
libXext_la_SOURCES = $(BUILTIN_SRCS) $(MODULE_SRCS)
+libXext_la_LIBADD = $(MODULE_LIBS)
if XORG
libXextbuiltin_la_SOURCES = $(BUILTIN_SRCS)
libXextmodule_la_SOURCES = $(MODULE_SRCS)
+libXextmodule_la_LIBADD = $(MODULE_LIBS)
endif
EXTRA_DIST = \
diff --git a/configure.ac b/configure.ac
index 0579551..3e8ea10 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1432,7 +1432,7 @@ PKG_CHECK_MODULES([XSERVERLIBS], [$REQUIRED_LIBS])
#
XSERVER_CFLAGS=${XSERVER_CFLAGS} ${XSERVERCFLAGS_CFLAGS}
XSERVER_LIBS=$DIX_LIB $CONFIG_LIB $MI_LIB $OS_LIB
-XSERVER_SYS_LIBS=${XSERVERLIBS_LIBS} ${SYS_LIBS} ${LIBS} ${SELINUX_LIBS}
+XSERVER_SYS_LIBS=${XSERVERLIBS_LIBS} ${SYS_LIBS} ${LIBS}
AC_SUBST([XSERVER_LIBS])
AC_SUBST([XSERVER_SYS_LIBS])
--
1.7.0
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xfree86: don't warn about nonexisting core pointer/keyboard in config.
In the vast majority of cases there is no xorg.conf that specifies a core
pointer/keyboard. Skip this warning, since we'll get another notification
about how the server relies on the config backend for input devices anyway.
Leave the warning in for the error case (AEI off).
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
hw/xfree86/common/xf86Config.c | 24
1 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 6fbf613..6987bcc 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -1269,14 +1269,10 @@ checkCoreInputDevices(serverLayoutPtr servlayoutp, Bool
implicitLayout)
}
}
-if (!foundPointer) {
- if (!xf86Info.allowEmptyInput) {
- /* This shouldn't happen. */
- xf86Msg(X_ERROR, Cannot locate a core pointer device.\n);
- return FALSE;
- } else {
- xf86Msg(X_INFO, Cannot locate a core pointer device.\n);
- }
+if (!foundPointer !xf86Info.allowEmptyInput) {
+ /* This shouldn't happen. */
+ xf86Msg(X_ERROR, Cannot locate a core pointer device.\n);
+ return FALSE;
}
/*
@@ -1413,14 +1409,10 @@ checkCoreInputDevices(serverLayoutPtr servlayoutp, Bool
implicitLayout)
}
}
-if (!foundKeyboard) {
- if (!xf86Info.allowEmptyInput) {
- /* This shouldn't happen. */
- xf86Msg(X_ERROR, Cannot locate a core keyboard device.\n);
- return FALSE;
- } else {
- xf86Msg(X_INFO, Cannot locate a core keyboard device.\n);
- }
+if (!foundKeyboard !xf86Info.allowEmptyInput) {
+ /* This shouldn't happen. */
+ xf86Msg(X_ERROR, Cannot locate a core keyboard device.\n);
+ return FALSE;
}
if (pointerMsg) {
--
1.6.6.1
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: Use DeliverGrabbedEvent for implicit passive grabs (#25400)
On Sat, Mar 06, 2010 at 08:51:25PM +0100, Florian Mickler wrote: On Mon, 1 Mar 2010 11:51:31 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Feb 24, 2010 at 08:04:57PM -0800, Keith Packard wrote: On Thu, 25 Feb 2010 12:49:21 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: Bonus point - CheckPassiveGrabsOnWindows suddenly becomes a lot lesss complicated. Yeah, and makes it far more obvious that it's following the spec. Keith, I'll leave that in your court, please apply to master as you see fit, I won't include it in my pull requests to avoid duplication. This looks pretty good; I'll review it with the protocol spec, but I'd like to also know if you happen to have run the test suite over the new code? no, not yet. I'm still battling with the test suite on my virtual machines and on an older box. once I have a suitable installation, I'll likely post the xtest logs but at this point I cannot offer this yet. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel this regresses my desktop. fluxbox is not able to move the windows around anymore. also popup of context-menue does not work. (well sometimes it does, but then the fluxbox-keyboard-shortcuts do not work) a revert on top of current master fixes it. thanks. I've reverted it on the nominations branch until we've narrowed down what the cause of it is. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] xorg-server 1.7.5.901
0001-Xext-Link-to-external-libraries-when-necessary.patch Description: application/mbox ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCHv10 4/5] dri2: Support the DRI2InvalidateBuffers event.
On Fri, Mar 05, 2010 at 12:47:31PM +0100, Francisco Jerez wrote:
Peter Hutterer peter.hutte...@who-t.net writes:
[...]
+static void
+DRI2ConfigNotify(WindowPtr pWin, int x, int y, int w, int h, int bw,
+ WindowPtr pSib)
+{
+DrawablePtr pDraw = (DrawablePtr)pWin;
+ScreenPtr pScreen = pDraw-pScreen;
+DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
+DRI2DrawablePtr dd = DRI2GetDrawable(pDraw);
+
+if (ds-ConfigNotify) {
+ UNWRAP(pScreen, ds, ConfigNotify);
+ (*pScreen-ConfigNotify)(pWin, x, y, w, h, bw, pSib);
+ WRAP(pScreen, ds, ConfigNotify, DRI2ConfigNotify);
+}
I don't think this is correct just yet. You're always forcing
DRI2ConfigNotify back after the wrap. What you should be doing though is
popping back whatever was there before. Otherwise, having a different
nesting order will screw up the wrapping code.
See 664ac92d8bbe956dd6fd80fac5dc3161028803b2 for a case where this has
bitten us once already. this may not be possible with the current code, but
better be safe than sorry.
I thought the whole point of this unwrap-call-and-rewrap model was that
each link in the chain can safely assume that it'll be at the top of the
stack whenever it's called.
I thought the point of the wrapping is that when the code is called, the
struct is restored to whatever it was for this particular layer that's to be
called next. that is sort-of the same as what you say, except that (as you
point out) if you have cross-callers interesting things happen.
If we cannot rely on this assumption anyway, could you explain me how
the change you're proposing is better than a plain:
+if (ds-ConfigNotify)
+ (*ds-ConfigNotify)(pWin, x, y, w, h, bw, pSib);
+
if you call into ds-ConfigNotify without wrapping the screen you can be
exposed to a loop. if anyone in the next layer calls pScreen-ConfigNotify,
you now jump up a layer and loop around again (?)
anyway, I've just checked the cursor rendering code in misprite.c and that
also hardcodes the wrapping part. so I guess you're right - you'll be ok if
you avoid the cross calls without the chain.
Cheers,
Peter
IIUC, the roots of the problem fixed by 664ac92d8 were functions like
ProcXFixesHideCursor that were calling CursorDisplayCursor directly
instead of invoking the whole chain.
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
