Trying to use my configuration from the previous version in unstable
(1.4.6) caused complete failure -- the second head is never even
considered, so I only get single headed operation. Attempting to do
"what xorg 7.3 wants you to do" doesn't work b/c 1.4.7 doesn't have
the relevant parts of xrandr 1.2 implemented.

Help? Or should I just revert to 1.4.6?
 - robert jacobs

kls wrote:


There's xserver-xorg-video-mga 1:1.9.99.dfsg.1-1 in experimental with
randr-1.2 support, you might want to test it. It's probably a better
idea to make 1.9.99 work than to fix 1.4.7 in the long term anyway.

Brice

I noticed the same problem with Matrox G550 and driver
xserver-xorg-video-mga 1:1.4.7.dfsg.1-3, only the first monitor works
while Xorg.0.log does not report any problems about the second.

Trying with the driver version from the experimental
(1:1.9.99.dfsg.1-1) with the same config gives some kind of clone mode
with weird resolutions for two monitors with several graphical
glitches.  I tried to change the config with grandr but it did not
give any other choice than the clone mode, but this might be fault of
grandr and not the driver. The man-page of xrandr does not look very
inviting so I did not yet try changing the settings with it, and
instead downgraded the driver and some other xorg packages to the
versions in testing to get a working set up.

Are these newer drivers likely to get fixed anytime soon or is the
"medium term" solution to stay with 1.4.6 driver? I am personally not
very motivated to try to fix or hunt for bugs in the experimental mga
driver (good reason to get rid of the POS matrox if anything), and
maybe nobody else is either for such old cards...

Jarmo Ilonen wrote:

Please send the whole output of 'xrandr' after reinstalling 1.9.99 so
that we see all available modes for each output. You can change the mode
of output FOO with something like
    xrandr --output FOO --mode 1024x768 --rate 75

I don't know about 1.4.7, it could be the last old-style MGA driver. But
1.9.99 will very very probably be fixed. It doesn't get as much
attention as Intel or ATI driver, but Tilman Sauerbeck has been taking
good care of it in the last month, so there's no reason why it would
change now. This RandR 1.2 driver is the future way to go, most drivers
are going this way now. MGA 1.9.99 is too young to be perfect, but it
should improve in the future. If you're really interested about this,
you might want to talk to Tilman directly, for instance on IRC.

Brice

Screen 0: minimum 320 x 200, current 1440 x 960, maximum 1600 x 1024
DVI connected 1440x900+0+0 306mm x 230mm
   1600x1024      60.0
   1280x1024      60.0     60.1
   1440x900       60.2*
   1280x960       60.0
   1280x800       60.0
   1280x768       60.0
   1024x768       60.0
   800x600        60.3
   640x480        60.0     59.9
VGA connected 1280x960+0+0 408mm x 306mm
   1280x1024      75.0     59.9
   1280x960       59.9*
   1152x864       75.0     74.8
   1024x768       75.1     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     66.7     60.0
   720x400        70.1

"DVI" (actually connected with a VGA-adapter) is an old crappy CRT, I
have been running it in 1024x768 normally. "VGA" is a new 20" LCD
(Samsung 204b) with 1600x1200 native resolution.

Changing the resolution of "DVI" to anything else caused the monitor
to go blank, sounded like the monitor shut itself physically down to
protect itself or something. Further changes did not produce a
picture, but the monitor again made some noises so the xrandr commands
did at least something. Changing the resolution of "VGA" worked fine,
but the 1600x1200 resolution was not an allowed resolution (I don't
remember the actual message).

Looking at the xorg logs there seems to be some confusion about the outputs:
(II) MGA(0): Output DVI using monitor section Samsung 204b
(II) MGA(0): Output VGA has no monitor section
but the physical sizes reported by the xrandr command above match the reality.

By the way, does this
http://lists.freedesktop.org/archives/xorg/2007-September/027857.html
also apply to mga driver? I have been using two monitors as two
separate X screens as xinerama is IMO not really an option unless the
monitors are nearly similar, which really is not the case here.

