[Dri-devel] Re: SPAM : DRI Devel ratio
В сообщении от 28 Май 2003 10:38 Russ Dill написал: > > >> Is this a good idia filter out all messages with html??? > > > > > >only if you think people who send html email have nothing usefull to > > >say. I'll ask a related question, is it good to filter out messages with > > >foriegn charsets, like, say, koi8-r? > > > > No, it is actually a bad idea. A very bad idea. A while back, I > > blocked Japanese encodings because a large portion of spam I > > received was in Japanese encoding (sp?). > > > > I was being sarcastic, his message was encoded with koi8-r, which, along > with being html, is one of the indescriminate reasons people block email > (and get a good number of false positives) I see :-( May be I have said not what I mean :-( I am not very well with english. . . There was question How many messages in html wich is not spam??? I can not read the messages, any way. . . unfortunatly I do not remember where I have read the suggestion do not post html in mail lists... Yes it is always posible to setup the mail list polisy accept only mail in Content-Type: text/plain; charset=ascii (yes this polisy also forbid charset=iso-8859-1) but in the case there mast be some explanation how to setup users' mail client to send mail in the list in appropriate form. . . --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Fwd: can you believe this wl
adri-develo adri-develodri-devele N¬HYÞµéX¬²'²Þu¼n7µ+hâ ~Vµéâ .´/¾¢²Z½§(uëh© Ê«jeÆßاj·¥jب©]jÖjÇ¢²¢û¥vív 9¸ÞrÔ¢·£ Z®Ú >º ë,JíÁªÞÛiÿü0ÂãyËl¶Þ벫qçè®®'^½éfj)b b²ÐëׯzYb²Û,¢êÜyú+éÞ¶m¦Ïÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~Ý®'^½é
[Dri-devel] 西安房地产信息网行业热门话题
Title: 西安房地产信息网 西安房地产信息网 www.800j.cc 非典时期买楼该注重什么？ 谁来评述“世家星城” . 我要发言 进入论坛 --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problem with latest trunk and i810?
- > But DRI doesn't seem to work with my i810 chipset. I'm attaching my - > 'dmesg' and 'XFree86.0.log'. Any help would be nice. :) - > (logs compressed because of the 40kb limit!) - > - > glxinfo says direct rendering is disabled. - - (II) I810(0): [dri] Unable to allocate backbuffer memory. Disabling DRI. - (II) I810(0): [drm] removed 1 reserved context for kernel - (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xd08d4000 at 0x4 - - try making the 16384 video ram to 32768 or decrease your screen size.. - start maybe at 1024x768... Tried that already. No change. Get the same messages. Tried at 640x480 too. Regards Deepak --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problem with latest trunk and i810?
> > But DIR doesn't seem to work with my i810 chipset. I'm attaching my > 'dmesg' and 'XFree86.0.log'. Any help would be nice. :) > (logs compressed because of the 40kb limit!) > > glxinfo says direct rendering is disabled. (II) I810(0): [dri] Unable to allocate backbuffer memory. Disabling DRI. (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xd08d4000 at 0x4 try making the 16384 video ram to 32768 or decrease your screen size.. start maybe at 1024x768... Dave. > > > Thanks -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Problem with latest trunk and i810?
Hi, I use RedHat 9 with a custom compiled 2.4.21-rc4 and the latest DRI (checked out two hours back :). But DIR doesn't seem to work with my i810 chipset. I'm attaching my 'dmesg' and 'XFree86.0.log'. Any help would be nice. :) (logs compressed because of the 40kb limit!) glxinfo says direct rendering is disabled. These are the relevant portions from my XF86Config file. -- Section "Module" Load "dbe" Load "extmod" Load "fbdevhw" Load "glx" Load "record" Load "freetype" Load "type1" Load "dri" EndSection VideoRam16384 EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor"Monitor0" DefaultDepth 16 SubSection "Display" Depth 16 Modes"1280x1024" "1024x768" "800x600" "640x480" EndSubSection EndSection Section "DRI" Group0 Mode 0666 EndSection --- Thanks dmesg.gz Description: GNU Zip compressed data XFree86.0.log.gz Description: GNU Zip compressed data
[Dri-devel] Problem with latest trunk and i810?
Hi, I use RedHat 9 with a custom compiled 2.4.21-rc4 and the latest DRI (checked out two hours back :). But DIR doesn't seem to work with my i810 chipset. I'm attaching my 'dmesg' and 'XFree86.0.log'. Any help would be nice. :) glxinfo says direct rendering is disabled. These are the relevant portions from my XF86Config file. -- Section "Module" Load "dbe" Load "extmod" Load "fbdevhw" Load "glx" Load "record" Load "freetype" Load "type1" Load "dri" EndSection VideoRam16384 EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor"Monitor0" DefaultDepth 16 SubSection "Display" Depth 16 Modes"1280x1024" "1024x768" "800x600" "640x480" EndSubSection EndSection Section "DRI" Group0 Mode 0666 EndSection --- Thanks Deepak Linux version 2.4.21-rc4 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 Wed May 28 08:59:53 IST 2003 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fef (usable) BIOS-e820: 0fef - 0fef3000 (ACPI NVS) BIOS-e820: 0fef3000 - 0ff0 (ACPI data) BIOS-e820: ffb0 - 0001 (reserved) 254MB LOWMEM available. On node 0 totalpages: 65264 zone(0): 4096 pages. zone(1): 61168 pages. zone(2): 0 pages. Kernel command line: ro root=/dev/hda1 vga=ask Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! Initializing CPU#0 Detected 733.378 MHz processor. Console: colour VGA+ 132x60 Calibrating delay loop... 1464.72 BogoMIPS Memory: 255288k/261056k available (1642k kernel code, 5380k reserved, 397k data, 268k init, 0k highmem) Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode cache hash table entries: 16384 (order: 5, 131072 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: Using local APIC timer interrupts. calibrating APIC timer ... . CPU clock speed is 733.3740 MHz. . host bus clock speed is 133.3406 MHz. cpu: 0, clocks: 1333406, slice: 666703 CPU0 mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: Using configuration type 1 PCI: Probing PCI hardware Transparent bridge - Intel Corp. 82801AA PCI Bridge PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0 PCI: Found IRQ 11 for device 00:1f.3 PCI: Sharing IRQ 11 with 00:1f.5 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket IA-32 Microcode Update Driver: v1.11 <[EMAIL PROTECTED]> Starting kswapd VFS: Diskquotas version dquot_6.4.0 initialized Journalled Block Device driver loaded Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10e i810_rng: RNG not detected FDC 0 is a National Semiconductor PC87306 loop: loaded (max 8 devices) 8139too Fast Ethernet driver 0.9.26 eth0: RealTek RTL8139 Fast Ethernet at 0xd080d000, 00:c0:26:2f:0e:7d, IRQ 11 eth0: Identified 8139 chip type 'RTL-8139C' Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 202M agpgart: Detected an Intel i810 E Chipset. agpgart: AGP aperture is 64M @ 0xd000 Uniform Multi-Platform E-IDE driver Revision: 7.00beta3-.2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH: IDE controller at PCI slot 00:1f.1 ICH: chipset revision 2 ICH: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio hda: QUANTUM FIREBALLlct20 20, ATA DISK drive blk: queue c0371480, I/O limit 4095Mb (mask 0x) hdc
[Dri-devel] Re: SPAM : DRI Devel ratio
> >> Is this a good idia filter out all messages with html??? > >> > > > >only if you think people who send html email have nothing usefull to > >say. I'll ask a related question, is it good to filter out messages with > >foriegn charsets, like, say, koi8-r? > > No, it is actually a bad idea. A very bad idea. A while back, I > blocked Japanese encodings because a large portion of spam I > received was in Japanese encoding (sp?). I was being sarcastic, his message was encoded with koi8-r, which, along with being html, is one of the indescriminate reasons people block email (and get a good number of false positives) -- Russ Dill <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Fixes for GLX_SGI_video_sync
On Wed, 28 May 2003, Dieter Nützel wrote: > Am Dienstag, 13. Mai 2003 18:07 schrieb Leif Delgass: > > Attached are two patches: the first fixes problems with GLX_SGI_video_sync > > in the drivers and common vblank code and adds a common driGetMSC32() > > function in vblank.c. The second patch adds a '-sync' option to glxgears > > that will use the extension to sync to the refresh. > > > > Here are more details on the first patch: > > > > - Added a generic driGetMSC32() to vblank.c, which gets the current MSC by > > calling drmWaitForVBlank() with a relative wait of 0 (i.e., don't wait, > > just return the current MSC value). I should point out that since the > > vblank counter in the kernel is an unsigned int rather than an unsigned > > long, this will return a 32-bit value (then cast to an int64_t) even for > > 64-bit platforms (not sure if this is true for all platforms, but I > > checked it on Alpha and Sparc64 on the compile farm and it's 32-bit). > > > > - The radeon and r200 drivers' implementations of GetMSC was using the > > wrong counter (frame age instead of vblank counter), and mga was doing a > > wait for "absolute 0" rather than a relative wait for 0. I changed all > > the drivers to use the new generic implementation. One possible problem > > of using the counter for both the SGI/OML extensions is that the OML > > version wants the counter incremented for each field with an interlaced > > mode, and the SGI version does not. > > > > - I added support to r128 for GLX_SGI_swap_control, GLX_SGI_video_sync, > > and GLX_MESA_swap_control. GLX_SGI_video_sync can be exported by any > > driver using the common vblank code by installing callbacks to the two > > generic functions (driWaitMSC32 and driGetMSC32) in the DriverAPI struct. > > > > - Since some of the drivers already had C99 designated initializers for > > some of the new DriverAPI members, I changed those drivers to use them for > > initializing all the members. gcc supports this as an extension to C89, > > but I'm not sure if this will be an issue when merging into the XFree86 > > tree. > > > > - I fixed a couple of problems with the driWaitForMSC32() implementation, > > some of which cropped up when it's used for the SGI extension instead of > > the OML extension. First, I made the local vars unsigned ints and added > > explicit casts on the paramters passed as int64_t to unsigned int, in > > order to match up with the unsigned int sequence returned from the kernel > > and make it more clear (to me at least) what's going on. Second, I made > > the function behave as expected for SGI_sync_control when target_msc == 0 > > (which is what is passed in from glxcmds.c for the SGI extension), i.e. > > don't wait for the target, just proceed to the test against the divisor > > and remainder. This should be fine for the OML version if zero is passed > > as the target, as it works as if the target was missed (and you're pretty > > much gauranteed to always miss 0 for a 64-bit counter which is supposed to > > never roll over). The last fix affects both extensions: the calculation > > of the next target MSC (from the divisor/remainder) needed a tweak: > > MSC - (MSC % divisor) + remainder gives you the refresh closest to the > > current one, but it can be _after_ the current one, so we only need to add > > divisor if that value is less than or equal to the current MSC. > > > > > > Anyone have comments and/or suggestions? Obviously, there are still > > 32-/64-bit issues to work out. > > What about hits stuff? > > -Dieter I committed this (minus the gears patch), so GLX_SGI_video_sync should be working for r200, radeon (r100), r128 and mga. The 32-/64-bit question is still an open one, though. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Fixes for GLX_SGI_video_sync
Am Dienstag, 13. Mai 2003 18:07 schrieb Leif Delgass: > Attached are two patches: the first fixes problems with GLX_SGI_video_sync > in the drivers and common vblank code and adds a common driGetMSC32() > function in vblank.c. The second patch adds a '-sync' option to glxgears > that will use the extension to sync to the refresh. > > Here are more details on the first patch: > > - Added a generic driGetMSC32() to vblank.c, which gets the current MSC by > calling drmWaitForVBlank() with a relative wait of 0 (i.e., don't wait, > just return the current MSC value). I should point out that since the > vblank counter in the kernel is an unsigned int rather than an unsigned > long, this will return a 32-bit value (then cast to an int64_t) even for > 64-bit platforms (not sure if this is true for all platforms, but I > checked it on Alpha and Sparc64 on the compile farm and it's 32-bit). > > - The radeon and r200 drivers' implementations of GetMSC was using the > wrong counter (frame age instead of vblank counter), and mga was doing a > wait for "absolute 0" rather than a relative wait for 0. I changed all > the drivers to use the new generic implementation. One possible problem > of using the counter for both the SGI/OML extensions is that the OML > version wants the counter incremented for each field with an interlaced > mode, and the SGI version does not. > > - I added support to r128 for GLX_SGI_swap_control, GLX_SGI_video_sync, > and GLX_MESA_swap_control. GLX_SGI_video_sync can be exported by any > driver using the common vblank code by installing callbacks to the two > generic functions (driWaitMSC32 and driGetMSC32) in the DriverAPI struct. > > - Since some of the drivers already had C99 designated initializers for > some of the new DriverAPI members, I changed those drivers to use them for > initializing all the members. gcc supports this as an extension to C89, > but I'm not sure if this will be an issue when merging into the XFree86 > tree. > > - I fixed a couple of problems with the driWaitForMSC32() implementation, > some of which cropped up when it's used for the SGI extension instead of > the OML extension. First, I made the local vars unsigned ints and added > explicit casts on the paramters passed as int64_t to unsigned int, in > order to match up with the unsigned int sequence returned from the kernel > and make it more clear (to me at least) what's going on. Second, I made > the function behave as expected for SGI_sync_control when target_msc == 0 > (which is what is passed in from glxcmds.c for the SGI extension), i.e. > don't wait for the target, just proceed to the test against the divisor > and remainder. This should be fine for the OML version if zero is passed > as the target, as it works as if the target was missed (and you're pretty > much gauranteed to always miss 0 for a 64-bit counter which is supposed to > never roll over). The last fix affects both extensions: the calculation > of the next target MSC (from the divisor/remainder) needed a tweak: > MSC - (MSC % divisor) + remainder gives you the refresh closest to the > current one, but it can be _after_ the current one, so we only need to add > divisor if that value is less than or equal to the current MSC. > > > Anyone have comments and/or suggestions? Obviously, there are still > 32-/64-bit issues to work out. What about hits stuff? -Dieter --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] What happend to "bufferSize.diff"?
I'm running this stuff for some weeks.
-Dieter
Index: xf86glx.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/mesa/src/X/xf86glx.c,v
retrieving revision 1.20
diff -u -r1.20 xf86glx.c
--- xf86glx.c 7 May 2003 17:47:59 - 1.20
+++ xf86glx.c 7 May 2003 22:27:30 -
@@ -135,10 +135,9 @@
/*
* In the case the driver defines no GLX visuals we'll use these.
- * One thing is funny here: the bufferSize field doesn't always include
- * the alpha bits. That is, bufferSize may be 24 when we have 8 bits
- * of red, green, blue and alpha. If set set bufferSize to 32 we may
- * foul-up the visual matching code below (search for bufferSize).
+ * Note that for TrueColor and DirectColor visuals, bufferSize is the
+ * sum of redSize, greenSize, blueSize and alphaSize, which may be larger
+ * than the nplanes/rootDepth of the server's X11 visuals
*/
#define NUM_FALLBACK_CONFIGS 5
static __GLXvisualConfig FallbackConfigs[NUM_FALLBACK_CONFIGS] = {
@@ -405,7 +404,14 @@
glXVisualPtr[j].greenMask = pVisual[i].greenMask;
glXVisualPtr[j].blueMask = pVisual[i].blueMask;
glXVisualPtr[j].alphaMask = glXVisualPtr[j].alphaMask;
- glXVisualPtr[j].bufferSize = rootDepth;
+ if (is_rgb) {
+ glXVisualPtr[j].bufferSize = glXVisualPtr[j].redSize +
+ glXVisualPtr[j].greenSize +
+ glXVisualPtr[j].blueSize +
+ glXVisualPtr[j].alphaSize;
+ } else {
+ glXVisualPtr[j].bufferSize = rootDepth;
+ }
}
/* Save the device-dependent private for this visual */
@@ -505,7 +511,7 @@
/* Find a visual that matches the GLX visual's class and size */
for (j = 0; j < pScreen->numVisuals; j++, pVis++) {
if (pVis->class == pGLXVis->class &&
- pVis->nplanes == pGLXVis->bufferSize) {
+ pVis->nplanes == (pGLXVis->bufferSize - pGLXVis->alphaSize)) {
/* Fixup the masks */
pGLXVis->redMask = pVis->redMask;
@@ -545,7 +551,7 @@
for (j = 0; j < pScreen->numVisuals; j++, pVis++) {
if (pVis->class == pGLXVis->class &&
- pVis->nplanes == pGLXVis->bufferSize &&
+ pVis->nplanes == (pGLXVis->bufferSize - pGLXVis->alphaSize) &&
!used[j]) {
if (pVis->redMask == pGLXVis->redMask &&
Re: [Dri-devel] [trunk] CVS compilation errors (DRM_WRITEMEMORYBARRIER)
Am Mittwoch, 28. Mai 2003 04:24 schrieb José Fonseca: > Sorry about that. I merged everything manually using a visual diff util > to prevent that this happened, and compiled everything after and > corrected the errors, but still failed. Thanks! Dieter --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [trunk] CVS compilation errors (DRM_WRITEMEMORYBARRIER)
Don't worry about it, shit happens. ;) I fixed a couple of things that I came across, and I'm doing a quick onceover through CVS web to double-check. Great work with the documentation, btw. One minor issue I had: Can we keep the emacs mode magic for the drm files: -*- linux-c -*- This sets up the indentation and style in emacs if you have the mode defined (as described in the kernel docs). It needs to be on the first line of the file. Would it mess up doxygen to add a comment above the header?, e.g.: /* -*- linux-c -*- */ /** * \file ... --Leif On Wed, 28 May 2003, [iso-8859-15] José Fonseca wrote: > Sorry about that. I merged everything manually using a visual diff util > to prevent that this happened, and compiled everything after and > corrected the errors, but still failed. > > José Fonseca > > On Tue, May 27, 2003 at 08:46:04PM -0500, Leif Delgass wrote: > > Looks like the change to drm_os_linux.h that removed the argument from the > > DRM_*MEMORYBARRIER() macros was reverted with the documentation merge. I > > just checked in a fix. > > > > --Leif > > > > On Wed, 28 May 2003, Dieter [iso-8859-15] Nützel wrote: > > > > > Linux 2.4.21-rc2-jam1 > > > > > > r128_state.c:81: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:96: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:122: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:138: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:157: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:172: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:199: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:223: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:398: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:419: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:440: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:462: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:510: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:524: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:552: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:565: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:610: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:625: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:673: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:685: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:768: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:828: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:882: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:955: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:979: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:1073: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:1097: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:1144: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:1206: macro `DRM_WRITEMEMORYBARRIER' used without args > > > r128_state.c:1234: macro `DRM_WRITEMEMORYBARRIER' used without args > > > make[12]: *** [r128_state.o] Error 1 > > > > > > radeon_cp.c:728: macro `DRM_MEMORYBARRIER' used without args > > > radeon_cp.c:735: macro `DRM_MEMORYBARRIER' used without args > > > radeon_cp.c:753: macro `DRM_MEMORYBARRIER' used without args > > > radeon_cp.c:760: macro `DRM_MEMORYBARRIER' used without args > > > make[12]: *** [radeon_cp.o] Error 1 > > > > > > etc. > > > > > > Thanks, > > > Dieter > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: ObjectStore. > > > If flattening out C++ or Java code to make your application fit in a > > > relational database is painful, don't do it! Check out ObjectStore. > > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > > ___ > > > Dri-devel mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > > -- > > Leif Delgass > > http://www.retinalburn.net > > > > > > > > --- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your application fit in a > > relational database is painful, don't do it! Check out ObjectStore. > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net -
Re: [Dri-devel] [trunk] CVS compilation errors (DRM_WRITEMEMORYBARRIER)
Sorry about that. I merged everything manually using a visual diff util to prevent that this happened, and compiled everything after and corrected the errors, but still failed. José Fonseca On Tue, May 27, 2003 at 08:46:04PM -0500, Leif Delgass wrote: > Looks like the change to drm_os_linux.h that removed the argument from the > DRM_*MEMORYBARRIER() macros was reverted with the documentation merge. I > just checked in a fix. > > --Leif > > On Wed, 28 May 2003, Dieter [iso-8859-15] Nützel wrote: > > > Linux 2.4.21-rc2-jam1 > > > > r128_state.c:81: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:96: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:122: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:138: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:157: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:172: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:199: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:223: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:398: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:419: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:440: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:462: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:510: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:524: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:552: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:565: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:610: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:625: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:673: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:685: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:768: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:828: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:882: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:955: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:979: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:1073: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:1097: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:1144: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:1206: macro `DRM_WRITEMEMORYBARRIER' used without args > > r128_state.c:1234: macro `DRM_WRITEMEMORYBARRIER' used without args > > make[12]: *** [r128_state.o] Error 1 > > > > radeon_cp.c:728: macro `DRM_MEMORYBARRIER' used without args > > radeon_cp.c:735: macro `DRM_MEMORYBARRIER' used without args > > radeon_cp.c:753: macro `DRM_MEMORYBARRIER' used without args > > radeon_cp.c:760: macro `DRM_MEMORYBARRIER' used without args > > make[12]: *** [radeon_cp.o] Error 1 > > > > etc. > > > > Thanks, > > Dieter > > > > > > > > --- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your application fit in a > > relational database is painful, don't do it! Check out ObjectStore. > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > -- > Leif Delgass > http://www.retinalburn.net > > > > --- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [trunk] CVS compilation errors (DRM_WRITEMEMORYBARRIER)
Looks like the change to drm_os_linux.h that removed the argument from the DRM_*MEMORYBARRIER() macros was reverted with the documentation merge. I just checked in a fix. --Leif On Wed, 28 May 2003, Dieter [iso-8859-15] Nützel wrote: > Linux 2.4.21-rc2-jam1 > > r128_state.c:81: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:96: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:122: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:138: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:157: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:172: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:199: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:223: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:398: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:419: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:440: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:462: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:510: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:524: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:552: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:565: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:610: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:625: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:673: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:685: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:768: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:828: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:882: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:955: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:979: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:1073: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:1097: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:1144: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:1206: macro `DRM_WRITEMEMORYBARRIER' used without args > r128_state.c:1234: macro `DRM_WRITEMEMORYBARRIER' used without args > make[12]: *** [r128_state.o] Error 1 > > radeon_cp.c:728: macro `DRM_MEMORYBARRIER' used without args > radeon_cp.c:735: macro `DRM_MEMORYBARRIER' used without args > radeon_cp.c:753: macro `DRM_MEMORYBARRIER' used without args > radeon_cp.c:760: macro `DRM_MEMORYBARRIER' used without args > make[12]: *** [radeon_cp.o] Error 1 > > etc. > > Thanks, > Dieter > > > > --- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [trunk] CVS compilation errors (DRM_WRITEMEMORYBARRIER)
Linux 2.4.21-rc2-jam1 r128_state.c:81: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:96: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:122: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:138: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:157: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:172: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:199: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:223: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:398: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:419: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:440: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:462: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:510: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:524: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:552: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:565: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:610: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:625: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:673: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:685: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:768: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:828: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:882: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:955: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:979: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1073: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1097: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1144: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1206: macro `DRM_WRITEMEMORYBARRIER' used without args r128_state.c:1234: macro `DRM_WRITEMEMORYBARRIER' used without args make[12]: *** [r128_state.o] Error 1 radeon_cp.c:728: macro `DRM_MEMORYBARRIER' used without args radeon_cp.c:735: macro `DRM_MEMORYBARRIER' used without args radeon_cp.c:753: macro `DRM_MEMORYBARRIER' used without args radeon_cp.c:760: macro `DRM_MEMORYBARRIER' used without args make[12]: *** [radeon_cp.o] Error 1 etc. Thanks, Dieter --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 西安房地产信息网行业热门话题
Title: 西安房地产信息网 西安房地产信息网 www.800j.cc 非典时期买楼该注重什么？ 谁来评述“世家星城” . 我要发言 进入论坛 --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 page flipping patch..
On Mon, 2003-05-26 at 15:55, Dave Airlie wrote: > > > > Two problems, basically: > > > > * software rendering, as you've found out > > * there's only one offscreen area > > > > This would probably need to be addressed at a higher level. > > so is there any plans to tackle these from a DRI or XFree86 level? I don't know if anyone is working on this currently. > after looking there is no way the driver can do much for it apart from > what I've done, Just what I said. :) XAA might be the right level. > it does come down to any render to the actual screen needs > to hit both front and back buffers or is there another way.. i can't > imagine syncing buffer swaps between GL and X11 would really help you'd > have to refresh all the 2d clients still, SGI appeared to have done this > from reading some of the stuff on the DRI website, but details are very > lacking... That might be the only way to get correct interaction between GL and X11 drawing. -- 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: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_MESA_ycbcr_texture possible with the old radeon?
On Tue, 27 May 2003, Ian Romanick wrote: > Leif Delgass wrote: > > On Fri, 23 May 2003, Ian Romanick wrote: > > > > > >>Andreas Stenglein wrote: > >> > >>>In radeon_reg.h there are some new txformats: > >>>RADEON_TXFORMAT_VYUY422 > >>>RADEON_TXFORMAT_YVYU422 > >>> > >>>Would it be possible to make the > >>>MESA_ycbcr_texture extension available for the > >>>original (old) radeon or are there some issues > >>>which prevent this? > >>> > >>>Are there other extensions which could be > >>>"backported" from the R200-driver? > >>>Maybe GL_NV_texture_rectangle, GL_ARB_texture_cube_map ? > >> > >>Now that MESA_ycbcr_texture is in the r100 driver, did you want to > >>tackle NV_texture rectangle? > > > > > > The MESA_ycbcr_texture patch hadn't been committed to CVS yet, but since > > I've tested them, I committed the r128 and R100 portions of the patch. I > > didn't commit the i810 and mga patches, since I'm not able to test those > > myself. > > Sorry for falling asleep at the wheel. I was waiting to make sure we > had the DRM version requirement issue for R100 resolved first. I guess > we decided that the version didn't matter? Right. Since the new radeon Mesa driver (the first to export the extension) always uses an 8-bit format for blits, it will work with any drm version. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bug encountered
Ian Romanick wrote: morzillo wrote: Hi all! i'm try to play game based on GL with a R200(Radeon 8500 DDR, original) and DRI based on the XFree 4.3.5 and MesaGL ,and this is the result in the console (the game's run perfectly but this one, report these bug)... Loading required GL library /usr/lib/libGL.so.1 Got available fonts list! Mesa implementation error: r200SwapBuffers: drawable has no context! Please report to the DRI bug database at dri.sourceforge.net Mesa implementation error: r200SwapBuffers: drawable has no context! Sorry my poor english I use BABEL for traduction :-) (Spanish) Ola! :) Is this bug in DRI CVS or XFree86 CVS? If it is from DRI CVS, then it is a known problem. I am working on a fix. It should be in CVS soon. Actually, the fix was committed on May 21st. What driver are you using? --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture wrap modes
Leif Delgass wrote: On Thu, 15 May 2003, Ian Romanick wrote: Ian Romanick wrote: Ian Romanick wrote: Log message: Fixed the various supported texture wrap modes. Added a fallback for unsupportable combinations of S/T wrap modes. All of the exported modes on Radeon, R200, and MGA should be correct now. I'm going to try and look at i830 this week. Could somebody please see about fixing up Rage128 and 3dfx? I see that both of those have some of the same problems that the "fixed" drivers used to have. I took care of i830 & i810. I don't have access to any i810 or i815 hardware, so I haven't tested that patch yet. Could somebody with that hardware please test this patch? I spoke to someone at Intel. None of their hardware implements GL_CLAMP. All of their drivers implement GL_CLAMP as GL_CLAMP_TO_EDGE, which is what I have done. Since that's a pretty common case, it's a bad one to make a sw fallback. The good news is that neither of these drivers have the mode mixing quirks that require the fallback cases. I was just updating the extension lists on the driver status page on the DRI website and noticed a couple of extensions being exported from the i810 driver that don't look like they should be there: EXT_stencil_wrap (no hardware stencil buffer for i810), and SGIS_texture_border_clamp (doesn't seem to handle border clamp, and ARB_texture_border_clamp isn't exported). Should these be removed? The stencil related extensions should stay. The i810 driver does export visuals with a stencil buffer, but it uses a software fallback for that path. Since the Mesa software rasterizer supports EXT_stencil_wrap, the i810 driver should export it. :) SGIS_texture_border_clamp was a mistake of mine. I took out the ARB version, but forgot to take out the SGIS version. This reminds me of something I've wanted to do for Mesa, but have had on the back burner for months. It would be nice to have extension aliasing. That is, if a driver enables SGIS_texture_border clamp, ARB_texture_border_clamp gets automatically enables (and vice versa). It's not a very big deal (which I why I haven't done it yet!), but it would have helped prevent this bug. :) --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_MESA_ycbcr_texture possible with the old radeon?
Leif Delgass wrote: On Fri, 23 May 2003, Ian Romanick wrote: Andreas Stenglein wrote: In radeon_reg.h there are some new txformats: RADEON_TXFORMAT_VYUY422 RADEON_TXFORMAT_YVYU422 Would it be possible to make the MESA_ycbcr_texture extension available for the original (old) radeon or are there some issues which prevent this? Are there other extensions which could be "backported" from the R200-driver? Maybe GL_NV_texture_rectangle, GL_ARB_texture_cube_map ? Now that MESA_ycbcr_texture is in the r100 driver, did you want to tackle NV_texture rectangle? The MESA_ycbcr_texture patch hadn't been committed to CVS yet, but since I've tested them, I committed the r128 and R100 portions of the patch. I didn't commit the i810 and mga patches, since I'm not able to test those myself. Sorry for falling asleep at the wheel. I was waiting to make sure we had the DRM version requirement issue for R100 resolved first. I guess we decided that the version didn't matter? I'll go ahead and commit the MGA and i810 patches. FYI, for r128 I changed the format defines from _YUV422 and _YUV422_2 to the more descriptive _VYUY422 and _YVYU422, which matches the names used in the R200, R100, and mach64 drivers. That's a good idea. --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bug encountered
morzillo wrote: Hi all! i'm try to play game based on GL with a R200(Radeon 8500 DDR, original) and DRI based on the XFree 4.3.5 and MesaGL ,and this is the result in the console (the game's run perfectly but this one, report these bug)... Loading required GL library /usr/lib/libGL.so.1 Got available fonts list! Mesa implementation error: r200SwapBuffers: drawable has no context! Please report to the DRI bug database at dri.sourceforge.net Mesa implementation error: r200SwapBuffers: drawable has no context! Sorry my poor english I use BABEL for traduction :-) (Spanish) Ola! :) Is this bug in DRI CVS or XFree86 CVS? If it is from DRI CVS, then it is a known problem. I am working on a fix. It should be in CVS soon. --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] CVS policy questions
Hi, I have a working version of xdriinfo (the tool that dumps the drivers' configuration information) that I'd like to commit somewhere in the config-0-0-1-branch. I suppose xc/programs/... would be the right place. It's just that this would be the only thing in xc/programs besides the XServer (all the other dirs are empty). Then I have a python module for parsing the drivers' XML documents and configuration files and a tool that generates a complete configuration file from the driver's information, also written in python. Does that belong into DRI CVS or should it be maintained somewhere else? Best regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bug encountered
Hi all! i'm try to play game based on GL with a R200(Radeon 8500 DDR, original) and DRI based on the XFree 4.3.5 and MesaGL ,and this is the result in the console (the game's run perfectly but this one, report these bug)... Loading required GL library /usr/lib/libGL.so.1 Got available fonts list! Mesa implementation error: r200SwapBuffers: drawable has no context! Please report to the DRI bug database at dri.sourceforge.net Mesa implementation error: r200SwapBuffers: drawable has no context! Sorry my poor english I use BABEL for traduction :-) (Spanish) Thanks for contrib Linux :) MoRZiLLo... --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Intel E7505...
On Tue, May 27, 2003 at 08:43:03AM -0400, Adam K Kirchhoff wrote: > Can anyone tell me if the agp chipset on the Intel E7505 is supported > under Linux? Are there any known issues with the DRI on this chipset? 2.5 has explicit support for E7x05, 2.4 still doesn't iirc. Dave --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Intel E7505...
Adam K Kirchhoff wrote: Can anyone tell me if the agp chipset on the Intel E7505 is supported under Linux? Are there any known issues with the DRI on this chipset? AFAIK, it is supported by recent kernels. You just need to use 'agp_try_unsupported=1' when you insmod / modprobe agpgart.o. --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
