Nouveau Companion 41

Besides the usual bug fixing, stillunknown started on coding a kernel mode setting driver for G8x (details here). Having problems with a black screen, he turned to mmiotrace and found the problem (details here). A few days later he committed his first version to mesa/drm/modesetting-101 (details here). Pq did some smaller code review and noticed a few memory leaks and typos which were promptly fixed by stillunknown. Further work, however, was put on hold due to the need of a proper memory management.

pmdata started his work on NV3x Gallium3D. He copied the NV4x code path and changed the state emission to work with data from objects instead of directly writing commands to the GPU. That work was finished about 2 weeks later (details here).

Darktama worked on NV50. Thanks to him, the 2D part gained support for EXA composite and Xv. The support has some drawbacks, though:

- Compositing manager is needed for Xv
- They should be working on most NV50 based cards. At least NV84 and NV86 should work, as well as the NV50 (= original 8800GTS). All cards having context stuff in the DRM should work. If not, let us know!
- By the way: EXA solid() and copy() were there from the beginning, as they are required by EXA. Stillunknown and malc0 added some fixes for mode-setting during this coding spree.

Marcheu finally solved the problem with the fixed pipelines for Gallium3D, but did not have to code it yet. P0g started with NV1x work got the gears to render and waited for Marcheu to start coding the solution. Marcheu suggested doing the fixed pipeline stuff as an LLVM optimization pass (LLVM is a feature in Gallium).

Randr1.2 code had problems when the EDID data channel of the LVDS (laptop panel) was wired but did not respond. That left the code without a screen resolution to work with. Stillunknown hunted through the BIOS in order to find out where the native resolution was exactly stored and came up with a fix a few days later (bug report). But it was not to be: Alphix still reported problems.

There has been some uncertainty whether Nouveau would use GEM or TTM. Well, we use both as GEM is not a complete memory manager, but an interface which needs to be implemented in the driver. As darktama put it on June 5th:

"I have (semi-complete) code somewhere for Nouveau drm/gallium on ttm, that's not stalled for any other reason than I want to get some g8x stuff sorted first since it could effect our mm requirements that said, I don't know which will prevail, I'm not really too concerned though..there's plenty of hw issues/features to deal with first [...] Nouveau will probably use TTM [behind he GEM API]."

The various -ng branches are a playground for GEM interface with TTM behind the scenes (details here). They should mostly work, but with numerous bugs that need to be fixed, and some things that Darktama wants to rework. It is good enough to play with KMS on NV4x (malc0's code) and nv5x, and Compiz works quite well on NV4x since DRI2 support appeared. (And no: We won't help you getting it to work just yet, you are on your own trying :)).

On the other hand, TTY restore for NV5x cards is still done via video BIOS (int10) calls.