From: <ph...@bo...> - 2000-10-24 23:24:39
|
I've been looking through os-support/lnx_agp.c Its an existing find that was last updated in october 2000 A presumably key function is xf86BindGARTMemory but I just did a find . -type f -print | xargs grep -l xf86BindGARTMemory in the Xserver directory and the only files that turned up were ./hw/xfree86/os-support/xf86_OSproc.h ./hw/xfree86/os-support/linux/lnx_agp.c ./hw/xfree86/os-support/shared/agp_noop.c NOTHING seems to be using it. Yet you guys do use AGP, via drmAgpXXXXXX() calls. Why are you reinventing the wheel? Why aren't you using the existing xfree86 AGP manipulation calls? |
From: Jeff H. <jha...@va...> - 2000-10-25 13:56:26
|
Philip Brown wrote: > > I've been looking through os-support/lnx_agp.c > Its an existing find that was last updated in october 2000 > > A presumably key function is > xf86BindGARTMemory > > but I just did a > > find . -type f -print | xargs grep -l xf86BindGARTMemory > > in the Xserver directory > > and the only files that turned up were > > ./hw/xfree86/os-support/xf86_OSproc.h > ./hw/xfree86/os-support/linux/lnx_agp.c > ./hw/xfree86/os-support/shared/agp_noop.c > > NOTHING seems to be using it. > > Yet you guys do use AGP, via drmAgpXXXXXX() calls. > > Why are you reinventing the wheel? Why aren't you using the existing > xfree86 AGP manipulation calls? > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > http://lists.sourceforge.net/mailman/listinfo/dri-devel You have to understand that the DRI functions have a different purpose then the ones in XFree. The DRM has to know about agp, so it talks to the agp kernel module itself. It has to be able to protect certain regions of agp memory from the client side 3d drivers, yet it has to export some regions of it as well. While most of this functionality (most, not all) can be accomplished with the /dev/agpgart interface, it makes sense to use the DRM's current authentication mechanism. This means that there is less complexity on the client side. If we used /dev/agpgart then the client would have to open two devices, authenticate to both of them, and make half a dozen calls to agpgart, then only care about the DRM device. (As a side note, the XFree calls were written after the drm functions.) Also to answer a previous question about not using XFree calls for memory mapping, you have to understand that under most OS'es (probably solaris as well), XFree's functions will only work for root privileged processes. The whole point of the DRI is to allow processes that can connect to the Xserver to do some form of direct to hardware rendering. If we limited ourselves to using XFree's functionality, we would not be able to do this. We don't want everyone to be root. I hope this clears up some of your questions. -Jeff |
From: Rik F. <fa...@va...> - 2000-09-01 12:08:14
|
On Fri 1 Sep 2000 00:07:47 -0700, Philip Brown <ph...@bo...> wrote: > Well, I was trying to avoid joining another mailing list... but here I am. > > Could someone please tell me the minimum files to screw with, to port > the kernel-level stuff to a different UNIX flavor. > > I've been poking around, and it looks like I have to mess with > > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm > > However, I'm a bit bewildered, for multiple reasons. > > 1. the "library" and "kernel" sources seem to be in the SAME DIRECTORY: > drm/kernel ?? Some library sources are _linked_ to this directory so that you can build a test program. We should probably get rid of this because the test program isn't used much -- I've submitted a bug report on SourceForge. > 2. There's a "generic" subdir, which seems to be related to the > "generic" support hinted at by various precisioninsight.com documents; > > Except that directory is EMPTY. I don't see this in my tree. Did you use the -P option when you did the CVS co? That will prune empty directories. |
From: Rik F. <fa...@al...> - 2000-09-07 19:42:20
|
On Thu 7 Sep 2000 09:35:37 -0700, Philip Brown <ph...@bo...> wrote: > Is there a very very simple test program out there, that I could use to > test my kernel porting work, when my card gets here, and I can actually > start programming? :-) > > Ideally, something that can test just one operation at a time? The drmstat.c program in the X tree will test _some_ DRM kernel functions. Unfortunately, it's difficult to test many of the functions in a stand-alone manner; and no one seems to have updated it for recent drivers. It's difficult to tell if this is what your mail is about, but I hope it helps. |
From: <ph...@bo...> - 2000-09-07 20:03:34
|
[ Rik Faith writes ] > On Thu 7 Sep 2000 09:35:37 -0700, > Philip Brown <ph...@bo...> wrote: > > Is there a very very simple test program out there, that I could use to > > test my kernel porting work, when my card gets here, and I can actually > > start programming? :-) > > > > Ideally, something that can test just one operation at a time? > > The drmstat.c program in the X tree will test _some_ DRM kernel functions. > Unfortunately, it's difficult to test many of the functions in a > stand-alone manner; and no one seems to have updated it for recent drivers. well, it's a start... GAH! It's linuxified. Looks like the BSD folks haven't ported it yet to the rest of the world. sigh. It mostly uses a bunch of system("cat /proc/XXXX") calls. There's almost no reason for it to be a C program. May as well be a perl script instead. Ya know, the whole /proc/drm thing is nice for users. But since the primary dev is on linux, how about you linux guys standardize on an actual /dev/drm style interface that can be consistent across ALL UNIXen? And having a manpage, or at minimum, a usage() subroutine for stuff like drmstat would be a nice habit to get into, to. As soon as my programs have more than one possible usage flag, I ALWAYS add a usage() subroutine. |
From: Rik F. <fa...@va...> - 2000-09-08 01:41:38
|
On Thu 7 Sep 2000 13:45:23 -0700, Philip Brown <ph...@bo...> wrote: > reminder: I'm working with solaris, trying to get the user-level > bsd port to compile > > > > So.. why the heck is all that ugliness there in > xf86_libc.h, about #undef'ing, and #defining all these STANDARD THINGS, > like > > #undef mode_t > #define mode_t xf86mode_t This is support for the XFree86 module system. > Its' screwing up solaris compilation to hell, because you ALSO directly do > > #include <sys/ioccom.h> > > which requires #include <sys/types.h> under solaris The rule is that, if you include the module wrapper header files, then you must not include any other header files. drm.h needs the _IO* macros defined, and the only way to get them is to include a header file. Apparently, this is causing problems under Solaris. The solution seems to be to provide a private copy of the _IO* macros in a file that it is safe for drm.h to #include. > So I hacked things from the bsd tree. > Since I dont have cvs checkin permission, here's some diffs to get the > beastie to compile under solaris. It would be great if you could submit these via the SourceForge patch manager -- that way they won't get lost. (Unified diffs (diff -u) are usually easier to read and are more common on this list than are other kinds of diffs.) > 274,300d271 > < > < #if 0 > < for (i = 0; i < 8; i++) { > < sprintf(sysctl_name, "hw.dri.%d.name", i); > < sprintf(dev_name, "/dev/dri/card%d", i); > < len = sizeof(buf); > < if (sysctlbyname(sysctl_name, buf, &len, 0, 0) == 0) { > < buf[len-1] = '\0'; > < for (driver = pt = buf; *pt && *pt != ' '; ++pt) > < ; > < if (*pt) { /* Device is next */ > < *pt = '\0'; > < if (!strcmp(driver, name)) { /* Match */ > < for (devstring = ++pt; *pt && *pt != ' '; ++pt) > < ; > < if (*pt) { /* Found busid */ > < return drmOpenByBusid(++pt); > < } else { /* No busid */ > < dev = strtol(devstring, NULL, 0); > < return drmOpenDevice(dev_name, dev, > < mode, user, group); > < } > < } > < } > < } else remove(dev_name); > < } > < #endif This whole loop is fixed for bsd-compatibility on the main trunk in the linux version of xf86drm.c. I don't have a bsd system to test on, but it works without /proc by using /dev directly. |
From: <ph...@bo...> - 2000-09-08 07:24:14
|
[ Rik Faith writes ] > On Thu 7 Sep 2000 13:45:23 -0700, > Philip Brown <ph...@bo...> wrote: > > So.. why the heck is all that ugliness there in > > xf86_libc.h, about #undef'ing, and #defining all these STANDARD THINGS, > > like > > > > #undef mode_t > > #define mode_t xf86mode_t > > This is support for the XFree86 module system. Okay, you told me *where* it's being used. You didn't tell me WHY it's being used :-) Seems very backwards to me. It's doing things exactly backward. It should be how X11 handles things like CARD16, etc. typedef whatever xf86mode_t and then use xf86mode_t everywhere. overriding things like "mode_t" seems like non-safe practice, bound to lead into trouble sooner or later. And sure enough, it is now "sooner". > The rule is that, if you include the module wrapper header files, then you > must not include any other header files. drm.h needs the _IO* macros > defined, and the only way to get them is to include a header file. Wouldn't it be better to fix the way drm.h and other things work, instead of breaking header files? > Apparently, this is causing problems under Solaris. The solution seems to > be to provide a private copy of the _IO* macros in a file that it is safe > for drm.h to #include. Again, sounds like further along the "wrong" road. > It would be great if you could submit these via the SourceForge patch > manager -- that way they won't get lost. (Unified diffs (diff -u) are > usually easier to read and are more common on this list than are other > kinds of diffs.) I'll try that. After some sleep :-) |
From: Rik F. <fa...@va...> - 2000-09-26 13:07:34
|
On Sat 23 Sep 2000 11:23:34 -0700, Philip Brown <ph...@bo...> wrote: > I'm looking at the level of > > xfree86/os-support/bsd/drm > > and around the headers, I see > > #ifdef XFree86Server > [relative includes here] > #else > [full <include.h> headers here] > #endif > > Why is that? Starting with XFree86 4.0.0, the X server supports OS-independent modules. It order to support OS-independence, the server wraps all of the standard libc calls so that each module sees the API exported by the X server instead of the API that is specific to the OS. Code that will be compiled as an XFree86 module must not include any system-level header files (i.e., from /usr/include) or make any calls directly to libc entry points -- instead they include XFree86 wrappers and make calls to the XFree86 API, which then either calls libc or some compatibility code. The ifdef statements you are asking about allow the file (e.g., xf86drm.c) to be built as an os-independent module on the server side and as an os-dependent library or object file on the client side. [Note that the contents of xf86drm.c are not necessarily OS-independent at this time, but they are moving toward OS independence (I added a lot of the BSD-specific support to the version in os-support/linux/drm, for example) and will eventually be moved to another directory.] |
From: <ph...@bo...> - 2000-10-25 20:47:09
|
[ Jeff Hartmann writes ] > I hope this clears up some of your questions. Some. There are still one or two loose ends :-) > (As a side note, the XFree calls were written after the drm functions.) Ah. That helps for understanding of that bit. Is lnx_agp.c written by the xfree team, or the dri team? > ... If we used > /dev/agpgart then the client would have to open two devices, > authenticate to both of them, and make half a dozen calls to agpgart, > then only care about the DRM device. The CLIENT? Isn't the X _server_ the one doing the opening of the AGP hardware? And why is it so horrible to keep the two drivers open, if it drastically reduces code complexity? As you say, it opens the AGP stuff, then forgets about it. So keeping it separate should not increase code complexity compared to unifying it. Unification of code into a single module, is not always good. Especially if it is a future goal of xfree to support using AGP, without neccessarily using DRM. > Also to answer a previous question about not using XFree calls for > memory mapping, you have to understand that under most OS'es (probably > solaris as well), XFree's functions will only work for root privileged > processes. The whole point of the DRI is to allow processes that can > connect to the Xserver to do some form of direct to hardware rendering. > If we limited ourselves to using XFree's functionality, we would not be > able to do this. We don't want everyone to be root. How so, specifically for [device] memory mapping? The local client hands the local server a shared memory chunk, and says "Please map this to hardware for me". Or contrariwise, the local client asks the local server "Give me a chunk of memory that is mapped to the hardware. The X server then complies. The X server runs as root. It has "direct" access to the hardware. The client runs as a regular user. It has proxy access to the hardware through the X server. What's the problem with that? |
From: Jeff H. <jha...@va...> - 2000-10-25 22:20:15
|
Philip Brown wrote: > Ah. That helps for understanding of that bit. > Is lnx_agp.c written by the xfree team, or the dri team? It was written by XFree86 president David Dawes. > > > ... If we used > > /dev/agpgart then the client would have to open two devices, > > authenticate to both of them, and make half a dozen calls to agpgart, > > then only care about the DRM device. > > The CLIENT? Isn't the X _server_ the one doing the opening of the > AGP hardware? The Xserver is the one doing the initialization. However every client side driver that uses agp has to mmap an agp region or two. > > And why is it so horrible to keep the two drivers open, if it drastically > reduces code complexity? It will add complexity. Take my word for it. > As you say, it opens the AGP stuff, then forgets about it. So keeping it > separate should not increase code complexity compared to unifying it. You now need to authenticate via two seperate mechanisms. You have to ask the Xserver for permission to access the agp device. Then you have to do the same for the drm. Both of these authentications are complex involving a good hunk of code. This also means that the end user has to worry about configuring permissions for two devices correctly instead of just one. Anything that makes it harder for the user to use direct rendering is bad in my opinion. Its already hard enough. Plus the DRM kernel module usually has to know intimate details about agp. Sometimes it has to destroy mappings on the fly for security reasons (under the i810 for example). The above method is not flexible enough to do what we need to get done. > > Unification of code into a single module, is not always good. > > Especially if it is a future goal of xfree to support using AGP, without > neccessarily using DRM. Why would this be a problem? Granted its two interfaces to worry about, but they are very similar. If your using agp memory in a ddx module that supports the DRI, you use the drm calls if direct rendering is initialized. If your using agp memory without direct rendering enabled you use the XFree functions. Its not that complex. > > > Also to answer a previous question about not using XFree calls for > > memory mapping, you have to understand that under most OS'es (probably > > solaris as well), XFree's functions will only work for root privileged > > processes. The whole point of the DRI is to allow processes that can > > connect to the Xserver to do some form of direct to hardware rendering. > > If we limited ourselves to using XFree's functionality, we would not be > > able to do this. We don't want everyone to be root. > > How so, specifically for [device] memory mapping? > > The local client hands the local server a shared memory chunk, and says > "Please map this to hardware for me". > Or contrariwise, the local client asks the local server "Give me a chunk of > memory that is mapped to the hardware. > > The X server then complies. What do you mean here? Do you mean that the Xserver should have the ability to change the page tables of each client so that they would have a mapping to the hardware? Sounds horribly complex. I don't know of any OS which can do this from a user-space. Are you sure solaris can do this? I'm fairly confident that Linux can not. (However we could make a kernel driver to do this, but thats alot of work for no real gain, plus it adds ALOT of complexity to the kernel. You have to remember that every process running under Linux has its own individual page tables. This could also be something that could easily hurt stability, since a bug in the mapping code could now corrupt another processes page tables.) > > The X server runs as root. It has "direct" access to the hardware. > The client runs as a regular user. It has proxy access to the hardware > through the X server. > > What's the problem with that? Do you mean proxy as in indirect access to the hardware? Or do you mean proxy as in the Xserver will map the hardware for you? If you mean indirect, your missing the point. The WHOLE point of the DRI is to remove latency and overhead from talking to the graphics device. The acronym DRI stands for Direct Rendering Infrastructure. Handling this is a secure manner is a difficult problem. If we didn't care about performance, sure indirect is the way to go (it's alot simpler problem to solve.) Under certain circumstances we are going to be sending enormous amounts of data to the hardware (typically hundreds of MB/s.) Do you really propose that we add a level of indirection to that much streaming data? If you do not mean indirect access, but indirect mapping then see the above comment about how memory mapping works under other OS'es. -Jeff |
From: mitch(rezn) <gt...@pr...> - 2000-10-26 04:01:34
|
I could be wrong but I believe there is a problem with either gl.h or glu.h that comes with X 4.x involving mipmaps. I'm currently righting a opengl demo that uses mipmaps and I've noticed that it uses a gray scale for all the textures. |
From: Rik F. <fa...@va...> - 2000-10-26 00:47:15
|
On Wed 25 Oct 2000 13:46:12 -0700, Philip Brown <ph...@bo...> wrote: > > ... If we used > > /dev/agpgart then the client would have to open two devices, > > authenticate to both of them, and make half a dozen calls to agpgart, > > then only care about the DRM device. > > The CLIENT? Isn't the X _server_ the one doing the opening of the > AGP hardware? The client has to map the AGP memory into its address space. If it opened the /dev/agpgart device as a non-root user, we'd have to have some way to determine if it was an X client that was trusted by DRI. Instead, we perform the determination of trust and provide a way to get all of the mappings via the DRM device. Remember that the mappings that the client needs for DRI may be shared memory, hardware registers or frame buffer, or AGP or PCI GART memory. Dealing with all of these mappings in one place makes the code easier to maintain. > > Also to answer a previous question about not using XFree calls for > > memory mapping, you have to understand that under most OS'es (probably > > solaris as well), XFree's functions will only work for root privileged > > processes. The whole point of the DRI is to allow processes that can > > connect to the Xserver to do some form of direct to hardware rendering. > > If we limited ourselves to using XFree's functionality, we would not be > > able to do this. We don't want everyone to be root. > > How so, specifically for [device] memory mapping? > > The local client hands the local server a shared memory chunk, and says > "Please map this to hardware for me". > Or contrariwise, the local client asks the local server "Give me a chunk of > memory that is mapped to the hardware. > > The X server then complies. > > The X server runs as root. It has "direct" access to the hardware. > The client runs as a regular user. It has proxy access to the hardware > through the X server. > > What's the problem with that? It won't work. Remember that the communication between the client and server is done via the X11 protocol which is transported (in general) across a socket. You can't hand memory back and forth via a socket. [You could write a kernel driver that the X server would use to insert mapped memory into the client's address space, but this strikes me as a horrible solution, and is probably not what you were thinking about anyway. In any case, it would be significantly more difficult to do than what we are doing now.] Right now, there is a well-defined kernel driver. The X server: 1) tells that driver which regions of memory are available for mapping, and 2) authenticates clients that open connections to that driver. The clients then map memory using a standard mmap(2) call -- the only difference from using mmap(2) on /dev/mem is that authenticated non-root clients can successfully map regions of memory that would not be possible for them to map via /dev/mem. For more information on how the DRM works, please see the documents on http://www.precisioninsight.com/dr/drm.html for some information on how all this works (the DRM document is out of date now, but the basic design decisions remain). |
From: <ph...@bo...> - 2000-10-26 01:56:26
|
[ Rik Faith writes ] > On Wed 25 Oct 2000 13:46:12 -0700, > Philip Brown <ph...@bo...> wrote: > > The CLIENT? Isn't the X _server_ the one doing the opening of the > > AGP hardware? > > The client has to map the AGP memory into its address space. If it > opened the /dev/agpgart device as a non-root user, we'd have to have > some way to determine if it was an X client that was trusted by DRI. > Instead, we perform the determination of trust and provide a way to get > all of the mappings via the DRM device. Remember that the mappings that > the client needs for DRI may be shared memory, hardware registers or > frame buffer, or AGP or PCI GART memory. Dealing with all of these > mappings in one place makes the code easier to maintain. Okay, client gets a custom memory-mapped chunk, to make register fiddling easier. That part was pre-assumed. So far, so good... > > The local client hands the local server a shared memory chunk, and says > > "Please map this to hardware for me". > > Or contrariwise, the local client asks the local server "Give me a chunk of > > memory that is mapped to the hardware. > > > > The X server then complies. > > > > The X server runs as root. It has "direct" access to the hardware. > > The client runs as a regular user. It has proxy access to the hardware > > through the X server. > > > > What's the problem with that? > > It won't work. Remember that the communication between the client and > server is done via the X11 protocol which is transported (in general) > across a socket. You can't hand memory back and forth via a socket. But you can via shared memory. Which is why MIT-SHM was invented, after all. Dunno how well mmap and shm combines, though. Alternately: Why does the client side *really* need pure "direct" access? Okay, latency. But why can't you use doors or something, to have the client call functions in the server when it needs to tweak the hardware? SHM for getting the bulk pixels across, and then doors should almost remove the latency issue. This wouldn't bug me so much if there was an existing way to get hardware accelerated openGL in an "indirect" fashion. I'd just go work on that effort, and simplify my life. But the majority of the opensource effort right now for intel UNIX 3d hardware is going into the DRI modules, it seems. So you are the only game in town. > Right now, there is a well-defined kernel driver. The X server: > > 1) tells that driver which regions of memory are available for > mapping, and > > 2) authenticates clients that open connections to that driver. Why all the extra-special authentication? Why isn't it good enough to say "Whoever's on console can have access"? I dont know how linux does it, but on solaris, theres a fairly simple thing somewhere that checks who logs in on console, and basicaly does chown $USER /dev/fb /dev/audio Why isn't something simple like that appropriate, instead of adding yet another driver into the mix? > For more information on how the DRM works, please see the documents on > http://www.precisioninsight.com/dr/drm.html for some information on how > all this works (the DRM document is out of date now, but the basic > design decisions remain). I have read it already. Guess I'll revisit it. But also, to reply to Jeff's bit: >> Unification of code into a single module, is not always good. >> >> Especially if it is a future goal of xfree to support using AGP, without >> neccessarily using DRM. > >Why would this be a problem? Granted its two interfaces to worry about, >but they are very similar. If your using agp memory in a ddx module >that supports the DRI, you use the drm calls if direct rendering is >initialized. If your using agp memory without direct rendering enabled >you use the XFree functions. Its not that complex. It makes life a lot harder for someone like me, who is trying to understand the server code without having prior intimate knowlege of it. I think that generally, it is a reasonable assumption that if you are examining a piece of large code, for, lets say, "How does the software handle printing?", you look for the one module that printing. You dont expect to have to look on one side of the code for "Here's where I print postscript level1 documents", and an entirely different directory for "here's where I print postscript level 2 documents, to the same kind of printer, through the same port" * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * But the biggest pain in the ass, on the driver-level, is the assumption that you can split the agp driver up into a "front end", and a "back end", and that drivers can freely share functions between different modules. This is non-trivial under solaris. At this point, I'm not even sure it is POSSIBLE. In some ways, kernel modules under solaris are like user processes. They do not reside directly on physical RAM addresses: They get their own virtual address spaces. So I'm looking for any and all ways I can simplify this somewhat baroque structure. |
From: Nathan H. <na...@ma...> - 2000-10-26 05:25:39
|
On Wed, Oct 25, 2000 at 06:55:12PM -0700, Philip Brown wrote: > > Alternately: > Why does the client side *really* need pure "direct" access? > Okay, latency. But why can't you use doors or something, to have the client > call functions in the server when it needs to tweak the hardware? No, bandwidth. We are talking huge bandwidth here. The 3d cards are already maxing out PC busses. They're inventing new busses just to keep up with the enormous demands of the 3d cards. Any indirect access will involve at least 1 copy. That's going to halve the available bandwidth. The DRI actually increases latency through buffers. It doesn't matter. It's bandwidth that you try to maximise. > But the majority of the opensource effort right now for intel UNIX 3d > hardware is going into the DRI modules, it seems. So you are the only game > in town. What's this supposed to mean? The DRI is open source. The CVS is open. The mailing list is open. Everyone is allowed to contribute. PI releases every scrap of documentation possible and discusses nearly everything on the public mailing list. What more can PI do? > Why all the extra-special authentication? Why isn't it good enough to say > "Whoever's on console can have access"? > > I dont know how linux does it, but on solaris, theres a fairly simple thing > somewhere that checks who logs in on console, and basicaly does > > chown $USER /dev/fb /dev/audio > > Why isn't something simple like that appropriate, instead of adding yet > another driver into the mix? Because it isn't the console you want to authorise. You authorise against a X11 session. |
From: <ph...@bo...> - 2000-10-26 06:24:18
|
[ Nathan Hand writes ] > On Wed, Oct 25, 2000 at 06:55:12PM -0700, Philip Brown wrote: > > > But the majority of the opensource effort right now for intel UNIX 3d > > hardware is going into the DRI modules, it seems. So you are the only game > > in town. > > What's this supposed to mean? It means that if I want to get decent 3d hardware support, I have to work with what you guys are doing. Hence why I am very keen on trying to convince you folks to make my porting job easier :-) > The DRI is open source. The CVS is open. The mailing list is open. Everyone > is allowed to contribute. PI releases every scrap of documentation possible > and discusses nearly everything on the public mailing list. > What more can PI do? Well, since you did ask specifically, "what more can P.I. do?": Code to APIs. Don't write APIs to match the code after you've written it. Ideally, you should stop all forward coding, until you have written up two separate APIs -- the user level, and driver level -- that you know is going to work across linux, *bsd, solaris, and anything else appropriate. [Heck, I guess MacOS X might even be appropriate at this point] (and split up the user side, and kernel side on different pages/documents, with explainations how they will actually get USED, with examples) Submit them to the major appropriate newsgroup for comments on "Is this really optimal for your platform?" Then look at the API, and figure out, "These sections can be 100% portable. Lets put them in os-support/shared NOW. Never mind that nothing else is using them right now". Then for future mods: if you think the API doesnt meet forward needs, then fix the API *FIRST*. Code after you've updated it. ------------------------------ > > I dont know how linux does it, but on solaris, theres a fairly simple thing > > somewhere that checks who logs in on console, and basicaly does > > > > chown $USER /dev/fb /dev/audio > > > > Why isn't something simple like that appropriate, instead of adding yet > > another driver into the mix? > > Because it isn't the console you want to authorise. You authorise against a > X11 session. You have described what DRI does currently. You haven't described WHY it does it that way, which was my question. How can you have a session that can use DRI, where the primary user is not on console? PS: Odd, you give the impression you work for P.I. But you're not on the "team" page of the website |
From: Marcelo E. M. <mar...@bi...> - 2000-10-26 07:42:23
|
>> Philip Brown <ph...@bo...> writes: > How can you have a session that can use DRI, where the primary user > is not on console? FWIW, you can do this. Log in, generate an authentication entry, set the display to the remote machine, you are done. A "proper" method for doing this is on the works, but there are other things on my queue atm. -- Marcelo |
From: Nathan H. <na...@ma...> - 2000-10-26 10:33:06
|
On Wed, Oct 25, 2000 at 11:23:50PM -0700, Philip Brown wrote: > [ Nathan Hand writes ] > > > The DRI is open source. The CVS is open. The mailing list is open. Everyone > > is allowed to contribute. PI releases every scrap of documentation possible > > and discusses nearly everything on the public mailing list. > > What more can PI do? > > Well, since you did ask specifically, "what more can P.I. do?": > > Code to APIs. Don't write APIs to match the code after you've written it. What makes you think it wasn't done this way? > > Because it isn't the console you want to authorise. You authorise against a > > X11 session. > > You have described what DRI does currently. You haven't described WHY it > does it that way, which was my question. I think I have. The WHY and the WHAT have the same answer. > PS: Odd, you give the impression you work for P.I. > But you're not on the "team" page of the website I'm sorry if I gave that impression: I didn't intend to. |
From: bpendleton <bpe...@ze...> - 2000-10-26 13:42:36
|
Philip Brown wrote: > > How can you have a session that can use DRI, where the primary user is not > on console? > Render farm applications. The application is started remotely and renders using the local X server. No one is at the console. No one even needs to be logged in. No everyone using high speed 3D graphics under Linux is sitting at a console playing games. Bob Pendleton |
From: <ph...@bo...> - 2000-10-26 15:25:23
|
[ bpendleton writes ] > Philip Brown wrote: > > > > How can you have a session that can use DRI, where the primary user is not > > on console? > > > > Render farm applications. The application is started remotely and > renders using the local X server. No one is at the console. No one even > needs to be logged in. That's what I thought. In which case, its a customized machine, and there is no problem with doing chmod render_id /dev/dri or variants, to allow this to happen. |
From: Rik F. <fa...@va...> - 2000-10-26 12:15:15
|
On Wed 25 Oct 2000 23:23:50 -0700, Philip Brown <ph...@bo...> wrote: > PS: Odd, you give the impression you work for P.I. > But you're not on the "team" page of the website PI doesn't exist any more -- it was acquired by VA Linux Systems in April, 2000. The www.precisioninsight.com web pages aren't being updated any more, although we still have some documentation there that we have to move to SourceForge. |
From: Rik F. <fa...@va...> - 2000-10-26 12:28:53
|
On Wed 25 Oct 2000 23:23:50 -0700, Philip Brown <ph...@bo...> wrote: > You have described what DRI does currently. You haven't described WHY it > does it that way, which was my question. > How can you have a session that can use DRI, where the primary user is not > on console? X11 uses a model that allows more than one user (possibly on more than one machine) to connect to a single display (these connections may be limited with xhost and/or xauth, but they are possible in the basic X11 model -- you can do this my setting your display environment variable to the display on which you want your window to appear and, give the proper xhost/xauth settings, the window will appear there). The DRI tries to preserve the X11 model as much as possible. If clients had to be running as the console user, for example, this would eliminate an expected behavior of X11. So, instead, the DRI makes sure that the client has passed the standard xhost/xauth checks (because this is expected X11 behavior). The client also has to be local to the machine (since we are providing a direct-rendering solution). Additionally, we've added the ability for a system administrator to impose a stricter, though optional, _local_ policy on DRI use: the sysadmin can restrict DRI use to the members of a particular Unix group (Red Hat 7.0 imposes the additional restriction that the DRI user must be on the console, but this is a policy decision made by the distribution and the sysadmin who installs and configures the system -- the DRI is flexible enough in this respect to work well with any policy the sysadmin wants to impose, including the expected default X11 behavior). |
From: Rik F. <fa...@va...> - 2000-10-26 10:34:40
|
On Wed 25 Oct 2000 18:55:12 -0700, Philip Brown <ph...@bo...> wrote: > But you can via shared memory. Which is why MIT-SHM was invented, > after all. Dunno how well mmap and shm combines, though. They don't combine at all -- both are methods of creating a mapping within the process's virtual address space. > Alternately: > Why does the client side *really* need pure "direct" access? See Kilgard & Horn's System Support for OpenGL Direct Rendering: http://reality.sgi.com/opengl/direct/direct.html > Why all the extra-special authentication? Why isn't it good enough to say > "Whoever's on console can have access"? > > I dont know how linux does it, but on solaris, theres a fairly simple thing > somewhere that checks who logs in on console, and basicaly does > > chown $USER /dev/fb /dev/audio > > Why isn't something simple like that appropriate, instead of adding yet > another driver into the mix? I agree that the "console" security model might be a really good one for this application, but we selected a security model that is stronger than "whoever's on the console" (specifically, we require that the client has an open connection to the X server, and we allow the sysadmin to restrict use of direct rendering to a small group of people, independent of the group of people that can log in on the console). However, implementing this security model requires one or two tiny IOCTLs in the driver -- the driver is still necessary and the bulk of the driver performs other functions. > But the biggest pain in the ass, on the driver-level, is the assumption > that you can split the agp driver up into a "front end", and a "back end", For the DRI, you can 1) implement only the back end, *OR* 2) implement all of the AGP functionality in the DRM driver. The DRM driver must export IOCTLs that performs certain AGP functions -- it doesn't matter if the DRM driver does this, if there is an AGP/GART driver that does this, or if the native system has calls which do this. > and that drivers can freely share functions between different modules. Using a unified driver solves this problem. > This is non-trivial under solaris. At this point, I'm not even sure it is > POSSIBLE. > In some ways, kernel modules under solaris are like user processes. They do > not reside directly on physical RAM addresses: They get their own virtual > address spaces. > > So I'm looking for any and all ways I can simplify this somewhat baroque > structure. Don't think that you have to implement a driver infrastructure the way we do for Linux. Instead, concentrate on the exported IOCTL API and implement that at the driver level, and make sure that xf86drm.c exports the same function call API. |
From: <ph...@bo...> - 2000-10-26 15:46:24
|
[ Rik Faith writes ] > ... > Don't think that you have to implement a driver infrastructure the way > we do for Linux. Instead, concentrate on the exported IOCTL API and > implement that at the driver level, and make sure that xf86drm.c exports > the same function call API. So you're saying if I just get xf86drm.c happy, DRI should then work on my system? |
From: Dan M. <dm...@dc...> - 2000-10-26 21:22:39
|
Apologies for a somewhat-OT question, but I thought this would be the best place to ask. I'm working on a special-purpose application that requires TV (S-video) output functionality, as implemented in most recent video cards. I began working with the ATI Radeon, only to find out that ATI is unwilling to provide documentation on its video output features... So, I've been perusing the 3dfx hardware docs, which seem more promising. Before I get burned again though, I'd like to see if anyone has looked into this already... My question is this: is there enough information in publicly-available 3dfx docs to activate its TV-output? I'm already planning to write my own driver, etc; I don't need code. I just need some documentation along the lines of "To get TV out going, set such-and-such video mode, bang on such-and-such registers..." Thanks, Dan |