I have not been able to determine whether this package is *supposed* to
work with DVI output on a Matrox G550 card.  Does regular single-head
DVI operation require special Matrox modules?

It would be splendid if the package description would say whether it is
supposed to provide basic DVI functionality or not.

The strategy of just trying it does not work in my case because xorg
is not working for me.  I get signal out of range even with correctly
specified frequency ranges, and even with a bizarre extremely narrow
range of frequencies, X launches but has strange non-resizing -dpi and
extremely ugly font behavior.  (Perhaps it should be obvious to me
whether this means the card is working.)

The man page is unclear.  It says "The second head of dual-head cards
is supported for the G450 and G550" which implies that DVI works
unless there are dual VGA versions of those cards.  But then it says
"[t]hat module ... may be necessary to use the DVI (digital) output on
the G550 ...." which implies that it might or might not work, and
doesn't say when it might and when it might not.  When might it?

The xorg web sites don't seem to say (there is a broken link), and the
Matrox forums are hideously complicated on the point due to various
versions of xorg and Matrox modules and people who are overclocking
and using special DRI thingies for gaming.

What's a person who just wants basic functionality to do?

So a package description that simply states whether it is supposed to
work or not (and thus whether the user needs to go on a wild goose
chase getting Matrox's unsupported proprietary closed-source black-box
obviously non-dfsg modules to work) would be great.

A hint on what to do if you need the proprietary driver would be
beyond great, somewhere in the fantastic to superlative range.

(I am unsure whether to downgrade to Sarge xfree86 or earlier, forge
ahead fixing xorg, figure out how to use the proprietary driver,
reinstall etch, or replace my card.  Guidance from the package
description and man page would simplify those choices.)

If the driver is slowly picking away at the closed-source, kind of
working and kind of not but expected to improve and would users please
report bugs -- that sort of thing -- that would be good to mention.

Thanks.

forcemerge 372079 372067
thank you

Some problems have been reported [1,2] and should be fixed. I just pingued
your bug #372079 to know its status. I don't think it is a documentation
issue.

There are bugs, sorry, and few people to debug them or fix them, so it
takes time to get them fix. If DVI still does not work for you with
latest upstream, you might want to discuss this upstream and maybe even
help them debug/fix.

Brice

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372079
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376326

hey, thanks for taking an interest.

not sure i agree with the last statement.  if it is known not to work
because of bugs, users need to know enough details (without wading
through bug reports) so that they don't get bloody concussions from
banging their heads against a brick wall.  the ambiguous wording in
the man page imho invites those concussions.  please, save the
foreheads.

(parenthetical note: i speak from experience.  my non-working dvi
output on my pretty-common g550 video card has been a thorn in my side
for a really long time (years) and has led to this situation:

  o i have to use xfree 4.2 with an outdated proprietary sourceless driver
  o i have to keep many other packages held back to be consistent with that
  o i therefore can't even use firefox, much less iceweasel, because
an infuriating bug,
     apparently but not necessarily in a version of a gdk library that
cannot be upgraded,
     decides to deliberately crash, randomly and frequently, instead of
     simply failing the operation apparently not supported by xfree
("server does not implement
     operation" or some such).

i *don't* mean to complain about this, because everybody is a
volunteer and matrox is apparently making it really difficult for
people.  i wish i could help more.  my purpose in mentioning this is
to inform you that it is *not trivial* for a user to debug and fix
this sort of thing when his or her computer use is physically limited
(not everybody can do the typing required for debugging) or technical
expertise is limited.  my main point is that it is worse when it's
hard to get a straightforward answer on whether it is even possible.
i don't know whether ubuntu's decision re drivers is relevant or not,
but it is imho understandable that ubuntu starts to look attractive if
the only alternative is to buy another video card.  but other than
this one thorn, debian works ok....

end parenthetical note.)

perhaps you mean that it is not JUST a documentation issue?

are you saying i should try again?  if so, i'll try a fresh etch
install and the installer's x conf.  i have been following the driver
version numbers and i don't think i saw any changes that might be
relevant.  perhaps i missed something?  it still seems like the man
page is ambiguous on whether single dvi is expected to work or not.
it still seems like it's not going to work.

perhaps i should try installing the ubuntu .deb for the driver if etch
doesn't work.

please do not close these bugs yet!

again, thanks for looking at this.

t takahashi wrote:

Sure, if the bug becomes a known feature, it might be better to document it.

I never had a MGA board myself, so the bug does not look that important
to me :/ Since you're saying that the bug has been here for a while and
multiple people are suffering for it, it might be good to do something.
If you are motivated, I suggest you talk to upstream. The MGA driver
development is still active, so there's a good chance you get an answer
either on IRC or on xorg@lists.freedesktop.org (need to be subscribed)
or by reporting a bug in bugzilla.freedesktop.org.
If you can't do that, let me know, I'll do it for you. However, since
you seem to be very familiar with this problem, it might be more
efficient if you're able to discuss with them directly (I mean, without
me (who never had a MGA board) in the middle).

