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
