Re: Nvidia driver relation to XFree
On Wed, 5 Nov 2003, Gerhard W. Gruber wrote: nvidia.o is not a kernel module. It is just a dynamically loaded object file that gets loaded by the XFree86 dynamic loader and called entirely in user mode. It could have been done as an ordinary .so DLL, but the design objective was to have these work regardless of operating system. That's why there is a loader built-in to XFree86. I think I know now where the confusion comes from. There is a kernel module for nVidia which you can download at their site and there is also, seemingly, a module within XFree86. I suppose the kernel part from nVidia is only there for 3D acceleration stuff, right? I looked into what functions this module exports but I can't make much of it. Seems mostly to do with register/memory access. There seems to still be some confusion here, let me try to clarify in more detail: There are 2 completely different Nvidia video drivers: 1) The open source one that comes with XFree86, as shipped by XFree86.org. This driver is called the nv driver as this is the name you specify for it in the XFree86 X server config file. The filename of this driver is nv_drv.o and this is the XFree86 2D driver which resides in the /usr/X11R6/lib/modules/drivers directory. This driver is 2D only and does not support 3D acceleration. It does not have a kernel module associated with it. 2) The proprietary closed source binary only video driver that is provided by Nvidia on their web site. This driver is called the nvidia driver because that is the name you specify for it in the XFree86 X server config file. The filename of this driver is nvidia_drv.o and this is the XFree86 2D driver which resides in the /usr/X11R6/lib/modules/drivers directory. This driver package also comes with Nvidia's proprietary libGL implementation, libglx module replacement, and Nvidia's proprietary binary only kernel module, as well as a binary blob and small amount of source code glue to relink it for new kernels. This kernel module resides in the kernel module heirarchy under /lib/modules and is named nvidia.o. All of the different parts of the Nvidia driver are proprietary, and provide 2D and 3D acceleration, etc. Some drivers DO have kernel modules, to handle the DMA transfers that are necessary for adequate 3D operation. However, kernel drivers are loaded with insmod. If you specify a driver name in the Device section of an XF86Config file, it is NOT a kernel driver. It is a user-mode library. There is a module which has to be loaded with insmod (or depmod if you prefer :) ), so I was wondering what this module is exactly doing and how it is related to XFree86. You never need to kernel modules by hand as the X server will do this for you automatically. When DRI is enabled in the open source drivers, and the driver also supports DRI, this will cause the X server to use modprobe to load the proper module for that card. Presumeably the Nvidia binary drivers work in a similar manner. Also, whenever one does load kernel modules by hand, using modprobe is generally speaking, the preferred method as it handles various things automatically. modprobe is more or less a front end to insmod so to speak. depmod does not load modules, it is ran during boot time, or after updating kernel modules and calculates kernel module interdependancies. Have you never looked at the XFree86 source code? You need to do so. Really. Much of this would be cleared up. I had a look at the source code, but the code base for XFree86 is not exactly small, so I didn't knew where to start. xc/programs/Xserver/hw/xfree86/drivers I looked into the kernel sources and I found some support for switching non-standard consoles (meaning non-textmode) which is aparently used by XFree86 and others like SVGAlib. The X server handles saving the current text mode, prior to then programming a new video mode itself, and then handles restoring the text mode when a VTswitch occurs. If you have a kernel module that you load with insmod, there still needs to be an XFree86 board-specific driver that can talk to that kernel driver. Yes. That's what I meant. I already looked into the code of XFree86 nVidia driver, but this will take some time to figure it out. :) I presume you mean the nv driver. Driver nvidia then XFree86 will load /usr/X11R6/lib/modules/drivers/nvidia_drv.o. The name of the EnterVT entry point is up to the driver, but it will usually be based on the driver name, just like you said. The module of XFree86 is nv for nVidia. The proprietary drivers are called nvidia. Apparently nVidia open sourced only that small part needed on the side of XFree86 and closed source on the kernel part. No, there are two completely different drivers. One is nv which is 2D only as described above, and is open source and maintained by Mark Vojkovich at Nvidia. The other proprietary driver does not use the
Re: Nvidia driver relation to XFree
On Wed, 5 Nov 2003, Gerhard W. Gruber wrote: Agreed. I think he is of the belief perhaps that an X driver module is perhaps like an SVGAlib API you can use in arbitrary programs perhaps including kernelspace, which of course isn't true. NO, I was not thinking of that. I was rather thinking to take a look on how the mode is exactly set so I can copy this to the kernel module. Of course not verbatim as this wouldn't work since it is user space code. I never intended to use the user space code from the kernel. What I wanted to know is, on how to read the current state so that I can save that information, do whatever I need to do, and then restore the original state so that the application executaion can resume without problems. Ok, gotcha. That's of course all true... I think he just totally misunderstands XFree86 and it's driver architecture in general. Might be. :) But that is because I had to download a kernel module and the OpenGL stuff from the nVidia web site. I think most of that is needed in order to use 3D acceleration, but I was not sure what else is in there. Correct, the Nvidia driver is not just for 3D acceleration however, it is a complete video driver, 2D/3D/etc. which is comprised of various components, and does not use the driver code included with XFree86. The Nvidia driver is useful to you if you want to use it in XFree86, but it isn't useful to you from a driver developer perspective as the source code isn't available. Perhaps knowing that the majority of drivers don't even have a kernel module at all period is a clearer indicator that XFree86 and it's userland video driver modules do _everything_ WRT setting video modes, and configuring the hardware to blast pixels. It can't do everything. When I run Enemy territory it switches to OpenGL 3D mode. This can obviously not done from within XFree86, because if that would be the case, I wouldn't have needed to download that kernel module and the libraries. Wrong. Video mode switching is completely done within XFree86 itself, and does not involve the kernel at all. The video driver directly programs the CRTC on the video card in some drivers, and in other drivers, the video mode is programmed using the video BIOS. Drivers with kernel modules, the kernel module contains interfaces which allow the userland 2D/3D driver components to do direct rendering to the video card, using DMA/IRQ. The Nvidia proprietary kernel module also contains other goodies of which probably include some kind of JIT compiler to compile microcode on the fly for their GPU engine. What else it might contain is anyone's guess as it isn't open source. Other proprietary drivers work similarly as well. Indeed. I think the key part of your message, and I'm in complete concurrence with you, is read the source Luke. ;o) I will do that. Now with your all help I know at least where I can start reading. :) Hope it helps out. ;o) Actually the open sourced part is in /root/src/NVIDIA_kernel-1.0-4191 along with the closed module nvidia.o downloaded from ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4496 That is not open sourced really. That is nothing bug glue code, and is useless other than for the purpose of relinking the Nvidia proprietary kernel driver to a new kernel, so you can continue to use their driver. Remember, open source does not mean you can read the source code, it means http://www.opensource.org definition of open source, which is where the term was coined. Initially the term was trademarked as well, so that people could not apply the term open source inappropriately to software that did not comply to the OSD (Open Source Definition), however the general community has kindof bastardized the term open source to mean you can access the source code and it doesn't matter what the license is. However it very much does matter what the terms of license a given piece of source code is under as to wether it can properly be called open source under the true and proper Open Source Definition. The Nvidia driver is not in any way open source. Just wanted to clarify this sometimes common misconception, in hopes that many people are reading this, and take a liking to the fine http://www.opensource.org website and it's terminology, fun articles, stories, and useful hacker tidbits and history. ;o) So it seems there IS a kernel module to accompany XFree86. :) There is no Nvidia kernel module which comes with XFree86, just the one that comes with the Nvidia proprietary video driver off Nvidia's website of which no source code is provided other than the small aforementioned useless kernel glue code used for relinking. This code, and the driver do not come with XFree86 and are not useful to driver developers trying to write their own video driver code or talk directly to the video card, as it is a proprietary driver. Hope this clears up any misconceptions for sure this time. ;o) The most useful
Re: Nvidia driver relation to XFree
On Thursday 06 November 2003 02:50 am, Mike A. Harris wrote: Remember, open source does not mean you can read the source code, it means http://www.opensource.org definition of open source, which is where the term was coined. Your statement confuses me. Maybe I miss your point, open source *does* mean you can read the source code. (Maybe you meant to say it does not mean that you can *only* read the source code?) Anyway, a hopefully relevant quote from the site you cited (http://www.opensource.org/): quote The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing. /quote I can't recall the name, but there is that other thing that Microsoft promotes that is their attempt to co-opt open source, the program that lets some of their customers view the source (for a fee) and (possibly) submit bug fixes, but does not actually let them modify the code (IIUC). regards, Randy Kramer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Thu, 6 Nov 2003 02:37:18 -0500 (EST), Mike A. Harris [EMAIL PROTECTED] wrote: There are 2 completely different Nvidia video drivers: Thanks. Now that is clear to me. There was some confusion on my part about the relation between the two. Also, whenever one does load kernel modules by hand, using modprobe is generally speaking, the preferred method as it Yes. I was mixing the names of depmod with modprobe. The X server handles saving the current text mode, prior to then programming a new video mode itself, and then handles restoring the text mode when a VTswitch occurs. Yes. The problem for me is how to save the current state of the video card, I hoped to learn that from the sources of XFree, but since it doesn't need to this ,it is not that much help to me. But there is still some value for me in it, because at least I can see how to reliably switch to textmode, which currently also doesn't work for me. I presume you mean the nv driver. Yes. maintained by Mark Vojkovich at Nvidia. The other proprietary Oh. That's a surprise to me. I thought only the proprietary part is from nVidia as they don't want to give out information. Well, maybe I can contact him and ask if he can tell me on how to save the the current state of the card. :) At least worth a try. very small part of it which the source code is available for which is not driver related, but which is a glue or shim later to glue the Nvidia binary blob to the kernel. This small bit of code is not helpful for video driver authors however, it contains no video control bits, just kernel glue. I noticed that. :) I thought that there should be at least some information in the exported functions, but I couldn't make much out of it. Look at the driver source in XFree86 for foo_dga.c files for example stuff. Thanks. I have not that much time, but from what I could read so far in the sources there are bits that are usefull to me. Hope this helps. Good luck with your work! Thanks. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Thu, 6 Nov 2003 02:50:57 -0500 (EST), Mike A. Harris [EMAIL PROTECTED] wrote: Wrong. Video mode switching is completely done within XFree86 itself, and does not involve the kernel at all. The video driver directly programs the CRTC on the video card in some drivers, and in other drivers, the video mode is programmed using the video BIOS. Drivers with kernel modules, the kernel module contains interfaces which allow the userland 2D/3D driver components to do direct rendering to the video card, using DMA/IRQ. The Nvidia Thanks. proprietary kernel module also contains other goodies of which probably include some kind of JIT compiler to compile microcode on the fly for their GPU engine. What else it might contain is Well, that I am not interested in anyway. Hope it helps out. ;o) Yes. Definitley. That is not open sourced really. That is nothing bug glue code, and is useless other than for the purpose of relinking the Nvidia proprietary kernel driver to a new kernel, so you can continue to use their driver. But it does export some function to be called from user space. Another kernel module can of course utilize these functions as well. At least if you know on how to use them. :) Hope this clears up any misconceptions for sure this time. ;o) Yes. :) The most useful stuff for you is most likely the 2D XFree86 nv driver source code, and whatever might be in the Linux kernel framebuffer driver, or BSD et al. Since no docs are available for this hardware though, you may have a tough time doing anything with it without the aide of someone familiar with the hardware. Wish you the best of luck nonetheless. I give it a try at least. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Thu, 6 Nov 2003 12:48:47 -0400, Randy Kramer [EMAIL PROTECTED] wrote: Your statement confuses me. Maybe I miss your point, open source *does* mean you can read the source code. (Maybe you meant to say it does not mean that you can *only* read the source code?) Well, there are two different meanings in the Open of Open Source. 1.) Open as in free for all to use, like in the GPL. 2.) Open to read for everybody. In the second case you can read the code, and often this already helps to understand why a bug in your own code occurs or how to employ badly documented features, but you are not allowed to use it in any way. Of course copying a function call from one source to the other shouldn't hurt because there is only one way to call a specific function, but you may not copy an algorithm or part of it. quote The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing. /quote But that is Open as in the first meaning which is not true for all open sources. I can't recall the name, but there is that other thing that Microsoft promotes that is their attempt to co-opt open source, the program that lets some of their customers view the source (for a fee) and (possibly) submit bug fixes, but does not actually let them modify the code (IIUC). It was in their govermental program, but I can't recall the name now. Some words that you would never associate with MS like trust and security. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Thu, 6 Nov 2003 00:49:28 +0100, Rafa? Rzepecki [EMAIL PROTECTED] wrote: Why won't you check the open sourced XFree86 driver called 'nv'? The only functionality it lacks is AFAIK OpenGL and XV acceleration, and I don't think you would use these in a debugger. That's what i do. Thanks. Also you could have a look at how libraries like SVGAlib do VT switching. I already looked also in these. My major problem is that I have not much experience with VGA programming, but I certainly have to check this as well. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Wednesday 05 of November 2003 00:30, Gerhard W. Gruber wrote: The module of XFree86 is nv for nVidia. The proprietary drivers are called nvidia. Apparently nVidia open sourced only that small part needed on the side of XFree86 and closed source on the kernel part. AFAIK, NVidia's driver consists of two parts, which intercommunicate: - the kernel driver, - the XFree driver, along with modified libGL. And EVERYTHING is closed source binary. Except for a little part of kernel driver which is needed for the driver to be able to load into whatever kernel the user is running; this part is compiled and then linked with binary part of that kernel module, which is then installed and loadable by insmod. And that kernel module communicates with closed source binary driver for XFree86, drv_nvidia.o. I hope that clears it up. -- Rafa Rzepecki ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Wed, 5 Nov 2003 18:14:03 +0100, Rafa³ Rzepecki [EMAIL PROTECTED] wrote: I hope that clears it up. Yes. Thanks. I hoped that the XFree part would have been open source, but of course that is a small hope. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Wednesday 05 of November 2003 23:03, Gerhard W. Gruber wrote: On Wed, 5 Nov 2003 18:14:03 +0100, Rafa Rzepecki [EMAIL PROTECTED] wrote: I hope that clears it up. Yes. Thanks. I hoped that the XFree part would have been open source, but of course that is a small hope. :) Why won't you check the open sourced XFree86 driver called 'nv'? The only functionality it lacks is AFAIK OpenGL and XV acceleration, and I don't think you would use these in a debugger. Also you could have a look at how libraries like SVGAlib do VT switching. -- Rafa Rzepecki ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 3 Nov 2003 18:36:52 -, Rob Taylor [EMAIL PROTECTED] wrote: one way to do what you want (from kernel space) is to use the kernel framebuffer driver for writing graphics, and use up one of the VT's for your debugger, switching to that vt when doing, umm, whatever your doing I know, and I'm looking into this, but I would prefer to support the normal X screen if possible. I have to ask tho, whats wrong with kgdb? 1.) kgdb I think has to use a kernel patch. 2.) If kgdb is similar to gdb then I don't really like it because the interface sucks. :) 3.) I want to have a decent debugger that can be used for stuff like driver development, but also user space debugging, with a nice interface. 4.) The original project is already there but the author abandonded it and I found thi sproject interesting, so I would like to continue it. From what I see on the statistics on sourceforge, it seems there is enough interest in such a project. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 11:31:41 -0800, Tim Roberts [EMAIL PROTECTED] wrote: nvidia.o is not a kernel module. It is just a dynamically loaded object file that gets loaded by the XFree86 dynamic loader and called entirely in user mode. It could have been done as an ordinary .so DLL, but the design objective was to have these work regardless of operating system. That's why there is a loader built-in to XFree86. I think I know now where the confusion comes from. There is a kernel module for nVidia which you can download at their site and there is also, seemingly, a module within XFree86. I suppose the kernel part from nVidia is only there for 3D acceleration stuff, right? I looked into what functions this module exports but I can't make much of it. Seems mostly to do with register/memory access. Some drivers DO have kernel modules, to handle the DMA transfers that are necessary for adequate 3D operation. However, kernel drivers are loaded with insmod. If you specify a driver name in the Device section of an XF86Config file, it is NOT a kernel driver. It is a user-mode library. There is a module which has to be loaded with insmod (or depmod if you prefer :) ), so I was wondering what this module is exactly doing and how it is related to XFree86. Have you never looked at the XFree86 source code? You need to do so. Really. Much of this would be cleared up. I had a look at the source code, but the code base for XFree86 is not exactly small, so I didn't knew where to start. I looked into the kernel sources and I found some support for switching non-standard consoles (meaning non-textmode) which is aparently used by XFree86 and others like SVGAlib. If you have a kernel module that you load with insmod, there still needs to be an XFree86 board-specific driver that can talk to that kernel driver. Yes. That's what I meant. I already looked into the code of XFree86 nVidia driver, but this will take some time to figure it out. :) The driver put it into that mode originally. It has a data structure that tells it exactly what timing parameters it set. All it has to do is do that again. I see. I hoped that the driver would read the current state from the hardware and forgot that it probably wouldn't need to do that. :) Driver nvidia then XFree86 will load /usr/X11R6/lib/modules/drivers/nvidia_drv.o. The name of the EnterVT entry point is up to the driver, but it will usually be based on the driver name, just like you said. The module of XFree86 is nv for nVidia. The proprietary drivers are called nvidia. Apparently nVidia open sourced only that small part needed on the side of XFree86 and closed source on the kernel part. ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. I see. That would fit what I read in the kernel module, at least what is available. There are documents on DGA in the XFree86 tree, and you can probably find pointers on the XFree86 web site. As others have said, however, I'm not sure it will help you, because DGA is an application interface that gets called from user-mode. Even if I can't use DGA directly, the source should provide information on how to handle the hardware, so that would help me also. I have to take a look at these. Thanks. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 3 Nov 2003 17:48:01 -0500 (EST), Mike A. Harris [EMAIL PROTECTED] wrote: Agreed. I think he is of the belief perhaps that an X driver module is perhaps like an SVGAlib API you can use in arbitrary programs perhaps including kernelspace, which of course isn't true. NO, I was not thinking of that. I was rather thinking to take a look on how the mode is exactly set so I can copy this to the kernel module. Of course not verbatim as this wouldn't work since it is user space code. I never intended to use the user space code from the kernel. What I wanted to know is, on how to read the current state so that I can save that information, do whatever I need to do, and then restore the original state so that the application executaion can resume without problems. That's of course all true... I think he just totally misunderstands XFree86 and it's driver architecture in general. Might be. :) But that is because I had to download a kernel module and the OpenGL stuff from the nVidia web site. I think most of that is needed in order to use 3D acceleration, but I was not sure what else is in there. Perhaps knowing that the majority of drivers don't even have a kernel module at all period is a clearer indicator that XFree86 and it's userland video driver modules do _everything_ WRT setting video modes, and configuring the hardware to blast pixels. It can't do everything. When I run Enemy territory it switches to OpenGL 3D mode. This can obviously not done from within XFree86, because if that would be the case, I wouldn't have needed to download that kernel module and the libraries. Indeed. I think the key part of your message, and I'm in complete concurrence with you, is read the source Luke. ;o) I will do that. Now with your all help I know at least where I can start reading. :) xc/programs/Xserver/hw/xfree86/drivers Thanks. The source of the Nvidia proprietary drivers is in: /dev/null Actually the open sourced part is in /root/src/NVIDIA_kernel-1.0-4191 along with the closed module nvidia.o downloaded from ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4496 So it seems there IS a kernel module to accompany XFree86. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Nvidia driver relation to XFree
I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. Can I use this interface in kernel modules as well? I think it should be possible. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? I know that I can install the framebuffer support for the kernel and then I would have an interface to do this, but I wonder how X is doing that. Can I get the pointer to the framebuffer and use it, or is there some way to do this via an interface through the driver. It is not exaclty clear to me on how X and nvidia.o are related to each other. Of course the same holds true for other cards, so the best solution for my purpose would be to find some way that is more or less independent of the card, but I guess this is to much to ask for. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 2003-11-03 at 16:51, Gerhard W. Gruber wrote: I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. Can I use this interface in kernel modules as well? I think it should be possible. You would probably need to use an XFree86 extension. Look at the DGA extension. -- Torgeir Veimo [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 17:51:53 +0100, Gerhard W. Gruber wrote: I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. The video driver is part of XFree86. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. However, the driver does have to save the INITIAL state of the graphics card when the driver starts up so it can restore that before switching back to a console. The console driver does NOT know how to switch back to text mode, so XFree86 must insure that the card is in its original condition before allowing the VT switch to go on. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Can I use this interface in kernel modules as well? I think it should be possible. Absolutely not. XFree86 drivers are just user-mode shared object files loaded by the XFree86 executable. They use a custom API and call a bunch of user-mode functions. They will not work in kernel mode. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? Haven't we had this conversation before? I know that I can install the framebuffer support for the kernel and then I would have an interface to do this, but I wonder how X is doing that. The XFree86 driver has INTIMATE knowledge of the specific graphics card. Typically, the driver goes out and reads the PCI configuration registers (or allows XFree86 to do it) to get the physical addresses assigned to the board. Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. Can I get the pointer to the framebuffer and use it, or is there some way to do this via an interface through the driver. It is not exaclty clear to me on how X and nvidia.o are related to each other. nvidia.o is part of XFree86. It is a dynamically-loaded library that implements the same interface as all other XFree86 video drivers, and it calls back in to the XFree86 executable and its other drivers for most of its services. Of course the same holds true for other cards, so the best solution for my purpose would be to find some way that is more or less independent of the card, but I guess this is to much to ask for. :) DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a user-mode service. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 16:58:10 +, Torgeir Veimo [EMAIL PROTECTED] wrote: You would probably need to use an XFree86 extension. Look at the DGA extension. I don't want to use X itself. I need to use this functionality from within a kernel module, so I don't want to rely on a user space application. I just want to know what is happening inside X to see if I can use at least some of it for my project. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Nvidia driver relation to XFree
one way to do what you want (from kernel space) is to use the kernel framebuffer driver for writing graphics, and use up one of the VT's for your debugger, switching to that vt when doing, umm, whatever your doing I have to ask tho, whats wrong with kgdb? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Roberts Sent: 03 November 2003 18:09 To: [EMAIL PROTECTED] Subject: Re: Nvidia driver relation to XFree On Mon, 03 Nov 2003 17:51:53 +0100, Gerhard W. Gruber wrote: I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. The video driver is part of XFree86. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. However, the driver does have to save the INITIAL state of the graphics card when the driver starts up so it can restore that before switching back to a console. The console driver does NOT know how to switch back to text mode, so XFree86 must insure that the card is in its original condition before allowing the VT switch to go on. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Can I use this interface in kernel modules as well? I think it should be possible. Absolutely not. XFree86 drivers are just user-mode shared object files loaded by the XFree86 executable. They use a custom API and call a bunch of user-mode functions. They will not work in kernel mode. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? Haven't we had this conversation before? I know that I can install the framebuffer support for the kernel and then I would have an interface to do this, but I wonder how X is doing that. The XFree86 driver has INTIMATE knowledge of the specific graphics card. Typically, the driver goes out and reads the PCI configuration registers (or allows XFree86 to do it) to get the physical addresses assigned to the board. Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. Can I get the pointer to the framebuffer and use it, or is there some way to do this via an interface through the driver. It is not exaclty clear to me on how X and nvidia.o are related to each other. nvidia.o is part of XFree86. It is a dynamically-loaded library that implements the same interface as all other XFree86 video drivers, and it calls back in to the XFree86 executable and its other drivers for most of its services. Of course the same holds true for other cards, so the best solution for my purpose would be to find some way that is more or less independent of the card, but I guess this is to much to ask for. :) DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a user-mode service. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 10:08:37 -0800, Tim Roberts [EMAIL PROTECTED] wrote: The video driver is part of XFree86. I don't think that this is neccessarily true, or is it? I don'tknow how it is for other cards but in case of NVidia you have this kernel module nvidia.o which you need to load and in the Device section I specify as driver nvidia. Of course it could be that this is just a name which coincides with the kernel module name. I assumed that it is the name of the module that is the driver, but I realize that this is not neccessarily so. Do you mean that this driver also has some part within X itself? It owuld make sense I guess. But then where is this particular module? Is this also some closed source stuff from nVidia? At least I only had to download the kernel module and nothing else because Suse is not allowed to bundle it with their distribution. I suppose, that this would be true for a module within X as well. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. However, the driver does have to Well, at least it needs to know which mode it was, because I can configure several modes and the switch shold restore the one that has been active when I switched console. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Is this the name of the driver mentioned in the XF86Config Device section? In my case this would then be called nvidiaLeaveVT? Absolutely not. XFree86 drivers are just user-mode shared object files loaded by the XFree86 executable. They use a custom API and call a bunch of user-mode functions. They will not work in kernel mode. But the call of the EnterVT/LeaveVT has to end up in the kernel module somewhere, so I guess it should be possible to trace that and see what is called. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? Haven't we had this conversation before? Well, it could be, because I asked this in several newsgroups. :) I sure never posted it on the XFree mailinglist I think. :) The XFree86 driver has INTIMATE knowledge of the specific graphics card. Typically, the driver goes out and reads the PCI configuration registers (or allows XFree86 to do it) to get the physical addresses assigned to the board. Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? nvidia.o is part of XFree86. It is a dynamically-loaded library that implements the same interface as all other XFree86 video drivers, and it calls back in to the XFree86 executable and its other drivers for most of its services. Thanks. I see if I can locate this functions and what they do. DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a user-mode service. Where can I find information about this? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 03 Nov 2003 19:53:56 +0100, Gerhard W. Gruber wrote: ? On Mon, 03 Nov 2003 10:08:37 -0800, Tim Roberts [EMAIL PROTECTED] wrote: The video driver is part of XFree86. I don't think that this is neccessarily true, or is it? Yes, it is. I don'tknow how it is for other cards but in case of NVidia you have this kernel module nvidia.o which you need to load and in the Device section I specify as driver nvidia. nvidia.o is not a kernel module. It is just a dynamically loaded object file that gets loaded by the XFree86 dynamic loader and called entirely in user mode. It could have been done as an ordinary .so DLL, but the design objective was to have these work regardless of operating system. That's why there is a loader built-in to XFree86. Of course it could be that this is just a name which coincides with the kernel module name. I assumed that it is the name of the module that is the driver, but I realize that this is not neccessarily so. Some drivers DO have kernel modules, to handle the DMA transfers that are necessary for adequate 3D operation. However, kernel drivers are loaded with insmod. If you specify a driver name in the Device section of an XF86Config file, it is NOT a kernel driver. It is a user-mode library. Do you mean that this driver also has some part within X itself? ALL XFree86 graphics drivers are part of XFree86. The interface they use is specified by and used by the XFree86 executable ONLY. Have you never looked at the XFree86 source code? You need to do so. Really. Much of this would be cleared up. It owuld make sense I guess. But then where is this particular module? Is this also some closed source stuff from nVidia? At least I only had to download the kernel module and nothing else because Suse is not allowed to bundle it with their distribution. I suppose, that this would be true for a module within X as well. If the driver lives in /usr/X11R6/lib/modules/drivers and is named in XF86Config, it is NOT a kernel module. It is a dynamic library that is an integral part of XFree86. If you have a kernel module that you load with insmod, there still needs to be an XFree86 board-specific driver that can talk to that kernel driver. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. Well, at least it needs to know which mode it was, because I can configure several modes and the switch shold restore the one that has been active when I switched console. The driver put it into that mode originally. It has a data structure that tells it exactly what timing parameters it set. All it has to do is do that again. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Is this the name of the driver mentioned in the XF86Config Device section? In my case this would then be called nvidiaLeaveVT? Yes, the name of the driver file is in the XF86Config Device section. If you say: Driver nvidia then XFree86 will load /usr/X11R6/lib/modules/drivers/nvidia_drv.o. The name of the EnterVT entry point is up to the driver, but it will usually be based on the driver name, just like you said. But the call of the EnterVT/LeaveVT has to end up in the kernel module somewhere, so I guess it should be possible to trace that and see what is called. NO, NO, NO! EnterVT/LeaveVT do NOT end up in a kernel module! The user-mode driver that is part of XFree86 does ALL of the register manipulation needed to change the video mode in and out of graphics. It's ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. ... Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? It doesn't INTERACT with the driver. It IS the driver. Every driver in the XFree86 source code (which you really need to read) includes EnterVT and LeaveVT entry points, that do whatever needs to be done to switch the board into and out of graphics mode. For many of the drivers, EnterVT and LeaveVT looks the same; they just call into other functions within that driver. DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a
Re: Nvidia driver relation to XFree
Tim Roberts wrote: NO, NO, NO! EnterVT/LeaveVT do NOT end up in a kernel module! The user-mode driver that is part of XFree86 does ALL of the register manipulation needed to change the video mode in and out of graphics. It's ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. ... Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? It doesn't INTERACT with the driver. It IS the driver. Every driver in the XFree86 source code (which you really need to read) includes EnterVT and LeaveVT entry points, that do whatever needs to be done to switch the board into and out of graphics mode. For many of the drivers, EnterVT and LeaveVT looks the same; they just call into other functions within that driver. I think that one more thing to be said here is that the video drivers' Enter/LeaveVT are 1) completely driver private functions, and 2) - more important - not doing everything needed in order to switch to another VT or back to the server. Leave/EnterVT (with root entry points in one of the top level structures, ScrnInfo) are possibly a cascade of functions which are called one after the other in order to do this. Just - in what hacky way ever - calling a video driver's Enter/LeaveVT will have very unpleasant and unexpected results. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
On Mon, 3 Nov 2003, Tim Roberts wrote: Just noticed a couple of (obviously accidental) inaccuracies which I thought I'd try to clear up a bit as the original poster might be confused a bit from some slightly conflictual statements that are IMHO obvious typo/thinkos. The video driver is part of XFree86. I don't think that this is neccessarily true, or is it? Yes, it is. I don'tknow how it is for other cards but in case of NVidia you have this kernel module nvidia.o which you need to load and in the Device section I specify as driver nvidia. nvidia.o is not a kernel module. It's not? ;o) It is just a dynamically loaded object file that gets loaded by the XFree86 dynamic loader and called entirely in user mode. That's nv_drv.o for the XFree86 supplied driver, and nvidia_drv.o for the Nvidia supplied proprietary one of course. It could have been done as an ordinary .so DLL, but the design objective was to have these work regardless of operating system. That's why there is a loader built-in to XFree86. A debateable benefit considering the amount of additional developmental hurdles the ELF loader brings with it, including extra unnecessary complexities trying to debug a modular X server, and requiring a special patched gdb, or to do a static build, which often times then doesn't show the problem anymore, etc. etc. And then there's the fact of how truely few non-OSS modules exist out there, and wether they actually do operate across different OS's of the same architecture. IMHO the ELF loader is only a real win for all it's costs if proprietary-only modules without source code truely work on all OS's. But that's debateable I'm sure, and kindof a side topic, so I digress. Of course it could be that this is just a name which coincides with the kernel module name. I assumed that it is the name of the module that is the driver, but I realize that this is not neccessarily so. Some drivers DO have kernel modules, to handle the DMA transfers that are necessary for adequate 3D operation. However, kernel drivers are loaded with insmod. modprobe actually. ;o) Do you mean that this driver also has some part within X itself? ALL XFree86 graphics drivers are part of XFree86. The interface they use is specified by and used by the XFree86 executable ONLY. Have you never looked at the XFree86 source code? You need to do so. Really. Much of this would be cleared up. Agreed. I think he is of the belief perhaps that an X driver module is perhaps like an SVGAlib API you can use in arbitrary programs perhaps including kernelspace, which of course isn't true. It owuld make sense I guess. But then where is this particular module? Is this also some closed source stuff from nVidia? At least I only had to download the kernel module and nothing else because Suse is not allowed to bundle it with their distribution. I suppose, that this would be true for a module within X as well. If the driver lives in /usr/X11R6/lib/modules/drivers and is named in XF86Config, it is NOT a kernel module. It is a dynamic library that is an integral part of XFree86. Or installed separately by a proprietary vendor's installation or third party project such as GATOS (for the case of ATI hardware, just as an example.) But the call of the EnterVT/LeaveVT has to end up in the kernel module somewhere, so I guess it should be possible to trace that and see what is called. NO, NO, NO! EnterVT/LeaveVT do NOT end up in a kernel module! The user-mode driver that is part of XFree86 does ALL of the register manipulation needed to change the video mode in and out of graphics. It's ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. That's of course all true... I think he just totally misunderstands XFree86 and it's driver architecture in general. Perhaps knowing that the majority of drivers don't even have a kernel module at all period is a clearer indicator that XFree86 and it's userland video driver modules do _everything_ WRT setting video modes, and configuring the hardware to blast pixels. ... Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? It doesn't INTERACT with the driver. It IS the driver. Every driver in the XFree86 source code (which you really need to read) includes EnterVT and LeaveVT entry points, that do whatever needs to be done to switch the board into and out of graphics mode. For many of the drivers, EnterVT and LeaveVT looks the same; they