If you read the whole changelog in detail and you're sure nothing is
relevant to your bug, it's probably useless to try upgrading again, yes.

I'd rather be sure about that before patching the manpage. That's why
upstream opinion will help.

Brice

So it is here, 4 years now. :-/

Sarge's XFree 4.3 with Matrox closed driver (HALlib) is working fine
here.  Well, not entirely, I still had to work around things with an
incredible configuration hack... :-(

With some more horrible hacking, it seems to be possible to make Matrox'
Hallib, and thus DVI, work with later X.org versions, too, see [1].
But actually, the unbelievable hassle of those procedures has stopped me
from upgrading my desktop to Etch till now.

Nikolaus

[1] http://matrox.tuxx-home.at
Hm, this website currently seems to be down. That's bad, I hope it will
recover!

as of recently, it was not clear to a non-x-expert even with
nontrivial google searching:

whether the open source driver is sufficient for simple 2d dvi use
with magic settings -- or not

whether the tuxx driver is nec or sufficient -- or has issues

how to best vet the tuxx driver for security (the author seems like a
great guy, btw)

whether the ubuntu .deb will work on etch (how to check its signature
from etch is probably easy but requires work to find out how)

whether feisty would work

how likely any of the above are to break upon an upgrade of x (or libraries)

Indeed it seems that at least the man page is vague here.

Well, the tuxx driver is sort of a gray area, isn't it?  I guess no
authority besides the author himself cares about that driver, and the
users are probably just happy to see it working again, someway.

[ snipped ubuntu part ]

With X upgrades?  Likely, I guess. :-/

Nikolaus

nikolaus, or any others, have you found anything that works for you yet?

(etch, lenny, sid, ubuntu, tuxx?)

thanks.

Hi,

I just uploaded xserver-xorg-video-mga 1.9.99.dfsg.1-1 to experimental.
It brings RandR 1.2 support, which improves mode detection and dynamic
configuration. It should also support DVI. About RandR 1.2, note that
you might need to update your xorg.conf, see the pointers I inserted in
http://bgoglin.livejournal.com/12835.html

Thanks,
Brice

i will try this and report back on my g550 non-dual dvi, if that'll help.

but first, does anybody know:

  o which versions of x (xorg in etch/lenny/sid) will it work with?
  o does one simply upgrade to that xorg, install this driver, and
change xorg.conf?  or is there more to do, like tweak xrandr, to get
it working?

very exciting.

thanks.

oops, my first question was unnecessary; "Now that David pushed X.org
7.3 to unstable" implies that we'll need to upgrade to unstable to get
the dvi to work.  my second question nevertheless applies, as it's
worth recording here whether other stuff needs to happen, like
installing xrandr or anything else.

upgrading from xfree 4.2 + proprietary blob to floss xorg will be nice.

thanks.

t takahashi wrote:

Both 1.4.7 (the one in unstable) and 1.9.99 (the one in experimental)
are built against Xserver 1.4 currently in unstable. So you'll to
upgrade to xserver-xorg-core (and also xserver-xorg-input-*) from unstable.

With a default xorg.conf (or even no xorg.conf at all), the server
should start and be able to use multiple outputs (I guess 2 of them
should be enabled by default). xrandr can then be used to
query/disable/resize/enable/move all available outputs at runtime. The
only thing required in xorg.conf could be a "Virtual" line in subsection
display (to get a large virtual screen where your multiple outputs will
able to be placed).

Brice