Date: Mon, 30 Jul 2001 11:27:02 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: tlambert2@mindspring.com Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Death sentence to KLD screen savers? Comments? Message-ID: <200107300227.LAA14664@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Sun, 29 Jul 2001 13:07:14 MST." <3B646CF2.F5E332A9@mindspring.com> References: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> <3B5E7DB3.97656D3C@mindspring.com> <200107260729.QAA25125@zodiac.mech.utsunomiya-u.ac.jp> <3B646CF2.F5E332A9@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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 true. 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 operation. > 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 panics. 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. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107300227.LAA14664>