Date: Tue, 27 Aug 1996 09:33:17 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sos@FreeBSD.org Cc: regnauld@tetard.glou.eu.org, hackers@FreeBSD.org Subject: Re: Specs on a Hitachi CM2085me monitor anybody ?? Message-ID: <199608271633.JAA24894@phaeton.artisoft.com> In-Reply-To: <199608270835.KAA14677@ra.dkuug.dk> from "sos@FreeBSD.org" at Aug 27, 96 10:35:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > But as Terry pointed out (and the problem was also brought up last > > time), any user land stuff would just blow away and be useless in > > kernel debugging (resetting the VGA board). > > Hmm, in the version of syscons that I'm currently working on there is > support for adding a new ioctl via a LKM, that can be used to load > special code to modify you timing. Also If you can tell me what > H&V-sync your monitor can handle, I can probably do a small patch > to the mode setting code that will allow you to use your monitor > for std modes ie 80x25, 80x50 etc... How do you deal with XF86_S3 reprogramming your dot clocks? You need to restore them as well... No, the only valid full-recovery mechanism is to build a finite state automaton, and don't let it wind state that you can't unwind. If they want something better than 800x600 on a Diamond card for X, for instance, then they need to load a non-default card driver that can wind and unwind the state to get there without the X code in user space writing to the port address space. There are good security reasons for taking this ability away from the server anyway; it does too many "requires root" things as it is... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608271633.JAA24894>