>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

So, you seems to be effectively saying that any program running in the
lower priority in the user-land is the source of performance
degrataion :-)

>2)     Inability to disable the screen saver in, for example,
>       a "panic" situation, where there is no opportunity to

You may be thinking that we can put the video hardware back to the
known state after ANY KLD screen saver has run.  This is simply not

It is simply that the KLD screen savers we currently have are
well-behaved. Once you write a KLD screen saver which directly
manipulates the video hardware in the way the console driver isn't
aware of (and there is no mechanisms which will prevent you from doing
this), it becomes impossible for the console driver to undo such

>       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.

The console driver cannot undo what the X server does, because the X
server manipulates every bits of the video hardware to maximize its
performance and the console has no control over this. IF the X server
used olny console ioctls or touched generic VGA registers only, we
could put the video card back to the known state when the kernel

It's true that you can write a user-land screen saver which touchs the
video hardware (non-standard registers etc.) in a similar way to the X
server.  But, such screen savers won't be portable in the sense that
it runs only on certain video cards, and breaks on the other.
Therefore, you need to stick with console ioctls (and libvgl) to make
it run on every hardware.

# Of course, we don't have this problem with text-type screen savers
# which may use escape sequences or ncurses.


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

Reply via email to