[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]| -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
On Tue, 2003-10-21 at 04:29, Michel Dänzer wrote: > On Tue, 2003-10-21 at 16:03, Chris Ison wrote: > > > > Oct 21 23:56:51 (null) kernel: radeon: no version magic, tainting > > kernel. > > This happens here when I insmod radeon.o instead of radeon.ko with a 2.6 > kernel. It still works though, what happens if you try to load the > module manually? If you're using radeonfb in console, it could be the > new DRM PCI probing code which prevents it from loading if the devices > it supports have already been claimed. I've converted the DRM to old-style attachment. I haven't tested with radeonfb to see if it actually fixed it (netboot linux kernels are annoying to prepare), but my radeon and sis cards continued to work. If someone could test with radeonfb and the latest DRM, that would be great. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] getting list messages twice or more
I am, posted Oct 22, 8:14PM CST --- Alex Deucher <[EMAIL PROTECTED]> wrote: > Is anyone else getting every meesage that is sent to dri-devel twice or > sometimes even 3 or 4 times? It just started happening over the last > couple days. > > Alex > > __ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > > > --- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Ian Romanick wrote: Michel Dänzer wrote: On Wed, 2003-10-22 at 20:38, Ian Romanick wrote: Eric Anholt wrote: Would we ever be setting pointers through a setparam interface? I think making it an int makes it relatively clear that it's a 32-bit value, though it might be valuable to use [u]intXX_t for the drm (and dri screen private?) sruct definitions everywhere to make things clear. Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and 64-bit longs and pointers. Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes. That won't be necessary in any case; once there is a chip (which we support...) with a 64 bit address space, just add a parameter to set the high 32 bits. :) I don't mind either way, but I don't feel like figuring out which type to use for a 64 bit value and dealing with the build problems it might cause right now. I added Keith's proposed struct with int64_t as the value, and I added '#include ' to xf86drmCompat.c. Everything compiled fine. As a side note, at what time will we be able to deprecate xf86drmCompat? Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway. We can definitely remove the xf86drmCompat layer for XFree86 5.0. I believe it's well understood that major version changes will break existing binary interfaces. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] versioning ioctl and unique changes
On Wed, 2003-10-22 at 04:56, Eric Anholt wrote: > - What should the DRM do if the minor number for either DI or DD > interface is greater than the DRM knows about? Return DRM_ERR( EINVAL ) ? > - Do we want to put some reserved fields in the SET_VERSION ioctl in > case we want to extend it in some manner in the future? The versioning could be used to extend it? :) > - Should the libdri minor version be bumped for the new > DRICreatePCIBusID function? I think so. > Is using xf86LoaderCheckSymbol the way to see if it's available, That or the minor version I guess, whichever is more convenient. > and does it need to be in the symbol lists for the drivers? Yes, or it will probably be reported as unresolved when the dri module isn't loaded. > - I would like to move xf86drm.c to shared/drm/ (it's a shared file > anyway). [...] > - drm.h should probably get re-merged and put into shared/ Sounds good. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-10 18:18 --- "I have 2.4.22-ac4 unpatched" You have no module in the kernel for support of the radeon, either compile the Xfree module seperately then insmod it, or use the kernel patch. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Michel Dänzer wrote: On Wed, 2003-10-22 at 20:38, Ian Romanick wrote: Eric Anholt wrote: Would we ever be setting pointers through a setparam interface? I think making it an int makes it relatively clear that it's a 32-bit value, though it might be valuable to use [u]intXX_t for the drm (and dri screen private?) sruct definitions everywhere to make things clear. Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and 64-bit longs and pointers. Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes. That won't be necessary in any case; once there is a chip (which we support...) with a 64 bit address space, just add a parameter to set the high 32 bits. :) I don't mind either way, but I don't feel like figuring out which type to use for a 64 bit value and dealing with the build problems it might cause right now. I added Keith's proposed struct with int64_t as the value, and I added '#include ' to xf86drmCompat.c. Everything compiled fine. As a side note, at what time will we be able to deprecate xf86drmCompat? Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI CVS Running slow
Chris Ison wrote: Is anyone aware, or know how to resolve the slowness of the current DRI CVS, I'm only getting 30fps with glxgears compared to the 250+fps with the SF dri cvs. How recent is your CVS and which card are you using? For a short time vsync was enabled by default, and that would limit your frame rate. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] versioning ioctl and unique changes
On Wed, 2003-10-22 at 13:59, Michel Dänzer wrote: > On Wed, 2003-10-22 at 04:56, Eric Anholt wrote: > > - What should the DRM do if the minor number for either DI or DD > > interface is greater than the DRM knows about? > > Return DRM_ERR( EINVAL ) ? Okay, that's what it's doing. > > - Do we want to put some reserved fields in the SET_VERSION ioctl in > > case we want to extend it in some manner in the future? > > The versioning could be used to extend it? :) That would be messy, unfortunately, on BSD at least. The ioctl handler checks that the data size the user specified and that got copied in by the kernel matches the size the kernel expects. Actually, I suppose it would be doable, by marking the specific ioctl as expecting the smaller of the two sizes, making the size check be usersize >= kerenelexpectedsize, and then the specific ioctl handler would special-case the larger size. So I guess as long as there's no real expectation of needing to extend it, it can be ignored. > > - Should the libdri minor version be bumped for the new > > DRICreatePCIBusID function? > > I think so. > > > Is using xf86LoaderCheckSymbol the way to see if it's available, > > That or the minor version I guess, whichever is more convenient. > > > and does it need to be in the symbol lists for the drivers? > > Yes, or it will probably be reported as unresolved when the dri module > isn't loaded. Okay, I'll do these. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote: > Eric Anholt wrote: > > > Would we ever be setting pointers through a setparam interface? I think > > making it an int makes it relatively clear that it's a 32-bit value, > > though it might be valuable to use [u]intXX_t for the drm (and dri > > screen private?) sruct definitions everywhere to make things clear. > > Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and > > 64-bit longs and pointers. > > Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the > first 4GB today, but when PCI Express comes, I don't think that will > always be the case. I'd hate to have to invent a new ioctl to support PCI Express > when that > day comes. That won't be necessary in any case; once there is a chip (which we support...) with a 64 bit address space, just add a parameter to set the high 32 bits. :) I don't mind either way, but I don't feel like figuring out which type to use for a 64 bit value and dealing with the build problems it might cause right now. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] getting list messages twice or more
Same here. bye. At 12:16 PM 22/10/2003, Alex Deucher wrote: Is anyone else getting every meesage that is sent to dri-devel twice or sometimes even 3 or 4 times? It just started happening over the last couple days. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel Rafael Máximo --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Eric Anholt wrote: Would we ever be setting pointers through a setparam interface? I think making it an int makes it relatively clear that it's a 32-bit value, though it might be valuable to use [u]intXX_t for the drm (and dri screen private?) sruct definitions everywhere to make things clear. Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and 64-bit longs and pointers. Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: More expat problems...
Felix Kühling wrote: I'm sorry, I don't see where it gets linked. grep for glcontextmodes on a freshly regenerated driver Makefile doesn't find anything. The only related commit I found in my dri-patches archive is to lib/GL/dri/Imakefile. It compiles glcontextmodes.o in lib/GL/dri. But I can't find how it gets linked to the drivers. *Blush*. With the overloaded use of the word "linked" it took a bit for it to sink into my brain. You are correct. glcontextmodes.o does not get linked into the *_dri.so files. It was just dumb luck (emphasise whichever word seem more appropriate) that it worked at all. I'll fix up the makefiles today. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-10 10:20 --- What does "ls -l /dev/dri" show? Are you running devfs? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: can't get dricvs to use radeon drm
On Wed, 22 Oct 2003, Chris Ison wrote: >> Have you done all the proper idiot checks? >> >> I hate to use the word that way, but that's how I'd phrase it if I were >> speaking to myself... >> >> Have you checked to make sure /dev/dri/card0 exists, has the proper >> major and minor numbers, and is readable and writeable by root? >> > >ok, /dev/dri/card0 doesn't exists, so why does it work for the SF dri >and not the freedesktop one ... /dev/dri does exist, I'm thinking the SF >drm creates /dev/dri/card0 but the freedesktop one doesn't, but I could >be wrong. I will investigate this further by reverting back to the SF >cvs. The DRI project officially moved the CVS repository from sourceforge to freedesktop.org, so the freedesktop.org is now the official DRI project CVS repository and the sourceforge CVS repository is completely obsolete. Don't use it. The DRM doesn't create device nodes on the filesystem (that would be totally insane). The X server itself creates /dev/dri/card* as needed. -- Mike A. Harris --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-10 09:36 --- I need a little help getting this working. I have 2.4.22-ac4 unpatched and X 4.3.99.14 with patch 723. I have DRI, glx and radeon in my X config file. 'startx' gives this in /var/log: (==) RADEON(0): Write-combining range (0xe000,0x400) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed [drm] failed to load kernel module "radeon" (II) RADEON(0): [drm] drmOpen failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. I have a feeling I;ve forgotten something simple. BTW, glxgears segfaults. What have I missed? Thanks! -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] getting list messages twice or more
Is anyone else getting every meesage that is sent to dri-devel twice or sometimes even 3 or 4 times? It just started happening over the last couple days. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] America's Army 1.9.0 rendering bugs on radeon hardware
On Wed, 2003-10-22 at 07:44, Louis Garcia wrote: > I'm still running XF-4.3.0. I don't like running devel stuff. This bug > hasn't been fixed in 4_3_0 branch has it? Unlikely. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
ok, problem solved, looks lik I encounted a bug thats been fixed in the last couple of days, cvs up'd, redid make World and make install, copied across the radeon.o and it all works fine now. Thanx for everyones help. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] America's Army 1.9.0 rendering bugs on radeon hardware
I'm still running XF-4.3.0. I don't like running devel stuff. This bug hasn't been fixed in 4_3_0 branch has it? --Lou On Tue, 2003-10-21 at 21:36, Michel Dänzer wrote: > On Wed, 2003-10-22 at 00:58, Louis Garcia wrote: > > I'm running a radeon-7500 card and been playing wolfenstein and quake3 > > just fine under Fedora Core 3 (redhat beta). I just got America's Army > > to try it. Well it runs fine but the 3D rendering is messed up. How can > > I tell if this is a dri bug or a game bug? Is anyone playing this game? > > > > This bug report is exactly what I'm experiencing: > > https://bugzilla.icculus.org/show_bug.cgi?id=695 > > According to https://bugzilla.icculus.org/show_bug.cgi?id=695#c8 it > works with a DRI CVS snapshot from September though. Have you tried a > recent DRI CVS snapshot? > --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Radeon DRM memory layout transition
> systems will break, we don't need to add more. On PPC64 where mixed > mode is supported, sizeof(int) != sizeof(void*). I assume > the same is true on IA-64, x86-64, and SPARC64. x86-64 Linux (gcc) sizeof(int) == 4 sizeonf(long) == 8 sizeof(void*) == 8 x86-64 Windows (VC) sizeof(int) == 4 sizeonf(long) == 4 sizeof(void*) == 8 -- Daniel, Epic Games Inc. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] can't get dricvs to use radeon drm
Are you also loading a framebuffer driver? If so remove it and the DRM from freedesktop CVS will load. To make sure DRM is loaded right look for this in dmesg [drm] Initialized mga 3.1.0 20021029 on minor 0 --- Eric Anholt <[EMAIL PROTECTED]> wrote: > On Wed, 2003-10-22 at 00:55, Chris Ison wrote: > > > Have you done all the proper idiot checks? > > > > > > I hate to use the word that way, but that's how I'd phrase it if I were > > > speaking to myself... > > > > > > Have you checked to make sure /dev/dri/card0 exists, has the proper > > > major and minor numbers, and is readable and writeable by root? > > > > > > > ok, /dev/dri/card0 doesn't exists, so why does it work for the SF dri > > and not the freedesktop one ... /dev/dri does exist, I'm thinking the SF > > drm creates /dev/dri/card0 but the freedesktop one doesn't, but I could > > be wrong. I will investigate this further by reverting back to the SF > > cvs. > > Note that the X Server will first try to create /dev/dri/cardX if it's > missing, chmod/chown /dev/dri/cardX according to your settings in > XF86Config, then open /dev/dri/cardX. If that fails, it checks that the > device major/minor matches its expectations and recreates it if > necessary, then tries opening again. > > That said, I'm not sure what's going on here, if you actually have the > module loaded and the kernel printed the info line (the radeon > equivalent of "[drm] Initialized mga 3.1.0 20021029 on minor 0"). If > the module's loaded and it's not printing the line, then I need the > output of scanpci, I think. > = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 10:42, Linus Torvalds wrote: > On Wed, 15 Oct 2003, Jon Smirl wrote: > > > > If you are familar with the hardware please check that I got the PCI ID lists > > right. > > Please fix the fact that modern PCI is _not_ enumerated with just "bus, > slot, function". A lot of machines are starting to have a "domain number", > which allows fro multiple independent PCI subsystems in the same machine. > > On linux, you can use "pci_name(pdev)" to get a truly unique descriptor of > the device (within the PCI subsystem). It will look something like > > :00:02.0 > > for "domain 0, bus 0, device 2, function 0". > > In fact, for future sanity, it makes sense to not only have the location, > but the bus _type_ there too. Some day, maybe we won't all be using PCI > enumeration, and it really makes sense to prepare for that by explicitly > saying what _kind_ of address it is. > > So if you have a "struct pci_device *dev", then to uniquely identify it > among all other devices, use something like > > snprintf(name, sizeof(name), "pci%s", pci_name(dev)); > > which will allow you to use the same naming at some later day when/if you > want to support something else. In other words, if you were to support > sbus, you would have > > struct sbus_device = find_sbus_device(...) > > snprintf(name, sizeof(name), "sbus%s", sbus_name(dev)); > > and the name would still be unique, and you can easily parse it to see > what kind of device it is and where it is (even though different buses > will have different notions of what "where" is). > > (Yeah, yeah, you're only supporting PCI-mapped devices now - even the AGP > stuff obviously shows up in the PCI namespace. That doesn't mean that you > should design the interfaces to only handle PCI). Sent privately first, but I've got a couple more questions now. What is the proper way to get the equivalent of pci_name(pdev) on pre-2.5? Also, what is the cutoff where pci_name is available? Are the values from pci_name decimal or hex? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Tue, 21 Oct 2003, Eric Anholt wrote: > > What is the proper way to get the equivalent of pci_name(pdev) on > pre-2.5? Also, what is the cutoff where pci_name is available? Are the > values from pci_name decimal or hex? The cut-off is 2.5.74 or so. The numbers are hex, and it's really implemented by just caching the result of sprintf(string, "%04x:%02x:%02x.%d", pci_domain_nr(dev->bus), dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn)); (that last "%d" is irrelevant - the number is alway sin the range 0..7, so it's same in decimal, octal and hex ;). "pci_name()" is more convenient in printouts etc. If backwards compatibility of compatibility with *BSD makes "pci_name()" inconvenient, feel free to do it by hand like this, but the important parts I had were: - _please_ use the domain number. There are real machines with multiple independent PCI buses. We've already seen some real-life problems with drivers that look for companion chips without knowing about the "domain" thing, and as a result they find the wrong chip. The domain problem is rare today, but it will likely be less rare tomorrow. - please start thinking of the day when DRI won't be all about PCI, and the naming might be more complicated than the normal domain/bus/slot/func thing. Thus the suggestion to tag the address with the "address type" information. So whether you use "pci_name()" or anything else is much less important than the two points above. Linus --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
