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
__________________________________________
