State of Zaphod dual screen support

[Aaron Plattner]

On Mon, Mar 08, 2010 at 08:38:04AM -0800, David Mohr wrote:
> On Wed, Mar 3, 2010 at 1:24 PM, Aaron Plattner <aplattner at nvidia.com> wrote:
> > On Tue, 2010-03-02 at 22:24 -0800, David Mohr wrote:
> >> On Mon, Mar 1, 2010 at 6:07 PM, David Mohr <damailings at mcbf.net> wrote:
> >> > On Mon, Mar 1, 2010 at 3:38 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> >> >> On Mon, Mar 01, 2010 at 12:41:02AM -0700, David Mohr wrote:
> >> >>> On Sun, Feb 28, 2010 at 11:37 PM, Peter Hutterer
> >> >>> <peter.hutterer at who-t.net> wrote:
> >> >>> > On Sun, Feb 28, 2010 at 11:29:12PM -0700, David Mohr wrote:
> >> >>> >> I'm part of the minory who currently uses a Zaphod style dual monitor
> >> >>> >> setup with separate X screens for every monitor. When I recently
> >> >>> >> upgraded from 7.4 to 7.5, some utilites which I adopted[1] which
> >> >>> >> manipulate the mouse cursor started malfunctioning. My two X screens
> >> >>> >> are setup to be "apart" so that the mouse does not pass between them,
> >> >>> >> and I use my utilities to move the mouse between the two screens. But
> >> >>> >> with 7.5 every now and then a condition is triggered where the mouse
> >> >>> >> cursor will just continually jump from screen to screen, keeping the X
> >> >>> >> server at 100% CPU. I cannot even shut it down using
> >> >>> >> CTRL-ALT-Backspace.
> >> >>> >>
> >> >>> >> I've noticed comments in other threads on this mailing list that
> >> >>> >> Zaphod mode is not really supported any more (for completeness' sake,
> >> >>> >> I'm using the binary Nvidia drivers). So my question is, is there
> >> >>> >> value in trying to track down the bug in Xorg which causes the mouse
> >> >>> >> to jump back and forth?
> >> >>> >
> >> >>> > yes. I've seen this myself and I have not yet identified the issue. it's a
> >> >>> > server bug and unrelated to the binary driver. If you can help track this
> >> >>> > issue down, it would be much appreciated.
> >> >>>
> >> >>> Ok. Unfortunately I have not been able to find reliable conditions for
> >> >>> triggering the bug. I'll try again and see what I can find.
> >> >>
> >> >> i found using a wacom tablet with a xinerama setup and then switch back and
> >> >> forth triggers it eventually. the problem is the "eventually" bit...
> >> >
> >> > Yes, it's similar for me. One of the tools I use switches the mouse
> >> > over when it hits the edge of the screen, so it's warping the pointer
> >> > relatively often. I can't reproduce the problem reliably, but if I
> >> > keep going back and forth it doesn't take very long to trigger it.
> >> >
> >> >>> Is there any way to get good information out of the running X instance
> >> >>> once the bug has been triggered? I can only think of sending a signal
> >> >>> to get a core dump, but then I'm not sure how much useful information
> >> >>> that would contain.
> >> >>
> >> >> once it happens, gdb in and single-stepping may be the only approach. a
> >> >> backtrace would be great already, just to make sure if you're seeing the
> >> >> same problem as I am.
> >> >
> >> > Ugh. Here the trouble begins. When I attach to the process with gdb,
> >> > it tells me it's in nvidia_drv.so, which of course doesn't have
> >> > debugging symbols. So I can't get a useful backtrace or start to
> >> > single step.
> >>
> >> I tried it a second time and again was only able to break in
> >> nvidia_drv.so. I'm wondering if I installed all the right debugging
> >> packages. I use debian, so I installed xserver-xorg-core-dbg. Is that
> >> sufficient?
> >>
> >> I don't have much experience with how gdb behaves if there are no
> >> debugging symbols available in _part_ of the program. Could it be that
> >> I can inspect the X server by setting a breakpoint somewhere and then
> >> continuing?
> >> If so, what would be a good place to put a breakpoint (I have no clue
> >> about X internals)?
> >
> > Since the cursor is actively changing, you could try putting a
> > breakpoint on xf86SetCursor.
> 
> Thanks Aaron, the xf86SetCursor suggestion worked out. Unfortunately I
> must admit I'm not sure how to proceed, since the execution path
> constantly leads into the closed nvidia_drv module... Here is an
> excerpt from my gdb session, maybe this is some help for Peter to
> decide whether it's the same bug or not.
> 
> (gdb) break xf86SetCursor
> Breakpoint 1 at 0x8185b64: file
> ../../../../hw/xfree86/ramdac/xf86HWCurs.c, line 115.
> (gdb) cont
> Continuing.
> 
> Breakpoint 1, xf86SetCursor (pScreen=0x925a730, pCurs=0x0, x=0, y=0)
>     at ../../../../hw/xfree86/ramdac/xf86HWCurs.c:115
> 115     {
> (gdb) n
> 116         xf86CursorScreenPtr ScreenPriv =
> (xf86CursorScreenPtr)dixLookupPrivate(
> (gdb) n
> 121         if (pCurs == NullCursor) {
> (gdb)
> 116         xf86CursorScreenPtr ScreenPriv =
> (xf86CursorScreenPtr)dixLookupPrivate(
> (gdb)
> 118         xf86CursorInfoPtr infoPtr = ScreenPriv->CursorInfoPtr;
> (gdb)
> 121         if (pCurs == NullCursor) {
> (gdb)
> 122             (*infoPtr->HideCursor)(infoPtr->pScrn);
> (gdb)
> 0xb5ffb8f0 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so
> (gdb) n
> Cannot find bounds of current function
> (gdb) cont
> Continuing.
> 
> Breakpoint 1, xf86SetCursor (pScreen=0x922ba58, pCurs=0x9653e38, x=7, y=409)
>     at ../../../../hw/xfree86/ramdac/xf86HWCurs.c:115
> 115     {
> (gdb) break xf86HWCurs.c:123
> Breakpoint 2 at 0x8185b90: file
> ../../../../hw/xfree86/ramdac/xf86HWCurs.c, line 123.
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, xf86SetCursor (pScreen=0x922ba58, pCurs=0x9653e38, x=7, y=409)
>     at ../../../../hw/xfree86/ramdac/xf86HWCurs.c:126
> 126         bits = dixLookupPrivate(&pCurs->devPrivates,
> CursorScreenKey(pScreen));
> (gdb) n
> 128         x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX;
> (gdb) n
> 126         bits = dixLookupPrivate(&pCurs->devPrivates,
> CursorScreenKey(pScreen));
> (gdb) n
> 128         x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX;
> (gdb) n
> 129         y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY;
> (gdb) n
> 132         if (!pCurs->bits->argb || !infoPtr->LoadCursorARGB)
> (gdb) n
> 139         if (!(infoPtr->Flags & HARDWARE_CURSOR_UPDATE_UNHIDDEN))
> (gdb)
> 143         if (pCurs->bits->argb && infoPtr->LoadCursorARGB)
> (gdb)
> 144             (*infoPtr->LoadCursorARGB) (infoPtr->pScrn, pCurs);
> (gdb)
> 0xb5ffc0b0 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so
> 
> If anyone has pointers for what I should look at, let me know. I'll
> try to read some sources later this week, I haven't had the time to do
> that yet.

It's odd that GDB is getting confused when doing a "next" over the call
through the function pointer.  I'll bet it's because your X server is
compiled with optimization, which also explains it jumping between lines
126 and 128 a few times.  If you want to properly step through
xf86SetCursor, you might be able to put a breakpoint on line 155, the last
line of the function.  You might also have better luck if you compile an X
server without optimization.

You could start by getting a backtrace to see who is calling xf86SetCursor.
Also, just continuing from there and seeing if it's hitting the breakpoint
repeatedly would be a good thing to try.

-- Aaron