From sacadmin Mon Jan 22 18:40:40 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N2edcM005676; Mon, 22 Jan 2007 18:40:40 -0800 (PST) Received: (from alanc@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id l0N2edRI005672; Mon, 22 Jan 2007 18:40:39 -0800 (PST) Date: Mon, 22 Jan 2007 18:40:39 -0800 (PST) From: Alan Coopersmith Message-Id: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: Alan.Coopersmith@Sun.COM Subject: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] Status: RO Content-Length: 15960 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@sun.com. -Alan Coopersmith- alan.coopersmith@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 and 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 From alan.coopersmith@sun.com Mon Jan 22 18:45:04 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0N2j4v0005773 for ; Mon, 22 Jan 2007 18:45:04 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0N2j3Wp006111; Mon, 22 Jan 2007 18:45:04 -0800 (PST) Message-ID: <45B576AF.2010606@sun.com> Date: Mon, 22 Jan 2007 18:45:03 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: PSARC-EXT@sac.sfbay.sun.com CC: Alan.Coopersmith@sun.com, OpenSolaris X Windows Mailinglist Subject: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 16299 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@sun.com & xwin-discuss@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@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 and 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 From sacadmin Tue Jan 23 03:24:10 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NBOAUS014266; Tue, 23 Jan 2007 03:24:10 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NBO9UL005680; Tue, 23 Jan 2007 03:24:09 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NBO3B1004160; Tue, 23 Jan 2007 11:24:04 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00G01JKE2V00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 23 Jan 2007 11:24:03 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB0062VJO34S10@d1-emea-09.sun.com>; Tue, 23 Jan 2007 11:24:03 +0000 (GMT) Date: Tue, 23 Jan 2007 11:24:03 +0000 From: Darren J Moffat Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com, Alan.Coopersmith@Sun.COM Message-id: <45B5F053.3050709@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 631 Alan Coopersmith wrote: > For comparison, these are the ones we ship 32-bit versions of that we've > skipped 64-bit versions of: > cirrus_alpine.so - Cirrus Logic > cirrus_drv.so - Cirrus Logic > cirrus_laguna.so - Cirrus Logic Qemu emulates a CL-GD5446 and provides support for running in 64bit. Would that mean it would be useful to have one of these as 64bit or would the 64 bit vesa_drv.so be sufficient ? Given that this is X11R7.2 is there going to be a /usr/X11R7 symlink that points to /usr/X11 ? What happens to the existing /usr/X11R6 symlink that currently points to /usr/X11 ? -- Darren J Moffat From Darren.Moffat@Sun.COM Tue Jan 23 03:25:00 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NBP01f014278 for ; Tue, 23 Jan 2007 03:25:00 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NBOxQd021217 for ; Tue, 23 Jan 2007 03:24:59 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NBOr4K027665 for ; Tue, 23 Jan 2007 11:24:53 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00D01HVL3C00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sac.sfbay.sun.com; Tue, 23 Jan 2007 11:24:53 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB00633JPA4S10@d1-emea-09.sun.com> for PSARC-EXT@sac.sfbay.sun.com; Tue, 23 Jan 2007 11:24:47 +0000 (GMT) Date: Tue, 23 Jan 2007 11:24:46 +0000 From: Darren J Moffat Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <45B576AF.2010606@sun.com> Sender: Darren.Moffat@Sun.COM To: Alan Coopersmith Cc: PSARC-EXT@sac.sfbay.sun.com, OpenSolaris X Windows Mailinglist Message-id: <45B5F07E.2040801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <45B576AF.2010606@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 645 Alan Coopersmith wrote: > For comparison, these are the ones we ship 32-bit versions of that we've > skipped 64-bit versions of: > cirrus_alpine.so - Cirrus Logic > cirrus_drv.so - Cirrus Logic > cirrus_laguna.so - Cirrus Logic Qemu emulates a CL-GD5446 and provides support for running in 64bit. Would that mean it would be useful to have one of these as 64bit or would the 64 bit vesa_drv.so be sufficient ? Given that this is X11R7.2 is there going to be a /usr/X11R7 symlink that points to /usr/X11 ? What happens to the existing /usr/X11R6 symlink that currently points to /usr/X11 ? -- Darren J Moffat From mb1x@gmx.com Tue Jan 23 03:37:19 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NBbJbO014393 for ; Tue, 23 Jan 2007 03:37:19 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NBbJLW008438 for ; Tue, 23 Jan 2007 03:37:19 -0800 (PST) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0NBbJE8013667 for ; Tue, 23 Jan 2007 03:37:19 -0800 (PST) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay23.sun.com with ESMTP for PSARC-EXT@sac.sfbay.sun.com; Tue, 23 Jan 2007 11:36:52 Z Received: from relay21.sun.com (relay21.sun.com [192.12.251.14]) by mms25es.sun.com with ESMTP for PSARC-EXT@sac.sfbay.sun.com; Tue, 23 Jan 2007 11:36:52 Z Received: from mail.gmx.net ([213.165.64.20] [213.165.64.20]) by relay21.sun.com for PSARC-EXT@sac.sfbay.sun.com; Tue, 23 Jan 2007 11:36:51 Z Received: (qmail invoked by alias); 23 Jan 2007 11:36:50 -0000 Received: from e178030009.adsl.alicedsl.de (EHLO [192.168.0.138]) [85.178.30.9] by mail.gmx.net (mp047) with SMTP; 23 Jan 2007 12:36:50 +0100 X-Authenticated: #17573310 Message-Id: <45B5F376.1030901@gmx.com> Date: Tue, 23 Jan 2007 12:37:26 +0100 From: Martin Bochnig User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren J Moffat CC: Alan Coopersmith , OpenSolaris X Windows Mailinglist , PSARC-EXT@sac.sfbay.sun.com Subject: Re: [xwin-discuss] Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <45B576AF.2010606@sun.com> <45B5F07E.2040801@Sun.COM> In-Reply-To: <45B5F07E.2040801@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Status: RO Content-Length: 802 Darren J Moffat wrote: > Alan Coopersmith wrote: > > For comparison, these are the ones we ship 32-bit versions of that > we've > > skipped 64-bit versions of: > > > cirrus_alpine.so - Cirrus Logic > > cirrus_drv.so - Cirrus Logic > > cirrus_laguna.so - Cirrus Logic > > Qemu emulates a CL-GD5446 and provides support for running in 64bit. > Would that mean it would be useful to have one of these as 64bit or > would the 64 bit vesa_drv.so be sufficient ? Good catch, Darren! It would be useful. The VESA driver has its limitations. > > > Given that this is X11R7.2 is there going to be a /usr/X11R7 symlink > that points to /usr/X11 ? What happens to the existing /usr/X11R6 > symlink that currently points to /usr/X11 ? Maybe maintaining both? -- Martin Bochnig From alan.coopersmith@sun.com Tue Jan 23 08:23:54 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NGNrLJ021373 for ; Tue, 23 Jan 2007 08:23:53 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NGNn8w029219; Tue, 23 Jan 2007 08:23:51 -0800 (PST) Message-ID: <45B63655.9010902@sun.com> Date: Tue, 23 Jan 2007 08:22:45 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: Darren J Moffat CC: PSARC-EXT@sac.sfbay.sun.com, OpenSolaris X Windows Mailinglist Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <45B576AF.2010606@sun.com> <45B5F07E.2040801@Sun.COM> In-Reply-To: <45B5F07E.2040801@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1247 Darren J Moffat wrote: > Alan Coopersmith wrote: > > For comparison, these are the ones we ship 32-bit versions of that we've > > skipped 64-bit versions of: > > > cirrus_alpine.so - Cirrus Logic > > cirrus_drv.so - Cirrus Logic > > cirrus_laguna.so - Cirrus Logic > > Qemu emulates a CL-GD5446 and provides support for running in 64bit. > Would that mean it would be useful to have one of these as 64bit or > would the 64 bit vesa_drv.so be sufficient ? Unfortunately, I know almost nothing about Qemu, so will have to rely on advice from others there. > Given that this is X11R7.2 is there going to be a /usr/X11R7 symlink > that points to /usr/X11 ? What happens to the existing /usr/X11R6 > symlink that currently points to /usr/X11 ? The X11R6 symlink was added for compatibility with other systems which used that path. At this point I am not aware of any systems installing X11R7 into /usr/X11R7. (Most Linux distros in fact took the change as their time to move directly into /usr/bin, /usr/lib, etc.) Thus, I'm leaving the /usr/X11R6->X11 symlink as is and not adding a new one. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Darren.Moffat@Sun.COM Tue Jan 23 08:27:57 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NGRu4L021540 for ; Tue, 23 Jan 2007 08:27:56 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NGRtqF013010 for ; Tue, 23 Jan 2007 08:27:56 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NGRoaP021865 for ; Tue, 23 Jan 2007 16:27:50 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCB00B01XKLFC00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sac.sfbay.sun.com; Tue, 23 Jan 2007 16:27:50 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCB0068QXQC4T20@d1-emea-09.sun.com> for PSARC-EXT@sac.sfbay.sun.com; Tue, 23 Jan 2007 16:27:48 +0000 (GMT) Date: Tue, 23 Jan 2007 16:27:48 +0000 From: Darren J Moffat Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <45B63655.9010902@sun.com> Sender: Darren.Moffat@Sun.COM To: Alan Coopersmith Cc: PSARC-EXT@sac.sfbay.sun.com, OpenSolaris X Windows Mailinglist Message-id: <45B63784.803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <45B576AF.2010606@sun.com> <45B5F07E.2040801@Sun.COM> <45B63655.9010902@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1397 Alan Coopersmith wrote: > Darren J Moffat wrote: >> Alan Coopersmith wrote: >> > For comparison, these are the ones we ship 32-bit versions of that >> we've >> > skipped 64-bit versions of: >> >> > cirrus_alpine.so - Cirrus Logic >> > cirrus_drv.so - Cirrus Logic >> > cirrus_laguna.so - Cirrus Logic >> >> Qemu emulates a CL-GD5446 and provides support for running in 64bit. >> Would that mean it would be useful to have one of these as 64bit or >> would the 64 bit vesa_drv.so be sufficient ? > > Unfortunately, I know almost nothing about Qemu, so will have to rely on > advice from others there. Martin has responded saying he things this is needed for Qemu because the VESA driver has issues under Qemu. >> Given that this is X11R7.2 is there going to be a /usr/X11R7 symlink >> that points to /usr/X11 ? What happens to the existing /usr/X11R6 >> symlink that currently points to /usr/X11 ? > > The X11R6 symlink was added for compatibility with other systems which > used that path. At this point I am not aware of any systems installing > X11R7 into /usr/X11R7. (Most Linux distros in fact took the change as > their time to move directly into /usr/bin, /usr/lib, etc.) Thus, I'm > leaving the /usr/X11R6->X11 symlink as is and not adding a new one. Seems reasonable to me, just wanted to check it hadn't been overlooked. -- Darren J Moffat From sacadmin Tue Jan 23 12:32:18 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NKWIMg004053; Tue, 23 Jan 2007 12:32:18 -0800 (PST) Received: from [129.150.12.43] (vpn-129-150-12-43.SFBay.Sun.COM [129.150.12.43]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0NKWDS7443865; Tue, 23 Jan 2007 12:32:14 -0800 (PST) Message-ID: <45B6706B.5010506@sun.com> Date: Tue, 23 Jan 2007 10:30:35 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Alan Coopersmith CC: PSARC@sac.sfbay.sun.com, Alan.Coopersmith@sun.com Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> In-Reply-To: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1058 Alan Coopersmith wrote: > Subject: PSARC FastTrack [01/29/2007]: Xorg server upgrade to 7.2 > ... > 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. > This isn't an architectual question, but which of these senarios means Nevada? We just cut a release from Nevada, x86 only, which wasn't a patch release, micro release or minor release. It seems to have been positioned as an "special" update release, another version of S10. (Does anybody know what uname claims on this release?) Anyway, what do you put back into Nevada? One train of logic is that its the next Minor release under development, while the recent actions (which I suspect will be repeated) tend to say Update? - jek3 From sacadmin Tue Jan 23 12:49:02 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NKn2eF004692 for ; Tue, 23 Jan 2007 12:49:02 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0NKn1E5019539 for ; Tue, 23 Jan 2007 12:49:02 -0800 (PST) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0NKn1Uj019459 for ; Tue, 23 Jan 2007 13:49:01 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCC00N019SE2V00@mail-amer.sun.com> (original mail from Mark.J.Nelson@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 23 Jan 2007 13:49:01 -0700 (MST) Received: from sr1-ubrm-03 ([129.147.9.26]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCC000699TP8IF9@mail-amer.sun.com>; Tue, 23 Jan 2007 13:49:01 -0700 (MST) Date: Tue, 23 Jan 2007 13:49:01 -0700 From: "Mark J. Nelson" Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <45B6706B.5010506@sun.com> Sender: Mark.J.Nelson@Sun.COM X-X-Sender: mjnelson@sr1-ubrm-03 To: Joseph Kowalski Cc: PSARC@sac.sfbay.sun.com, Alan.Coopersmith@Sun.COM Reply-to: Mark.J.Nelson@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> <45B6706B.5010506@sun.com> Status: RO Content-Length: 1329 On Tue, 23 Jan 2007, Joseph Kowalski wrote: > Alan Coopersmith wrote: >> 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. > This isn't an architectual question, but which of these senarios means > Nevada? We just cut a release from Nevada, x86 only, which wasn't a > patch release, micro release or minor release. It seems to have been > positioned as an "special" update release, another version of S10. > (Does anybody know what uname claims on this release?) uname -r yields "5.11" on the Solaris Express, Developer Edition release. > Anyway, what do you put back into Nevada? One train of logic is that > its the next Minor release under development, while the recent actions > (which I suspect will be repeated) tend to say Update? I hesitate to speak for Alan, but I'm pretty sure that the isaexec strategy above is intended for integration to Nevada, and the 32-bit strategy above is intended for integration to a Solaris 10 Update. --Mark From sacadmin Tue Jan 23 13:11:49 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NLBnfQ005814; Tue, 23 Jan 2007 13:11:49 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NLBnXm022482; Tue, 23 Jan 2007 13:11:49 -0800 (PST) Message-ID: <45B67A15.7040708@sun.com> Date: Tue, 23 Jan 2007 13:11:49 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Joseph Kowalski CC: Alan Coopersmith , PSARC@sac.sfbay.sun.com Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> <45B6706B.5010506@sun.com> In-Reply-To: <45B6706B.5010506@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1664 Joseph Kowalski wrote: > Alan Coopersmith wrote: >> Subject: PSARC FastTrack [01/29/2007]: Xorg server upgrade to 7.2 >> > ... >> 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. >> > This isn't an architectual question, but which of these senarios means > Nevada? We just > cut a release from Nevada, x86 only, which wasn't a patch release, micro > release or > minor release. It seems to have been positioned as an "special" update > release, another > version of S10. (Does anybody know what uname claims on this release?) The "minor release" scenario above describes what will be integrated into Nevada, which the Solaris PAC has told us is a minor release, and they have not changed their guidance. Solaris Express, in it's various forms, including the one you describe, releases interim snapshots of the development tree of this minor release, but does not count as a release in ARC terms. (I thought this had formally been recorded in a previous ARC policy somewhere but can't find it now - the closest I can find is an entry for 2002/678 in the project list, with a stub one-pager saying it would have an opinion, but I see no materials directory for it.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Tue Jan 23 15:31:43 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NNVhpM009093 for ; Tue, 23 Jan 2007 15:31:43 -0800 (PST) Received: from [129.150.12.43] (vpn-129-150-12-43.SFBay.Sun.COM [129.150.12.43]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0NNVg6x528899; Tue, 23 Jan 2007 15:31:42 -0800 (PST) Message-ID: <45B69A7D.9080400@sun.com> Date: Tue, 23 Jan 2007 13:30:05 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Mark.J.Nelson@sun.com CC: PSARC@sac.sfbay.sun.com, Alan.Coopersmith@sun.com Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> <45B6706B.5010506@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 542 Mark J. Nelson wrote: > uname -r yields "5.11" on the Solaris Express, Developer Edition release. This seems to indicate that the release just cut is being cast as a preview version of some future Minor release, perhaps called 5.11. Holding an envelope to by forehead cause me to say the answer is: "Much knashing of teeth". Opening the envelope yeilds the question, "What happens when a full 5.11 release is scheduled?". I guess the good news is the course of action makes the current integrations somewhat simple. - thanks, - jek3 From alan.coopersmith@sun.com Tue Jan 23 15:47:24 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NNlONB009307 for ; Tue, 23 Jan 2007 15:47:24 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NNlMAI003563; Tue, 23 Jan 2007 15:47:22 -0800 (PST) Message-ID: <45B69E8A.9010409@sun.com> Date: Tue, 23 Jan 2007 15:47:22 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Martin Bochnig CC: Darren J Moffat , OpenSolaris X Windows Mailinglist , PSARC-EXT@sac.sfbay.sun.com Subject: Re: [xwin-discuss] Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <45B576AF.2010606@sun.com> <45B5F07E.2040801@Sun.COM> <45B5F376.1030901@gmx.com> In-Reply-To: <45B5F376.1030901@gmx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 716 Martin Bochnig wrote: > Darren J Moffat wrote: >> Qemu emulates a CL-GD5446 and provides support for running in 64bit. >> Would that mean it would be useful to have one of these as 64bit or >> would the 64 bit vesa_drv.so be sufficient ? > > Good catch, Darren! > It would be useful. > The VESA driver has its limitations. That counts as someone who knows qemu much better than I do. Consider the Cirrus drivers added to the 64-bit list. (Turning on a 64-bit build of a driver we already build 32-bit takes about 5 minutes, mostly the edits to the package prototypes and testing the build works.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Wed Jan 24 01:53:08 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O9r7S1020913 for ; Wed, 24 Jan 2007 01:53:07 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0O9r67v005875 for ; Wed, 24 Jan 2007 01:53:07 -0800 (PST) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0O9r1xh023790 for ; Wed, 24 Jan 2007 09:53:01 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCD00K01A1JV000@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 24 Jan 2007 09:53:01 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCD0029OA4CCR00@d1-emea-10.sun.com>; Wed, 24 Jan 2007 09:53:01 +0000 (GMT) Date: Wed, 24 Jan 2007 09:53:00 +0000 From: Darren J Moffat Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <45B69A7D.9080400@sun.com> Sender: Darren.Moffat@Sun.COM To: Joseph Kowalski Cc: Mark.J.Nelson@Sun.COM, PSARC@sac.sfbay.sun.com, Alan.Coopersmith@Sun.COM Message-id: <45B72C7C.10300@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> <45B6706B.5010506@sun.com> <45B69A7D.9080400@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 782 Joseph Kowalski wrote: > Mark J. Nelson wrote: >> uname -r yields "5.11" on the Solaris Express, Developer Edition release. > This seems to indicate that the release just cut is being cast as a > preview version > of some future Minor release, perhaps called 5.11. > > Holding an envelope to by forehead cause me to say the answer is: "Much > knashing of teeth". > Opening the envelope yeilds the question, "What happens when a full 5.11 > release is scheduled?". Nothing different to what we have been doing with Solaris Express all along. Note the name of the release "Solaris Express Developer Edition", this is just Solaris Express as was as far as the Solaris part is concerned with marketing hype and the SIGALRM for the name change having fired. -- Darren J Moffat From sacadmin Wed Jan 24 14:06:35 2007 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OM6Zjb011978 for ; Wed, 24 Jan 2007 14:06:35 -0800 (PST) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OM6Ywu979329; Wed, 24 Jan 2007 14:06:34 -0800 (PST) Message-ID: <45B7D808.9000105@sun.com> Date: Wed, 24 Jan 2007 12:04:56 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Darren J Moffat CC: Mark.J.Nelson@sun.com, PSARC@sac.sfbay.sun.com, Alan.Coopersmith@sun.com Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> <45B6706B.5010506@sun.com> <45B69A7D.9080400@sun.com> <45B72C7C.10300@Sun.COM> In-Reply-To: <45B72C7C.10300@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1328 Darren J Moffat wrote: > Joseph Kowalski wrote: >> Mark J. Nelson wrote: >>> uname -r yields "5.11" on the Solaris Express, Developer Edition >>> release. >> This seems to indicate that the release just cut is being cast as a >> preview version >> of some future Minor release, perhaps called 5.11. >> >> Holding an envelope to by forehead cause me to say the answer is: >> "Much knashing of teeth". >> Opening the envelope yeilds the question, "What happens when a full >> 5.11 release is scheduled?". > > Nothing different to what we have been doing with Solaris Express all > along. > > Note the name of the release "Solaris Express Developer Edition", this > is just Solaris Express as was as far as the Solaris part is concerned > with marketing hype and the SIGALRM for the name change having fired. Mark, correct me if I'm wrong, but I believe there is another difference in that this release creates another support tail. The only way to get something fixed on Solaris Express is to load/update to a newer version of Solaris Express. If that's also the only way to get a fix for "Solaris Express, Developer Edition release", then yea, I agree this is not different. My knashing of teeth comment was more about our seeming inability not to revisit issue later, than about any real brokenness here. - jek3 From sacadmin Wed Jan 24 14:16:40 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OMGeeN012215 for ; Wed, 24 Jan 2007 14:16:40 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0OMGcZr014372; Wed, 24 Jan 2007 14:16:39 -0800 (PST) Message-ID: <45B7DAC6.6050708@sun.com> Date: Wed, 24 Jan 2007 14:16:38 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Joseph Kowalski CC: Darren J Moffat , Mark.J.Nelson@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <200701230240.l0N2edRI005672@sac.sfbay.sun.com> <45B6706B.5010506@sun.com> <45B69A7D.9080400@sun.com> <45B72C7C.10300@Sun.COM> <45B7D808.9000105@sun.com> In-Reply-To: <45B7D808.9000105@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 593 Joseph Kowalski wrote: > Mark, correct me if I'm wrong, but I believe there is another difference > in that this release creates another > support tail. The only way to get something fixed on Solaris Express is > to load/update to a newer version > of Solaris Express. If that's also the only way to get a fix for > "Solaris Express, Developer Edition release", > then yea, I agree this is not different. That is also the support plan for Developer Edition at this time. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gww@eng.sun.com Wed Jan 24 15:01:44 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0ON1hvd013785 for ; Wed, 24 Jan 2007 15:01:43 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0ON1he7029960; Wed, 24 Jan 2007 15:01:43 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0ON24V8024541; Wed, 24 Jan 2007 15:02:04 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0ON241Q024540; Wed, 24 Jan 2007 15:02:04 -0800 (PST) Date: Wed, 24 Jan 2007 15:02:04 -0800 (PST) From: Gary Winiger Message-Id: <200701242302.l0ON241Q024540@marduk.eng.sun.com> To: PSARC-EXT@sac.sfbay.sun.com, alan.coopersmith@sun.com Cc: Alan.Coopersmith@sun.com, xwin-discuss@opensolaris.org Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] Status: RO Content-Length: 1015 > 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.) How about other "login" managers, like xdm and whatever KDE uses? Wouldn't it be better for the X server to know when it's done initializing and drop its privileges then? Gary.. From alan.coopersmith@sun.com Wed Jan 24 16:37:00 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0P0b0ek015597 for ; Wed, 24 Jan 2007 16:37:00 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0P0axK0015753; Wed, 24 Jan 2007 16:36:59 -0800 (PST) Message-ID: <45B7FBAB.3070403@sun.com> Date: Wed, 24 Jan 2007 16:36:59 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Gary Winiger CC: PSARC-EXT@sac.sfbay.sun.com, xwin-discuss@opensolaris.org Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <200701242302.l0ON241Q024540@marduk.eng.sun.com> In-Reply-To: <200701242302.l0ON241Q024540@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1267 Gary Winiger wrote: >> 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.) > > How about other "login" managers, like xdm and whatever KDE uses? > Wouldn't it be better for the X server to know when it's done > initializing and drop its privileges then? That is the as-yet-unfinished TCA from PSARC 2004/187 (the original Xorg in Solaris case): 2. The project team is advised to consider dropping unnecessary privileges (especially fork and exec) through the facilities provided by "Least Privilege for Solaris" (PSARC 2002/188). It's still on the todo list when resources allow, though if we get xsvc replaced with a more secure method of mapping frame buffers, may become unnecessary. (Of course, the fork and exec privileges mentioned in the TCA are two we know we have to keep after initialization, but there are others we may be able to drop.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gww@eng.sun.com Wed Jan 24 16:43:58 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0P0hwwd015659 for ; Wed, 24 Jan 2007 16:43:58 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0P0hv4x001523; Wed, 24 Jan 2007 16:43:57 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0P0iIXU024724; Wed, 24 Jan 2007 16:44:18 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0P0iIPY024723; Wed, 24 Jan 2007 16:44:18 -0800 (PST) Date: Wed, 24 Jan 2007 16:44:18 -0800 (PST) From: Gary Winiger Message-Id: <200701250044.l0P0iIPY024723@marduk.eng.sun.com> To: gww@eng.sun.com, alan.coopersmith@sun.com Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] Cc: PSARC-EXT@sac.sfbay.sun.com, xwin-discuss@opensolaris.org X-Sun-Charset: US-ASCII Status: RO Content-Length: 974 > >> 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.) > > > > How about other "login" managers, like xdm and whatever KDE uses? > > Wouldn't it be better for the X server to know when it's done > > initializing and drop its privileges then? > > That is the as-yet-unfinished TCA from PSARC 2004/187 (the original Xorg in > Solaris case): So reading between the lines "such as dtlogin or gdm" is a misstatement and should read "dtlogin and gdm are the only functional display managers" or some such cleanup. Grump, that should have been a TCR and only a TCA if all display managers worked so that the uid dance could be done. I guess not this case..... Gary.. From alan.coopersmith@sun.com Wed Jan 24 16:47:38 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0P0lc1s015681 for ; Wed, 24 Jan 2007 16:47:38 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0P0lbaL019553; Wed, 24 Jan 2007 16:47:38 -0800 (PST) Message-ID: <45B7FE28.5090200@sun.com> Date: Wed, 24 Jan 2007 16:47:36 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Gary Winiger CC: xwin-discuss@opensolaris.org, PSARC-EXT@sac.sfbay.sun.com Subject: Re: [xwin-discuss] Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <200701250044.l0P0iIPY024723@marduk.eng.sun.com> In-Reply-To: <200701250044.l0P0iIPY024723@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1370 Gary Winiger wrote: >>>> 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.) >>> >>> How about other "login" managers, like xdm and whatever KDE uses? >>> Wouldn't it be better for the X server to know when it's done >>> initializing and drop its privileges then? >> That is the as-yet-unfinished TCA from PSARC 2004/187 (the original Xorg in >> Solaris case): > > So reading between the lines "such as dtlogin or gdm" is a misstatement > and should read "dtlogin and gdm are the only functional display > managers" or some such cleanup. Grump, that should have been > a TCR and only a TCA if all display managers worked so that the > uid dance could be done. xdm is the only other display manager shipped in Solaris, and we could add the uid dance support to it without much trouble. (Xsun & Xorg should already do the uid dance on their own when started via programs such as xinit, where they can deduce the uid to switch to from getuid().) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Brian.Cameron@Sun.COM Wed Jan 24 19:35:43 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0P3ZhjT018125 for ; Wed, 24 Jan 2007 19:35:43 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0P3ZgeT013946 for ; Wed, 24 Jan 2007 19:35:42 -0800 (PST) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0P3Zg8m002340 for ; Wed, 24 Jan 2007 20:35:42 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCE00L01LWPF400@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for PSARC-EXT@sac.sfbay.sun.com; Wed, 24 Jan 2007 20:35:42 -0700 (MST) Received: from [129.158.217.231] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCE008W1NBB9BF5@mail-amer.sun.com>; Wed, 24 Jan 2007 20:35:42 -0700 (MST) Date: Thu, 25 Jan 2007 11:30:52 +0800 From: Brian Cameron Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <200701250044.l0P0iIPY024723@marduk.eng.sun.com> Sender: Brian.Cameron@Sun.COM To: Gary Winiger Cc: Alan.Coopersmith@Sun.COM, xwin-discuss@opensolaris.org, PSARC-EXT@sac.sfbay.sun.com Message-id: <45B8246C.50106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200701250044.l0P0iIPY024723@marduk.eng.sun.com> User-Agent: Thunderbird 2.0b1 (X11/20070115) Status: RO Content-Length: 1422 Gary/Alan: >>>> 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.) >>> >>> How about other "login" managers, like xdm and whatever KDE uses? >>> Wouldn't it be better for the X server to know when it's done >>> initializing and drop its privileges then? >> That is the as-yet-unfinished TCA from PSARC 2004/187 (the original Xorg in >> Solaris case): > > So reading between the lines "such as dtlogin or gdm" is a misstatement > and should read "dtlogin and gdm are the only functional display > managers" or some such cleanup. Grump, that should have been > a TCR and only a TCA if all display managers worked so that the > uid dance could be done. > > I guess not this case..... I believe Xorg would be "functional" with other display managers, it just will run as root. So, in other words, using display managers other that CDE and GDM will not offer this security feature which is unique to Solaris. Other distros allow the Xserver to run as root. I think Alan is planning to add this enhancement to Xorg upstream so other display managers can also implement this security feature if desired. Brian From Brian.Cameron@Sun.COM Tue Jan 30 02:31:15 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0UAVFd2004786 for ; Tue, 30 Jan 2007 02:31:15 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0UAVEis022497 for ; Tue, 30 Jan 2007 02:31:14 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0UAVEsW001276 for ; Tue, 30 Jan 2007 03:31:14 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCO00C01EGMN100@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for PSARC-EXT@sac.sfbay.sun.com; Tue, 30 Jan 2007 03:31:13 -0700 (MST) Received: from [129.158.217.251] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCO00DJKFVVHFO9@mail-amer.sun.com> for PSARC-EXT@sac.sfbay.sun.com; Tue, 30 Jan 2007 03:31:13 -0700 (MST) Date: Tue, 30 Jan 2007 18:26:26 +0800 From: Brian Cameron Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <45B576AF.2010606@sun.com> Sender: Brian.Cameron@Sun.COM To: Alan Coopersmith Cc: PSARC-EXT@sac.sfbay.sun.com, OpenSolaris X Windows Mailinglist Message-id: <45BF1D52.7050403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <45B576AF.2010606@sun.com> User-Agent: Thunderbird 2.0b1 (X11/20070115) Status: RO Content-Length: 17715 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@sun.com & > xwin-discuss@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@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 and > 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@opensolaris.org From Erwann.Chenede@Sun.COM Tue Jan 30 03:04:30 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0UB4UfW005532 for ; Tue, 30 Jan 2007 03:04:30 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l0UB4TQ0029973 for ; Tue, 30 Jan 2007 03:04:30 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0UB4NAw023248 for ; Tue, 30 Jan 2007 11:04:24 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCO00A01H9LIM00@d1-emea-09.sun.com> (original mail from Erwann.Chenede@Sun.COM) for PSARC-EXT@sac.sfbay.sun.com; Tue, 30 Jan 2007 11:04:23 +0000 (GMT) Received: from [129.157.192.222] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCO003ZFHF6UP00@d1-emea-09.sun.com> for PSARC-EXT@sac.sfbay.sun.com; Tue, 30 Jan 2007 11:04:19 +0000 (GMT) Date: Tue, 30 Jan 2007 12:04:26 +0100 From: Erwann Chenede Subject: Re: [xwin-discuss] Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] In-reply-to: <45BF1D52.7050403@sun.com> Sender: Erwann.Chenede@Sun.COM To: Brian Cameron Cc: Alan Coopersmith , OpenSolaris X Windows Mailinglist , PSARC-EXT@sac.sfbay.sun.com Message-id: <45BF263A.8040102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <45B576AF.2010606@sun.com> <45BF1D52.7050403@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 18498 Hi Brian, you can find most of the missing pc files here : www.gnome.org/~erwannc/missing-pc-files.tar.bz2 Erwann Brian Cameron wrote: > > 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@sun.com & >> xwin-discuss@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@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 and >> 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@opensolaris.org > > _______________________________________________ > xwin-discuss mailing list > xwin-discuss@opensolaris.org From alan.coopersmith@sun.com Tue Jan 30 07:25:14 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0UFPEaK009220 for ; Tue, 30 Jan 2007 07:25:14 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0UFPA1n026705; Tue, 30 Jan 2007 07:25:12 -0800 (PST) Message-ID: <45BF6316.30401@sun.com> Date: Tue, 30 Jan 2007 07:24:06 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: Brian Cameron CC: PSARC-EXT@sac.sfbay.sun.com, OpenSolaris X Windows Mailinglist Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <45B576AF.2010606@sun.com> <45BF1D52.7050403@sun.com> In-Reply-To: <45BF1D52.7050403@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 527 Brian Cameron wrote: > 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? Those are not part of the 7.2 X server, but will be delivered when we upgrade the client libraries to 7.2, which is a later project. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From alan.coopersmith@sun.com Tue Jan 30 07:27:52 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0UFRqOl009374 for ; Tue, 30 Jan 2007 07:27:52 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0UFRluj027582; Tue, 30 Jan 2007 07:27:48 -0800 (PST) Message-ID: <45BF63B3.4080701@sun.com> Date: Tue, 30 Jan 2007 07:26:43 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: Alan Coopersmith CC: PSARC-EXT@sac.sfbay.sun.com, OpenSolaris X Windows Mailinglist Subject: Re: Xorg server upgrade to 7.2 [PSARC/2007/051 Timeout: 01/29/2007] References: <45B576AF.2010606@sun.com> In-Reply-To: <45B576AF.2010606@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 409 Alan Coopersmith wrote: > 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. Since the timer has expired with no outstanding issues, I am now closing this case as approved. Thank you for your time. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering