DRM_IOCTL_ADD_CTX perms; can't create context
I'm working on re-implementing an application to use mesa-solo with dri. I'm using a Radeon 9200 SE (rv280), latest CVS drm code and mesa drivers. In my mesa-solo tests I'm finding that there are two calls to drmCreateContext. The first is made by the server, and the second is made by the client application via glXCreateContext. The second call fails (access permission) at the ioctl call DRM_IOCTL_ADD_CTX. -- cut [17185712.396000] [drm:drm_ioctl] pid=5525, cmd=0xc0086420, nr=0x20, dev 0xe200, auth=1 [17185712.396000] [drm:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 1 [17185712.396000] [drm:drm_addctx] 1 [17185712.396000] [drm:drm_ioctl] pid=5525, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 [17185712.396000] [drm:drm_lock] 1 (pid 5525) requests lock (0x), flags = 0x [17185712.396000] [drm:drm_lock] 1 has lock [17185712.396000] [drm:drm_ioctl] pid=5525, cmd=0x40546440, nr=0x40, dev 0xe200, auth=1 -- cut [17185716.412000] [drm:drm_ioctl] pid=5527, cmd=0xc0086420, nr=0x20, dev 0xe200, auth=1 [17185716.412000] [drm:drm_ioctl] ret = fff3 --- cut -- Both processes are run as root, but there are two separate processes requesting the context - the miniglx server app is the first (successful), and the client prog is second (fails). I notice that the server app requests a lock which it doesn't surrender. Can this be the problem? (i.e. can the client add a context when the server holds the lock?). I don't understand the ioctl perms, but I'd have thought that root should get to do this. Is it that there are two processes here, and only one can have the context? Any ideas would be appreciated. Dan Sperka Center for Neuroscience UC Davis djsperka_at_ucdavis_dot_edu --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: linux-solo: drmCreateContext fails in DRM_IOCTL_ADD_CTX
Thanks, Stephane. What confuses me is that I'm running all these ioctls as root. I've done them sudo'd, then as root directly, both from a console (makes debugging a bit difficult) and via ssh. Any comment on why the addctx ioctl appears to run to completion (when I view my dbg statements in drm.ko output with dmesg), but the userspace function call to drmCreateContext gets an error message? Will the kernel disallow an ioctl with Permission denied, but still allow the ioctl method to run? Can't imagine why that would be the case Dan A check inside drmCreateContext shows that an error (13) is in fact returned by that method. An strace shows the following at the ioctl call: ioctl(4, 0xc0086420, 0xbfd0d758)= -1 EACCES (Permission denied) Well, I believe that, though I don't understand why I'm getting this error. I've read some comments on dri-devl from last summer regarding DRM and root/non-root privs. Could I be getting caught up by those requirements? Can anyone suggest how I debug/solve this problem? Yes, IIRC since the DRM root/non root stuff, you have to either run as root, or make all the ioctls non-root. Stephane Dan Sperka Center for Neuroscience UC Davis djsperka_at_ucdavis_dot_edu --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
linux-solo: drmCreateContext fails in DRM_IOCTL_ADD_CTX
hI - I'm trying to run linux-solo on Ubuntu 5.10 with kernel 2.6.15.1. This machine is a PIII and has an AGP radeon 9200SE (Rv280). I can boot into X and get direct rendering with this kernel and (newly compiled) modules. My drm modules are from cvs ca. 1/25/2006 I run the server and test app as root. I run sample_server, and all appears OK (using radeon_dri.so driver lib in miniglx.conf): [EMAIL PROTECTED]:/home/pdev/src/solo/Mesa/progs/miniglx# [miniglx] probed chipset 0x5964 got MMIOAddress 0xb7dfc000 offset 134217728 shared virtual width is 1280 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmGetBusid returned '' [drm] added 8192 byte SAREA at 0xd089b000 [drm] mapped SAREA 0xd089b000 to 0xb7dfa000, size 8192 [drm] framebuffer handle = 0xe000 [drm] register handle = 0xff8f [gart] AGP enabled at 2x [gart] 8192 kB allocated with handle 0x0001 [gart] ring handle = 0xf800 [gart] ring read ptr handle = 0xf8101000 [gart] vertex/indirect buffers handle = 0xf8102000 [gart] AGP texture map handle = 0xf8302000 Using 8 MB AGP aperture Using 1 MB for the ring buffer Using 2 MB for vertex/indirect buffers Using 1 MB for AGP textures Will use back buffer at offset 0x60 Will use depth buffer at offset 0xb0 Will use 114688 kb for textures at offset 0x100 in drmCreateContext [drm] Added 32 65536 byte vertex/indirect buffers [drm] dma control initialized, using IRQ 11 [drm] Initialized kernel gart heap manager, 5111808 color tiling disabled page flipping disabled [miniglx] Setting mode: visible 1280x1024 virtual 1280x1024x32 [miniglx] Readback mode: visible 1280x1024 virtual 1280x1024x32 RADEONEngineRestore Next I try to run miniglxtest (again as root) but get an error -- glxCreateContext fails, ultimately in drmCreateContext [EMAIL PROTECTED]:/home/pdev/src/solo/Mesa/progs/miniglx# ./miniglxtest [miniglx] probed chipset 0x5964 CreateNotify drmOpenByBusid: Searching for BusID PCI:1:0:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports PCI:1:0:0 Authorize - magic 1 drmCreateContext: err in ioctl, errno=13 drmCreateContext failed Error: glXCreateContext failed DestroyNotify I trace the code to drm/libdrm/xf86drm.c: drmCreateContext In that method is an ioctl call, ioctl(fd, DRM_IOCTL_ADD_CTX, ctx) Now I'm at my limit of understanding. I've placed some dbg stmts in the ioctl function (drm/linux-core/drm_context.c: drm_addctx()), and the ioctl method _appears_ to run to completion and return 0 (hence success). (I see these outputs in dmesg.) A check inside drmCreateContext shows that an error (13) is in fact returned by that method. An strace shows the following at the ioctl call: ioctl(4, 0xc0086420, 0xbfd0d758)= -1 EACCES (Permission denied) Well, I believe that, though I don't understand why I'm getting this error. I've read some comments on dri-devl from last summer regarding DRM and root/non-root privs. Could I be getting caught up by those requirements? Can anyone suggest how I debug/solve this problem? Thanks, Dan --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Need buffer swap counts
I am using mesa-solo in an application that attempts to generate simple 3d scenes at the full frame rate of the video card. I use an /etc/drirc file with the following option for my app: option name=vblank_mode value=3/ this option is supposed to synchronize the swap to the VBLANK period. Based on my reading of the code, and based on actual measurements this works as advertised, and quite well. I want to KNOW FOR CERTAIN that the swap occurred for a given frame, and that it didn't skip a frame or two in the process. When that happens, I need to know how many frames were missed. In some instances we use /dev/rtc for an independent measurement, but we cannot always rely on that solution. Under ordinary X, there is GLX_OML_sync_control, which provides methods to determine whether frame(s) were missed. In the miniglx interface this extension doesn't exist, and the various methods - like queryFrameTracking -- which would answer my questions are all hidden in opaque structs (opaque to a client app, at least). In particular, 'queryFrameTracking' is a member of 'DRIdrawable', but that struct is opaque to a glX client application like mine (it is defined in miniglxP.h). Can anyone tell me if a) I am wrong, i.e. ...nope, just call 'thisMethod' from your app, dummy or b) how I might approach the problem of exposing this functionality. I am somewhat familiar with the dri/Mesa code, but am not an expert. I would like the solution to be somewhat generic w/r/t video cards (but complete coverage isn't required -- r200 at a minimum because that's what we are using right now). Dan --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Why does radeon dri not allow page flipping?
The file radeon_dri.c sets several defaults in the radeon's private data. ctx-driverPrivate = (void *)info; info-gartFastWrite = RADEON_DEFAULT_AGP_FAST_WRITE; info-gartSize = RADEON_DEFAULT_AGP_SIZE; info-gartTexSize= RADEON_DEFAULT_AGP_TEX_SIZE; info-bufSize = RADEON_DEFAULT_BUFFER_SIZE; info-ringSize = RADEON_DEFAULT_RING_SIZE; info-page_flip_enable = RADEON_DEFAULT_PAGE_FLIP; There seems to be no way to configure my r200 to do page flipping! I've hacked the last line above to force page_flip_enable=1, and the page flipping seems to work with my tests, but this begs the question - Is there some other reason that page flipping is disabled (and cannot be re-enabled by configuration settings)? In other words, will the driver fail miserably under some conditions which I have not tried? I am using mesa linux-solo and radeonfb (miniglx). My application requires strict phase-locking with the video refresh rate. I can achieve this without page flipping, but the back-to-front buffer copy takes too long and I get a tear. Page flipping cleans this up nicely and my app happily marches in lockstep with the video refresh, no tears, just like the baby shampoo. I'd like to add a setting to miniglx.conf, enablePageFlip - something like I can put in my xorg.conf under my r200's Device section. I'd be glad to submit a patch if someone can give me a little guidance on the mechanics of creating the patch. Thanks, Dan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
linux-solo-x86 r200 build broken
Just checked out Mesa from CVS and attempted a build. It fails in src/mesa/drivers/dri/r200 -- portion of build log below. It appears that there are two files named 'radeon.h' in the -I dirs for the build of r200_dri.c. One is the one we need, but the other is in the drm folders. The drm folder (../../../../../../drm/shared) appears first on the command line, hence it is picked up. Its not the right file, though, so the build fails (but there's no indication of a missing .h file). I had a CVS checkout from a couple weeks ago and there was a change in the Makefile in src/mesa/drivers/dri/r200. I tried to replace the 'suspect' Makefile with the Makefile from my old CVS, but that build fails with a different error -- which refers to a DRM_* macro. It would appear that BOTH 'radeon.h' files are required (somewhere) in this build, but only one gets picked up. What has changed? Dan -- Command line from build using today's CVS make linux-solo-x86 cut - gcc -c -I../../../../../src/glx/mini -I../../../../../../drm/shared -I../../../. ./../../drm/libdrm -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I. ./../../../../../drm/shared -I../../../../../../drm/linux -I../../../../../inclu de -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../ ../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../ ../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../radeon/server -DDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C _SOURCE=199309L -D_GNU_SOURCE -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_ SSE_ASM -DPTHREADS -Wmissing-prototypes -O3 -g -std=c99 -Wundef -fPIC -ffast-mat h -DGLX_DIRECT_RENDERING server/radeon_dri.c -o server/radeon_dri.o server/radeon_dri.c: In function `RADEONEngineRestore': server/radeon_dri.c:160: error: `RADEONInfoPtr' undeclared (first use in this fu nction) server/radeon_dri.c:160: error: (Each undeclared identifier is reported only onc e --- Command line from build using today's CVS (with older makefile src/mesa/drivers/dri/r200/Makefile) make linux-solo-x86 cut - gcc -c -I../../../../../src/glx/mini -I../../../../../../drm/shared -I../../../. ./../../drm/libdrm -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I. ./../../../../../drm/shared -I../../../../../../drm/linux -I../../../../../inclu de -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../ ../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../ ../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -DDRI_NEW_INTERFACE _ONLY -D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L -D_ GNU_SOURCE -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -Wmissing-prototypes -O3 -g -std=c99 -Wundef -fPIC -ffast-math -DGLX_DIRECT_REND ERING server/radeon_dri.c -o server/radeon_dri.o server/radeon_dri.c: In function `RADEONDRIPciInit': server/radeon_dri.c:447: error: `DRM_PAGE_SIZE' undeclared (first use in this fu nction) --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] miniglx and radeon r200
Problem solved! My mistake - wrong driver being used. miniglx.conf: clientDriverName=r200_dri.so (was radeon_dri.so as in distribution file) D-U-M spells dum. Sorry for the bother. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
