Re: [Xpert]Video drivers and the kernel
Hi! > (Aside, is this because X uses keyboard in raw mode? would be nice to still > be able to ctrl-alt-del to rebood from console) Anyone know about > using alt-sysrq to restore console? Alt-SysRq-U,S,B. Should work as long as kernel is alive. It is not completely clean shutdown, but will prevent fsck. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
Hi! (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? Alt-SysRq-U,S,B. Should work as long as kernel is alive. It is not completely clean shutdown, but will prevent fsck. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
>(Aside, is this because X uses keyboard in raw mode? would be nice to >still be able to ctrl-alt-del to rebood from console) Anyone know about >using alt-sysrq to restore console? > >So, if the kernel had a card specific module that just knew enough >to put the card back into text mode, or if it used the card's bios >to do it like the int10.a module in XFree 4.0, we would lack for nothing. >(hmm vesafb could be extended?) Working on it. I already have it so you can go from vgacon to /dev/fb and back to vgacon. It is in the works to have vgacon restore the text mode, palette and fonts when switching away from the X server. One of the problems I have seen is under heavy load switching away from X often doesn't restore the text console properly. Vgacon could. This is also handy when the X server dies :-) As for using the card's BIOS. Yuck yuck!! We have other platforms to consider like PPC. PPC is a pretty popular platform. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
(Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) Working on it. I already have it so you can go from vgacon to /dev/fb and back to vgacon. It is in the works to have vgacon restore the text mode, palette and fonts when switching away from the X server. One of the problems I have seen is under heavy load switching away from X often doesn't restore the text console properly. Vgacon could. This is also handy when the X server dies :-) As for using the card's BIOS. Yuck yuck!! We have other platforms to consider like PPC. PPC is a pretty popular platform. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
Please CC me if sending to xpert list. This is a big topic. I think I can contribute a whole two cents worth though... Interesting to note that NT's windowing system moved from being originally in userland to inside the kernel between V3.? and 4.0. Remember mom saying "If your friends all jump off a bridge..." The issue I understand is that context switching kernel<>user slows things down. And then there's trying to make an api... XFree just maps mmio/framebuffer and ioports into it's own address space and bangs the hardware, so it's fast and can do anything. DRI extends this to client 3D code in a sense. Bottom line for me, I don't care; as long as I still can use remote X apps, and Quake3 uses my 3D hardware, I'm happy to have people spend their time improving X how they see fit, and they're done an incredible job so far. My only complaint is when there's a problem with X: It's cool that I can just restart it rather than reboot like windows. (so you can play from console of a server right? :) This is a benefit of it being in userspace. But it would be nice if I didn't have to do it via telnet; sometimes I don't have a box on a network. (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) > On Tue, 13 Feb 2001, Louis Garcia wrote: > > > I was wondering why video drivers are not part of the kernel like every > > other piece of hardware. I would think if video drivers were part of the > > kernel and had a nice API for X or any other windowing system, would not > > only improve performance but would allow competing windowing systems > > without having to develop drivers for each. Has anyone thought or > > rejected this idea. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
Please CC me if sending to xpert list. This is a big topic. I think I can contribute a whole two cents worth though... Interesting to note that NT's windowing system moved from being originally in userland to inside the kernel between V3.? and 4.0. Remember mom saying "If your friends all jump off a bridge..." The issue I understand is that context switching kerneluser slows things down. And then there's trying to make an api... XFree just maps mmio/framebuffer and ioports into it's own address space and bangs the hardware, so it's fast and can do anything. DRI extends this to client 3D code in a sense. Bottom line for me, I don't care; as long as I still can use remote X apps, and Quake3 uses my 3D hardware, I'm happy to have people spend their time improving X how they see fit, and they're done an incredible job so far. My only complaint is when there's a problem with X: It's cool that I can just restart it rather than reboot like windows. (so you can play from console of a server right? :) This is a benefit of it being in userspace. But it would be nice if I didn't have to do it via telnet; sometimes I don't have a box on a network. (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) On Tue, 13 Feb 2001, Louis Garcia wrote: I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: > I was wondering why video drivers are not part of the kernel like every > other piece of hardware. I would think if video drivers were part of the > kernel and had a nice API for X or any other windowing system, would not > only improve performance but would allow competing windowing systems > without having to develop drivers for each. Has anyone thought or > rejected this idea. You should drop this subject as it will only result in flame wars. They have in the past and the result is always the same... 1) XFree86 is about the X window system. We don't give a damn about competing window systems. 2) There isn't a single API that can encompass all hardware. 3) Kernel drivers are OS specific things and XFree86 runs on too many platforms so we won't be able to abandon user-space drivers. At least not any time soon. That said, there are fbdev drivers for XFree86 and there are some hardware-specific solutions like NVIDIA's binary drivers. If you want to do something else, that's your perrogative. But don't waste your time trying to get everybody to agree with you. I won't happen. Sorry to be a bit abrupt, but there have been a few other discussions of this nature in the past and it's best that it doesn't go much further. At least not on XFree86 lists. Mark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. You should drop this subject as it will only result in flame wars. They have in the past and the result is always the same... 1) XFree86 is about the X window system. We don't give a damn about competing window systems. 2) There isn't a single API that can encompass all hardware. 3) Kernel drivers are OS specific things and XFree86 runs on too many platforms so we won't be able to abandon user-space drivers. At least not any time soon. That said, there are fbdev drivers for XFree86 and there are some hardware-specific solutions like NVIDIA's binary drivers. If you want to do something else, that's your perrogative. But don't waste your time trying to get everybody to agree with you. I won't happen. Sorry to be a bit abrupt, but there have been a few other discussions of this nature in the past and it's best that it doesn't go much further. At least not on XFree86 lists. Mark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
