tech-x11 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

5.2 Xorg issues

I have a machine with multi-head-capable video (specifically, it's a
Dell Precision M6300 laptop).  I'm running NetBSD/amd64 5.2 on it.  The
X that comes with 5.2 works tolerably well with it, including driving
up to three outputs (builtin flatscreen, VGA, and DVI) - it has the
cursor-extending bug, but the one program I use enough to care about
has a workaround.

However, it insists on driving all three outputs as portions of a
single root, effectively pasting the various displays together.

This is not what I want.  I want each head to be a separate screen.
Basically, the converse of Xinerama.

I spoke with a friend who knows more about such things than I, and he
told me the way to do this was to disable Xinerama.  This did not
surprise me, but I'd already tried that, and found that using -xinerama
(documented as disabling Xinerama) did not change the behaviour,
whereas using +xinerama (documented as enabling it) produced a segfault
(or, at least, a crash with "Caught signal 11.  Server aborting" in the
logs and, under suitable circumstances, a core dump).  I figured that
perhaps the command-line parsing for the options was backwards or
something and there was a bug with disabling.

Today I started looking at this in more detail.

The command-line parsing is not backwards.  The server is (erroneously,
IMO) behaving Xinerama-style when Xinerama is disabled; enabling it
crashes because some things (like RandR) short-circuit their
initialization when Xinerama is enabled - but, when there's only one
screen, Xinerama disables itself when initialized; this then leads
those other things to think it's disabled and assume their init
routines did the correct things for a Xinerama-disabled run, which they
didn't because when the init routines ran, Xinerama was enabled.  And,
despite the Xinerama-style behaviour, it seems Xinerama is not actually
responsible for the multi-head behaviour; some other layer is doing
that and insisting on presenting the rest of the server with a single
screen.  In my test case, this manifests as a crash whose backtrace
looks like

#6  <signal handler called>
#7  0x000000000045f744 in dixLookupPrivate ()
#8  0x000000000049a840 in xf86RandR12CreateScreenResources ()
#9  0x000000000049ef9f in xf86CrtcScreenInit ()
#10 0x000000000043ad7e in main ()

So, I have three questions:

(1) What's the best thing to do with this crash?  There's a certain
amount of "don't do that, then" applying to enabling Xinerama on a
single-screen display, but surely a segfault is not a right response.

(2) Is there any way to get what I want, or is it just that Xorg is so
advanced that it can't do what Xsun could back in the '80s, and I'm on
my own for getting that functionality back?

(3) (Much lower importance.)  Is there any hope for getting the
cursor-extending bug reported anywhere useful?  It's very
long-standing; I was seeing it back in the mid-'90s, and it would be
very nice to finally get it fixed.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index