Hello,

I am using the NVidia driver with two X screens (:0.0 primary, VGA and :0.1 secondary, internal notebook display).

When I drag a desktop icon, a frame appears showing where the icon will end. If I drag this frame around and back to the place where the icon is (i.e. "I do not actually want to move it"), on the secondary screen (:0.1), xfdesktop crashes. It does not crash on the primary screen (:0.0).

The log entry in ~/.xsession-errors is:

The program 'xfdesktop' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 6918 error_code 8 request_code 142 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
xfdesktop[3796]: starting up

Best Regards

S. Raase a écrit :
Does it happen with vesa or nv driver?
Is compositing activated?
Can you get a backtrace?

Cheers,

S. Raase a écrit :

please let 564694@bugs.debian.org on CC:

Yeah but there's a 99% chance the bug is caused by a binary blob there's
no way to debug. Anyway DualHead doesn't look at something supported,
wether by X server or clients, if it's a proprietary nvidia stuff.


http://wiki.debian.org/HowToGetABacktrace + some help from google about
the X window system error.

Cheers,

Hello,
OK, I'll try.

nv on my system does not allow DualHead at all, neither does vesa and
the problem does not apply on screen :0.0 or :1.0, but it does on screen
:0.1 and :1.1. (I did not try nouveau, last time it just core dumped.)

The problem did exist with nvidia driver version 185.18.36 and it does
with 190.53 as well.

I strongly suspect the nvidia driver of not causing the crash, but
instead a mis-handling if xfce4 is been used on multiple x-screens.
Can't test this theory though, because I don't know how to create
different screens with another driver.

For your information, I do not use the TwinView feature for DualHead of
the nvidia driver (which essentially implements some Xinerama), but
instead the basic way of X11 using one server and one x-screen per real
screen. These screens are completely separate.

Anyway, I am running Debian/testing as of today, 2010-01-11. The crash
has been there for at least a few days, although I have no idea when it
appeared.

I'll attach my xorg.conf, as well as Xorg.0.log to this mail.

I do not know where xfdesktop4 is started or how to start it manually
inside gdb, so this information is helpful but not useful to me.

If you can help me getting a backtrace I am willing to help, but I
cannot provide you with further information right now.

Best regards

S. Raase a écrit :

You already said that. Basically we can't debug anything in nvidia
driver so we're stuck.

And I strongly suspect the nvidia driver causing the crash.

Then I fail to see how it can't be reproducible with another driver.

What was updated during that few days? (not xfdesktop4, that's for sure)

Then attach it using gdb -p ?

Everything is in the wiki page I gave.

Cheers,

Hello,

Tell me of a driver which can product two X screens on one server and
I'll try. I've just never seen some other driver for hardware I posess.

grep "install xf" /var/log/dpkg.log* [after gunzip] tells me:
xfce-keyboard-shortcuts in November, xfce4-clipman in October. A few
more in September. Nothing affecting X11 since November.

I attached three sessions with gdb, but it didn't work.
First one is complete, the others look the same in the beginning.

Which dbg-packages do I actually need? I only installed xfdesktop4-dbg.

Best Regards

S. Raase a écrit :

Well, if it's not a specific feature of nvidia driver, all. If it's a
specific feature of the nvidia driver and we have no way to debug it,
end of the story.

So could you explain what exactly is the “two X screens on one server”,
how do you configure it (I guess your previously attached Xorg.conf
might help) and what exactly do you run and how. Something like a bug
report. Something with which I can work to try to reproduce the problem.

I was more interested about X stuff.

Well it doesn't look really usable. Try to kill xfdesktop first, then
run it directly from gdb so you are able to break on gdk_x_error.

But, as said before, I'm not really interested with debugging on a
binary driver.

Hello,
An X-Server may control an arbitrary number of screens, which appear to
the system as completely different. Like every hardware output may
appear as a screen (like in my case). There are referred to as ":0.0",
":0.1", ":0.2", and so on. This is a standard feature of X11 since dawn
of time.

Or I may start a new X-Server for every output, each containing just a
single screen. These are then called ":0.0", ":1.0", ":2.0" and so on.
In recent times, both concepts for multiheading are dying, because X11
does not allow moving windows from one screen or server to another.

I do not know of many X11-drivers which make use of screens, they might
have existed in XF86_3-times. Multimonitoring was not important back
then. If a driver does not make use of this concept at all, it is still
a standard X11 feature...
(a) binary nvidia driver using nvidia TwinView (ati has something
similar but called differently), which in essence is a Xinerama
extension, and as Xinerama is deprecated in favour of XRandR 1.2+ and
applications have to be Xinerama-aware, I don't like it. (3D
acceleration does work with binary nvidia drivers.)

(b) binary nvidia driver using the standard X Screen approach, which
means that one server controls the graphics hardware and provides two
separate X Screens (:0.0 and :0.1). This is the way I use it, as 3D
works on both monitors and as they are completely separated applications
have no idea where they are displayed. XFCE4 does know about this
approach, otherwise I would have to run a window manager on every screen.

(c) the modern approach with XRandR 1.2+ which is using a huge virtual
framebuffer and providing different "views" onto it, while at the same
time providing video signals in a specific resolution and without
panning. This is the preferred way in the future, but NVidia will not
implement it in their drivers.

Take a look at my Xorg.conf and you see how I set up the separate
X-Screen approach; I tell the server I want multimonitoring but no
Xinerama and then the binary driver sets it up accordingly.

Nothing. But the bug might have slipped my attention completely, as I
seldomly shuffle my icons around to the places where they already are.

If I kill xfdesktop it is started again automatically. Anyway, there are
a lot more small caveats with XFCE4 on a separate X-Screen. (Like after
clicking into the task list the pointer has to leave the task bar before
any other clicks will be accepted; they are silently ignored instead.)

Then I would propose that you close the bug and mark it with "I'm not
interested and I won't fix it."

I can live with this bug although it is a somewhat nasty one. As is the
case with most bugs - if they are known they are not dangerous.
Anyway, if the multihead support (or separate x-screen support) in XFCE4
is largely untested and people are unwilling to take care of it, then
they should drop it completely. This way one can run whatever
environment on any screen, which is one advantage of this approach;
think about XFCE4 on your monitor and wm2/icewm/whatever on a TV screen.

Best Regards

Hello again,

It is called "zaphod mode" and supported by a few drivers. As drivers
move over to XRandR they often remove support for this mode as well
(intel, radeon) on the way; most don't have it yet.

Again, I see "xfdesktop4" crashing, not the nvidia driver. There are a
few other annoying things happen on the second screen as well (like: I
cannot click on two different items in the task bar until I move the
mouse pointer out of the whole bar and then in, else my click will be
ignored). You see nvidia crashing (it doesn't).

I'm interested in getting bugs fixed and I am willing to help if I can.

Seems I can't.

Best regards,
S. Raase