State of Zaphod dual screen support

[David Mohr]

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)?

Thanks,
~David