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.
