Subject: Re: control of wscons screens
To: None <email@example.com>
From: Juergen Hannken-Illjes <firstname.lastname@example.org>
Date: 05/14/2002 17:57:54
On Tue, May 14, 2002 at 04:49:16PM +0100, email@example.com 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.
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 - firstname.lastname@example.org - TU Braunschweig (Germany)