From owner-freebsd-x11@FreeBSD.ORG Fri Jan 18 05:44:03 2008 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 984F116A41B; Fri, 18 Jan 2008 05:44:03 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id DCFA013C44B; Fri, 18 Jan 2008 05:44:02 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.1/8.14.0) with ESMTP id m0I5D9JM050821; Fri, 18 Jan 2008 06:13:09 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.14.1/8.14.0/Submit) with UUCP id m0I5D97Z050820; Fri, 18 Jan 2008 06:13:09 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.13.6/8.13.6) with ESMTP id m0I51jaY036739; Fri, 17 Jan 2008 08:01:45 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.13.6/8.13.6) with ESMTP id m0I4xZCT036482; Fri, 17 Jan 2008 07:59:35 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.13.6/8.13.6/Submit) id m0I4xY07036481; Fri, 17 Jan 2008 07:59:34 +0100 (CET) (envelope-from peter) Date: Fri, 17 Jan 2008 07:59:34 +0100 From: Peter Much To: wblock@wonkity.com, freebsd-x11@FreeBSD.org, flz@FreeBSD.org Message-ID: <20080118045934.GA35739@gate.oper.dinoex.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (uucp.dinoex.sub.de [194.45.71.2]); Fri, 18 Jan 2008 06:13:10 +0100 (CET) Cc: Subject: Re: x11-drivers/xf86-video-mga: current issues X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 05:44:03 -0000 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@70Hz nor 1800x1300@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