Alan:

Sorry for responding after the timeout, but I just upgraded to the
Xorg 7.2 and have some questions.  Overall, looks great and seems
faster than the old Xserver.

However, I'm a bit annoyed that the full set of Xorg *.pc files don't
seem to be installed to /usr/lib/pkgconfig (e.g. x11.pc, xext.pc,
Xdamage.pc, xtst.pc, etc.).  Why is this?  I thought we were finally
going to resolve this with the port to 7.2?

Brian


> 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
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org


Reply via email to