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
>>xxxxEnterVT and xxxxLeaveVT (where xxxx 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 user-mode service.
>
>Where can I find information about this?
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.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