Anyway, this is actually a computer at work so I cannot waste too much
time debugging, but if there are some specific things to test I can
try to find some time...

Ok, I tried that. After using xrandr to set up my desktops to the
original layout (works fine), I'm left with three issues in 1.9.99, of
which the first is a problem and the rest are gripes:

1) Starting WindowMaker causes X to SIGILL, and I can't trace it down
b/c X never finishes starting if I run it inside GDB. This seems to be
libpixman compiled with the wrong flags -- I can get it to happen with
Xvfb also (and debug it!). ...

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb7c546b0 (LWP 7097)]
0xb7ed76b9 in fbCompositeSolidMask_nx8x8888mmx () from
/usr/lib/libpixman-1.so.0
(gdb) disas
[...]
0xb7ed76b2 <fbCompositeSolidMask_nx8x8888mmx+226>:  movq   -0x123c(%ebx),%mm5
0xb7ed76b9 <fbCompositeSolidMask_nx8x8888mmx+233>:  movss  -0x80(%ebp),%xmm0
0xb7ed76be <fbCompositeSolidMask_nx8x8888mmx+238>:  mov    %eax,-0x6c(%ebp)

movss seems to be a SSE instruction, and I only have an athlon
thunderbird. This seems to be bug 442852. Should I add this to that
report?

2) There seems to be no way to specify the properties of the second
monitor at startup, so it blithely assumes some defaults (which happen
to be wrong on my old fixed frequency monitors that don't speak DDC
... although based on Jarmo Ilonen's comment, it looks like it doesn't
even inquire). It's easy enough to tell it to do the right thing after
X is started using xrandr, but it'd be nice to not be abusing my
monitor with a mode it can't do for the seconds before it finishes.

3) I can get SEGVs if I change VTs at the wrong time (before it's
finished initializing everything, presumably)

Thanks!
 - robert jacobs

With the update to libpixman, I can now run 1.9.99. It mostly works,
except 2d performance is abysmal -- full-screen windows (1152x900 for
me) take about a second to redraw. (however, 3d performance is as
good, or maybe slightly better, than it ever was)

Is this useful for me to report now, or should I wait for whenever it
gets pushed into unstable (when upstream will be more nearly finished)?
(If so, I've noticed that randr forgets the doublescan flag, and that
wmnet's window contents gets placed in the wrong place)

In any case, 1.4.7 is sufficiently broken (since dual-heading doesn't
work at all) that I'd like to recommend that it not be allowed to
propagate.

Thank you!
 - robert jacobs

kls wrote:

Ok, thanks for the report. Should I mark your bug as fixed in 1.9.99 and
let you open a new bug report about 2D being very slow in 1.9.99 (or in
2.0 when it is released)?

I'll forward your mail to the upstream dev anyway, we'll see what he thinks.

You mean 1.4.7 is more broken than 1.4.6, right?

Brice

Sounds reasonable.

In my opinion. Of course, looking at the bug report listing, 1.4.7 fixed
bug #430112, so you win some, lose some.

debbts@eamp.org wrote:

Ok closing.

Ok.

Brice

...
ddc data from two monitors, which I did not notice before because I
was forcing the video modes. I'll attach the logs from both here, old
driver 1.4.6 in "Xorg.0.log.testing" and with experimental 1.9.99
driver in "Xorg.0.log.experimental".

In the old log "MGA(0): Printing DDC gathered Modelines:" reports the
maximum mode 1280x1024, even though this monitor is the new LCD and is
later forced to 1600x1200 (MGA(0): *Default mode "1600x1200"...). For
MGA(1) DDC reports modes up to 1600x1200, but is later set to use the
1024x768 mode. As this setup is working fine, it looks like the driver
or X (or whomever is at the fault) reads the DDC data from the monitor
connected to the wrong output.

The experimental log is not so interesting, it only reports DDC from
the DVI-connected monitor, the old CRT, and no DDC data at all from
the VGA-connected LCD. Funny that xrandr command I pasted in a
previous post gets the physical screen sizes right even though the
modes are mixed.

Anyway, this starts to get offtopic for this (already closed) bug-report...