Kazutaka YOKOTA wrote:
> >> I propose to have user-land screen savers instead of KLD
> >> screen savers.
> >
> >[ ... "performance degradation" ... ]
> >
> >[ ... "file access" ... ]
> >
> >I don't see either of these as being compelling arguments
> >in favor of a user space implementation; I guess this means
> >you want to do file access in your screen saver(s).
> 
> Both points/complaints/requests have been raised several times in our
> mailing lists in the past. (Sorry, I don't keep copies.)

I didn't say they weren't arguments, merely that I did not
find them compelling.  This looks to me like change for the
sake of change.


> Some people don't like cputime eaten up by the screen saver in the
> kernel...

The simple answer for this is to run in a kproc, and set the
priority to "idle", so it only runs when there is nothing else
to run.

Actually, running in user space adds two problems:

1)      Performance degradation as a result of protection
        domain crossing which does not exist in the current
        implementation

2)      Inability to disable the screen saver in, for example,
        a "panic" situation, where there is no opportunity to
        return to user space and have the screen put back into
        a known good state.  This is analogous to the problem
        we have diagnosing kernel panics while X11 is running
        on the console: only the user space program can undo
        what it has done, and we can not run the user space
        program.

> Some peopel want to write "interesting" screen savers...

Now we see the real reason for this... 8^).


> >Now if you could run Windows screen saver modules, you
> >might have a good argument for change, above and beyond
> >"change for the sake of change".
> 
> Personally I am not interested in fancy screen savers :-) But, just want
> to keep things tidy and keep the system running smoothly. By moving
> much of the screen saver support from the console driver to the
> user-land...

The problem here is that only the video driver knows what
it knows; short of converting FreeBSD's console over to
something like "GGI", you will have a hard time moving
*everything* to userland.

-- Terry


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to