Re: 5.2 Xorg issues

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I have a machine with multi-head-capable video [...]

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

Doh!  I knew I'd forget something.  It's probably implicit in "Dell
Precision M6300", but that's not to say it's easy to find out.

dmesg doesn't help much, unless you have PCI tables handy:

vga0 at pci1 dev 0 function 0: vendor 0x10de product 0x040d (rev. 0xa1)

Xorg.0.log is at least slightly more informative:

(--) NV: Found NVIDIA Quadro FX 1600M at 01@01:00:0

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

That's not what I recall zaphod mode as being; I recall it as being
whether the pointer slides between screens when it moves off the screen
(zaphod mode) or whether some application has to use WarpPointer to
switch screens (non-zaphod mode).  That's certainly what the MIT Xsun
uses the name to mean.  For example, sunCursorOffScreen has a comment

    /*
     * Active Zaphod implementation:
     *    increment or decrement the current screen
     *    if the x is to the right or the left of
     *    the current screen.
     */

I'm not sure whether I'd rather change screens zaphodically or whether
I'd rather require the use of WarpPointer requests.  (It probably makes
less difference for me than for many people, because I pretty much
completely decouple keyboard focus from the pointer, so there's no
reason the pointer has to move when I switch input focus from screen A
to screen B, except for cases like the cg4 I mention below where that's
necessary to switch which one is displayed.)

> Traditionnaly multihead ha only been available by the way of multiple
> graphics cards.

Well...mostly.  There were some exceptions; for example, the Sun cg4 (I
think it was) had 10 bits per pixel, organized as a 1bpp plane, an 8bpp
plane, and a selector plane controlling, per-pixel, which of the other
two got displayed.  Some servers presented this as a 1bpp screen and an
8bpp screen, flipping the enable plane to display one or the other,
depending (usually) on which one held the pointer.  And, while it was
not stock, I hacked on the MIT sample server so that one of the 8bpp
framebuffers could be used as eight 1bpp framebuffers instead - again,
multiplexed onto a single video output.  But, mostly, yeah.

> Then came graphics cards with multiple outputs [...].  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.

I'm not surprised to hear that; it sounds a lot like what I saw.

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

...and, by implication, others haven't.  And it seems I've got one of
the latter. :(

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

So it simplifies multiple output handling by simplifying the range of
configurations you can achieve with it?  Sounds to me like a
regression, but what do I know....

While grepping around for this stuff, I stumbled across Xdmx source; it
sounds a lot like a way to get what I want...except that 5.2 doesn't
build it as far as I can see.  You wouldn't by any chance happen to
know what would be involved in making it build?

>> (1) What's the best thing to do with this crash?
> This is a bug that should be fixed.  If a driver doesn't support
> enabling xinerama, the X server shouldn't crash.

I don't think it's "a driver" that's at fault, per se; it looks to me
as though anything supporting RandR >= 1.2 will fail similarly, though
I haven't dug through enough details to be sure.

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

Not worth the bother to me to fix it for my own use; the cause is known
and it's relatively harmless, as such things go.  If NetBSD - or X -
isn't interested in the bug report because I'm not running
bleeding-edge code, shrug, they can find/fix it themselves.  It's easy
enough to reproduce on servers that suffer from it.

>> (2) Is there any way to get what I want,
> Short answer no, unfortunatly.

That's what I was afraid of :-(

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

Based on my brief playing with xrandr, it is missing one crucial piece:
clients still see one screen with a large root.  They have to be
RandR-aware to figure out that the root is being chopped up into
pseudo-screens.  This is a major piece of why I want separate screens.

>> (3) (Much lower importance.)  Is there any hope for getting the
>> cursor-extending bug reported anywhere useful?
> I don't know what you mean exactly by "the cursor-extending bug",

When setting a bitmap cursor, the protocol permits the mask to be set
to None, which is supposed to mean that all pixels of the source are to
be displayed.  Servers with the bug mangle this in the case of a 3xN
cursor, extending it to, typically, 32xN with padding on the right.
(It probably affects other shapes too; that's just the case I run into
most often.)  That there is no real need for this is easily shown by
providing an explicit mask bitmap rather than using None, which in
every case I have seen works around the bug.

This is not, strictly, contrary to the protocol; components of a cursor
"may be transformed arbitrarily to meet display limitations", but the
simple workaround demonstrates that there is no actual need to mangle
the cursor this way.  That's why I call it a bug, not a misfeature.

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

5.2's is the most recent X I have.  But I can easily build a simple
test program, if people would be up for running it.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B