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
