x11-drivers/xf86-video-mga: current issues

[Peter Much]

Quote Florent Thoumie:

>Can I have confirmation from a couple people that the patch from
>ports/117726 actually solves most (if not all) problems with the mga
>driver?

Negative. It does definitely not work suitably in a single head 
config, the way it currently is. It solves the problems from 
ports/117726, but not those from ports/116851.

Explanation:

I recently upgraded all my ports, going from somewhen in 2005 
to most current, and had to notice that the Matrox G400 MAX, which was 
working perfectly with the old ports (it was Xorg 6.9, I think), now did
no longer work suitable. 
OS still stays RELEASE-5.5, w/ all patches installed.

What now got compiled from current portsdir is the 1.4.7 mga driver 
with patch-1.4.7-master-20080102 applied.

The problem here is: I see error 

>(EE) Cannot find empty range to map base to
>(WW) MGA(0): Video BIOS info block not detected!

as described in ports/116851, and, while the old ports yielded

>(==) MGA(0): Min pixel clock is 17 MHz
>(--) MGA(0): Max pixel clock is 360 MHz
>(II) MGA(0): Clock range:  17.75 to 360.00 MHz

now I see

>(==) MGA(0): Min pixel clock is 17 MHz
>(--) MGA(0): Max pixel clock is 252 MHz
>(II) MGA(0): Clock range:  17.75 to 252.00 MHz

And consequentially, neither 2032x1480 at 70Hz nor 1800x1300 at 80Hz do
work anymore. (Lower resolutions would work.)

I tried to use the 1.9.100 version as of 2008/01/01, but that way I
got exactly into the problems as described in PR ports/117726.

When I did install Warren's workaround for xorg-server (as described
in http://www.wonkity.com/~wblock/mgapatch/xorg-patch.txt, but
staying with 1.4.7+patch driver just as it currently is), this
did solve my problem, dotclock back at 360, resolutions alright.
Thank You, Warren!


So, while the matters concerning ports/117726 (which looks to me
concerning more or less the question if one is willing to use xrandr)
seem to be widely discussed, the other problem (ports/116851, i.e. 
the card not reading BIOS information), seems now to be in the status
"closed unsolved", and no one seems to care about anymore.(?!)

Furthermore, the ports/116851 problem is obviousely NOT concerning 
only dual-head configs. It seems to significantly reduce standard
performance values, too!

And, worst of all, it is a real "Dehancement": things that were 
reached without problem two years ago are now beyound the
specs!


So, at first I would like to ask a couple of questions:

1. What precisely did You do to make this "(EE) Cannot find empty
range" error go away - if anything? (If you have flatscreens, you
most likely do not need dotclocks above 250MHz, so there would not
be a need to do anything about it). 

2. Is the patch in ports/117726 (and now in the ports-tree) supposed 
to fix this error? The statements in the PR database are all too 
obscure, while the code looks like it might be (and I'm not going 
to do logical analysis there). I just can say, it does _not_ work
for me (while Warren's patch does). It may likely be the case that 
something that would be necessary has not got upgraded here, or not
got installed. It may also be the case that it works on RELEASE-6 but
not on RELEASE-5 - which wouldn't be a big matter as I am going for
RELENG-6.3 very soon now and RELEASE-5 is going out of support 
anyway - I only would like to figure out a precise status.

3. As this problem definitely yields from changes in the Xorg (and
most likely not, what Warren suggests in ports/116851 PR, from things
that BIOS or OS do - because I did not change anything on BIOS or
OS!), can we someway figure out when it came up and what was changed
then? (I have a scope of possibly more than two years, and that's a 
bit long.)

4. As there seems to exist the opinion that this problem belongs
to Xorg maintainers (and as I have the strong opinion that before
creating fixes one should figure out what made the problem arise
in the first place - especially with things that did already work
at an earlier time): is there an involvement of Xorg maintainers
in this matter? (I searched, but did not find any comment on
that)

5. (sorry, can't resist) Is it regular practice in the PR handling 
to place things that have no easy solution right now, but did already
work before, into status "closed unsolved", only because they 
actually should belong to some other party (and without mentioning
the tracking-ID at that other party)? 
No offense meant - there are different styles of doing such.

Sorry - I would have preferred to just figure out whats wrong and
then act as necessary - but this is so obscure, I dont get to the
point.

rgds,
PMc