Re: 5.2 Xorg issues

[Matthieu Herrb <matthieu.herrb%laas.fr@localhost>]

On Sat, Jun 29, 2013 at 01:59:15PM -0400, Mouse wrote:
> 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.

Without a dmesg or an Xorg.0.log file it's difficult to guess which
graphics chipset that laptop is using and hence which driver X is
using. 

Unfortunatly multihead handling is quite dependant on the X drivers... 

> 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.

This is called zaphod mode in X terminology. 
> 
> 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.

You're missiing something here. 

Traditionnaly multihead ha only been available by the way of multiple
graphics cards. Each graphics card was handled by a separate X
"screen" attached to it. This was :0.0 :0.1 and so on. Xinerama is
(was) an extension to merge all the physical screens into a single big
one, by merging their framebuffers. 

Then came graphics cards with multiple outputs, like the one on you
laptop. There is only one GPU and one framebuffers, only the RAMDACs
(or their digital equivalents in the DVI/HDMI/DP world) are different
for each output. X drivers started to handle those by using a
"pseudo-xinerama" model: each output was handled as if it was a
separate screen, except that (because of the single framebuffer) all
screens were already merged, as with Xinerama. Some drivers (mostly
the ati/radeon and matrox) also implemented specific "zaphod" modes to
allow people like you to keep one X screen per output.

The +/-xinerama flag on the X server has no impact on this
pseudo-xinerama mode. It only controls the real Xinerama extension,
which merges separate video cards into one X screen. 

Then came XRandr 1.1 and 1.2 which provide an unified way to handle
multiple outputs, simplifying the drivers and the configuration. But
XRandR only provides one X screen covering all outputs.  Some drivers
(including the intel one) have completely dropped zaphod mode support.

> 
> 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.

This is a bug that should be fixed. If a driver doesn't support
enabling xinerama, the X server shouldn't crash. The difficulty is
that NetBSD 5.2 ship with an old X server version that's no longer
maintained upstreams. So you'll have to fix that on the NetBSD side.

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

Short answer no, unfortunatly. But since XRandR knwos about differents
outputs of a card and can make that information available, some window
managers (I know that at least i3 does it) provide desktops that are
attached to XRandR outputs and allow you to switch dektops on one
output independantly of the outhers, which is what most people miss
from zaphod mode.
> 
> (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.

I don't know what you mean exactly by "the cursor-extending bug", but
again, it would be useful to 1st check that it's still present in more
recent versions of X / drivers than what's shipped with NetBSD 5.2.
-- 
Matthieu Herrb