The following is an initial proposal for an extension to wsconsctl to
enable controling the current screen.  I would greatly appreciate
answers to the following questions:

- is this capability available elsewhere?
- is this capability valuable as an addition to NetBSD?
- is wsconsctl the appropriate place to add it?
- if not, where?

Problem to solve: It seems that in order to suspend/resume a laptop
running an X server, wscons must first be switched into text mode
prior to suspending then switched back to graphics mode after
resuming.  For ease of use in the apm scripts (e.g., suspend and
resume) there should be a command that enables screen switching.
Switching screens can be done using the VT_ACTIVATE ioctl on the
wscons configuration file, so providing a command line interface to
that capability would be valuable.

Existing capability: As far as I can tell there are no existing
VT_ACTIVATE ioctls outside of the kernel in the 1.5 release branch.  I
don't have a -current source tree handy, so I can't say if it differs
in this regard.  This suggests, however, that there are no command
line interfaces that enable switching the wscons screen.

Proposed solution: The purpose of wsconsctl is to control aspects of
the wscons system.  Consequently, it seems appropriate to embed the
screen switching functionality within wsconsctl.  It seems that this
can be accomplished in the following way:

- Add a new "configuration" section to the code to extend the current
  keyboard, mouse, and display sections.  This section would be
  activated by the currently unused -c flag.  A new section is needed
  (rather than overloading the display section) because the file to
  manipulate is different (i.e., /dev/ttyEcfg rather than /dev/ttyE0).

- The new file config.c would implement the getting and setting of the
  current screen using the VT_GETACTIVE and VT_ACTIVATE ioctls.

- It may or may not be appropriate to include an option for waiting a
  certain amount of time and subsequently querying the current screen
  after setting it to account for the delay imposed by actual devices
  when they make the switch.  I am unsure if this is a problem in
  practice.  Suggestions welcome here.

Presumably code for this new section would exactly mimic the parallel
sections that already exist.

Please let me know if this is a reasonable proposal.  Additionally,
please offer any suggestions for implementation and/or naming of the
externally visible elements.

Thanks for your attention to this.

Cheers,
Brook