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
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
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
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
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.