Subject: PSARC FastTrack [01/29/2007]: Xorg server upgrade to 7.2
I am sponsoring this fasttrack for myself, with a timeout of January 29.
The release binding is Patch/Micro. Note that I have set this to be an
externally visible case, with mail going to psarc-ext at sun.com &
xwin-discuss at opensolaris.org.
[Sorry to PSARC members who got this already on the internal alias -
apparently sac_nextcase outwitted me and redirected the e-mail behind
my back - please reply to this one instead.]
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Template Version: @(#)sac_nextcase %I% %G% SMI
Copyright 2007 Sun Microsystems, Inc.
1. Introduction
1.1. Project/Component Working Name:
Xorg server upgrade to 7.2
1.2. Name of Document Author/Supplier:
Author: Alan Coopersmith
1.3 Date of This Document:
22 January, 2007
4. Technical Description
Xorg server upgrade to 7.2
==========================
This project upgrades the Xorg server in Solaris from X11R6.9 to X11R7.2,
and adds several new features which were not previously included in the
Solaris builds.
Upstream architectural changes from Xorg community:
---------------------------------------------------
Xorg command line changes:
Several changes have been made to the Xorg command line options since 6.9:
Added to all Xorg-based servers:
-wr sets the default root window to solid white instead
of the standard root weave pattern.
-ardelay milliseconds
sets the autorepeat delay (length of time in mil-
liseconds that a key must be depressed before
autorepeat starts).
-arinterval milliseconds
sets the autorepeat interval (length of time in mil-
liseconds that should elapse between autorepeat-
generated keystrokes).
-ardelay was formerly known as -ar1, -arinterval was -ar2 - the old
names are still accepted by the code to preserve compatibility, but
are no longer documented in the manual page or usage message.
Added to Xorg only:
-showDefaultModulePath
Print out the default module path the server was
compiled with.
-showDefaultLibPath
Print out the path libraries should be installed to.
Removed from all Xorg-based servers:
bc disables certain kinds of error checking, for bug
compatibility with previous releases (e.g., to work
around bugs in R2 and R3 xterms and toolkits).
Deprecated.
-xkbdb filename
uses filename for default keyboard keymaps.
-noloadxkb
disables loading of an XKB keymap description on
server startup.
Removal of LBX extension:
The LBX (Low-Bandwidth X) extension supported in previous versions of
the Xorg server has been removed. The community suggests using either
ssh -X with compression or the NX project from www.nomachine.com.
This project only removes LBX from the extensions supported by Xorg and
leaves the client side support intact (lbxproxy command and functions in
libXext) in Solaris.
Removal of CID font support:
The Xorg server no longer supports CID-keyed PostScript Type 1 Fonts.
These were originally created to support East Asian character sets in
Type 1 fonts, but have since been replaced almost universally by
TrueType and OpenType fonts. Removal of CID fonts in Solaris was
listed as a future EOF in the Solaris 9 release notes, and the last
known CID fonts shipped in Solaris were removed in s10_48.
Removal of getconfig:
Previous versions of Xorg, when run without a config file, ran a perl
script at startup time to map discovered PCI device id's to driver names
to load. Starting a perl interpreter at Xorg startup added to the
startup time, and the flexibility offered was not really used, so Xorg
has replaced this with a table built into the X server in the 7.2 release.
The only use of getconfig on Solaris was a override file provided by the
accelerated drivers from Nvidia to load their "nvidia" instead of the
open source "nv" driver when their kernel module was installed. For this
release, the hardcoded mapping in the Xorg server has been updated to
prefer the nvidia driver when it is installed. A future project is planned
to develop a more flexible method to map VIS_GETIDENTIFIER ioctl results
to driver modules for mapping Solaris kernel frame buffer drivers to Xorg
driver modules in a way that works on SPARC, x86, and Sun Ray, but without
the overhead of starting a perl interpreter.
XACE (X Access Control Extension) API:
XACE is not an actual extension to the X protocol, but a framework inside
the X server to be used by other extensions. It was originally developed
by the SELinux team at the NSA, and integrated into Xorg 7.2 by Sun & NSA
engineers who made sure it could serve as a common framework for both
SELinux and Solaris Trusted Extensions.
http://people.freedesktop.org/~ewalsh/xace_proposal.html describes XACE as:
The XACE (X Access Control Extension) is a set of generic "hooks"
that can be used by other X extensions to perform access
checks. The goal of XACE is to prevent clutter in the core dix/os
code by providing a common mechanism for doing these sorts of
checks. The concept is identical to the Linux Security Module (LSM)
in the Linux Kernel.
XACE is a generalization of the "Security" extension, which
provides a simple on/off trust model, with untrusted windows being
restricted in certain areas. Most of XACE consists simply of
replacing the Security-specific checks in the dix/os layer with
generic callback lists. However, the framework is flexible enough
to allow for hooks to be added or deprecated in the future.
LSARC 2004/109 added similar hooks to the Xorg server for the Xtsol
extension module to be able to insert security checks when loaded.
These hooks were a Project Private interface between the Xorg binary
delivered via the X consolidation and the Xtsol module delivered via
the TLC consolidation (aka the Trusted Extensions product).
To avoid cross-consolidation coordination issues, this project will
allow the Xtsol extension to use the existing interfaces to install
their hooks into the XACE callback lists. A future project will work
on migrating the Xtsol extension from its Project Private interfaces
for installing callback functions to using the standard XACE
functions to register callbacks.
Supported architectures:
------------------------
Solaris currently only includes 32-bit x86 binaries for Xorg 6.9.
This project adds 64-bit x86 and 64-bit SPARC binaries for the Xorg
server and loadable modules as well.
64-bit versions are provided since Sun has had multiple customer
requests for X servers that can address more than 4 gb worth of
address space in order to allow storing large amounts of pixmap and
other data in the X server instead of making the X clients retransmit
them. Additionally, with video cards now shipping with 1gb of
on-board video RAM and roadmaps showing increases still coming in the
future, 64-bit addressing is needed to be able to address all the
VRAM on multi-card systems now, and potentially in the future
on a single frame buffer.
Since current Solaris releases feature only a 64-bit kernel on SPARC,
and there are no current SPARC Xorg modules to retain compatibility
with, there is no reason to ship a 32-bit Xorg server on SPARC, while
on x86 both 32-bit & 64-bit CPU's are supported.
Thus on SPARC platforms, /usr/X11/bin/Xorg will be a SPARCv9 binary.
On x86 platforms, this project will deliver the Xorg server as both
/usr/X11/bin/i386/Xorg
/usr/X11/bin/amd64/Xorg
When integrated into a minor release of Solaris on x86, this project will
deliver /usr/X11/bin/Xorg as a link to /usr/lib/isaexec to automatically
pick the bit-size matching the current kernel.
When integrated into a patch release of Solaris on x86, this project will
deliver /usr/X11/bin/Xorg as a link to /usr/X11/bin/i386/Xorg to preserve
compatibility with existing 3rd-party Xorg modules.
(Currently, the project team is aware of only one existing 3rd-party module
for Xorg on Solaris - the nvidia driver from Nvidia. We are working with
Nvidia to have them provide a 64-bit version of this driver for Solaris as
they already do on Linux. When available, the 64-bit driver will be
delivered in Solaris Nevada and in future Solaris 10 updates, but existing
Solaris 10 users may have a 32-bit version only installed, so switching to
a 64-bit default Xorg in a patch would break those users.)
Customers on either release who wish to override the default may do so by
changing the server property of the x11-server SMF property to specify
/usr/X11/bin/i386/Xorg or /usr/X11/bin/amd64/Xorg.
Driver differences per architecture:
------------------------------------
The 32-bit x86 Xorg will continue to include the same drivers currently
provided in Xorg 6.9 (with updates to add new hardware support to some).
The 64-bit x86 Xorg will provide a subset of those drivers, not including
support for older hardware unlikely to be found in AMD64/EM64T-capable
machines.
Graphics device driver modules which will be included in 64-bit x86 Xorg:
ati_drv.so - wrapper for atimisc/radeon/r128
atimisc_drv.so - ATI Mach64, early Rage models
radeon_drv.so - ATI Radeon 7000->X850
r128_drv.so - ATI Rage 128
vesa_drv.so - VESA standard fallback
vga_drv.so - VGA standard fallback
ast_drv.so - Aspeed Tech remote KVM (used in Sun AMD64 servers)
i810_drv.so - Intel i810->i965
mga_drv.so - Matrox
nv_drv.so - nVidia GeForce/Quadro
trident_drv.so - Trident (on-board graphics chip in Sun V20z)
via_drv.so - VIA
vmware_drv.so - VMWare simulated display
For comparison, these are the ones we ship 32-bit versions of that we've
skipped 64-bit versions of:
apm_drv.so - Alliance Promotion (production ended 1998)
ark_drv.so - Ark Logic
chips_drv.so - Chips & Technologies
cirrus_alpine.so - Cirrus Logic
cirrus_drv.so - Cirrus Logic
cirrus_laguna.so - Cirrus Logic
cyrix_drv.so - Cyrix MediaGX
glint_drv.so - 3Dlabs/TI glint
i128_drv.so - Number Nine Imagine 128 (bankrupt 2000)
i740_drv.so - Intel i740
neomagic_drv.so - NeoMagic (mid-late 90's laptops)
nsc_drv.so - National Semiconductor
rendition_drv.so - Rendition Verite (Windows support dropped
after Win98/NT4)
riva128.so - nVidia Riva/TNT
s3_drv.so - S3 (not ViRGE or Savage)
s3virge_drv.so - S3 ViRGE & Trio3D
savage_drv.so - S3 Savage
siliconmotion_drv.so - Silicon Motion
sis_drv.so - SiS, XGI Volari
tdfx_drv.so - 3Dfx (bankrupt 1999)
tga_drv.so - DEC 21039/TGA
tseng_drv.so - Tseng Labs
There is no known architectural reason why additional drivers from the
32-bit only list could not be provided in 64-bit format should a business
case arise (or no reason a user/community member couldn't build their own
from the X.Org open source release and use them without Sun support).
For SPARC, the only graphics driver that will be provided by this project
in SUNWxorg-graphics-ddx is wsfb_drv.so, which uses <sys/fbio.h> and
<sys/visual_io.h> ioctls to map /dev/fb and treat it as a dumb frame buffer,
on frame buffer devices in which the Solaris kernel driver supports such
access. Later projects from the SPARC Graphics team in the Systems Group
will deliver device-specific Xorg driver modules for SPARC frame buffers.
The dummy_drv.so used to provide a Xvfb-like memory-based non-displayed
screen will also be provided with Xorg on SPARC.
For input devices, Xorg on SPARC will include only the driver modules
kbd_drv.so (Keyboard), mouse_drv.so, and void_drv.so (input placeholder
module for when it is desired to run without keyboard or mouse).
Other differences per archictecture:
------------------------------------
As an OpenGL architecture is already provided for SPARC by the SPARC
Graphics group, Mesa will not be delivered with Xorg on SPARC.
On x86/x64 platforms, Xorg is installed setuid root. The 64-bit Xorg for
x86 will be installed setuid root as well.
On SPARC platforms, Xorg will be installed setgid root, as Xsun has always
been on SPARC.
X servers currently need either gid 0 or uid 0 to get the privilege levels
necessary for these operations:
- Power Management via /dev/pm (both platforms)
- priority control of processes in IA class via priocntl() (both platforms)
X servers currently need uid 0 to get the privilege levels necessary for
these operations:
- access to PCI bus registers and mappings via /dev/xsvc (x86/x64 only)
- ability to set I/O Privilege Level (IOPL) via sysi86 (x86/x64 only)
When started via a display manager such as dtlogin or gdm, Xorg is started
as uid 0 by the display manager, and once the user logs in via the display
manager, it sets it's uid to the logged in user. (This is after initializing
the hardware, setting the IOPL and mapping /dev/xsvc, so uid 0 is no longer
needed at that point.)
Non-hardware based X servers:
-----------------------------
Xnest is an X server which displays in a window on another X server, for
uses such as running a full remote desktop session inside your current X
session, or for running a session as another user, as gdmflexiserver does.
Xvfb is an X server which renders to an in-memory frame buffer but does
not display itself anywhere, which is often used for graphics applets on
web servers to do rendering which is then shipped via http to a web browser,
or for running X applications unattended.
Solaris currently includes Xnest & Xvfb X servers based on the Xsun code,
shipped in /usr/openwin/bin. (Xvfb is actually just a shell script which
calls Xsun with appropriate arguments [PSARC/2002/282].) Thus, when
Xsun is EOF'ed, replacements will be needed for those X servers.
This project adds two additional X server programs to Solaris: Xephyr and
Xorg-based Xvfb. Both will be built out of the Xorg tree, and will be
shipped in /usr/X11/bin/ via the SUNWxorg-server package on both SPARC & x86.
Xvfb will be mostly a drop in replacement for the existing Xvfb, though with
the Xorg command line syntax and supported extension set instead of those of
Xsun.
Xephyr is somewhat of a hybrid between Xnest & Xvfb, displaying in a window
on another X server as Xnest does, but doing all the rendering itself to an
in memory framebuffer like Xvfb that it then displays as a bitmap image.
This allows it to support extensions like Xrender and Xcomposite even when
the underlying X server does not, as well as avoiding several of the design
issues that have long plagued Xnest, such as mismatches between the font sets
supported by the Xnest server vs. the underlying X server. We are intending
it to serve as the replacement for Xnest.
On SPARC, Xvfb & Xephyr will be delivered as 64-bit binaries to be able to
share private libraries with the Xorg server.
On x86, Xvfb & Xephyr will be delivered as both 32-bit & 64-bit binaries,
with the main bin directory having an isaexec wrapper to choose the bit-size
matching the current kernel. (Similar to the Xorg on x86 in minor release
layout described above.)
Imported interfaces
-------------------
isaexec Stable [Committed] PSARC 1997/220
Xorg CLI External [Volatile] PSARC 2004/187
Exported interfaces
-------------------
Xorg CLI changes Volatile
Xvfb Volatile
Xephyr Volatile
LBX extension Obsolete Previously Standard (PSARC 1998/299)
/usr/openwin/bin/Xnest Obsolete Previously Standard (PSARC 1998/299)
/usr/openwin/bin/Xvfb Obsolete Previously Standard (PSARC 1998/299)
getconfig Removed Previously External (PSARC 2004/187)
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
X Consolidation - Desktop C-Team
6.5. ARC review type: FastTrack
