Posted at 2007-08-11
Now that this craptastic blog thing is working again it's time for an mga status update \o/
The randr-1.2 branch is in a nice state. Last week idr told me how to do output detection with the vbios' PInS block, so now the driver automatically creates the output objects corresponding to the hardware. This makes the driver usable without having to edit the source code \o/
I tested all of my cards with that output detection code, and almost all of them passed. The one that didn't is my G450 DVI, which has a single DVI connector. Unsurprisingly the PInS data says exactly that. However, I got the card with a DVI -> 2 * VGA adapter cable. If that cable is plugged in, we want to have two VGA outputs instead. So it looks like I'll really have to make it possible to override output detection in xorg.conf :/
The G550 dual dvi still has the same stupid problems as always. Another big issue is hardware cursor support. The problem is that Matrox' G series cards only have one hardware cursor, which is tied to CRTC1. For the 2nd CRTC, there's no hardware cursor. Unfortunately, the randr 1.2 API for hardware cursors works correctly only if every CRTC has a hardware cursor, so we can't use it (yet).
I've also done some EXA work--it seems that most (all?) of my previous tests were flawed. I think that EXA's pixmap migration caused EXA not calling into the MGA code for all operations. A few days ago I told it to always migrate pixmaps from system to video RAM and vice versa, and voila, GTK+ apps were unusable because all those nice Over blends that it does were fucked up. Anyway, I managed to fix that. Doing full rendercheck runs on G450 and G550 then revealed that the A8 writes problem isn't fixed at all. Previously I thought that only Add operations on A8 textures were b0rked, but it turns out that all A8 writes are broken. On both the G450 and G550. Bogus tests ftw \o/
Tags xorg, mga
Posted at 2007-03-18
I finally pushed the initial bits of MGA RandR1.2 support earlier.
It's not finished, so it might fry your card. Just don't use it yet.
There's one pretty annoying problem, too. Somehow I managed to break the UploadToScreen hook that's needed for EXA. So, someone fix that please. kthxbye.
Update
Heh. In the current xorg-server, the default migration scheme for EXA has been changed from "greedy" to "always" -- making it use "greedy" again miraculously fixes UploadToScreen.
Tags xorg, mga
Posted at 2007-03-10
I finally had some progress with RandR1.2 support in the MGA driver: Yesterday I got mergedfb to work on my G450 dual VGA. It's not perfect yet, eg I cannot go from clone mode (CRTC2 inactive) to mergedfb, instead I need to fire up CRTC2 from the start. That should be fixable though. I expect that adding support for DVI (at least single DVI) will be easy as well.
Expect the code to hit git in a few days :)
Tags xorg, mga
Posted at 2007-02-03
I'm not sure why, but in September or October last year I decided to do more work on the MGA driver for Xorg. Back then the only card I had was a G450 Marvel eTV, so I figured it would be good to have more cards to test stuff on. I probably wanted to test the EXA code on other cards, too. Later last year I wanted to improve/fix DVI and dual head support which meant I actually had to get a DH card.
So in the last four months I grabbed a bunch of MGA cards, and the list now looks like this:
- G200. One VGA output. Pretty boring, but it's good to have around for regression tests.
- G450 Marvel eTV. One VGA output, TV out, TV in.
- G450 Dual Head. Two VGA outputs.
- G450 DVI. One DVI output, but it comes with a cable that gives you two VGA outputs.
- G550 Dual DVI. Features Matrox' LFH60 connector.
- G550 DVI/VGA. One VGA output, one DVI output.
I think I should also get one of the oldish Millenium (2064?) cards, because they got a different DAC than the newer ones. Having a G400 dual head would be good, too, cause dual head is completely (?) different as compared to G450/G550 on that card (Maven I2C madness).
At the moment I'm trying to reorganize the MGA code into CRTC and output specific parts, to support RandR 1.2 sanely. That should help making the code much more readable, too.
Tags mga, xorg
Posted at 2007-01-08
Last week I hacked on Dave Airlie's valgrind-mmt.
Features I implemented:
- Support for tracking write-only registers. This is done by asking Valgrind for the value that the application wanted to set, rather than reading the register after it was set.
- Support for tracking register reads. Actually you have to comment out some code (it's pretty obvious which) to make it not track those. FIXME :)
- The MMIO address isn't hardcoded anymore, but it's set with an command line argument (--offset). Weird stuff will happen if you don't set the offset.
- It now tracks up to 100 MMIO areas instead of just one. This hardcoded limit is butt-ugly, but 100 mmaps should be enough for everyone, right? ;)
- It probably only works on 32 bit arches now, and 64 bit registers are not supported.
Here's the diff against Valgrind SVN trunk.
Tags valgrind, xorg
Posted at 2006-12-27
I gave myself a second DFP as a pre-christmas gift and tried to get dual DVI working on my G550.
One weekend and the holidays later, I can now power on the second DFP, and make it display the expected contents. I think the only problem left is that it's distorted. The visible area isn't shown at 0|0, but at a random point, it seems. So it's not usable yet, but I'm getting there.
Tags xorg, mga
Posted at 2006-08-26
I've been trying to get EXA working on MGA for the past few weeks. ajax posted a patch based on kdrive MGA driver on Bugzilla, and I fixed several nasties there.
Because of my own stupidity I couldn't get the Copy hooks working until yesterday. But now the two basic operations Solid and Copy are working nicely, it seems!
Getting composite to work is nasty though, I doesn't work at all atm :/
Update
Composite is working a little bit; the problem was a bad define for the TEXTURE_TRAP opcode \o/
Update2
I suck at keeping this updated. Composite works mostly well, though there's some font rendering issues left. Expect a merge from the exa branch to master soonish (with either the bug fixed or a software fallback put in place).
Tags xorg, mga
Posted at 2005-12-30
A couple of weeks ago, I began porting X11R7.0 to CRUX. It was a good chunk of work (it's 209 ports so far), but it's working nicely.
Having a modular tree instead of the monolithic one is awesome :)
I created a new repository for the X ports, it's available via httpup
Installing these ports manually is not recommended, use "prt-get depinst xorg" instead :)
Let me know if there are any problems.
Tags crux, xorg
