Date: Sun, 30 Apr 1995 01:43:49 -0500 (CDT) From: Mike Pritchard <pritc003@maroon.tc.umn.edu> To: ache@astral.msk.su (Andrey A. Chernov, Black Mage) Cc: hackers@FreeBSD.org, sos@login.dknet.dk Subject: Re: Screen print capability Message-ID: <199504300643.BAA05486@mpp.com> In-Reply-To: <rSdaYela04@astral.msk.su> from "Andrey A. Chernov, Black Mage" at Apr 29, 95 03:55:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199504282254.RAA03844@mpp.com> Mike Pritchard writes: > >I implemented a /dev/screen device with code adapted from subr_log.c > >(/dev/klog). A daemon process (screend) sits and waits via select until > >a print screen event is generated. This event is generated by any of > >the combinations of the print_screen key that currently generate a NOP: > >shift+print, alt+print, and so on. When the waiting process wakes up, > >it will read the current screen contents (which can be something from > >the history buffer if you scroll back and hit the print screen button > >at that time). > > I think it should be implemented in another way. Arguments: > We have almost-true SCO console (syscons). > SCO console have escape to print out screen contents > and ioctl to grab screen contents and Alt-PrintScreen works there. > We need to ask Soren to implement this stuff in standard SCO > compatible way. > -- > Andrey A. Chernov : And I rest so composedly, /Now, in my bed, Are you saying that SCO consoles allow some type of escape sequence to be output to the screen to print the screen? Trivial to add to my current code, but I'm not sure I like the idea, since if I accidently cat a binary I might wind up doing 20 screen prints, or someone might send me a mail-bomb with 20 of those escape sequences in it. Even if the screen contents are returned via an ioctl instead of a read, you still need some mechanisim to wait for a screen print event (screend, and I'll pick another name) and then suck up the contents and print them out. With up to 16 virtual consoles, creating a special /dev/screen device to allow access to the current display seemed more reasonable than having to work with up to 16 /dev/ttyv* devices and then trying to shoehorn something onto that interface that wasn't a total kludge and didn't cause other side effects. Are there any SCO applications that we really want to support that rely on a screen capture mechanisim that works in a certain way? If so, then I'll be glad to do things that way if someone would just tell me what the external interface needs to look like. However, my current method should also be adaptable to PCVT type consoles with minimal work. This allows us to be more flexible, instead of limiting ourselves to an SCO type interface and having to duplicate code in two different areas (in syscons & pcvt). -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504300643.BAA05486>