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 just call into other functions within that >driver. Indeed. I think the key part of your message, and I'm in complete concurrence with you, is "read the source Luke". ;o) For the benefit of the original poster, the source of the drivers is in: xc/programs/Xserver/hw/xfree86/drivers The source of the Nvidia proprietary drivers is in: /dev/null ;o) Hope this helps. -- Mike A. Harris _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
