Bug 28026

	On machines that support suspend-to-ram or suspend-to-disk
	(not as extensively tested), it has been observed that
	suspending (via either the 'apm' binary or closing the lid,
	pressing suspend button etc.) whilst in graphics mode (e.g.
	running an X server, either XF86_SVGA or XF86_Mach64) will
	put the machine in a strange state, where the display is
	very dim (but still barely visible), but machine will not
	respond to keyboard, power button or network, and the
	machine is still using mucho power (e.g. gets v.hot in
	bag).

	The only recourse then is to reset, with the attendant loss
	of uptime and filesystem checks. Sometimes, it can be harder
	to find a paperclip than you think...

	Switching to a text mode VT first avoids this problem, the
	machine will suspend and resume as expected.

Fix: It is possible to hack around the problem by calling a
	binary (e.g. from 'rc.suspend') that switches to text mode
	first, before issuing the suspend call.

	This obviously leaves two files that need to be maintained,
	particularly when cvsup'ing regularly it is inevitable that
	this extra step will be overlooked sooner or later.

	Also, a better way to address this issue (if not in the X
	server itself), seems to be in the 'apm' binary, which
	should DTRT.

	I attach for your consideration some example patches to
	'apm' and its Makefile, and some (commented-out) options
	with descriptive commands for 'etc/defaults/make.conf'
	(intended to be activated in '/etc/make.conf', naturally).

	In this way, it is as unobtrusive as possible on machine/systems
	that don't need this, yet fixes the problems for machines
	that do.

	Thanks.

How-To-Repeat: 
	On such a machine as described (laptop with APM enabled
	and Rage Mobility chipset), suspend the machine, either
	via hardware or via 'apm', whilst running X.