On Tue, May 14, 2002 at 04:49:16PM +0100, brook@biology.nmsu.edu wrote:
> 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

Looks good, but:

VT_GETACTIVE and VT_ACTIVATE are only valid if WSDISPLAY_COMPAT_USL is defined.

First step should be new generic ioctl's to manage screens.

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)