From jerry.gilliam@sun.com Thu Jan 14 17:14:41 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0F1EfdN012616 for ; Thu, 14 Jan 2010 17:14:41 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0F1EcQv001455; Thu, 14 Jan 2010 19:14:40 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KW900L0RKSFB100@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Jan 2010 17:14:39 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW900144KSFNIF0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Jan 2010 17:14:39 -0800 (PST) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0F1Edq7841796; Thu, 14 Jan 2010 17:14:39 -0800 (PST) Date: Thu, 14 Jan 2010 17:05:12 -0800 From: Jerry Gilliam Subject: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] To: PSARC-ext@sun.com Cc: Jan Setje-Eilers , Enrico , jerry.gilliam@sun.com, Seth Goldberg , alan.coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B4FBF48.8070005@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 15328 I am sponsoring the following fast-track on behalf of Jan Setje-Eilers with a time-out of 01/22/2010. The project desires minor binding. ------------------------------ Bitmapped Console PSARC/2009/415 1) Summary The Bitmapped Console brings Support for higher resolutions and color depth than the current VGA 640x480 16-color console on x86 systems. The initial delivery will support x86 systems using traditional BIOS and VESA option ROMs. EFI systems, once supported will leverage this work to enable their frame buffer consoles. 2) Technical Details The following applies when a graphics card / frame buffer is being used as a physical or virtual console. This project does not change the behavior of serial consoles. 2.0) Overview The loader (GRUB) automatically chooses an appropriate video mode by intersecting available VESA modes with EDID reported display capabilities and activates it. Any failure to obtain EDID or make VESA calls will leave the system in VGA text mode which the OS will use as it did previously. Then it loads the OS as before and hands a description of the mode to the OS via the vbe members of the multiboot info structure. The early boot_console code which is used pre-consconfig for console messages as well as early kmdb interaction uses that description to map the described frame buffer region and uses it as a bitmapped console device. At consconfig gfx_private (which this project makes vgatext a consumer of) takes over this role and the coherent console (tem) is used to display the console on this frame buffer. Side note: vgatext does not gain any specific vesa support, so it is not being re-named. It simply passes down tem IOCTLs and gfx_private will act appropriately. During a typical non-interactive boot the current "happy face" soothing image gains higher resolution and color depth typically 16-bit, often at a native panel resolution, a significant improvement over 640x480 at 4-bit. Any of the following events will stop the animation, clear the screen and display the text that would otherwise have been on the console at that point: Entering kmdb by any means: mdb -K, panic, F1-a Booting -kd skips graphics entirely as immediate interaction is required. sulogin running on console Any key-press post kbtrans attach (prior to which only kmdb can be interacted with). The console login prompt is displayed and X is not expected to start. This is determined by: svc:/system/console-login:default being on-line while any service svc:/application/graphical-login is disabled or in maintenance. If a graphical-login is enabled a couple seconds is allowed for X to start and take over the console frame buffer, then another reset to text mode is attempted. This simply fails if X owns the console device at that point, but catches configurations that run graphical-login services without running X on console such as sunray servers. 2.1) Mode setting by GRUB The GRUB splashimage command recognizes png files and will select an appropriate mode based on the cards advertised VESA modes and the display capabilities derived from the displays EDID. While the splashimage command can precede the rest of the script comprising the menu entry, the actual mode setting is deferred until the rest of the other commands have succeeded (which means that at least a bootable kernel has been loaded). 2.2) Graphical boot During graphical boot /boot/solaris/boot-images/boot.png is displayed as the background. To indicate progress /boot/solaris/boot-images/stepN.png where N=0 to 14 are used to display an alpha blended animation. Fewer than 15 images may be provided. This animation is displayed until either a key is pressed to switch to text, or X takes over the console. If gdm is not enabled, console login triggers a switch to text. Lastly boot/solaris/images/shutdown.png is displayed during shutdown. This can be disabled by setting load_shutdown_image on the system/console-status service to false. PNG was chosen based both on being a technically appropriate format as well as it's attempt to avoid the licensing quagmire that has plagued other formats. The png parsing code is based on pnglite v. 0.1.17 which is covered by OSR 12682. 2.3) Console text mode Console text mode will continue to default to 80 columns by 24 rows, but becomes configurable via the screen-#columns and screen-#rows properties (as seen in OBP). This uses the existing algorithms in tem that will pick an appropriately sized font and make a best effort at achieving the desired rows and columns. For example, the following properties which can be specified on the kernel command line would enable the graphical display and attempt to allocate a console terminal of 100 columns by 60 rows: console=graphics,screen-#columns=100,screen-#rows=60 2.4) Resetting frame buffer state on exit from X On exit X will generally attempt to restore the mode the card was in before it started. While some native drivers do restore enough state to reset a VESA mode properly, a number do not. Since it is impractical to test and fix every native driver on all cards, a method for explicitly setting the VESA mode at OS run-time is used. Setting the mode requires execution of a call into the VESA BIOS supplied by the card. This is achieved via vbiosd, a daemon that provides userland x86 realmode emulation. This daemon is a derivative work based on uvesafb::v86d, covered by OSR 12387. While the mode is set by vbiosd in userland, the state continues to be tracked by the KD_TEXT/KD_GRAPHICS states in the gfx_private lower-layer of the kernel driver. Mode changes happen in gfx_private and invoke vbiosd via a door. If X does not exit cleanly, the native driver can leave the card in an unknown state. This project does not change that behavior. vbiosd is managed by svc:/system/vbios. While it is only required when X is running, an effort must be made to keep the console in a sane state when X is started by something other than smf, such as say running Xorg manually, so the vbios service is always started. 2.5) Resetting frame buffer state on fast reboot Since the boot loader does not run during fast reboot, the kernel needs to ensure that the graphics card is in a sane state. This is achieved by setting the appropriate mode early on while the system can still make BIOS calls. 2.6) Resetting frame buffer state on suspend/resume Since userland must be running for vbiosd to reset the mode, the mode can not be reset directly as part of the resume entries. Rather another thread in the daemon, is invoked that is pause()d with a SIGTHAW handler that will send a KD_RESUME ioctl to the console device when invoked, which in turn invokes the vbiosd door thread to set the proper VESA mode. 3) Interfaces 3.1) Committed interfaces The possible states of the console property: text text output in either VGA text mode or VESA graphics mode depending on the mode set by the booter or system capabilities. force-text text output in VGA text mode regardless of the mode set by the booter graphics if the booter sets a VESA graphics mode, the graphical boot images are loaded and displayed if not the system will default to text output in VGA text mode ttya/ttyb serial output (not impacted by this work) In case of error the system will fall back to VGA text mode, but the value of the console property is not re-written. force-text exists to allow for continued compatibility with external screen readers and the like. Console terminal sizing properties: screen-#columns screen-#rows Additional Solaris VISUAL I/O control operation, commited in line with the previous vis_ interfaces which were made stable in PSARC/2003/432: VIS_CONSCLEAR this ioctl() takes a struct vis_consclear which defines the background color to be used to clear the screen. struct vis_consclear { unsigned char bg_color; /* Background color */ }; 3.2) Project private interfaces The following previously defined members of the multiboot_info structure are now used to pass pointers to structures describing the VESA implementation of the system. While they are derived from an external standard, their use here is project private: unsigned long vbe_control_info; unsigned long vbe_mode_info; unsigned short vbe_mode; unsigned short vbe_interface_seg; unsigned short vbe_interface_off; unsigned short vbe_interface_len; They point to the following structures which are defined by the VESA spec: struct VbeInfoBlock { uint8_t VbeSignature[4]; uint16_t VbeVersion; uint32_t OemStringPtr; uint32_t Capabilities; uint32_t ModeListPtr; uint16_t TotalMemory; uint16_t OemSoftwareRev; uint32_t OemVendorNamePtr; uint32_t OemProductNamePtr; uint32_t OemProductRevPtr; uint8_t Reserved[222]; uint8_t OemData[256]; } __attribute__((packed)); struct ModeInfoBlock { uint16_t ModeAttributes; uint8_t WinAAttributes; uint8_t WinBAttributes; uint16_t WinGranularity; uint16_t WinSize; uint16_t WinASegment; uint16_t WinBSegment; uint32_t WinFuncPtr; uint16_t BytesPerScanLine; /* >= 1.2 */ uint16_t XResolution; uint16_t YResolution; uint8_t XCharSize; uint8_t YCharSize; uint8_t NumberOfPlanes; uint8_t BitsPerPixel; uint8_t NumberOfBanks; uint8_t MemoryModel; uint8_t BankSize; uint8_t NumberOfImagePages; uint8_t Reserved1; /* direct color */ uint8_t RedMaskSize; uint8_t RedFieldPosition; uint8_t GreenMaskSize; uint8_t GreenFieldPosition; uint8_t BlueMaskSize; uint8_t BlueFieldPosition; uint8_t RsvdMaskSize; uint8_t RsvdFieldPosition; uint8_t DirectColorModeInfo; /* >= 2.0 */ uint32_t PhysBasePtr; uint8_t Reserved2[6]; /* >= 3.0 */ uint16_t LinBytesPerScanLine; uint8_t BnkNumberOfImagePages; uint8_t LinNumberOfImagePages; uint8_t LinRedMaskSize; uint8_t LinRedFieldPosition; uint8_t LinGreenMaskSize; uint8_t LinGreenFieldPosition; uint8_t LinBlueMaskSize; uint8_t LinBlueFieldPosition; uint8_t LinRsvdMaskSize; uint8_t LinRsvdFieldPosition; uint32_t MaxPixelClock; uint8_t Reserved3[189]; } __attribute__((packed)); 3.3) Uncommitted interfaces Service fmri and binary for the daemon. The service does not currently expose any properties. vbiosd: svc:/system/vbios usr/sbin/vbiosd 4) Man page diffs visual_io(7I) 498a499,514 > > VIS_CONSCLEAR Clear the screen. The driver is expected to > > paint the whole screen with the background > > color specified in the vis_consclear > > structure. > > > > The argument is a pointer to a vis_consclear structure > > which contains the following fields: > > > > struct vis_consclear { > > unsigned char bg_color; > > }; > > > > bg_color specifies the background color to be used to paint > > the screen. Only driver that set mode to VIS_PIXEL with the > > VIS_DEVINIT ioctl are expected to have to handle this ioctl. > > eeprom(1m) 109,116c109,120 < ttyb, and text. In text mode, console output goes to the < frame buffer and input comes from the keyboard. When < this property is not present, the console device falls < back to the device specified by input-device and < output-device. When neither the console property or the < input-device and output-device property pair are < present, the console defaults to the frame buffer and < keyboard. --- > > ttyb, text, graphics and force-text. In text mode, console > > output goes to the frame buffer and input comes from the > > keyboard. A variant of text mode, graphics displays an image > > with an animation until either a key is pressed or console > > interaction is required by console login, sulogin, or kmdb. A > > further variant of text, force-text will avoid using a VGA > > adapter as a bitmapped device setting it to VGA text mode. > > When this property is not present, the console device falls > > back to the device specified by input-device and > > output-device. When neither the console property or the > > input-device and output-device property pair are present, the > > console defaults to the frame buffer and keyboard. 117a122 > > screen-#columns screen-#rows 118a124,129 > > When screen is set to either graphics or text on a bitmapped > > device, screen-#columns and screen-#rows allow the desired > > number columns and rows of text to be specified. They default > > to 80 and 24 respectively. > > 5) References VESA BIOS EXTENSION (VBE) Core Functions Standard Version: 3.0 Please contact the project team for a pointer to a copy. pnglite OSR https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=12682 uvesafb::v86d OSR https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=12387 From Aaron.Zang@sun.com Thu Jan 14 21:22:48 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0F5Mmtq015672 for ; Thu, 14 Jan 2010 21:22:48 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0F5Mmq4019750 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 14 Jan 2010 21:22:48 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KW900M09WA0I600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Jan 2010 22:22:48 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW900EK1W9Y4880@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Jan 2010 22:22:47 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0F5MkxF006309 for ; Fri, 15 Jan 2010 05:22:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW900K00W5YR100@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 05:22:33 +0000 (GMT) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW9008OLW9G4W60@fe-emea-10.sun.com>; Fri, 15 Jan 2010 05:22:33 +0000 (GMT) Date: Fri, 15 Jan 2010 13:22:40 +0800 From: Aaron Zang Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B4FBF48.8070005@sun.com> Sender: Aaron.Zang@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Jan Setje-Eilers , Enrico , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B4FFBA0.7000106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2079 > 2.4) Resetting frame buffer state on exit from X > > On exit X will generally attempt to restore the mode the card was > in before it started. While some native drivers do restore enough > state to reset a VESA mode properly, a number do not. > > Since it is impractical to test and fix every native driver on all > cards, a method for explicitly setting the VESA mode at OS run-time > is used. Setting the mode requires execution of a call into the > VESA BIOS supplied by the card. This is achieved via vbiosd, a > daemon that provides userland x86 realmode emulation. This daemon > is a derivative work based on uvesafb::v86d, covered by OSR 12387. > > While the mode is set by vbiosd in userland, the state continues to > be tracked by the KD_TEXT/KD_GRAPHICS states in the gfx_private > lower-layer of the kernel driver. Mode changes happen in > gfx_private and invoke vbiosd via a door. > > If X does not exit cleanly, the native driver can leave the card > in an unknown state. This project does not change that behavior. > > vbiosd is managed by svc:/system/vbios. While it is only required > when X is running, an effort must be made to keep the console in > a sane state when X is started by something other than smf, such as > say running Xorg manually, so the vbios service is always started. > Hi Jerry, Good to see this going. I have something unclear about this section. The graphic card might not always be in VESA (KD_TEXT) mode before an X server starts. This is true when an second X server is started while the first X server is in control of the graphic card. It is now supported with virtual console and new gdm. Xorg's saving/restoring graphic context while starting/exiting or switching to/from via user land DDX driver works fine now. I am not sure that there won't be any problems if we make such assumption and restore the graphic card to VESA mode every time the X server exits. Regards, Aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From setje@sun.com Thu Jan 14 22:50:12 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0F6oBaM017010 for ; Thu, 14 Jan 2010 22:50:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0F6o8CO024605; Thu, 14 Jan 2010 23:50:08 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA001150BKSC00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Jan 2010 22:50:08 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00FBD0BJ6M50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Jan 2010 22:50:07 -0800 (PST) Received: from [10.7.251.212] (punchin-setje.SFBay.Sun.COM [10.7.251.212]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0F6o6kG872395; Thu, 14 Jan 2010 22:50:07 -0800 (PST) Date: Thu, 14 Jan 2010 22:50:06 -0800 From: Jan Setje-Eilers Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B4FFBA0.7000106@Sun.COM> To: Aaron Zang Cc: Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Enrico , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B50101E.2060600@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B4FFBA0.7000106@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 2558 Aaron Zang wrote: >> 2.4) Resetting frame buffer state on exit from X >> >> On exit X will generally attempt to restore the mode the card was >> in before it started. While some native drivers do restore enough >> state to reset a VESA mode properly, a number do not. >> >> Since it is impractical to test and fix every native driver on all >> cards, a method for explicitly setting the VESA mode at OS run-time >> is used. Setting the mode requires execution of a call into the >> VESA BIOS supplied by the card. This is achieved via vbiosd, a >> daemon that provides userland x86 realmode emulation. This daemon >> is a derivative work based on uvesafb::v86d, covered by OSR 12387. >> >> While the mode is set by vbiosd in userland, the state continues to >> be tracked by the KD_TEXT/KD_GRAPHICS states in the gfx_private >> lower-layer of the kernel driver. Mode changes happen in >> gfx_private and invoke vbiosd via a door. >> >> If X does not exit cleanly, the native driver can leave the card >> in an unknown state. This project does not change that behavior. >> >> vbiosd is managed by svc:/system/vbios. While it is only required >> when X is running, an effort must be made to keep the console in >> a sane state when X is started by something other than smf, such as >> say running Xorg manually, so the vbios service is always started. >> > > Hi Jerry, > Good to see this going. I have something unclear about this section. > The graphic card might not always be in VESA (KD_TEXT) mode before an X > server starts. > This is true when an second X server is started while the first X server > is in control of the graphic card. It is now supported with virtual console > and new gdm. Xorg's saving/restoring graphic context while starting/exiting > or switching to/from via user land DDX driver works fine now. > I am not sure that there won't be any problems if we make such assumption > and restore the graphic card to VESA mode every time the X server exits. In this case exiting really means that the X server explicitly sets KD_TEXT as part of releasing the device and turning control back over to the text console. This shouldn't happen unless the intent is to at least temporarily hand control of the frame buffer back to the text console, in which case there should not be a problem. If the X server ever sets KD_TEXT in a scenario where the graphics card is used in a native mode by another X server, I would expect problems even with just the VGA support. -jan From Aaron.Zang@sun.com Fri Jan 15 00:34:34 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0F8YYFa004235 for ; Fri, 15 Jan 2010 00:34:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0F8YW67034894 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 01:34:34 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA0071H55KBJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 00:34:33 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00KW155I2430@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 00:34:31 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0F8YTfU024414 for ; Fri, 15 Jan 2010 08:34:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA0080042M5700@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 08:34:15 +0000 (GMT) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA008U754I4WA0@fe-emea-10.sun.com>; Fri, 15 Jan 2010 08:33:59 +0000 (GMT) Date: Fri, 15 Jan 2010 16:34:06 +0800 From: Aaron Zang Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50101E.2060600@sun.com> Sender: Aaron.Zang@sun.com To: Jan Setje-Eilers Cc: Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Enrico , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B50287E.7080101@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B4FFBA0.7000106@Sun.COM> <4B50101E.2060600@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2935 On 01/15/10 14:50, Jan Setje-Eilers wrote: > Aaron Zang wrote: >>> 2.4) Resetting frame buffer state on exit from X >>> >>> On exit X will generally attempt to restore the mode the card was >>> in before it started. While some native drivers do restore enough >>> state to reset a VESA mode properly, a number do not. >>> >>> Since it is impractical to test and fix every native driver on all >>> cards, a method for explicitly setting the VESA mode at OS run-time >>> is used. Setting the mode requires execution of a call into the >>> VESA BIOS supplied by the card. This is achieved via vbiosd, a >>> daemon that provides userland x86 realmode emulation. This daemon >>> is a derivative work based on uvesafb::v86d, covered by OSR 12387. >>> >>> While the mode is set by vbiosd in userland, the state continues to >>> be tracked by the KD_TEXT/KD_GRAPHICS states in the gfx_private >>> lower-layer of the kernel driver. Mode changes happen in >>> gfx_private and invoke vbiosd via a door. >>> >>> If X does not exit cleanly, the native driver can leave the card >>> in an unknown state. This project does not change that behavior. >>> >>> vbiosd is managed by svc:/system/vbios. While it is only required >>> when X is running, an effort must be made to keep the console in >>> a sane state when X is started by something other than smf, such as >>> say running Xorg manually, so the vbios service is always started. >>> >> >> Hi Jerry, >> Good to see this going. I have something unclear about this section. >> The graphic card might not always be in VESA (KD_TEXT) mode before an >> X server starts. >> This is true when an second X server is started while the first X server >> is in control of the graphic card. It is now supported with virtual >> console >> and new gdm. Xorg's saving/restoring graphic context while >> starting/exiting >> or switching to/from via user land DDX driver works fine now. >> I am not sure that there won't be any problems if we make such assumption >> and restore the graphic card to VESA mode every time the X server exits. > > In this case exiting really means that the X server explicitly sets > KD_TEXT as part of releasing the device and turning control back over to > the text console. This shouldn't happen unless the intent is to at least > temporarily hand control of the frame buffer back to the text console, > in which case there should not be a problem. That's clear. Thanks for the explanation. It would be nicer to document this in the spec otherwise one may confuse this "exit" with the "exit" of a process. Regards, Aaron > > If the X server ever sets KD_TEXT in a scenario where the graphics card > is used in a native mode by another X server, I would expect problems > even with just the VGA support. > > -jan -- You know some birds are not meant to be caged, their feathers are just too bright. From Edward.Shu@sun.com Fri Jan 15 00:42:26 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0F8gQq1004355 for ; Fri, 15 Jan 2010 00:42:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0F8gNAW040897 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 01:42:26 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA0090H5IOJE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 00:42:24 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00KDI5IM2330@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 00:42:23 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0F8gMTL020932 for ; Fri, 15 Jan 2010 08:42:22 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00H0056WRI00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 16:42:22 +0800 (SGT) Received: from [129.158.218.35] ([unknown] [129.158.218.35]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00H2B5IJWTD0@mail-apac.sun.com>; Fri, 15 Jan 2010 16:42:21 +0800 (SGT) Date: Fri, 15 Jan 2010 16:39:30 +0800 From: Edward Shu Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B4FBF48.8070005@sun.com> Sender: Edward.Shu@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Jan Setje-Eilers , Enrico , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B5029C2.8040204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 10133 I think there are two concepts to be clarified, VGA text console and VESA text console. VGA text console is the legacy way. In this proposal, you may mean the VESA text console when text console is mentioned, that emulates the text output with the VESA graphics mode. As VESA is a generic graphics standard with few hardware specific acceleration, the text rendering speed will be much slower causing flicking screen. I recommend to reserve some open interfaces for third-party to fully accelerating the text rendering under VESA text mode. Other comments in lines below. > 2.5) Resetting frame buffer state on fast reboot > > Since the boot loader does not run during fast reboot, the kernel > needs to ensure that the graphics card is in a sane state. This is > achieved by setting the appropriate mode early on while the system > can still make BIOS calls. I am not sure you can find a right place to make the BIOS calls, because fast boot will be out of the real mode very early. > > 2.6) Resetting frame buffer state on suspend/resume > > Since userland must be running for vbiosd to reset the mode, the > mode can not be reset directly as part of the resume entries. Rather > another thread in the daemon, is invoked that is pause()d with a > SIGTHAW > handler that will send a KD_RESUME ioctl to the console device when > invoked, which in turn invokes the vbiosd door thread to set the proper > VESA mode. We actually have a srn driver to communicate with the X server to do suspend/resume. The srn driver protocol can be enhanced for vbiosd to act likely. > > 3) Interfaces > > 3.1) Committed interfaces > > The possible states of the console property: > > text text output in either VGA text mode or VESA > graphics mode depending on the mode set by > the booter or system capabilities. > > force-text text output in VGA text mode regardless of the > mode set by the booter > > graphics if the booter sets a VESA graphics mode, the > graphical boot images are loaded and displayed > if not the system will default to text output > in VGA text mode > > ttya/ttyb serial output (not impacted by this work) > > In case of error the system will fall back to VGA text mode, but > the value of the console property is not re-written. > > force-text exists to allow for continued compatibility with > external screen readers and the like. > > Console terminal sizing properties: > > screen-#columns > screen-#rows > > > Additional Solaris VISUAL I/O control operation, commited in line > with the previous vis_ interfaces which were made stable in > PSARC/2003/432: > > VIS_CONSCLEAR this ioctl() takes a struct vis_consclear which > defines the background color to be used to clear the screen. > > struct vis_consclear { > unsigned char bg_color; /* Background color */ > }; > > 3.2) Project private interfaces > > The following previously defined members of the multiboot_info > structure are now used to pass pointers to structures describing > the VESA implementation of the system. While they are derived > from an external standard, their use here is project private: > > unsigned long vbe_control_info; > unsigned long vbe_mode_info; > unsigned short vbe_mode; > unsigned short vbe_interface_seg; > unsigned short vbe_interface_off; > unsigned short vbe_interface_len; > > They point to the following structures which are defined by the > VESA spec: > > struct VbeInfoBlock { > uint8_t VbeSignature[4]; > uint16_t VbeVersion; > uint32_t OemStringPtr; > uint32_t Capabilities; > uint32_t ModeListPtr; > uint16_t TotalMemory; > uint16_t OemSoftwareRev; > uint32_t OemVendorNamePtr; > uint32_t OemProductNamePtr; > uint32_t OemProductRevPtr; > uint8_t Reserved[222]; > uint8_t OemData[256]; > } __attribute__((packed)); > > struct ModeInfoBlock { > uint16_t ModeAttributes; > uint8_t WinAAttributes; > uint8_t WinBAttributes; > uint16_t WinGranularity; > uint16_t WinSize; > uint16_t WinASegment; > uint16_t WinBSegment; > uint32_t WinFuncPtr; > uint16_t BytesPerScanLine; > > /* >= 1.2 */ > uint16_t XResolution; > uint16_t YResolution; > uint8_t XCharSize; > uint8_t YCharSize; > uint8_t NumberOfPlanes; > uint8_t BitsPerPixel; > uint8_t NumberOfBanks; > uint8_t MemoryModel; > uint8_t BankSize; > uint8_t NumberOfImagePages; > uint8_t Reserved1; > > /* direct color */ > uint8_t RedMaskSize; > uint8_t RedFieldPosition; > uint8_t GreenMaskSize; > uint8_t GreenFieldPosition; > uint8_t BlueMaskSize; > uint8_t BlueFieldPosition; > uint8_t RsvdMaskSize; > uint8_t RsvdFieldPosition; > uint8_t DirectColorModeInfo; > > /* >= 2.0 */ > uint32_t PhysBasePtr; > uint8_t Reserved2[6]; > > /* >= 3.0 */ > uint16_t LinBytesPerScanLine; > uint8_t BnkNumberOfImagePages; > uint8_t LinNumberOfImagePages; > uint8_t LinRedMaskSize; > uint8_t LinRedFieldPosition; > uint8_t LinGreenMaskSize; > uint8_t LinGreenFieldPosition; > uint8_t LinBlueMaskSize; > uint8_t LinBlueFieldPosition; > uint8_t LinRsvdMaskSize; > uint8_t LinRsvdFieldPosition; > uint32_t MaxPixelClock; > uint8_t Reserved3[189]; > } __attribute__((packed)); > > > 3.3) Uncommitted interfaces > > Service fmri and binary for the daemon. The service does > not currently expose any properties. > > vbiosd: svc:/system/vbios > > usr/sbin/vbiosd > > > 4) Man page diffs > > visual_io(7I) > > 498a499,514 > > > VIS_CONSCLEAR Clear the screen. The driver is expected to > > > paint the whole screen with the background > > > color specified in the vis_consclear > > > structure. > > > > > > The argument is a pointer to a vis_consclear structure > > > which contains the following fields: > > > > > > struct vis_consclear { > > > unsigned char bg_color; > > > }; > > > > > > bg_color specifies the background color to be used to paint > > > the screen. Only driver that set mode to VIS_PIXEL with the > > > VIS_DEVINIT ioctl are expected to have to handle this ioctl. > > > > > eeprom(1m) > > 109,116c109,120 > < ttyb, and text. In text mode, console output goes to the > < frame buffer and input comes from the keyboard. When > < this property is not present, the console device falls > < back to the device specified by input-device and > < output-device. When neither the console property or the > < input-device and output-device property pair are > < present, the console defaults to the frame buffer and > < keyboard. > --- > > > ttyb, text, graphics and force-text. In text mode, console > > > output goes to the frame buffer and input comes from the > > > keyboard. A variant of text mode, graphics displays an image > > > with an animation until either a key is pressed or console > > > interaction is required by console login, sulogin, or > kmdb. A > > > further variant of text, force-text will avoid using a VGA > > > adapter as a bitmapped device setting it to VGA text mode. > > > When this property is not present, the console device falls > > > back to the device specified by input-device and > > > output-device. When neither the console property or the > > > input-device and output-device property pair are present, > the > > > console defaults to the frame buffer and keyboard. > 117a122 > > > screen-#columns screen-#rows > 118a124,129 > > > When screen is set to either graphics or text on a bitmapped > > > device, screen-#columns and screen-#rows allow the desired > > > number columns and rows of text to be specified. They > default > > > to 80 and 24 respectively. > > > > > 5) References > > VESA BIOS EXTENSION (VBE) Core Functions Standard Version: 3.0 > Please contact the project team for a pointer to a copy. > > pnglite OSR > > https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=12682 > > > uvesafb::v86d OSR > > https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=12387 > > > > -- Best Regards, Ming. ------------------------------------------ -Edward Shu -Solaris x86 Engineering, Sun Microsystems -tele: +86-10-62673100 __________________________________________ From Darren.Moffat@sun.com Fri Jan 15 01:44:12 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0F9iCtx005265 for ; Fri, 15 Jan 2010 01:44:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0F9iCPc005209 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 01:44:12 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA0013P8DOVG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 01:44:12 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00KRC8DM24A0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 01:44:11 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0F9i96w027252 for ; Fri, 15 Jan 2010 09:44:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00F006X1QR00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 09:44:08 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00JJO8D2MW00@fe-emea-10.sun.com>; Fri, 15 Jan 2010 09:43:51 +0000 (GMT) Date: Fri, 15 Jan 2010 09:43:49 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B4FBF48.8070005@sun.com> Sender: Darren.Moffat@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Alan.Coopersmith@sun.com, Enrico , Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: <4B5038D5.5040601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 313 What is the method credential section of the SMF manifest used to start the vbios service ? ie what user/group id does it run as and what privileges(5) does it require. Does this case indirectly (or directly) solve the problems of suspend and resume for systems with ATI graphics cards ? -- Darren J Moffat From Enrico.Perla@sun.com Fri Jan 15 03:17:58 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FBHw1j006439 for ; Fri, 15 Jan 2010 03:17:58 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0FBHv6R033887 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 04:17:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA0060DCPXIG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:17:57 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA0061XCPWA720@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:17:56 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FBHuju004060 for ; Fri, 15 Jan 2010 03:17:56 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00A00CP3WB00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:17:56 -0800 (PST) Received: from macdonald.local ([unknown] [24.23.175.212]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA004SRCPWZ420@fe-sfbay-09.sun.com>; Fri, 15 Jan 2010 03:17:56 -0800 (PST) Date: Fri, 15 Jan 2010 03:17:56 -0800 From: Enrico Perla Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B5029C2.8040204@sun.com> Sender: Enrico.Perla@sun.com To: Edward Shu Cc: Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B504EE4.7090505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 3525 Edward Shu wrote: > > I think there are two concepts to be clarified, VGA text console > and VESA text console. VGA text console is the legacy way. > In this proposal, you may mean the VESA text console when > text console is mentioned, that emulates the text output with > the VESA graphics mode. As VESA is a generic graphics > standard with few hardware specific acceleration, the text > rendering speed will be much slower causing flicking screen. It actually depends on the card. By setting the framebuffer memory as cache combined, memset/memcpy (thus, video painting) are pretty smooth on a lot of recent hardware, also on long scrolling. We also 'pick' 16-bit modes over 32-bit modes in the 'automatic' mode selection so that half of the amount of memory needs to be moved around on scrolling. (I don't see any particular reason for a user to need a 32-bit console framebuffer, but he can choose so by directly using the vbeset command in GRUB) > I recommend to reserve some open interfaces for third-party to > fully accelerating the text rendering under VESA text mode. There is an experimental interface for that that I placed in the code. A driver can call 'gfxp_fb_register_fbops' to register blit, copy, clear, setmode, etc operations. It can also just register a small number of them and let the code use the standard ones for the other operations (simply, set the function pointer to NULL). I would keep it experimental: we don't have many drivers in general (and they behave already somehow differently, e.g. nvidia vs intel). If we get to the point where we have more drivers we may reconsider a larger redesign of how the framebuffer is managed (e.g. specific DDI/DDK functions?). > Other comments in lines below. > >> 2.5) Resetting frame buffer state on fast reboot >> >> Since the boot loader does not run during fast reboot, the kernel >> needs to ensure that the graphics card is in a sane state. This is >> achieved by setting the appropriate mode early on while the system >> can still make BIOS calls. > I am not sure you can find a right place to make the BIOS calls, because > fast boot will be out of the real mode very early. > We can go back to real mode for some time during normal boot. The interface is bop_doint. It basically maps a stub of code at low addresses and switches back to real mode to execute the interrupt. The fastreboot code already uses it since the putback for 6855522, we have just extended it (I can point you - and anyone who wants to - to a webrev if you wish so). >> >> 2.6) Resetting frame buffer state on suspend/resume >> >> Since userland must be running for vbiosd to reset the mode, the >> mode can not be reset directly as part of the resume entries. Rather >> another thread in the daemon, is invoked that is pause()d with a >> SIGTHAW >> handler that will send a KD_RESUME ioctl to the console device when >> invoked, which in turn invokes the vbiosd door thread to set the >> proper >> VESA mode. > We actually have a srn driver to communicate with the X server to do > suspend/resume. > The srn driver protocol can be enhanced for vbiosd to act likely. > One thing we really want to catch is when the userland comes back alive, since vbiosd is a userland process. Is there a way to get that from the driver protocol apart the SIGTHAW? Is there more in the driver protocol than getting our suspend and resume functions called ? If so, I would be very interested in checking that. - Enrico From Enrico.Perla@Sun.COM Fri Jan 15 03:27:37 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FBRbeT006502 for ; Fri, 15 Jan 2010 03:27:37 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FBRb34004170 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 03:27:37 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00513D617K00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:27:37 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00AHED60GR60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:27:37 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FBRagp004236 for ; Fri, 15 Jan 2010 03:27:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00D00D1ZVM00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:27:36 -0800 (PST) Received: from macdonald.local ([unknown] [24.23.175.212]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA004C9D60Z440@fe-sfbay-09.sun.com>; Fri, 15 Jan 2010 03:27:36 -0800 (PST) Date: Fri, 15 Jan 2010 03:27:36 -0800 From: Enrico Perla Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B5038D5.5040601@Sun.COM> Sender: Enrico.Perla@Sun.COM To: Darren J Moffat Cc: Jerry Gilliam , PSARC-ext@Sun.COM, Alan.Coopersmith@Sun.COM, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@Sun.COM Message-id: <4B505128.5060106@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1511 Darren J Moffat wrote: > What is the method credential section of the SMF manifest used to > start the vbios service ? ie what user/group id does it run as and > what privileges(5) does it require. It runs as root and needs to open /dev/xsvc to map the BIOS image. After that, it needs to be able to do in/out assembly instruction (so, basically, it needs to be able to set its IOPL to 3). I haven't set so far any specific privilege on the daemon since either /dev/xsvc or in/out look to me as a pretty good way to take over the system, if vbiosd proves to be vulnerable. Actually, though, we are a bit re-designing vbiosd (there was another service that was only responsible of checking if gdm started and receiving SIGTHAW to catch resumes that we are merging into vbiosd in order to have a single service). Since that will likely lead to two different threads, maybe we want to separate the privileges there? What would be your suggestion? > > Does this case indirectly (or directly) solve the problems of suspend > and resume for systems with ATI graphics cards ? > I don't think so. Xorg userland drivers do more than what we do and if they don't manage to make ATI cards re-post, we're definitely not even trying. Working on POSTing cards might be an extension of the project in the future (if we get to do the post emulation well, then we could use it to post VGA cards on SPARC, but it's not as straightforward as it may sound), but so far there is no plan to support that. - Enrico From Darren.Moffat@sun.com Fri Jan 15 03:40:22 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FBeMlQ006546 for ; Fri, 15 Jan 2010 03:40:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0FBeI2D050637 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 04:40:22 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA0071HDR9VO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:40:21 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA006ULDR7A7D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 03:40:20 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FBeIWM014293 for ; Fri, 15 Jan 2010 11:40:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00000DEAGY00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 11:40:16 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00JE1DQYMW70@fe-emea-10.sun.com>; Fri, 15 Jan 2010 11:40:11 +0000 (GMT) Date: Fri, 15 Jan 2010 11:40:10 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B505128.5060106@sun.com> Sender: Darren.Moffat@sun.com To: Enrico Perla Cc: Jerry Gilliam , PSARC-ext@sun.com, Alan.Coopersmith@sun.com, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: <4B50541A.3010405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 1432 Enrico Perla wrote: > > Darren J Moffat wrote: >> What is the method credential section of the SMF manifest used to >> start the vbios service ? ie what user/group id does it run as and >> what privileges(5) does it require. > It runs as root and needs to open /dev/xsvc to map the BIOS image. After > that, it needs to be able to do in/out assembly instruction (so, > basically, it needs to be able to set its IOPL to 3). > I haven't set so far any specific privilege on the daemon since either > /dev/xsvc or in/out look to me as a pretty good way to take over the > system, if vbiosd proves to be vulnerable. > > Actually, though, we are a bit re-designing vbiosd (there was another > service that was only responsible of checking if gdm started and > receiving SIGTHAW to catch resumes that we are merging into vbiosd in > order to have a single service). Since that will likely lead to two > different threads, maybe we want to separate the privileges there? What > would be your suggestion? I'd say in that case you aren't ready for ARC review if you don't know what vbiosd does. It isn't possible for the different threads to run with separate privileges. It sounds like because of its use of /dev/xsvc to map the BIOS image there is no option but to run as root with all privilege. Which is very unfortunate but I don't expect this project to provide a means other than /dev/xsvc to do that. -- Darren J Moffat From Enrico.Perla@Sun.COM Fri Jan 15 04:18:19 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FCIJlk007123 for ; Fri, 15 Jan 2010 04:18:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FCIJsa000380 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 04:18:19 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00J09FIJS900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 05:18:19 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00FEUFIIGW10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 05:18:18 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FCIIXh004356 for ; Fri, 15 Jan 2010 04:18:18 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00B00FCQAE00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 04:18:18 -0800 (PST) Received: from macdonald.local ([unknown] [24.23.175.212]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA004J7FIHZ4C0@fe-sfbay-09.sun.com>; Fri, 15 Jan 2010 04:18:18 -0800 (PST) Date: Fri, 15 Jan 2010 04:18:16 -0800 From: Enrico Perla Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50541A.3010405@Sun.COM> Sender: Enrico.Perla@Sun.COM To: Darren J Moffat Cc: Jerry Gilliam , PSARC-ext@Sun.COM, Alan.Coopersmith@Sun.COM, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@Sun.COM Message-id: <4B505D08.3000204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> <4B50541A.3010405@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 2263 Darren J Moffat wrote: > Enrico Perla wrote: >> >> Darren J Moffat wrote: >>> What is the method credential section of the SMF manifest used to >>> start the vbios service ? ie what user/group id does it run as and >>> what privileges(5) does it require. >> It runs as root and needs to open /dev/xsvc to map the BIOS image. After >> that, it needs to be able to do in/out assembly instruction (so, >> basically, it needs to be able to set its IOPL to 3). >> I haven't set so far any specific privilege on the daemon since either >> /dev/xsvc or in/out look to me as a pretty good way to take over the >> system, if vbiosd proves to be vulnerable. >> >> Actually, though, we are a bit re-designing vbiosd (there was another >> service that was only responsible of checking if gdm started and >> receiving SIGTHAW to catch resumes that we are merging into vbiosd in >> order to have a single service). Since that will likely lead to two >> different threads, maybe we want to separate the privileges there? What >> would be your suggestion? > > I'd say in that case you aren't ready for ARC review if you don't know > what vbiosd does. I do know what it does. And the code is getting 'merged' with another code which is already available. I can point you to a webrev, if you need to. > > It isn't possible for the different threads to run with separate > privileges Yes, what I meant was to use fork() over creating threads. But since the code that would be separated is small and has no interaction with the user, living with full privileges for that part too is an acceptable option. > It sounds like because of its use of /dev/xsvc to map the BIOS > image there is no option but to run as root with all privilege. Which > is very unfortunate but I don't expect this project to provide a means > other than /dev/xsvc to do that. > Which was my original guess. And the in and outs operation are important as well, actually more determinant: while /dev/xsvc is meant to be used only at startup, ins and outs are done all the time. Also, vbiosd emulates 16-bit code: if someone is able to change the code that gets emulated it can do again pretty much whatever it wants. vbiosd door is protected by accepting only kernel commands. - Enrico From gdamore@Sun.COM Fri Jan 15 07:21:51 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FFLpjo009697 for ; Fri, 15 Jan 2010 07:21:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0FFLnPa025142 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 08:21:51 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00H4RO0ED600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 07:21:50 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA0030QO0DD5D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 07:21:49 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FFLn1V011925 for ; Fri, 15 Jan 2010 07:21:49 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00300NS02D00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 07:21:49 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00I6FO0CK040@fe-sfbay-09.sun.com>; Fri, 15 Jan 2010 07:21:49 -0800 (PST) Date: Fri, 15 Jan 2010 07:21:48 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B5029C2.8040204@sun.com> Sender: Garrett.Damore@Sun.COM To: Edward Shu Cc: Jerry Gilliam , PSARC-ext@Sun.COM, Jan Setje-Eilers , Enrico , Seth Goldberg , Alan.Coopersmith@Sun.COM, Dan Mick , Edward Pilatowicz , joe.bonasera@Sun.COM Message-id: <4B50880C.1020306@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 10536 Edward Shu wrote: > > I think there are two concepts to be clarified, VGA text console > and VESA text console. VGA text console is the legacy way. > In this proposal, you may mean the VESA text console when > text console is mentioned, that emulates the text output with > the VESA graphics mode. As VESA is a generic graphics > standard with few hardware specific acceleration, the text > rendering speed will be much slower causing flicking screen. > I recommend to reserve some open interfaces for third-party to > fully accelerating the text rendering under VESA text mode. > Other comments in lines below. I agree with this.. specifically I can see that *scrolling* can be slow if not accelerated. I doubt just adding characters to the screen would be a problem, though. NetBSD's graphics console has a nice way of expressing bitblt support... perhaps something similar can be used here. - Garrett > >> 2.5) Resetting frame buffer state on fast reboot >> >> Since the boot loader does not run during fast reboot, the kernel >> needs to ensure that the graphics card is in a sane state. This is >> achieved by setting the appropriate mode early on while the system >> can still make BIOS calls. > I am not sure you can find a right place to make the BIOS calls, because > fast boot will be out of the real mode very early. > >> >> 2.6) Resetting frame buffer state on suspend/resume >> >> Since userland must be running for vbiosd to reset the mode, the >> mode can not be reset directly as part of the resume entries. Rather >> another thread in the daemon, is invoked that is pause()d with a >> SIGTHAW >> handler that will send a KD_RESUME ioctl to the console device when >> invoked, which in turn invokes the vbiosd door thread to set the >> proper >> VESA mode. > We actually have a srn driver to communicate with the X server to do > suspend/resume. > The srn driver protocol can be enhanced for vbiosd to act likely. > >> >> 3) Interfaces >> >> 3.1) Committed interfaces >> >> The possible states of the console property: >> >> text text output in either VGA text mode or VESA >> graphics mode depending on the mode set by >> the booter or system capabilities. >> >> force-text text output in VGA text mode regardless of the >> mode set by the booter >> >> graphics if the booter sets a VESA graphics mode, the >> graphical boot images are loaded and displayed >> if not the system will default to text output >> in VGA text mode >> >> ttya/ttyb serial output (not impacted by this work) >> >> In case of error the system will fall back to VGA text mode, but >> the value of the console property is not re-written. >> >> force-text exists to allow for continued compatibility with >> external screen readers and the like. >> >> Console terminal sizing properties: >> >> screen-#columns >> screen-#rows >> >> >> Additional Solaris VISUAL I/O control operation, commited in line >> with the previous vis_ interfaces which were made stable in >> PSARC/2003/432: >> >> VIS_CONSCLEAR this ioctl() takes a struct vis_consclear which >> defines the background color to be used to clear the screen. >> >> struct vis_consclear { >> unsigned char bg_color; /* Background color */ >> }; >> >> 3.2) Project private interfaces >> >> The following previously defined members of the multiboot_info >> structure are now used to pass pointers to structures describing >> the VESA implementation of the system. While they are derived >> from an external standard, their use here is project private: >> >> unsigned long vbe_control_info; >> unsigned long vbe_mode_info; >> unsigned short vbe_mode; >> unsigned short vbe_interface_seg; >> unsigned short vbe_interface_off; >> unsigned short vbe_interface_len; >> >> They point to the following structures which are defined by the >> VESA spec: >> >> struct VbeInfoBlock { >> uint8_t VbeSignature[4]; >> uint16_t VbeVersion; >> uint32_t OemStringPtr; >> uint32_t Capabilities; >> uint32_t ModeListPtr; >> uint16_t TotalMemory; >> uint16_t OemSoftwareRev; >> uint32_t OemVendorNamePtr; >> uint32_t OemProductNamePtr; >> uint32_t OemProductRevPtr; >> uint8_t Reserved[222]; >> uint8_t OemData[256]; >> } __attribute__((packed)); >> >> struct ModeInfoBlock { >> uint16_t ModeAttributes; >> uint8_t WinAAttributes; >> uint8_t WinBAttributes; >> uint16_t WinGranularity; >> uint16_t WinSize; >> uint16_t WinASegment; >> uint16_t WinBSegment; >> uint32_t WinFuncPtr; >> uint16_t BytesPerScanLine; >> >> /* >= 1.2 */ >> uint16_t XResolution; >> uint16_t YResolution; >> uint8_t XCharSize; >> uint8_t YCharSize; >> uint8_t NumberOfPlanes; >> uint8_t BitsPerPixel; >> uint8_t NumberOfBanks; >> uint8_t MemoryModel; >> uint8_t BankSize; >> uint8_t NumberOfImagePages; >> uint8_t Reserved1; >> >> /* direct color */ >> uint8_t RedMaskSize; >> uint8_t RedFieldPosition; >> uint8_t GreenMaskSize; >> uint8_t GreenFieldPosition; >> uint8_t BlueMaskSize; >> uint8_t BlueFieldPosition; >> uint8_t RsvdMaskSize; >> uint8_t RsvdFieldPosition; >> uint8_t DirectColorModeInfo; >> >> /* >= 2.0 */ >> uint32_t PhysBasePtr; >> uint8_t Reserved2[6]; >> >> /* >= 3.0 */ >> uint16_t LinBytesPerScanLine; >> uint8_t BnkNumberOfImagePages; >> uint8_t LinNumberOfImagePages; >> uint8_t LinRedMaskSize; >> uint8_t LinRedFieldPosition; >> uint8_t LinGreenMaskSize; >> uint8_t LinGreenFieldPosition; >> uint8_t LinBlueMaskSize; >> uint8_t LinBlueFieldPosition; >> uint8_t LinRsvdMaskSize; >> uint8_t LinRsvdFieldPosition; >> uint32_t MaxPixelClock; >> uint8_t Reserved3[189]; >> } __attribute__((packed)); >> >> >> 3.3) Uncommitted interfaces >> >> Service fmri and binary for the daemon. The service does >> not currently expose any properties. >> >> vbiosd: svc:/system/vbios >> >> usr/sbin/vbiosd >> >> >> 4) Man page diffs >> >> visual_io(7I) >> >> 498a499,514 >> > > VIS_CONSCLEAR Clear the screen. The driver is expected to >> > > paint the whole screen with the background >> > > color specified in the vis_consclear >> > > structure. >> > > >> > > The argument is a pointer to a vis_consclear structure >> > > which contains the following fields: >> > > >> > > struct vis_consclear { >> > > unsigned char bg_color; >> > > }; >> > > >> > > bg_color specifies the background color to be used to paint >> > > the screen. Only driver that set mode to VIS_PIXEL with the >> > > VIS_DEVINIT ioctl are expected to have to handle this ioctl. >> > > >> >> eeprom(1m) >> >> 109,116c109,120 >> < ttyb, and text. In text mode, console output goes to the >> < frame buffer and input comes from the keyboard. When >> < this property is not present, the console device falls >> < back to the device specified by input-device and >> < output-device. When neither the console property or the >> < input-device and output-device property pair are >> < present, the console defaults to the frame buffer and >> < keyboard. >> --- >> > > ttyb, text, graphics and force-text. In text mode, console >> > > output goes to the frame buffer and input comes from the >> > > keyboard. A variant of text mode, graphics displays an >> image >> > > with an animation until either a key is pressed or console >> > > interaction is required by console login, sulogin, or >> kmdb. A >> > > further variant of text, force-text will avoid using a VGA >> > > adapter as a bitmapped device setting it to VGA text mode. >> > > When this property is not present, the console device falls >> > > back to the device specified by input-device and >> > > output-device. When neither the console property or the >> > > input-device and output-device property pair are >> present, the >> > > console defaults to the frame buffer and keyboard. >> 117a122 >> > > screen-#columns screen-#rows >> 118a124,129 >> > > When screen is set to either graphics or text on a >> bitmapped >> > > device, screen-#columns and screen-#rows allow the desired >> > > number columns and rows of text to be specified. They >> default >> > > to 80 and 24 respectively. >> > > >> >> 5) References >> >> VESA BIOS EXTENSION (VBE) Core Functions Standard Version: 3.0 >> Please contact the project team for a pointer to a copy. >> >> pnglite OSR >> >> https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=12682 >> >> >> uvesafb::v86d OSR >> >> https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=12387 >> >> >> >> > > From setje@sun.com Fri Jan 15 07:59:36 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FFxZQ4010152 for ; Fri, 15 Jan 2010 07:59:36 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0FFxWhf056893; Fri, 15 Jan 2010 08:59:32 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00307PR81M00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 07:59:32 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA000XAPR7LI10@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 07:59:31 -0800 (PST) Received: from [10.7.251.212] (punchin-setje.SFBay.Sun.COM [10.7.251.212]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0FFxU7m970489; Fri, 15 Jan 2010 07:59:31 -0800 (PST) Date: Fri, 15 Jan 2010 07:59:29 -0800 From: Jan Setje-Eilers Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50880C.1020306@sun.com> To: "Garrett D'Amore" Cc: Edward Shu , Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Enrico , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B5090E1.7030805@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> <4B50880C.1020306@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1658 Garrett D'Amore wrote: > Edward Shu wrote: >> >> I think there are two concepts to be clarified, VGA text console >> and VESA text console. VGA text console is the legacy way. >> In this proposal, you may mean the VESA text console when >> text console is mentioned, that emulates the text output with >> the VESA graphics mode. As VESA is a generic graphics >> standard with few hardware specific acceleration, the text >> rendering speed will be much slower causing flicking screen. >> I recommend to reserve some open interfaces for third-party to >> fully accelerating the text rendering under VESA text mode. >> Other comments in lines below. > > I agree with this.. specifically I can see that *scrolling* can be slow > if not accelerated. In 16-bit depth (which is automatically selected in favor of 24-bit) performance is very hard distinguish from VGA text mode. We've explicitly been However you're right, before we figured out to map the frame buffer cache combined, performance was unacceptable. Since then we've been asking folks specifically about scrolling performance during demos and have not received any more negative feedback. We'll try to get some bits available at least semi publicly so folks not in mpk can convince themselves of this as well. > I doubt just adding characters to the screen would be a problem, though. Correct. The only additional thing we sort of wish VESA had is blit. > NetBSD's graphics console has a nice way of expressing bitblt support... > perhaps something similar can be used here. We do have some experimental interfaces, but that would be beyond the realm of VESA. -jan From setje@sun.com Fri Jan 15 08:09:57 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FG9vIp010399 for ; Fri, 15 Jan 2010 08:09:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0FG9sH7001081; Fri, 15 Jan 2010 09:09:55 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA005A1Q8I8R00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 08:09:54 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA0006EQ8GLH40@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 08:09:52 -0800 (PST) Received: from [10.7.251.212] (punchin-setje.SFBay.Sun.COM [10.7.251.212]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0FG9pEQ974463; Fri, 15 Jan 2010 08:09:51 -0800 (PST) Date: Fri, 15 Jan 2010 08:09:49 -0800 From: Jan Setje-Eilers Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50541A.3010405@Sun.COM> To: Darren J Moffat Cc: Enrico Perla , Jerry Gilliam , PSARC-ext@sun.com, Alan.Coopersmith@sun.com, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: <4B50934D.3000605@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> <4B50541A.3010405@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1810 Darren J Moffat wrote: > Enrico Perla wrote: >> >> Darren J Moffat wrote: >>> What is the method credential section of the SMF manifest used to >>> start the vbios service ? ie what user/group id does it run as and >>> what privileges(5) does it require. >> It runs as root and needs to open /dev/xsvc to map the BIOS image. After >> that, it needs to be able to do in/out assembly instruction (so, >> basically, it needs to be able to set its IOPL to 3). >> I haven't set so far any specific privilege on the daemon since either >> /dev/xsvc or in/out look to me as a pretty good way to take over the >> system, if vbiosd proves to be vulnerable. >> >> Actually, though, we are a bit re-designing vbiosd (there was another >> service that was only responsible of checking if gdm started and >> receiving SIGTHAW to catch resumes that we are merging into vbiosd in >> order to have a single service). Since that will likely lead to two >> different threads, maybe we want to separate the privileges there? What >> would be your suggestion? > > I'd say in that case you aren't ready for ARC review if you don't know > what vbiosd does. We do know what it does. Re-design is perhaps a stronger term than was appropriate here. Enrico was collapsing what were originally two daemons into one yesterday. He was primarily offering that he'd be happy to make additional changes if you had some smart ideas about how to deal with xsvc without running as root. > It isn't possible for the different threads to run with separate > privileges. It sounds like because of its use of /dev/xsvc to map the > BIOS image there is no option but to run as root with all privilege. > Which is very unfortunate but I don't expect this project to provide a > means other than /dev/xsvc to do that. Thanks. -jan From Darren.Moffat@sun.com Fri Jan 15 08:14:21 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FGELAP010443 for ; Fri, 15 Jan 2010 08:14:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0FGEGu6004742 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 09:14:20 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00J2TQFWBH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 15 Jan 2010 09:14:20 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00G46QFU3A30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 15 Jan 2010 09:14:19 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FGEI3A017706 for ; Fri, 15 Jan 2010 16:14:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00A00PO4IA00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 15 Jan 2010 16:13:57 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00254QF4LO50@fe-emea-09.sun.com>; Fri, 15 Jan 2010 16:13:52 +0000 (GMT) Date: Fri, 15 Jan 2010 16:13:52 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50934D.3000605@sun.com> Sender: Darren.Moffat@sun.com To: Jan Setje-Eilers Cc: Enrico Perla , Jerry Gilliam , PSARC-ext@sun.com, Alan.Coopersmith@sun.com, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: <4B509440.7080108@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> <4B50541A.3010405@Sun.COM> <4B50934D.3000605@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 1674 Jan Setje-Eilers wrote: > Darren J Moffat wrote: >> Enrico Perla wrote: >>> >>> Darren J Moffat wrote: >>>> What is the method credential section of the SMF manifest used to >>>> start the vbios service ? ie what user/group id does it run as and >>>> what privileges(5) does it require. >>> It runs as root and needs to open /dev/xsvc to map the BIOS image. After >>> that, it needs to be able to do in/out assembly instruction (so, >>> basically, it needs to be able to set its IOPL to 3). >>> I haven't set so far any specific privilege on the daemon since either >>> /dev/xsvc or in/out look to me as a pretty good way to take over the >>> system, if vbiosd proves to be vulnerable. >>> >>> Actually, though, we are a bit re-designing vbiosd (there was another >>> service that was only responsible of checking if gdm started and >>> receiving SIGTHAW to catch resumes that we are merging into vbiosd in >>> order to have a single service). Since that will likely lead to two >>> different threads, maybe we want to separate the privileges there? What >>> would be your suggestion? >> >> I'd say in that case you aren't ready for ARC review if you don't know >> what vbiosd does. > > We do know what it does. Re-design is perhaps a stronger term than was > appropriate here. Enrico was collapsing what were originally two daemons > into one yesterday. He was primarily offering that he'd be happy to make > additional changes if you had some smart ideas about how to deal with > xsvc without running as root. So doesn't changing two daemons into one change the architecture of this case ? Or is what is in the case the two daemons in one ? -- Darren J Moffat From setje@sun.com Fri Jan 15 08:32:34 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FGWYVP010640 for ; Fri, 15 Jan 2010 08:32:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FGW3PV018725; Fri, 15 Jan 2010 08:32:32 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00A5BRA3NL00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 08:32:27 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA000M2RA1LH80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 08:32:25 -0800 (PST) Received: from [10.7.251.212] (punchin-setje.SFBay.Sun.COM [10.7.251.212]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0FGWOQ3977323; Fri, 15 Jan 2010 08:32:25 -0800 (PST) Date: Fri, 15 Jan 2010 08:32:24 -0800 From: Jan Setje-Eilers Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B509440.7080108@Sun.COM> To: Darren J Moffat Cc: Enrico Perla , Jerry Gilliam , PSARC-ext@sun.com, Alan.Coopersmith@sun.com, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: <4B509898.8010402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> <4B50541A.3010405@Sun.COM> <4B50934D.3000605@sun.com> <4B509440.7080108@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1866 Darren J Moffat wrote: > Jan Setje-Eilers wrote: >> Darren J Moffat wrote: >>> Enrico Perla wrote: >>>> >>>> Darren J Moffat wrote: >>>>> What is the method credential section of the SMF manifest used to >>>>> start the vbios service ? ie what user/group id does it run as and >>>>> what privileges(5) does it require. >>>> It runs as root and needs to open /dev/xsvc to map the BIOS image. >>>> After >>>> that, it needs to be able to do in/out assembly instruction (so, >>>> basically, it needs to be able to set its IOPL to 3). >>>> I haven't set so far any specific privilege on the daemon since either >>>> /dev/xsvc or in/out look to me as a pretty good way to take over the >>>> system, if vbiosd proves to be vulnerable. >>>> >>>> Actually, though, we are a bit re-designing vbiosd (there was another >>>> service that was only responsible of checking if gdm started and >>>> receiving SIGTHAW to catch resumes that we are merging into vbiosd in >>>> order to have a single service). Since that will likely lead to two >>>> different threads, maybe we want to separate the privileges there? What >>>> would be your suggestion? >>> >>> I'd say in that case you aren't ready for ARC review if you don't >>> know what vbiosd does. >> >> We do know what it does. Re-design is perhaps a stronger term than >> was appropriate here. Enrico was collapsing what were originally two >> daemons into one yesterday. He was primarily offering that he'd be >> happy to make additional changes if you had some smart ideas about how >> to deal with xsvc without running as root. > > So doesn't changing two daemons into one change the architecture of this > case ? Or is what is in the case the two daemons in one ? > The case reflects the single daemon. In fact combining them was driven by the inevitable reaction that multiple daemons would provoke. -jan From alan.coopersmith@sun.com Fri Jan 15 08:36:49 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FGanOQ010660 for ; Fri, 15 Jan 2010 08:36:49 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FGam2r012904 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 10:36:49 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00103RHCHZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 08:36:48 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00JCFRHCN370@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 08:36:48 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FGamw1016897 for ; Fri, 15 Jan 2010 08:36:48 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00E00QW9QJ00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 08:36:48 -0800 (PST) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00HBVRHAR130@fe-sfbay-10.sun.com>; Fri, 15 Jan 2010 08:36:47 -0800 (PST) Date: Fri, 15 Jan 2010 08:36:46 -0800 From: Alan Coopersmith Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50934D.3000605@sun.com> Sender: alan.coopersmith@sun.com To: Jan Setje-Eilers Cc: Darren J Moffat , Enrico Perla , Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: <4B50999E.1010900@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> <4B50541A.3010405@Sun.COM> <4B50934D.3000605@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 750 Jan Setje-Eilers wrote: > We do know what it does. Re-design is perhaps a stronger term than was > appropriate here. Enrico was collapsing what were originally two daemons > into one yesterday. He was primarily offering that he'd be happy to make > additional changes if you had some smart ideas about how to deal with > xsvc without running as root. At least from our experience with Xorg, you will need full privileges (uid 0) for both /dev/xsvc and the sysi86 call to change the IOPL. You may be able to drop some privileges after you've done that (Xorg can't since it has to be able to unwind and redo those calls again later). -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Darren.Moffat@sun.com Fri Jan 15 08:38:58 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FGcwQR010703 for ; Fri, 15 Jan 2010 08:38:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FGcvZX005236 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 08:38:57 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00L0JRKXMN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 09:38:57 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00G4ARKW3E50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 09:38:56 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FGctbP028001 for ; Fri, 15 Jan 2010 16:38:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00000R8I9Q00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 16:38:48 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA002YDRKOLO50@fe-emea-09.sun.com>; Fri, 15 Jan 2010 16:38:48 +0000 (GMT) Date: Fri, 15 Jan 2010 16:38:48 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B509898.8010402@sun.com> Sender: Darren.Moffat@sun.com To: Jan Setje-Eilers Cc: Enrico Perla , Jerry Gilliam , PSARC-ext@sun.com, Alan.Coopersmith@sun.com, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: <4B509A18.5050207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> <4B50541A.3010405@Sun.COM> <4B50934D.3000605@sun.com> <4B509440.7080108@Sun.COM> <4B509898.8010402@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 298 Jan Setje-Eilers wrote: > The case reflects the single daemon. In fact combining them was driven > by the inevitable reaction that multiple daemons would provoke. Thanks that wasn't obvious to me initially. In that case my questions have been answers to my satisfaction. -- Darren J Moffat From randy.fishel@sun.com Fri Jan 15 10:33:06 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FIX5DG012824 for ; Fri, 15 Jan 2010 10:33:06 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0FIV7sp055551; Fri, 15 Jan 2010 11:33:02 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00807WUTBF00@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Jan 2010 10:32:53 -0800 (PST) Received: from grimmy.eng.sun.com ([129.146.108.114]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00773WUS7410@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Jan 2010 10:32:52 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FIVD1F015053; Fri, 15 Jan 2010 10:31:13 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.13.8+Sun/8.13.8/Submit) with ESMTP id o0FIVD7c015050; Fri, 15 Jan 2010 10:31:13 -0800 (PST) Date: Fri, 15 Jan 2010 10:31:13 -0800 (PST) From: Randy Fishel Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B504EE4.7090505@sun.com> X-X-Sender: randyf@grimmy To: Enrico Perla Cc: Edward Shu , Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> <4B504EE4.7090505@sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs User-Agent: Alpine 1.10 (GSO 962 2008-03-14) Status: RO Content-Length: 1473 On Fri, 15 Jan 2010, Enrico Perla wrote: > >> > >> 2.6) Resetting frame buffer state on suspend/resume > >> > >> Since userland must be running for vbiosd to reset the mode, the > >> mode can not be reset directly as part of the resume entries. Rather > >> another thread in the daemon, is invoked that is pause()d with a > >> SIGTHAW > >> handler that will send a KD_RESUME ioctl to the console device when > >> invoked, which in turn invokes the vbiosd door thread to set the > >> proper > >> VESA mode. > > We actually have a srn driver to communicate with the X server to do > > suspend/resume. > > The srn driver protocol can be enhanced for vbiosd to act likely. > > > One thing we really want to catch is when the userland comes back alive, > since vbiosd is a userland process. Is there a way to get that from the > driver protocol apart the SIGTHAW? > Is there more in the driver protocol than getting our suspend and resume > functions called ? If so, I would be very interested in checking that. > > srn is for userland consumption. The primary difference between srn and SIGTHAW, is that it provides syncronous access, so that it can also be used for suspend notification. If all you care about is a notification that resume is complete, SIGTHAW is sufficient. If you also want suspend notification and/or require a mechanism for notifying the framework of suspend or resume errors, then srn may be a better choice. ---- Randy From setje@sun.com Fri Jan 15 11:08:16 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0FJ8GcF013889 for ; Fri, 15 Jan 2010 11:08:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FJ8DaP010647; Fri, 15 Jan 2010 11:08:14 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWA00E07YHP8Y00@brm-avmta-1.central.sun.com>; Fri, 15 Jan 2010 12:08:13 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00DFBYHOQ000@brm-avmta-1.central.sun.com>; Fri, 15 Jan 2010 12:08:12 -0700 (MST) Received: from [10.7.251.212] (punchin-setje.SFBay.Sun.COM [10.7.251.212]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0FJ8B9G102530; Fri, 15 Jan 2010 11:08:12 -0800 (PST) Date: Fri, 15 Jan 2010 11:08:11 -0800 From: Jan Setje-Eilers Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: To: Randy Fishel Cc: Enrico Perla , Edward Shu , Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B50BD1B.8060304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> <4B504EE4.7090505@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1592 Randy Fishel wrote: > > On Fri, 15 Jan 2010, Enrico Perla wrote: > >>>> 2.6) Resetting frame buffer state on suspend/resume >>>> >>>> Since userland must be running for vbiosd to reset the mode, the >>>> mode can not be reset directly as part of the resume entries. Rather >>>> another thread in the daemon, is invoked that is pause()d with a >>>> SIGTHAW >>>> handler that will send a KD_RESUME ioctl to the console device when >>>> invoked, which in turn invokes the vbiosd door thread to set the >>>> proper >>>> VESA mode. >>> We actually have a srn driver to communicate with the X server to do >>> suspend/resume. >>> The srn driver protocol can be enhanced for vbiosd to act likely. >>> >> One thing we really want to catch is when the userland comes back alive, >> since vbiosd is a userland process. Is there a way to get that from the >> driver protocol apart the SIGTHAW? >> Is there more in the driver protocol than getting our suspend and resume >> functions called ? If so, I would be very interested in checking that. >> >> > > srn is for userland consumption. The primary difference between srn > and SIGTHAW, is that it provides syncronous access, so that it can > also be used for suspend notification. If all you care about is a > notification that resume is complete, SIGTHAW is sufficient. If you > also want suspend notification and/or require a mechanism for > notifying the framework of suspend or resume errors, then srn may be a > better choice. We only need to perform work on resume, so it sounds like SIGTHAW is reasonable. -jan From Edward.Shu@sun.com Mon Jan 18 06:37:18 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0IEbIMd020848 for ; Mon, 18 Jan 2010 06:37:18 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0IEbHeb007632; Mon, 18 Jan 2010 08:37:17 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWG001055Y5EO00@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jan 2010 06:37:17 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWG00HGT5Y4IE80@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jan 2010 06:37:17 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0IEbF2x005571; Mon, 18 Jan 2010 14:37:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWG002005UKVJ00@mail-apac.sun.com>; Mon, 18 Jan 2010 22:37:15 +0800 (SGT) Received: from [10.0.0.2] ([unknown] [114.246.93.93]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWG00CQV5XW9VC0@mail-apac.sun.com>; Mon, 18 Jan 2010 22:37:15 +0800 (SGT) Date: Mon, 18 Jan 2010 22:37:21 +0800 From: edward shu Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50BD1B.8060304@sun.com> Sender: Edward.Shu@sun.com To: Jan Setje-Eilers Cc: Randy Fishel , Enrico Perla , Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B547221.3050106@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> <4B504EE4.7090505@sun.com> <4B50BD1B.8060304@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 744 >>> >> >> srn is for userland consumption. The primary difference between >> srn and SIGTHAW, is that it provides syncronous access, so that it >> can also be used for suspend notification. If all you care about is >> a notification that resume is complete, SIGTHAW is sufficient. If >> you also want suspend notification and/or require a mechanism for >> notifying the framework of suspend or resume errors, then srn may be >> a better choice. > > We only need to perform work on resume, so it sounds like SIGTHAW is > reasonable. I am worried that there are some cards that require special device context saving in the suspend process. And they are required to reset the original video mode in the resume process. > > -jan From Edward.Shu@sun.com Mon Jan 18 06:53:34 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0IErY7e020905 for ; Mon, 18 Jan 2010 06:53:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0IErXKD008702 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 18 Jan 2010 06:53:34 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWG00A076P94P00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 18 Jan 2010 07:53:33 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWG005PJ6P80330@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 18 Jan 2010 07:53:33 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0IErWk1029495 for ; Mon, 18 Jan 2010 14:53:32 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWG005006DFFY00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 18 Jan 2010 22:53:32 +0800 (SGT) Received: from [10.0.0.2] ([unknown] [114.246.93.93]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWG00CXC6P59VC0@mail-apac.sun.com>; Mon, 18 Jan 2010 22:53:31 +0800 (SGT) Date: Mon, 18 Jan 2010 22:53:43 +0800 From: edward shu Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B5090E1.7030805@sun.com> Sender: Edward.Shu@sun.com To: Jan Setje-Eilers Cc: "Garrett D'Amore" , Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Enrico , Seth Goldberg , Alan.Coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B5475F7.30706@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> <4B50880C.1020306@sun.com> <4B5090E1.7030805@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 996 Jan Setje-Eilers: > Garrett D'Amore wrote: >> Edward Shu wrote: >>> >>> I think there are two concepts to be clarified, VGA text console >>> and VESA text console. VGA text console is the legacy way. >>> In this proposal, you may mean the VESA text console when >>> text console is mentioned, that emulates the text output with >>> the VESA graphics mode. As VESA is a generic graphics >>> standard with few hardware specific acceleration, the text >>> rendering speed will be much slower causing flicking screen. >>> I recommend to reserve some open interfaces for third-party to >>> fully accelerating the text rendering under VESA text mode. >>> Other comments in lines below. >> >> I agree with this.. specifically I can see that *scrolling* can be >> slow if not accelerated. So my concern is, if we want to add the hardware accerlerated "scrolling" in the future for a specific chip, we can do it very straightly. So as the "text font rendering", the "bitblt" and others. From Enrico.Perla@Sun.COM Mon Jan 18 07:21:48 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0IFLm5w021441 for ; Mon, 18 Jan 2010 07:21:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0IFLmG5011273 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 18 Jan 2010 07:21:48 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWG0040180C0T00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 18 Jan 2010 07:21:48 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWG00HBL80BIIC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 18 Jan 2010 07:21:47 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0IFLkbi010277 for ; Mon, 18 Jan 2010 07:21:47 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWG00B007WWCJ00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 18 Jan 2010 07:21:47 -0800 (PST) Received: from macdonald.local ([unknown] [24.23.175.212]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWG009AD8080P90@fe-sfbay-09.sun.com>; Mon, 18 Jan 2010 07:21:45 -0800 (PST) Date: Mon, 18 Jan 2010 07:21:44 -0800 From: Enrico Perla Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B5475F7.30706@sun.com> Sender: Enrico.Perla@Sun.COM To: edward shu Cc: Jan Setje-Eilers , "Garrett D'Amore" , Jerry Gilliam , PSARC-ext@Sun.COM, Jan Setje-Eilers , Seth Goldberg , Alan.Coopersmith@Sun.COM, Dan Mick , Edward Pilatowicz , joe.bonasera@Sun.COM Message-id: <4B547C88.3060103@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> <4B50880C.1020306@sun.com> <4B5090E1.7030805@sun.com> <4B5475F7.30706@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 7482 edward shu wrote: > > Jan Setje-Eilers: >> Garrett D'Amore wrote: >>> Edward Shu wrote: >>>> >>>> I think there are two concepts to be clarified, VGA text console >>>> and VESA text console. VGA text console is the legacy way. >>>> In this proposal, you may mean the VESA text console when >>>> text console is mentioned, that emulates the text output with >>>> the VESA graphics mode. As VESA is a generic graphics >>>> standard with few hardware specific acceleration, the text >>>> rendering speed will be much slower causing flicking screen. >>>> I recommend to reserve some open interfaces for third-party to >>>> fully accelerating the text rendering under VESA text mode. >>>> Other comments in lines below. >>> >>> I agree with this.. specifically I can see that *scrolling* can be >>> slow if not accelerated. > So my concern is, if we want to add the hardware accerlerated > "scrolling" in the future for a specific > chip, we can do it very straightly. So as the "text font > rendering", the "bitblt" and others. As I said in the previous reply, I've added a specific callback function that any driver can call to register bitblt, copy and alike operations. This is as simple as calling a function and the module provided routines will take precedence on standard, non-accelerated, VESA routines: (from: http://push/builds/enrico/vesa-dev/vesa-gate/webrev/usr/src/uts/i86pc/io/gfx_private/gfxp_bitmap.c.html -- at http://push/builds/enrico/vesa-dev/vesa-gate/webrev/ there is a quite recent webrev which lacks the work I'm doing to collapse consoled and vbiosd into a single daemon) 97 static struct gfxp_ops fb_ops = { 98 gfxp_bm_kdsetmode, /* kdsetmode */ 99 gfxp_bm_devinit, /* devinit */ 100 gfxp_bm_cons_copy, /* conscopy */ 101 gfxp_bm_cons_display, /* consdisplay */ 102 gfxp_bm_cons_cursor, /* conscursor */ 103 gfxp_bm_cons_clear, /* consclear */ 104 gfxp_bm_suspend, /* suspend */ 105 gfxp_bm_resume, /* resume */ 106 gfxp_bm_devmap /* devmap */ 107 }; 108 109 /* 110 * Generic drawing functions. 111 * These functions emulate in software the blit/copy of a square/rectangle on 112 * the screen. They are used by default and, right now, in the vast majority (if 113 * not the totality) of cases. If a graphic driver supports hardware blitting 114 * it can register a function callbacks via gfxp_bm_register_fbops(). 115 * NOTE that these functions are also used in polled I/O mode, and are so 116 * subject to its limitations. 117 */ 118 static void gfxp_bm_generic_blt(struct gfxp_softc *softc, 119 struct vis_consdisplay *); 120 static void gfxp_bm_generic_copy(struct gfxp_softc *softc, 121 struct vis_conscopy *); 122 (NOTE: the gfxp_bm_suspend/resume might go away. It depends if ever a driver may need to get control back - after - calling into gfx_private routines but before they return. Debatable. No driver currently consumes these). Then the registering function looks like: 236 /* 237 * Public functions to register and unregister driver routines with the 238 * generic gfx driver. NOTE: FBCONS macro expects the vgatext_softc structure 239 * pointer to be called 'softc'. 240 */ 241 void 242 gfxp_bm_register_fbops(gfxp_vgatext_softc_ptr_t ptr, struct gfxp_blt_ops *fbops) 243 { 244 struct gfxp_softc *softc = (struct gfxp_softc *)ptr; 245 FBCONS.fbops = fbops; 246 } 247 248 void 249 gfxp_bm_unregister_fbops(gfxp_vgatext_softc_ptr_t ptr) 250 { 251 struct gfxp_softc *softc = (struct gfxp_softc *)ptr; 252 FBCONS.fbops = NULL; 253 } And taking as an example the blit function: 438 static void 439 gfxp_bm_cons_display(struct gfxp_softc *softc, struct vis_consdisplay *da) 440 { 441 /* Sanitize input. */ 442 if (da->col < 0 || da->col >= FBCONS.xres || 443 da->row < 0 || da->row >= FBCONS.yres || 444 da->col + da->width > FBCONS.xres || 445 da->row + da->height > FBCONS.yres) { 446 return; 447 } 448 449 /* 450 * If we are in "console mode", update the screen. 451 * Use an hardware provided blt function, if possible, otherwise 452 * fallback to gfxp_bm_generic_blt(). 453 */ 454 if (FBCONS.active == 1) { 455 if (FBCONS.fbops == NULL || FBCONS.fbops->blt == NULL || 456 FBCONS.fbops->blt(da) != GFXP_SUCCESS) 457 gfxp_bm_generic_blt(softc, da); 458 459 /* Flush to memory. */ 460 membar_producer(); 461 } 462 /* Update the shadow buffer. */ 463 gfxp_bm_blt_updtshadow(softc, da); 464 } Where at 454 - 456 we call the driver function if present and fallback to the standard method if -for any reason- it fails. We -always- need to update the shadow buffer and that's done transparently to the driver. Why it is not more stabilized? First and foremost: nowadays graphics card memory and modern CPUs are fast. By touching the framebuffer memory only on writing (keeping a shadow frame buffer) and by setting the memory as write-combining, performances have been satisfactory so far. We had a test with the Look'n'Feel guys where they felt okay about the scrolling result (the rule of thumb they suggested was: "If the user cannot read what's written on the screen during a scrolling, then it's okay") and I'm more than happy to have more. I'm also happy to prepare some archives so that you can try it yourself and very happy to code any potential improvement. Second of all we have 2-3 ways of doing the same thing inside the Solaris kernel. Intel uses the DRM interface, while NVIDIA needs to call a set of 'dedicated' interfaces (provided by gfx_private). This is, besides the old atiatom.c code, as much of video graphic support as we currently have on x86/x86_64. We don't have a well established DDI interface for graphics, which would probably be the best direction to head towards. But that is, in my opinion, out of the scope of this project. Third, we still only have two drivers, one of which is closed source (so we don't have direct access to it and, as per off-line discussion, is not headed towards supporting console framebuffer accelerated routines). We can see how the aforementioned interface plays out and, at the same time, see in what direction we go (are we planning to have more in-kernel graphic drivers? are we targeting laptops or not?) and plan accordingly. All the framebuffer painting routines are reasonably generic and used both in the early stages (e.g. KMDB) and after the coherent console kicks in. Note also that this project actually solves a bit of duplication (probably a low hanging fruit, but still a couple hundreds of lines cut off): the vgatext module (which was loaded independently of gfx_private) is now a gfx_private consumer. While gfx_private does (always in my opinion) a little more than what it might be supposed to (it both acts as a pseudo-driver and actively draws on the screen), with the current architecture it is not a bad compromise. Also, depending on how fast EFI systems catch on we need the ability of generically draw on a bit mapped space, because it might be the only option we are left with. - Enrico > > > From Enrico.Perla@Sun.COM Mon Jan 18 07:25:20 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0IFPKe3021479 for ; Mon, 18 Jan 2010 07:25:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0IFPKdP013398; Mon, 18 Jan 2010 07:25:20 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWG0040J8688600@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jan 2010 07:25:20 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWG00HQO867ILC0@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Jan 2010 07:25:19 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0IFPJhr010392; Mon, 18 Jan 2010 07:25:19 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWG007008143300@fe-sfbay-10.sun.com>; Mon, 18 Jan 2010 07:25:19 -0800 (PST) Received: from macdonald.local ([unknown] [24.23.175.212]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWG00MPN867EL20@fe-sfbay-10.sun.com>; Mon, 18 Jan 2010 07:25:19 -0800 (PST) Date: Mon, 18 Jan 2010 07:25:19 -0800 From: Enrico Perla Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B547221.3050106@sun.com> Sender: Enrico.Perla@Sun.COM To: edward shu Cc: Jan Setje-Eilers , Randy Fishel , Jerry Gilliam , PSARC-ext@Sun.COM, Jan Setje-Eilers , Seth Goldberg , Alan.Coopersmith@Sun.COM, Dan Mick , Edward Pilatowicz , joe.bonasera@Sun.COM Message-id: <4B547D5F.6000707@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5029C2.8040204@sun.com> <4B504EE4.7090505@sun.com> <4B50BD1B.8060304@sun.com> <4B547221.3050106@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1214 edward shu wrote: > >>>> >>> >>> srn is for userland consumption. The primary difference between >>> srn and SIGTHAW, is that it provides syncronous access, so that it >>> can also be used for suspend notification. If all you care about is >>> a notification that resume is complete, SIGTHAW is sufficient. If >>> you also want suspend notification and/or require a mechanism for >>> notifying the framework of suspend or resume errors, then srn may be >>> a better choice. >> >> We only need to perform work on resume, so it sounds like SIGTHAW is >> reasonable. > I am worried that there are some cards that require special device > context saving in the suspend process. > And they are required to reset the original video mode in the resume > process. All that will happen before getting to the point where the SIGTHAW is delivered. The card is supposed to do the POST (and restoring) of the card all by itself and we won't interfere at all with it. When the SIGTHAW is delivered we are in the position of checking if X.org is up (in which case we basically do nothing) or not (in which case we push down to vbiosd a request to reset the saved VESA mode). - Enrico > >> >> -jan > From Seth.Goldberg@sun.com Tue Jan 19 11:37:46 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0JJbkL1004525 for ; Tue, 19 Jan 2010 11:37:46 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0JJbh2i007912 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 19 Jan 2010 13:37:46 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWI00G0LEIX2700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 19 Jan 2010 11:37:45 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWI00AJKEIW57A0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 19 Jan 2010 11:37:44 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0JJbiXw029849 for ; Tue, 19 Jan 2010 11:37:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWI00L00BNAWT00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 19 Jan 2010 11:37:44 -0800 (PST) Received: from kasha ([unknown] [10.1.48.74]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWI00GEBEHWMEH0@fe-sfbay-09.sun.com>; Tue, 19 Jan 2010 11:37:09 -0800 (PST) Date: Tue, 19 Jan 2010 11:36:33 -0800 (PST) From: Seth Goldberg Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B50999E.1010900@sun.com> Sender: Seth.Goldberg@sun.com X-X-Sender: sethg@"bergsoft.West.Sun.COM." To: Alan Coopersmith Cc: Jan Setje-Eilers , Darren J Moffat , Enrico Perla , Jerry Gilliam , PSARC-ext@sun.com, Jan Setje-Eilers , Seth Goldberg , joe.bonasera@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> <4B5038D5.5040601@Sun.COM> <4B505128.5060106@sun.com> <4B50541A.3010405@Sun.COM> <4B50934D.3000605@sun.com> <4B50999E.1010900@sun.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) Status: RO Content-Length: 1060 Quoting Alan Coopersmith, who wrote the following on Fri, 15 Jan 2010: > Jan Setje-Eilers wrote: >> We do know what it does. Re-design is perhaps a stronger term than was >> appropriate here. Enrico was collapsing what were originally two daemons >> into one yesterday. He was primarily offering that he'd be happy to make >> additional changes if you had some smart ideas about how to deal with >> xsvc without running as root. > > At least from our experience with Xorg, you will need full privileges > (uid 0) for both /dev/xsvc and the sysi86 call to change the IOPL. > You may be able to drop some privileges after you've done that (Xorg > can't since it has to be able to unwind and redo those calls again > later). The only way to fully drop privileges would be to identify the set of ports that will be accessed and add kernel interfaces to add those ports to the IO port bitmap in the process' TSS (it's even more complex for 64-bit processes). The system-level complexity is MUCH lower if the process executes with full privileges. --S From jerry.gilliam@sun.com Mon Jan 25 14:12:54 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0PMCsbX025555 for ; Mon, 25 Jan 2010 14:12:54 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0PMCqqW011516; Mon, 25 Jan 2010 14:12:53 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWT00207PPGN900@brm-avmta-1.central.sun.com>; Mon, 25 Jan 2010 15:12:52 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWT00HEXPPFQA70@brm-avmta-1.central.sun.com>; Mon, 25 Jan 2010 15:12:51 -0700 (MST) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0PMCnrS203933; Mon, 25 Jan 2010 14:12:49 -0800 (PST) Date: Mon, 25 Jan 2010 14:02:57 -0800 From: Jerry Gilliam Subject: Re: PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010] In-reply-to: <4B4FBF48.8070005@sun.com> To: PSARC-ext@sun.com Cc: Jan Setje-Eilers , Enrico , Seth Goldberg , alan.coopersmith@sun.com, Dan Mick , Edward Pilatowicz , joe.bonasera@sun.com Message-id: <4B5E1511.7030702@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B4FBF48.8070005@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 77 This case has timed-out with no objections and is thereby approved. -jg