> 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.
