Messages in this thread | | | Date | Wed, 12 Aug 1998 21:47:12 +0200 (CEST) | From | Geert Uytterhoeven <> | Subject | Re: kill -9 <pid of X> |
| |
On Wed, 12 Aug 1998, MOLNAR Ingo wrote: > On Wed, 12 Aug 1998, Alan Cox wrote: > > > Massive re-coding? Sounds like X just has to be protected from signal 9 > > > just like init. That means you just need something to make X unique > > > to the kernel's signal "generator". Remember, you did not kill X, you > > > told the kernel to do it --- and it did. > > > > Or the kernel decided to blow it away, or I fed it stuff that crashed it > > solidly. There are many ways to upset the Xserver. (Thats not entirely > > an argument against any specific setup btw - no doubt kernel code would > > have some upset potential too) > > is this a problem with the FB based X server too? If not then i dont see > the problem ... the FB console is always in a well-defined state. SAK > should work there too, just like on any console.
Video board wise the console is indeed in a well-defined state, unless you use a different X server than XF68_FBDev. But the keyboard is still in MEDIUM_RAW mode if you kill X the hard way. Simply restarting XF68_FBDev solves the problem though. I know, I did it many times when working on XF68_FBDev :-)
> X is 'fast and a bit unsafe sometimes'. ('very unsafe' with Alan's > definition ;) > > XFB is 'quite fast too and safe'. And people can start adding acceleration > (hard) to make it similarly fast, etc. But since we are not there yet, so > i think the flamewar is a bit too early :)
We're there, if you have a Retina Z3 graphics board :-)
Greetings,
Geert
-- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |