State of Zaphod dual screen support
David Mohr
damailings at mcbf.net
Mon Mar 8 08:38:04 PST 2010
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.
Thanks,
~David
More information about the xorg
mailing list