Index:
[thread]
[date]
[subject]
[author]
From: Torgeir Veimo <Torgeir.Veimo@vertech.no>
To : GGI <ggi-develop@eskimo.com>
Date: Sun, 02 Aug 1998 23:36:39 +0200
[Fwd: 3.9N]
--
-Torgeir
Return-Path: <root@x.physics.usyd.edu.au>
Delivered-To: vertech-torgeir@vertech.no
Received: (qmail 3716 invoked from network); 2 Aug 1998 17:54:45 -0000
Received: from x.physics.usyd.edu.au (129.78.129.25)
by 195.204.179.10 with SMTP; 2 Aug 1998 17:54:45 -0000
Received: (from daemon@localhost)
by x.physics.usyd.edu.au (8.8.5/8.8.5) id AAA03418
for members-list@XFree86.Org; Mon, 3 Aug 1998 00:24:18 +1000 (EST)
Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109])
by x.physics.usyd.edu.au (8.8.5/8.8.5) with ESMTP id AAA03413
for <members@XFree86.Org>; Mon, 3 Aug 1998 00:24:13 +1000 (EST)
Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id AAA20041; Mon, 3 Aug 1998 00:24:12 +1000 (EST)
Message-ID: <19980803002412.E24600@rf900.physics.usyd.edu.au>
Date: Mon, 3 Aug 1998 00:24:12 +1000
From: David Dawes <dawes@rf900.physics.usyd.edu.au>
To: members@XFree86.Org
Subject: 3.9N
Reply-To: devel@XFree86.Org
Mail-Followup-To: members@XFree86.Org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
Errors-To: owner-members@XFree86.Org
X-Mailing-List: members@XFree86.Org
X-Note: Send unsubscribe requests to members-request@XFree86.Org
XFree86 3.9N is now available. This is the first alpha version containing
the "new design" code.
For those who don't already know, a little over a year ago a small group
started working on a new XFree86 server design in a separate branch from
the main development line. 3.9N represents the merge of this work back
into the main development line. This is an important step along the
way to the 4.0 release, but there is still a lot more work to be done
(see below). Some people might initially be shocked/surprised by the
extent of some of the driver changes, but I believe that this is an
exciting step in XFree86 development. The potential is there for a
seriously impressive 4.0 release.
This version is available in three forms:
1. New source tarballs (in /pub/xf86/beta/Source):
X39Nsrc-1.tgz
X39Nsrc-2.tgz
X39Nsrc-3.tgz
or
X39N-servonly.tgz
for those that only want the server source
2. A patch against 3.9Ak and a script to remove some directories that are
no longer needed (in /pub/xf86/beta/patches-alpha):
3.9Ak-3.9N.diff.gz
3.9N.sh
3. A patch against 3.9jw (in /pub/xf86/beta/patches-nd):
3.9jw-3.9N.diff.gz
Both of the patches are large (5-10MB).
If you use CVSup you don't need to worry about any of the above.
Before attempting to do anything much with 3.9N, read through the
"DESIGN" document (there is a copy in /pub/xf86/beta/, and also in the
source tree directory xc/programs/Xserver/hw/xfree86). Also read through
the notes included below.
David
--
Here are some more or less random notes about the new design (ND) and
the merge. They are in no particular order, and I have almost certainly
forgotten to mention some important things.
- The "merge" consisted of merging all of the non-driver code. Driver
maintainers will need to convert their drivers for use with the new
design. This will be a significant task, more so in some cases than
others. Drivers that are not converted will clearly not work in 4.0
(there is no compatibility mode with the old design).
- It is possible that some things have been missed in the merge. One area
I'm sure will need checking is the parallel make support. Copyright
notices in files affected by the merge may need to be updated/adjusted
too. If you notice anything that seems to have been missed, send
details to the devel list.
- The mga, vga, tseng, chips, glint and tga drivers are the only ones
"usable" with the new design so far. These are at varying levels of
completeness. The mga driver for example works fine with some chipsets,
but needs to be resynchronised with the most recent version from the
old design (a volunteer to do this would be welcome). The 3.9Ak
version of the mga driver can be found in the xfree86/olddrivers/mga
directory.
- There is now a single X server binary called "XFree86". The same name
is used for both the loader version and the static version. It is
envisaged that this binary name will be common to all platforms and that
the hw/xfree98 and hw/xfree68 directories will eventually disappear.
In the xfree98 case, it is expected that a single core server binary
will be usable on both PC98 and "AT" ix86 hardware.
- It is possible to build three main server/module types. The default
for most platforms is the standard loader server which uses portable
modules loaded by the builtin loader. One other is a static server.
This has everything statically linked. The old system of allowing
dlopen-modules to be loaded by such a static server is no longer
supported. The third form is the standard loader server, but with the
modules in "dlopen" format. This last format is intended primarily
for development purposes (these modules can be debugged), and for
temporary use on platforms that the builtin loader doesn't yet know
about. The imake config variables that control this are:
DoLoadableServer (set this to NO to build a static server)
MakeDllModules (set this to YES to build dlopen-style modules)
- There is active work going on to extend gdb to support the portable
loading scheme. A first Linux binary of such a gdb will be available
soonish.
- Xnest, Xvfb and Xprt are not really buildable at them moment except
when building static servers. This will be fixed soon.
- The VidMode and XFree86-Misc extensions are disabled by default, and
need work on the server side before they will be usable again. They
will be reimplemented with more consideration of layering.
- The DGA extension is mostly implemented, but none of the drivers currently
have support for it enabled. Also this extensions will be extended in
the near future.
- The DPMS extension should be fairly complete, and some drivers have support
for it enabled.
- When building 3.9N for the first time, start with a fairly empty host.def
file. Things that cannot be built at the moment are disabled by default.
You may find that some of the things you would normally have in your
host.def file will cause problems when building 3.9N. I've tested
building 3.9N on FreeBSD 2.2.5 (all three server types), Linux (static),
SVR4.0 (loader) and Solaris 2.6 (static and loader). If you have
problems building on any platforms with an empty host.def, send details
to the devel list.
- The core of the new design is multi-head friendly. That means that it
possible to have multi-head drivers. Alan has demonstrated that this
works with the glint driver.
- A machine-independent banking layer has been added (by Marc La France).
This makes it possible to support cards with banked framebuffers at depths
higher than 8.
- XAA has been significantly reworked, largely by Mark Vojkovich. XAA
needed to be reworked to fit in with the multi-head friendly structure
of the new design. At the same time framebuffer dependencies have
been removed and it now fits in nicely with the X server layer/wrapper
architecture. I hear that there have been some performance improvements
too.
- A framebuffer memory manager has been added to handle the use of offscreen
memory. This is currently used by the pixmap cache code in XAA, but it can
be used for other things that require offscreen memory.
- Font renderers are now loadable modules. The bitmap module is always loaded
automatically by the server. Others can be loaded via the config file.
A future enhancement might be to make them loadable on demand. The FreeType
renderer hasn't been made into a loadable module yet, but this will be done
when the FreeType code is updated in the near future.
- Nothing has been done yet with XInput driver modules, and building these
is disabled by default. They will be taken care of in the not too
distant future.
- There have been some changes to the config file. Some of these were
possibly visible when the old server migrated to the new config file
parser. With the addition of Options that can take values there has been
a move away from some of the less core config file keywords to Options.
Some keywords are still recognised, but are converted to Options internally.
A few things have moved around. None of this is really documented yet.
As an example, here is what a config file for a server driving two
Millennium cards might look like:
Section "Module"
Load "dbe"
SubSection "extmod"
Option "omit xfree86-dga" # don't initialise the DGA extension
EndSubSection
EndSection
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
FontPath "/usr/X11R6/lib/X11/fonts/misc/"
FontPath "tcp/fonthost:7100"
ModulePath "/usr/X11R6/lib/modules"
EndSection
Section "ServerFlags"
Option "dont zoom"
Option "blank time" "10"
Option "standby time" "20"
Option "suspend time" "30"
Option "off time" "60"
EndSection
Section "Keyboard"
Protocol "standard"
XkbModel "microsoft"
XkbLayout "us"
EndSection
Section "Pointer"
Protocol "Auto"
Device "/dev/mouse"
Buttons 3
EndSection
Section "Monitor"
Identifier "Monitor 1"
HorizSync 30-86
VertRefresh 50-150
ModeLine "1280x1024" 135 1280 1312 1416 1664 1024 1027 1030 1064
Option "dpms"
EndSection
Section "Monitor"
Identifier "Monitor 2"
HorizSync 30-86
VertRefresh 50-150
ModeLine "1280x1024" 135 1280 1312 1416 1664 1024 1027 1030 1064
Option "sync on green"
EndSection
Section "Device"
Identifier "MGA 1"
Driver "mga"
Option "hw cursor" "off"
BusID "PCI:0:10:0"
EndSection
Section "Device"
Identifier "MGA 2"
Driver "mga"
BusID "PCI:0:12:0"
EndSection
Section "Screen"
Identifier "Screen 1"
Device "MGA 1"
Monitor "Monitor 1"
Option "pci retry"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1280x1024"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen 2"
Device "MGA 2"
Monitor "Monitor 2"
DefaultDepth 8
Subsection "Display"
Depth 8
Modes "1280x1024"
Visual "StaticColor"
Option "rgb bits" "8"
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Main Layout"
Screen "Screen 1" "" "" "" "Screen 2" # 2 is to the right of 1
Screen "Screen 2" "" "" "Screen 1" ""
EndSection
We need someone with experience in technical documentation to write up a
good description of the updated config file format, as well as more
generally making a start on getting our documentation in order for 4.0.
Unlike what happened with previous releases, we need to work on the
documentation in tandem with the code. Some people have joined this team
recently with the explicit purpose of helping to improve out docs. This
is a good starting point.
- Command line options "-screen" and "-layout" have been added to the X
server to allow one of multiple of those sections that might be in a
config file to be specified.
- Depth and bpp have often been used interchangeably, and often incorrectly
so. These terms are now used more precisely by the X server. It now
has separate -depth and -bpp command line options, as well as
"DefaultDepth" and "DefaultBpp" Screen section entries and "Depth"
and "Bpp" Display subsection entries. "bpp" refers to the pixmap bpp.
It is possible to separately specify the framebuffer bpp (-fbbpp),
although no drivers currently support a mode of operation where this
is useful. Some of this stuff (particularly the choice of defaults)
is still experimental and may change before 4.0 is released.
- When building with gcc, the default imake config enables lots of warning
flags. This generates huge amounts of warnings in many sections of the
code. The plan is to clean up a lot of these in line with our move to
stricter ANSI C. There are however some that will probably never be
eliminated because they are generated by acceptable code. When working
on an area of code you might find it useful to redefine GccWarningOptions
in your host.def file to reduce the noise level if it is making more
serious compiler warnings/errors hard to pick out. As the area of
code is stabilised you should reenable the full set of warning options
and investigate any warnings that are generated. Fix those that are
valid, but don't go through contortions to eliminate every last warning
if it is flagging code that is "acceptable".
- We are planning to define both APIs and ABIs for modules, particularly
drivers modules, and we're planning to have the first version of these
ready in time for the 4.0 release. The ABIs are versioned with major
and minor versions, and an important aim is avoid retain backward
compatibility by minimising changes to the major versions.
- The basic new design is detailed in the DESIGN document. The new
design provides a lot of flexibility to drivers, but at the same time
there is a basic set of strict design rules that drivers must conform
to. While the core aspects of these are fairly well developed, there
is room for changes prior to the release of 4.0, and there are some
issues that are still open. If you find that a driver you are working
on needs some changes to the basic specs, raise the issue immediately
on the "devel" list. All code submissions will be reviewed before
being accepted, but changes to the basic design will usually be rejected
unless they are discussed in advance.
- The driver flexibility in the new design comes at a cost, and that cost
is an increase in the driver responsibility and complexity. To help
with this, the XFree86 common layer provides a set of "helper" functions
to do a lot of the things that would otherwise be duplicated in most
drivers. The aim with these helper functions is to find a balance between
an interface that is useful to many drivers and an interface that isn't
too complex or obscure for most drivers. All of these helper functions
are optional, and it is expected that some drivers will find some of the
unsuitable and need to provide their own code for those things.
It is expected that there will be a relatively small number of basic driver
structures for different types of video chipset families, and that the
effort of writing a new driver can be reduced by providing a set of
driver templates for the different types.
Index:
[thread]
[date]
[subject]
[author]