Re: [Dri-devel] DRI savage driver status
for 3D, what version of mesa are you using? are you using the right libGL? For 2D look in xc/programs/Xserver/hw/xfree86/drivers/savage Try the 2D driver with 3D disabled and see if you still get corruption. it may be that the 3D side is stomping on the something from the 2D side. Alex --- Rafael Maximo [EMAIL PROTECTED] wrote: Hi, Some of you already know that i'm trying to work on the savage driver, i'm working on the 3D driver (/lib/GL/mesa/src/drv) and now it is compiling and i'll test it but i got some other problems. After compiling everything (2D, 3D, kernel modules, etc.) my screen on xfree 4.3.0 is a little corrupted (http://max.brz.net/screen.png), on XFree86 log it says that direct rendering is enable (http://max.brz.net/XFree86_log.txt) but i got something different from glxinfo (http://max.brz.net/glxinfo.txt). First i need to fix 2D driver but where should i look at first, is there any specific function that i should study? And why direct rendering is not enable? Is it a driver problem or a config problem? Here is the output of dmesg http://max.brz.net/dmesg.txt (agpgart and savage module were loaded with modprobe) Please send me any information that could help me make the savage driver works. bye. Rafael Máximo __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI savage driver status
you might compare it to Tim's old 2D driver (shipped with 4.3.0) and see what's changed...assuming his driver works for you in 2D. Alex --- Rafael Maximo [EMAIL PROTECTED] wrote: Hi, I decided to focus on 2D problem first but i don't know how I can debug the 2D driver and found where is the problem. I would appreciate any information or docs about debugging this kind of problem. I'm using the 2D driver on savage_1-0-0_branch and i didn't change anything except Imakefile because it is pointing to wrong directorys. Thanks. Rafael Máximo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Fix for radeon_drv.o ( Asus L5800C )
Keith I think this fixes a problem with the LCD not working on Asus
notebooks. I seem to recall this problem from a while back on some of
the xfree MLs. I don't know for sure however.
Alex
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Bellegueulle Damien wrote:
--- radeon_driver.c.orig2003-09-21 12:39:25.952390342 +0200
+++ radeon_driver.c2003-09-21 12:27:08.0 +0200
@@ -1058,7 +1058,7 @@
info-PanelPwrDly = RADEON_BIOS16(tmp+44);
if (info-PanelPwrDly 2000 || info-PanelPwrDly 0)
info-PanelPwrDly = 2000;
-for (i = 0; i 20; i++) {
+for (i = 0; i 21; i++) {
tmp0 = RADEON_BIOS16(tmp+64+i*2);
if (tmp0 == 0) break;
if ((RADEON_BIOS16(tmp0) == info-PanelXRes)
Bellegueulle,
Can you tell us a little more about what problem this fixes and why
you
think it's a good fix? There's not much information to go on
here...
Have you tried a current CVS version of the dri drivers? This looks
like a
patch against a quite different version (although the '20' is still
there).
Please note that our cvs host has changed to freedesktop.org.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon/r200 texture engine question
I'm thinking about implementing a textured video option on radeon for mergedfb (or non-mergedfb too for that matter). It would be useful since video windows could span heads in mergedfb mode and you could also have multiple Xv windows at the same time rather than just one with the overlay unit. My questions are as follows: 1. looking at the mga textured video code, it disables the DRI when it is in use. is there any reason for this? is it possible to use the texture engine for Xv and DRI at the smae time. It seems like it should. I think directfb does this for 3D and alpha blended windows already. When implemeting this on radeon, would I have to use the CP to program the texture registers or could I use MMIO? I've been toying with the idea of converting the existing Xv code to CP anyway, however if you disabled the DRI and wanted to use the overlay or the texture engine you'd need an MMIO code path at least. 2. I don't really understand the 3D driver. Could some one explain to me which registers I would need to manipulate to use the texture engine for Xv? or at least how it should work for 3D so I can attempt it for Xv? I assume they are defined in radeon_reg.h? They seem to be... 3. Is there a limit on the number of textures on radeon? How many Xv ports should I allow for the texture engine? I think mga allows 32, although that might have been an arbitrary decision. 4. Can the overlay and the texture engine Xv adapters co-exist? for instance when I register the Xv adapters can I register the texture Xv adapter and the overlay Xv adapter? that way I could choose to use one or the other by specifying a different Xv port in Xv apps. I don't see why I couldn't, I'm just wondering if there are any issues with doing that. 5. r200 vs r100 - how different are the texture engines? 6. Anything I'm missing? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI savage driver status
I believe there was some discussion of this on the directfb mailing list. I think the savage chips require a tile based framebuffer for acceleration, but this is incompatible with things that assume a linear based framebuffer. Alex --- Felix K�hling [EMAIL PROTECTED] wrote: I found at least a workaround for the problem. Set Option DisableTile on in the Device section of XF86Config-4. I think this has something to do with the frame buffer layout. Accellerated stuff seems to get it right. But non-accelerated stuff accesses the frame buffer in the wrong way. Try Option Accel off and you'll see what I mean. Basically the screen is squeezed vertically to half the height. I havn't found a real fix yet. Does someone with more 2D experience have a pointer? Felix On Fri, 26 Sep 2003 07:36:02 -0300 Rafael Maximo [EMAIL PROTECTED] wrote: [snip] I didn't commit any change to CVS yet, basicaly because all problems i got. For now the 2D driver need to be fixed (i didn't have time to look deep in this problem) and the code of the savage driver from S3 is a little bit confusing and sometimes very different from the other drivers and everything need to be fixed (2D, 3D and probably the kernel module). Besides all these problems, i'm not a very experienced programer witch make things e little harder for me. Any help will be very welcome. bye. Rafael M�ximo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, K�hling (_\�// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm vs. drm-4.0
The DRM changed between xfree86 4.0.x and 4.1.0 in an incompatible way. some kernel trees retained both DRMs so that you could build the appropriate DRM depending on what version of xfree86 you were using. Alex --- John Dennis [EMAIL PROTECTED] wrote: In the linux 2.4 kernel tree under drivers/char there is both a drm subdirectory and a drm-4.0 subdirectory. I've looked high and low for an explanation of drm vs. drm-4.0, I assume its a version difference, but I've come up dry. Can someone either explain to me what drm-4.0 is or send me a pointer to something that documents it. I'd like to know why one implementation is picked over the other, are there version dependencies, why it exists as parallel to drm and what its trying to fix. Thanks, John -- John Dennis [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9200se
you can either patch DRI cvs with the 9200se patch you tried or force the chipID to another radeon 9200. any of these chould work: 0x5963 0x5962 0x5961 0x5960 Also I believe Michel added the patch to CVS so it should show up in the snapshots soon. Alex --- maestro [EMAIL PROTECTED] wrote: hi all, my system configuration: P4 2,4Ghz fsb 800 HT super micro p4spa+ mainboard radeon 9200se graphics card running debian woody with kernel 2.4.21 XFree86 4.3.99-12 compiled from source recently i bought a radeon 9200se graphics card. it took me a very long time to get it work in X. its because the ati driver only knows about the 9200 but not the 9200se. the pci-chip-id is differen (9200 = 5963 / 9200se = 5964) i found a patch on the internet that makes the driver recognize that chip. (http://www.mail-archive.com/[EMAIL PROTECTED]/msg12830.html) i recompiled XFree86 and it worked perfectly. now i want dri support too. i downloaded the radeon package (radeon-20030926-linux.i386.tar.bz2) run install.sh and everything worked great but when i run startx i get the same message as when the card wasnt detected by the driver before. [quote /var/log/XF86log.0.log] ...snip (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (EE) No devices detected. [/quote] so my question is: does the radeon dri package support the 9200se and if not is it possible to apply the above patch to make it support it? secondly is it possible to get dri support right when building XFree86 using my existing and working driver? thanks for your help m --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon/r200 texture engine question
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2003-09-26 at 18:16, Alex Deucher wrote: 1. looking at the mga textured video code, it disables the DRI when it is in use. is there any reason for this? is it possible to use the texture engine for Xv and DRI at the smae time. It seems like it should. I agree. When implemeting this on radeon, would I have to use the CP to program the texture registers or could I use MMIO? Using the 3D engine without the CP is hard if not impossible. how do 2D, 3D, CP, etc fit together. I take it the CP is mainly a queue for 3D commands, but can also process register writes? I understand how the to issues commands for 2D to the CP, but how does 3D work? The DRI driver seems very foreign by comparison. having looked it over it guess the various functions queue up 3D commands which are then flushed to the 3D engine at some point. where do that commands get flushed? can I just use the texture commands or do I need to recreate the commands to create a quad first and then the texture? Could some one maybe sketch out the call order do to something like this in the DRI? Like: RADEONCreateQuad() RADEONCreateTexture() RADEONBindTexture() RADEONRenderObject() or something like that. so I can get an idea of what all needs to be done. Is there a reference that explains what each file in the 3D driver does and how they fit together? like: card_tex.c - texture functions used to allocate and render textures created in card_xxx.c card_span.c - does X on objects from card_yyy.c card_screen.c - does Y card_state.c - etc. I have a general idea based on the names, but I can't see exactly how they all fit together. if someone can better fill me in on this I'll write a intro to 3D engines and DRI code page for the DRI wiki. I've been toying with the idea of converting the existing Xv code to CP anyway, however if you disabled the DRI and wanted to use the overlay or the texture engine you'd need an MMIO code path at least. The register write macros could be changed (or new ones added) to use the CP transparently when appropriate. do you mean like psuedo-MMIO using the CP? or just other macros like the 2D accel code uses (OUTRING() and such). is it possible to use the 3D engine at all when the DRI is not enabled? 3. Is there a limit on the number of textures on radeon? How many Xv ports should I allow for the texture engine? I think mga allows 32, although that might have been an arbitrary decision. Yes, I don't think there's a limitation other than the amount of video RAM. 4. Can the overlay and the texture engine Xv adapters co-exist? I don't see why they couldn't. AFAIK other drivers offer both types of adaptors simultaneously. I hope others will fill in the questions I didn't feel competent enough to answer. As a bonus, once you've solved all the issues involved, adding some RENDER extension acceleration should be trivial. :) I played with that a little but never found the time to get it very far. And maybe windows with alpha channels one day ;) Do you have any code (however broken) I could look at? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon/r200 texture engine question
--- Ian Romanick [EMAIL PROTECTED] wrote: Alex Deucher wrote: I'm thinking about implementing a textured video option on radeon for mergedfb (or non-mergedfb too for that matter). It would be useful since video windows could span heads in mergedfb mode and you could also have multiple Xv windows at the same time rather than just one with the overlay unit. My questions are as follows: 1. looking at the mga textured video code, it disables the DRI when it is in use. is there any reason for this? Boy howdy is there ever! It is easy for the 2D driver and the 3D driver to work together because they don't share any state. Specifically, they don't share texture memory state, 3D hardware register state, or vertex engine state. As soon the 2D driver start using texture mapping hardware for Xv, all that state becomes shared. If you're going to go to the effort of making the server-side driver and the client-side (DRI) driver share all that state, you may as well go just a small bit further and get the client-side driver loaded server-side. :) If nothhing else, that would make maintainence easier. Ummm... ok... so by this you mean, linking the radeon_dri.o into radeon_drv.o so that I can call functions from the 3D driver in the 2D driver and hence share state? Sorry if I mis-understand... Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
just remove the '#include radeon_pci.h' line from those files. Also radeon_dri.c contains some references to AMD_SOMETHING that is undefined. if you comment out that statement all works fine. Alex --- Felix Kühling [EMAIL PROTECTED] wrote: On Fri, 26 Sep 2003 10:26:40 -0700 Alan Hourihane [EMAIL PROTECTED] wrote: CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: [EMAIL PROTECTED] 03/09/26 10:26:40 Log message: no longer need radeon_pci.h since the XFree86 merge Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_driver.c Removed files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_pci.h Revision ChangesPath 1.64 +1 -1 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c After a cvs update -d and make World I get errors during compilation. radeon_pci.h is still included by radeon_dri.c and radeon_probe.c. Time to revive the file? 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon/r200 texture engine question
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Sat, 2003-09-27 at 23:10, Alex Deucher wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: On Fri, 2003-09-26 at 18:16, Alex Deucher wrote: When implemeting this on radeon, would I have to use the CP to program the texture registers or could I use MMIO? Using the 3D engine without the CP is hard if not impossible. how do 2D, 3D, CP, etc fit together. I take it the CP is mainly a queue for 3D commands, but can also process register writes? It's basically a general command queue. OK. I understand how the to issues commands for 2D to the CP, but how does 3D work? Similarly, via special 3D command packets. Ok. this is starting to come together in my mind. I've also dug into the code a bit more. The DRI driver seems very foreign by comparison. having looked it over it guess the various functions queue up 3D commands which are then flushed to the 3D engine at some point. where do that commands get flushed? In the DRM. That's what I figured. can I just use the texture commands or do I need to recreate the commands to create a quad first and then the texture? The latter, there's no 'texture command' per se, textures are just part of the hardware state. OK. makes sense. I've been toying with the idea of converting the existing Xv code to CP anyway, however if you disabled the DRI and wanted to use the overlay or the texture engine you'd need an MMIO code path at least. The register write macros could be changed (or new ones added) to use the CP transparently when appropriate. do you mean like psuedo-MMIO using the CP? or just other macros like the 2D accel code uses (OUTRING() and such). Either. is it possible to use the 3D engine at all when the DRI is not enabled? AFAIK it's not possible to use the 3D engine without the CP. Apparently, it's possible to use the CP with MMIO though, but I haven't seen code or even documentation on how to do it. I'm going to start with just issuing commands to the CP like the 2D accel code does. I may dig into MMIO stuff later, but first I just want to get something working. As a bonus, once you've solved all the issues involved, adding some RENDER extension acceleration should be trivial. :) I played with that a little but never found the time to get it very far. Do you have any code (however broken) I could look at? Sure, http://penguinppc.org/~daenzer/DRI/radeon_render.c . It's for the R100 3D engine, and it doesn't render anything yet, or at least not anything like what it's supposed to. :\ I've briefly looked over the code. I've got a few questions. How does this take care of the state sharing issue (2D and 3D) that Ian brought up yesterday? the name would seem to indicate that your UploadCommon3DState() function handled that, but it looks more like it's just setting up state for your render accel functions. is there a reference anywhere for what the different 3D packets do? I suspect not. many of them I can guess at based on their names, but others are pretty unclear. I guess I'll just ask when I need help. SubsequentCPUToScreenTexture() looks like it sends the packets for creating a quad? what function should I look at in the DRI driver? there are several places where you have code that looks like this: BEGIN_RING( 8 ); OUT_RING_REG( RADEON_PP_TXFORMAT_0, RADEON_TXFORMAT_RGBA | RADEON_TXFORMAT_ALPHA_IN_MAP | RADEON_TXFORMAT_NON_POWER2 | RADEON_TXFORMAT_ALPHA_MASK_ENABLE ); OUT_RING_REG( RADEON_PP_TXOFFSET_0, offset ); OUT_RING_REG( RADEON_PP_TXPITCH_0, pitch - 32 ); OUT_RING_REG( RADEON_PP_TXSIZE_0, (width-1) | ((height-1) 16) ); ADVANCE_RING(); Why did you use 8 rather than 4? it seems to me you are only issuing 4 commands, or is the code just in an incomplete/testing state? Thanks for you help. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon/r200 texture engine question
Nevermind the 8/4 ring question, I figured that part out. one question though, how do you know whether to use OUT_REG_RING() or OUT_RING()? I take it OUT_REG_RING() is for register writes and I'm guessing OUT_RING() is for commands. I just want to verify. Thanks, Alex --- Michel D�nzer [EMAIL PROTECTED] wrote: As a bonus, once you've solved all the issues involved, adding some RENDER extension acceleration should be trivial. :) I played with that a little but never found the time to get it very far. Do you have any code (however broken) I could look at? Sure, http://penguinppc.org/~daenzer/DRI/radeon_render.c . It's for the R100 3D engine, and it doesn't render anything yet, or at least not anything like what it's supposed to. :\ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] s3virge (Was: config branch merge schedule)
unless someone beats me to it, I was planning on messing with the virge driver at some point going forward. I got a hold of the Duoview info from the virge databook, so I'm planning to add support for dualhead and probably mergedfb. after that I'll mess with the 3D driver. (does anyone know if there are databooks for the 3D stuff available anywhere? I heard that S3 released the virge databooks without an NDA. Also I seem to recall an SDK being available...) There are quite a few things on my plate right now (textured video for radeon, genericisizing mergedfb, etc.) though so I'm not sure when I'll get to it. plus I need to pick up an old virge mx first. Alex --- Jos� Fonseca [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2003 at 11:16:54AM +0100, Keith Whitwell wrote: Jos� Fonseca wrote: On Tue, Sep 30, 2003 at 12:24:53AM +0100, Jos� Fonseca wrote: PS: For general information, the HEAD failed to build somehere in the SiS driver. And the s3virge seems to have the missing-newline-at-eof problem somewhere. What is the status of the s3virge driver? If it's only half working and now not compiling, I think we should disable it. I wasn't quite clear on that - the s3virge only lives on its own branch (s3virge-0-0-1-branch) so there is nothing to disable. IIRC its state is that it's missing some GL functionality, and I don't think the security issue was even touted. See http://dri.sourceforge.net/snapshots/bleeding-edge/README.s3virge for more info. Actually, after more cerfull inspection, it appears that the build problem with the s3virge is that the branch is getting too far behind to correctly build with the X 4.3.0 sources... Have to look deeper though. It would be nice to keep the old drivers available. We should start doing 3D SDKs for each major XFree86 version, so that as the infrastucture (DRM, Mesa) gets _source-wise_ incompatible, we can still build the old drivers which ware _binary-wise_ compatible with recent X versions. I know XFree86 has a driver SDK already. Does anybody have an idea whether we could extend it for 3D? Jos� Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: branch 4 cle266 (Was: good news for savage users or not ???)
It might be better to import the 2D driver from xfree86 CVS since there have been some major changes and fixes since the original release. see bugzilla: http://bugs.xfree86.org/show_bug.cgi?id=525 Alex --- José Fonseca [EMAIL PROTECTED] wrote: OK. I've imported your tarball plus the 2D and DRM driver from VIA's original one. For anybody interested, it still requires some manual editing of some makefiles before it compiles but I wanted to commit what I have so far. So we teach the undergraduates this bit in twelve weeks, you've got two.. I'm sure they only want you to not get bored! ;-) Regards, José Fonseca __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] fixing pageflipping in mergedfb modes
I'm attempting to fix pageflipping in certain mergedfb modes. right now it only works in when crtc2 is right of crtc1. I suspect the problem has to do with the CRTC offsets that are set in RADEONDoAdjustFrame() for instance if I have crtc2 left of or above crtc1, I would need to adjust RADEON_CRTC_OFFSET by something like (crtc2_mode-CrtcHDisplay * crtc2_mode-CrtcVDisplay) right? and for clone mode, I'd have to adjust the offsets depending on the modes of each head. is my thinking right here? or does it work differently? Also, looking at radeon_dri.c, RADEONDRIFinishScreenInit() could we cap the 3D engine to 2048x2048 my adjusting the values of pRADEONDRI-width and pRADEONDRI-height? something like: if (pScrn-virtualX 2048) pRADEONDRI-width = 2048; else pRADEONDRI-width = pScrn-virtualX; if (pScrn-virtualY 2048) pRADEONDRI-width = 2048; else pRADEONDRI-width = pScrn-virtualY; Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Merging radeon mergedfb patch before 4.4.0
With my latest patch the just about all the outstanding bugs have been fixed. the only thing remaining is that pagflipping doesn't always work in some mergedfb configurations. I'm working on that one, but then again, pageflipping doesn't work for everyone anyway. The driver currently supports all major features you'd want in a dualheaded setup: 3D on both heads, Xv overlay moves from one crtc to the other depending on where the output is, and it provides a pseudo-xinerama extension for window placement and such. What are your thoughts on merging the radeon mergedfb patch into CVS? I agree that it would probably be a better idea to separate out the device independant code, but I'm not sure I'll have time to do that and test it before the 4.4 feature freeze (oct 15th). Also merging the driver now, as is, doesn't mean it can't be converted to the device independant code later on. I've emailed Kevin E. Martin as well to get his thoughts. Will there be another xfree86-DRI merge before the release? will Felix' config code make it in? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: fixing pageflipping in mergedfb modes
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Thu, 2003-10-02 at 18:41, Alex Deucher wrote: I'm attempting to fix pageflipping in certain mergedfb modes. right now it only works in when crtc2 is right of crtc1. I suspect the problem has to do with the CRTC offsets that are set in RADEONDoAdjustFrame() for instance if I have crtc2 left of or above crtc1, I would need to adjust RADEON_CRTC_OFFSET by something like (crtc2_mode-CrtcHDisplay * crtc2_mode-CrtcVDisplay) right? and for clone mode, I'd have to adjust the offsets depending on the modes of each head. is my thinking right here? or does it work differently? I wouldn't think anything like this should be necessary as long as the values passed to RADEONDoAdjustFrame() are virtual screen coordinates, but you may have become more competent than me in this area. :) I would have thought the same thing as well, but Xv required that I take into account the width of crtc2 when using the overlay on crtc1 in leftof mode. I'm seeing similar behavior when using pageflipping (the framebuffer is offset on crtc1) in leftof mode so that may require a similar fix. I'll report back when I mess with it a bit more. Also, looking at radeon_dri.c, RADEONDRIFinishScreenInit() could we cap the 3D engine to 2048x2048 my adjusting the values of pRADEONDRI-width and pRADEONDRI-height? something like: if (pScrn-virtualX 2048) pRADEONDRI-width = 2048; else pRADEONDRI-width = pScrn-virtualX; if (pScrn-virtualY 2048) pRADEONDRI-width = 2048; else pRADEONDRI-width = pScrn-virtualY; I doubt this would have a useful effect, if any (do the Radeon 3D drivers even use these fields?). As I have hinted repeatedly before, the only sane way to handle this for now is probably to disable the DRI if either virtual dimension exceeds 2048. Yeah, that's what I figured, I say the code and thought I would ask. I'll dif further this weekend. thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
FWIW, the 2D drivers from the trunk and the code drop from VIA are VERY different. I'm not sure where you are seeing the conflicts... just an FYI... --- Eric Anholt [EMAIL PROTECTED] wrote: Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] M10 support
xfree86 and DRI CVS have 2D support for m10 already. 3D is not possible as no one has sponsored development of an opensource driver and no one has the databooks for the r300 yet. So, if you want 3D, you'll have to use the ati binary driver. Alex --- Jason Dagit [EMAIL PROTECTED] wrote: Who is working on support for the M10? Anyone? I'm about to get one and I'm a little worried about using the ati drivers since they can crash the system on suspend/resume. This is a laptop system so I'm going to want suspend/resume and I don't want to be restarting X every time I resume. I could help with adding the support. I'm a decent programmer (although this is something I've never tried). But I thought I'd ask if anyone else was working on this yet. I would rather get the technical info from someone on the project then have to ask ati for it. I imagine the M10 support would be a specialization of the rv350 support. But I could be wrongI'm new to this and have always bought nvidia cards in the past. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] M10 support
--- Jason Dagit [EMAIL PROTECTED] wrote: Alex Deucher wrote (on Sat, 4 Oct 2003 at 08:49 -0700): xfree86 and DRI CVS have 2D support for m10 already. 3D is not possible as no one has sponsored development of an opensource driver and no one has the databooks for the r300 yet. So, if you want 3D, you'll have to use the ati binary driver. Are you sure about xfree86, I checked their website last night and they list support via the ati driver, which I took to mean the driver provided by ati. I checked the status page for dri and nothing is mentioned about the M10. Shouldn't that page be updated if you have 2d support now? the DRI and xfree86 recently synced up so, they are, right now, for most intents and purposes the same code base. Right now there is 2D support only for r3xx series cards. I haven't checked the web pages in a while. the ati driver is the name of the xfree86 driver for ati cards. it's not provided by ati although they do contribute code to it. Has anyone tried to get the databooks for the M10 or 9600 yet? How hard is this? Do you guys have an established reputation with ati? I heard the gatos people got the databooks for the r3xx cards but I'm not sure if that includes 3D registers as well or just 2d and overlay stuff. many xfree86 and DRI developers have a good relationship with ati. ati contributes quite a bit of code. I'm not sure if anyone has tried to get databooks for the 3D stuff yet; I don't even know if ati will release them. I noticed in the FAQ that it said you don't give out the info once they give it to you. Why is that? And why do they only give out the info to companies. Seems a bit silly. Could I just claim to have my own company and get the data? Why yes, I'm the CEO of Just for DRI, a new company that is making drivers for DRI. Ya know, or something equally silly. If you want the databooks, you'll need to register on their website. if you are not a company, then put in something like opensource developer or hobbyist. When you say sponsored development do you mean monetary sponsorship, or do you mean something else? Yes monetary sponsorship. writing a 3D driver for a new chip like the r3xx chips is no small undertaking. it's a lot of work. the weather channel funded the development of the r2xx drivers. Thanks for the reply, sorry I have so many questions that are probably really silly. Thanks, Jason __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MergedFB committed
I just commited mergedfb to DRI cvs. Let me know if there are any problems. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MergedFB committed
Sorry, I forgot to post a patch of what went in. I committed this patch: http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/mergedfb-dri.diff Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Yeah. I'll work on that this week unless anyone has any objections. Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: Log message: Add Merged Framebuffer (MergedFB) support to the radeon driver. On dualhead cards this creates a single shared framebuffer with 2 viewports looking into it. This allows things like the DRI to work on both heads. This also adds support for pseudo-xinerama so that xinerama aware apps will behave as expected in a dualheaded setup when used with MergedFB. Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon.h radeon.man radeon_cursor.c radeon_driver.c radeon_video.c Revision ChangesPath 1.39 +77 -7 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h 1.3 +125 -17 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man 1.15 +126 -75 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c 1.65 +1505 -202 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 1.18 +174 -44 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c Ugh. radeon_driver.c is getting out of hand in it's shear size now. Could this work be separated out into a radeon_mergedfb.c ? Then all the Xinerama related code is easily spotted when we can separate this stuff out into it's own support module that other drivers can use. Alan. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
I have a question about the license at the top of these new files. what should I put for the copyright? Some of the the code was written by me, but much of it was taken from the sis and mga drivers. Also, what to I put for the top line? the one that looks like this: /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25 2003/08/29 21:07:57 tsi Exp $ */ thanks, Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote: Log message: Add Merged Framebuffer (MergedFB) support to the radeon driver. On dualhead cards this creates a single shared framebuffer with 2 viewports looking into it. This allows things like the DRI to work on both heads. This also adds support for pseudo-xinerama so that xinerama aware apps will behave as expected in a dualheaded setup when used with MergedFB. Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon.h radeon.man radeon_cursor.c radeon_driver.c radeon_video.c Revision ChangesPath 1.39 +77 -7 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h 1.3 +125 -17 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man 1.15 +126 -75 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c 1.65 +1505 -202 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 1.18 +174 -44 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c Ugh. radeon_driver.c is getting out of hand in it's shear size now. Could this work be separated out into a radeon_mergedfb.c ? Then all the Xinerama related code is easily spotted when we can separate this stuff out into it's own support module that other drivers can use. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-cvs miniglx merge
it's be nice if we could merge radeon and r200 into one driver when we did this as well. Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Wed, Oct 08, 2003 at 12:53:29AM -0600, Otto Solares wrote: Hi! I am trying to merge the r200 driver from dri-cvs to mesa-miniglx, finally i had most files merged but i am finding heavy X dependencies in header files in dri-cvs (eg radeon.h), it was not supposed dri drivers should be backend agnostic? Is somebody working on resolving this situation? i think unified dri drivers should be a common goal. And yes!, dri drivers should live in mesa tree instead of Xfree IMHO. Indeed. I'm working on this at the moment. But being able to do this with a degree of cross code sharing is tricky. MiniGLX uses a subset of the current DDX driver mechanism's to initialize the DRI. It would be nice if that code can be shared. Before that can happen though, is that we need dynamic back/depth buffer creation - which is what I'm currently working on. In fact, I'll probably be creating a branch in the DRI CVS pretty soon. I've used the r200 driver as a basis for this work. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Broken Xv in current trunk?
that's my fault. there's a small bug that I missed that breaks Xv in non-mergedfb mode. I have the fix. it will be committed ASAP. Alex --- Stefan Lange [EMAIL PROTECTED] wrote: Hello, if I try to use Xv (via mplayer, or with xawtv using the v4l-module) with current cvs (trunk) the X server crashes. I'm using a r200-based card (Radeon 8500). When I check out cvs from just before the mergedfb-merge (i tried 2003-10-07, 4:30:00), I get no problems, so the merge might have broken something. Can anybody reproduce this? regards, Stefan --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ 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: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Broken Xv in current trunk?
A fix just went into xfree86 CVS earlier today that fixed several things related to Xv on i8xx hardware. that code hasn't been synced with DRI CVS yet. I don't have intel hardware so I can't test. The problem with Xv on radeon was a bug in my mergedfb code, but it's fixed now. Alex --- Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 9 Oct 2003, Michel Dänzer wrote: I could, and I just fixed this in CVS. The cause was dereferencing a pointer which is uninitialized in non-MergedFB mode. It's still broken on i845, though. No crashes, but Xv windows show up as all blue (I assume that's the overlay color), and the X server takes up 100% CPU time when trying to play anything. As a result, everything turns very jerky indeed, as other X clients end up getting delayed by the (broken) Xv support. It's been broken for at least a few weeks. I don't know what I can do to help debug it, but I'll happily test patches. Linus __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] sync radeon driver with Hui's latest patch
I recently synced up my DRI tree with Hui's latest patch from xfree86 cvs. I need the DVI code for my new 9200. Would anyone object to me adding this to DRI cvs? I'm using it now with no problems so far. Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] weird corruption with r200
I just got my 9200 up and running but I'm seeing some weird behavior. 3d works fine if I run in single head mode. however, if I run with mergedfb I get weird corruption in fullscreen apps like screen savers. for example, if I run the atlantis screen saver, there appears to be junk from previous 3D apps that is colored the same as the blue back ground. then when the whales are drawn you appear to be swimming behind remnants of old whales and gears from glxgears. running in single head mode works fine and running windowed 3d apps works fine on both heads in mergedfb mode. On my laptop in mergedfb mode (m6 - r100), fullscreen apps like screen savers show no such corruption; they render fine across both heads. I've tried all the different settings (TCL, frame throttling, etc.) nothing changes. does anyone know why this could happening? has anyone else experienced anything similar? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] weird corruption with r200
Well, I solved the problem...sort of... it happens when I'm using a merged mode that's 2048 wide. Does anyone know why there would be corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried a single head at 2048x1536? Mergedfb works at 2048x768, it just shows that corruption I described below. It's almost like there's old state getting mixed in or something. changing to 2047x768 clears it up, but then you have screen overlap. Alex --- I just got my 9200 up and running but I'm seeing some weird behavior. 3d works fine if I run in single head mode. however, if I run with mergedfb I get weird corruption in fullscreen apps like screen savers. for example, if I run the atlantis screen saver, there appears to be junk from previous 3D apps that is colored the same as the blue back ground. then when the whales are drawn you appear to be swimming behind remnants of old whales and gears from glxgears. running in single head mode works fine and running windowed 3d apps works fine on both heads in mergedfb mode. On my laptop in mergedfb mode (m6 - r100), fullscreen apps like screen savers show no such corruption; they render fine across both heads. I've tried all the different settings (TCL, frame throttling, etc.) nothing changes. does anyone know why this could happening? has anyone else experienced anything similar? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
re: [Dri-devel] weird corruption with r200
Further info on this. Not all GL apps are affected. I've only tried xscreensavers. of the GL screensavers most show that corruption I spoke of, but some seem unaffected (many from the rss package: http://rss-glx.sourceforge.net/). Those that work: BusySpheres Cage Colorfire Hufos smoke hufos tunnel pulsar Skyrocket solarwinds sundancer2 Don't work: Atlantis Bubble3D Circuit Cubenetic Cyclone Dangerball Endgame Engine Flipscreen3D Flocks lament most others Certain modes work: BioF Flux Helios Any insight would be much appreciated. thanks, Alex Well, I solved the problem...sort of... it happens when I'm using a merged mode that's 2048 wide. Does anyone know why there would be corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried a single head at 2048x1536? Mergedfb works at 2048x768, it just shows that corruption I described below. It's almost like there's old state getting mixed in or something. changing to 2047x768 clears it up, but then you have screen overlap. Alex --- I just got my 9200 up and running but I'm seeing some weird behavior. 3d works fine if I run in single head mode. however, if I run with mergedfb I get weird corruption in fullscreen apps like screen savers. for example, if I run the atlantis screen saver, there appears to be junk from previous 3D apps that is colored the same as the blue back ground. then when the whales are drawn you appear to be swimming behind remnants of old whales and gears from glxgears. running in single head mode works fine and running windowed 3d apps works fine on both heads in mergedfb mode. On my laptop in mergedfb mode (m6 - r100), fullscreen apps like screen savers show no such corruption; they render fine across both heads. I've tried all the different settings (TCL, frame throttling, etc.) nothing changes. does anyone know why this could happening? has anyone else experienced anything similar? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2003-10-12 at 17:27, Alex Deucher wrote: Well, I solved the problem...sort of... it happens when I'm using a merged mode that's 2048 wide. Does anyone know why there would be corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried a single head at 2048x1536? You could try yourself. :) I wish I had a monitor that could display 2048x1536. Mine tops out at 1600x1200 :) 3D works fine as long the width of the crtc(s) is less than 2048. virtual desktop size doesn't seem to affect 3D. 3d works fine if I run in single head mode. however, if I run with mergedfb I get weird corruption in fullscreen apps like screen savers. for example, if I run the atlantis screen saver, there appears to be junk from previous 3D apps that is colored the same as the blue back ground. then when the whales are drawn you appear to be swimming behind remnants of old whales and gears from glxgears. running in single head mode works fine and running windowed 3d apps works fine on both heads in mergedfb mode. Weird, as there's no fundamental difference between windowed and fullscreen. yeah. On my laptop in mergedfb mode (m6 - r100), fullscreen apps like screen savers show no such corruption; they render fine across both heads. I've tried all the different settings (TCL, frame throttling, etc.) nothing changes. does anyone know why this could happening? has anyone else experienced anything similar? I see problems in 2048x1024 on R100, but only with page flipping. Is that also true for your problem? No. I have pageflipping disabled. pageflipping doesn't work right in certain mergedfb modes (leftOf and Above - those where crtc2 precedes crtc1 in the framebuffer). Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
You can have as big a virtual desktop as you want so long as the total 3D contexts are not greater than 2048 in either direction. Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 01:26, Alex Deucher wrote: -- Michel Dnzer [EMAIL PROTECTED] wrote: On Sun, 2003-10-12 at 17:27, Alex Deucher wrote: Well, I solved the problem...sort of... it happens when I'm using a merged mode that's 2048 wide. Does anyone know why there would be corruption at 2048x768 (2 heads of 1024x768)? Has anyone tried a single head at 2048x1536? You could try yourself. :) I wish I had a monitor that could display 2048x1536. Mine tops out at 1600x1200 :) 3D works fine as long the width of the crtc(s) is less than 2048. virtual desktop size doesn't seem to affect 3D. It should actually be the other way around... unless it's some kind of bandwidth issue or something, but I assume you're running with Hui's patch for that? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Major mergedFB rework committed to CVS
I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
hmmm... Have you ever gotten mergedfb working under freebsd? I've never tested on freebsd. can you send your log? Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Alright... You can ignore the unresolved symbol messages. That was my mistake. However, the X server is still crashing under FreeBSD with the MergedFB option enabled. Adam On Mon, 13 Oct 2003, Adam K Kirchhoff wrote: Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher wrote: I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
Can you clarify what you tried and what the problem is? Does everything work as expected when using a particular XFree86 binary and not with another, or are you having a problem with the changes I committed last night? If you are having trouble with the driver, there are a couple of things you can try: Option MergedFB false Mergedfb is on by default as it provides a clone mode. this is to match the behavior of the old radeon driver clone mode. setting it to false disables the 2nd crtc. crtc1 then drives both displays. Try defining a virtual resolution of 1152x864 and seen if that fixes it. Send a copy of your log file. Alex --- Martin Spott [EMAIL PROTECTED] wrote: Alex Deucher [EMAIL PROTECTED] wrote: I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. I'm fine with running the 'new' X server _modules_ with a previously built XFree86 binary when I install the new stuff without restarting the X server I'm currently using. Unfortunately the 'new' X server core binary fails to run at my default resolution [EMAIL PROTECTED] Hz but falls back to 1024x768 at somewhat around 60 Hz (usual effects of too low refresh rate). 'xdpyinfo' fails to print the _real_ parameters: name of display:quickstep.plesnik.bonsai.de:0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:40399012 XFree86 version: 4.3.99.12 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: [...] default screen number:0 number of screens:1 screen #0: dimensions:1152x864 pixels (361x271 millimeters) This is _definitely wrong !!! resolution:81x81 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 root window id:0x48 depth of root window:16 planes [...] The effect appears with 24 bpp as well. There is _not_ virtual resolution defined and I did not change my XF86Config since september, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
You are right. Last night I created a virtual desktop of 2100x768 and display mode of 1024x768, then ran several fullscreen GL xscreensaver hacks. All of them displayed fine. I haven't looked at the source to the hacks, but I assume they look at the current display mode and the create a 3D window of that size, 1024x768 in this case. I guess the GL screensavers may be draw their 3D window at starting at 0,0. The only time I see the rendering fail is when the actual 3D window(s) itself exceeds 2048. For instance if I resize a glxgears window, it will render fine up to 2048, then the window goes blank, or if I run several instances of glxgears lined up, the one that exceeds 2048 will go blank. perhaps the limit is actually 2047? that wouldn't seem to be the case since rendering still happens at 2048 it's just full of arifacts. perhaps it is bandwidth. I downloaded the newest version of xscreensaver last night. the new behavior is to create 2 instances of the GL hack based on the xinerama info and display one on head head. the hack running on the first head displays fine; the one running on the second head shows the corruption. So it seems to have something to do with 2048. Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 06:13, Alex Deucher wrote: You can have as big a virtual desktop as you want so long as the total 3D contexts are not greater than 2048 in either direction. Wrong. The 2048 limit is for the virtual location of the right and bottom edges of 3D windows. The 3D engine couldn't care less about what the CRTCs do with the data it renders, except for the bandwidth. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
Also, I don't think it's a bandwith issue. I can run mergedfb in above mode with a virtual desktop of 1280x1792 (1024x768 above 1280x1024) and all is well. this is signifigantly more bandwidth than 2048x768. Unless the pitch has more to do with it than the height... Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 06:13, Alex Deucher wrote: You can have as big a virtual desktop as you want so long as the total 3D contexts are not greater than 2048 in either direction. Wrong. The 2048 limit is for the virtual location of the right and bottom edges of 3D windows. The 3D engine couldn't care less about what the CRTCs do with the data it renders, except for the bandwidth. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DXTC/S3TC support for Radeons?
this is a patent issue: http://dri.sourceforge.net/cgi-bin/moin.cgi/S3TC --- Csan [EMAIL PROTECTED] wrote: Hello all, I've been wondering whether DXTC/S3TC will be implemented in the DRI (Radeon) drivers. I got an ATI Radeon Mobility M9 Lf (AGP). I haven't been able to find any info in this topic on the DRI Wiki. # ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. OpenGL renderer relies on DXTC/S3TC support. History: Exiting due to error # glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read, GLX_SGIS_multisample client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_NV_vertex_array_range, GLX_MESA_agp_offset GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20020827 AGP 4x x86/MMX TCL OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x25 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x29 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2b 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x2c 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x2d 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2e 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2f 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x30 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x31 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x32 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow Could any of you share some info on this with me/us? Thanks a lot. Regs, __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 16:26, Alex Deucher wrote: perhaps the limit is actually 2047? No, the RE_WIDTH_HEIGHT register takes 11 bits for the coordinates of the rightmost column and bottommost line. There may be off-by-one errors in the code though... Yeah, that's what I thought... perhaps it is bandwidth. I agree with you that's unlikely. I downloaded the newest version of xscreensaver last night. the new behavior is to create 2 instances of the GL hack based on the xinerama info and display one on head head. the hack running on the first head displays fine; the one running on the second head shows the corruption. So it seems to have something to do with 2048. It wouldn't be as simple as clears not working (properly) = 2048, would it? Can you capture the problem in screenshots? That sounds right. because the 3D image shows up correctly. it's like looking through a mesh of bits of old 3d objects (colored the same as the background) with the new 3D scene rendering correctly behind it. I'll try ang grab a screenshot tonight. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
--- Martin Spott [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2003 at 06:56:32AM -0700, Alex Deucher wrote: Can you clarify what you tried and what the problem is? When I restart the 'new' (with MergedFB) XFree86 X server binary with the old XF86Config (attached) I get a flickering screen with a resolution that is obviously below what I usually set - but 'xdpyinfo' displays the parameters that I usually expect (but are not present). That's what I'm not clear on. when you say XFree86 X server binary do you mean /usr/X11R6/bin/XFree86 or radeon_drv.o? I assume you mean the latter. /usr/X11R6/bin/XFree86 has no mergedfb specific code in it. that is all taken care of in the driver. I attached the X server log file '.0' with flickering screen and Option MergedFB false '.1' with this option put into the XF86Config, which clears the situation for me ! I'll take a look at this tonight. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
When the X server is running it is all in memory. when you copy a never version over the existing install, it just copies over the files. The new files aren't used until you restart the X server. upon restarting you are then loading the new X server (XFree86) which then loads the radeon_drv.o driver to drive your hardware. somehow validating the mode for crtc2 must be messing up the mode for crtc1. I rewrote some of that code, so it's possible I messed something up. Alex --- Martin Spott [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2003 at 09:03:38AM -0700, Alex Deucher wrote: That's what I'm not clear on. when you say XFree86 X server binary do you mean /usr/X11R6/bin/XFree86 or radeon_drv.o? I assume you mean the latter. /usr/X11R6/bin/XFree86 has no mergedfb specific code in it. that is all taken care of in the driver. Doh I really mean /usr/X11R6/bin/XFree86 - how would I reload radeon_drv.o on a running X server ? See: 1.) I'm running last week's build at [EMAIL PROTECTED] _after_ the config-branch merge (X server restart after installing). Everything is fine. 2.) I'm compiling todays CVS and install it _over_ last week's build - the X server remains running. Still everything's fine, FlightGear runs very nice. 3.) I'm restarting the X server and see [EMAIL PROTECTED] or so. 4.) I add your Option MergedFB false into XF86Config and restarting the X server makes me happy, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Mon, 13 Oct 2003, Alex Deucher wrote: it seems to crash while validaing the modes on the second head. Which is odd since, if I turn off mergedfb and just use normal xinerama, it works fine, it has no problems validating the modes. they use different validation routines. I ought to rewrite the crtc2 routine, but I haven't had a chance. the current one is based on the old clone mode validation routine. Still, I'm not sure why it would work on linux and not freebsd. I don't know why it should work on linux but not freebsd. you might try turning off DCC and EDID. perhaps those functions are causing a problem on freebsd, although it they wokred ok the first head, they should work on the second. Option noddc true Option IgnoreEDID true Option MonitorLayout CRT, CRT I was already using the MonitorLayout option, and I just tried the noddc option and the IgnoreEDID option. Neither worked. You can also try adjusting the DDC mode: Option DDCMode I just tried with it set to on and off. Neither worked. Also make sure you specify the virtual size in the screen section of your config file. Adam Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Mon, 13 Oct 2003, Alex Deucher wrote: hmmm... Have you ever gotten mergedfb working under freebsd? Last night was the first time I tried, so no :-) I've never tested on freebsd. can you send your log? http://memory.visualtech.com/XFree86.0.log Same config file (minus a few changes to the mouse section) and same source tree works on the same machine under Linux :-) Adam Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Alright... You can ignore the unresolved symbol messages. That was my mistake. However, the X server is still crashing under FreeBSD with the MergedFB option enabled. Adam On Mon, 13 Oct 2003, Adam K Kirchhoff wrote: Alex, Last night, prior to your commit, X server was crashing on FreeBSD when trying to use MergedFB. No errors, however, where showing up in the log file prior to the Fata server error As of this morning, it's still crashing, but it's showing lots of unresolved symbols: Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONChooseOverlayCRTC from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONStrToRanges from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONAdjustFrameMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONUpdateXineramaScreenInfo from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONXineramaExtensionInit from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONnoPanoramiXExtension from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergePointerMoved from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONMergedFBSetDpi from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONRecalcDefaultVirtualSize from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONGenerateModeList from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol RADEONSetCursorPositionMerged from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! On Sun, 12 Oct 2003, Alex Deucher wrote: I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
I've uploaded some screenshots as an example: http://www.botchco.com/alex/2048-error/ the new version of xscreensaver displays a separate instance on each head of a xinerama desktop. so in this case only the context running up again the 2048 limit (the right side) shows the error. When I turn off xinerama or run an older version of xscreensaver the corruption shown on the right side of the above images shows across the entire screen. Looks like a clearing problem. you can see there seems to be remnants of old whales and glxgears overlayed on the new scene. Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: ... I downloaded the newest version of xscreensaver last night. the new behavior is to create 2 instances of the GL hack based on the xinerama info and display one on head head. the hack running on the first head displays fine; the one running on the second head shows the corruption. So it seems to have something to do with 2048. It wouldn't be as simple as clears not working (properly) = 2048, would it? Can you capture the problem in screenshots? __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
what's the difference between the two? why does linux have it's own version? why couldn't the linux version be used with BSD? something to do with the kernel? Alex --- Eric Anholt [EMAIL PROTECTED] wrote: On Mon, 2003-10-13 at 09:14, Alex Deucher wrote: If the mode validation interacts with the bios at all (I don't really know this stuff), one major difference between Linux and FreeBSD is use of emulation for int10. On a Linux system, you can use emulation like on FreeBSD by moving /usr/X11R6/lib/modules/linux/libint10.a out of the way so the generic (emulation) one is used. Int10 and the emulation for it is the most common cause of differences between Linux and *BSD for 2d in XFree86, I would say. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
--- Roland Scheidegger [EMAIL PROTECTED] wrote: Martin Spott wrote: Alex Deucher [EMAIL PROTECTED] wrote: I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. I'm fine with running the 'new' X server _modules_ with a previously built XFree86 binary when I install the new stuff without restarting the X server I'm currently using. Unfortunately the 'new' X server core binary fails to run at my default resolution [EMAIL PROTECTED] Hz but falls back to 1024x768 at somewhat around 60 Hz (usual effects of too low refresh rate). 'xdpyinfo' fails to print the _real_ parameters: I have a similar problem. Though in my case, I don't get a picture at all - the monitor just goes to standby. Disabling MergedFB solves the problem. Config file can be found here: http://homepage.hispeed.ch/rscheidegger/XF86Config.mergedfb log file: http://homepage.hispeed.ch/rscheidegger/XFree86.0.log something with the mode validation seems fishy... Part of the problem is I'm not entirely sure how the hardware/driver decides what output gets assigned to what crtc. In windows you can change this, in xfree86, it's done sort of automatically. The driver assumes that the DVI/LCD port is the primary and the crt port is the secondary. however if there's nothing attached to the DVI port, the vga port should be attached to crtc1, but that doesn't always happen. it looks like, in your case, that it's reversing the outputs (the 1280x1024 mode is being sent to the other port and the 0x0 is being sent to your monitor). to make matter worse some OEMs reverse how the DACs are wired or which pins the DDC info come in on for each head. All of which makes figuring out the modes kind of a PITA. I plan to delve into this more next time I get a chance. Take a look at the various mode validation functions in the radeon driver! it's enough to make your head spin! The reason mergedfb is enabled by default is to emulate the clone behavior in the old driver. perhaps this should be changed in the future? In the mean time, I may switch back to validating the modes on crtc2 before crtc1. that was the way I had it initially and the way it was for clone mode. I switched it when I was working on a sort of autoconfigure for mergedfb. however, that didn't work out as expected due to the way the radeon ddc functions are structured. they need to be reworked to make autoconfig work properly. Although I don't know why the order should matter, but you never know... UGH... I HATE dealing with modes... And I also get some minor corruption if I run games fullcreen (with MergedFB disabled), when the fullscreen resolution of the game is the same as the virtual resolution - nwn showed a blue line at the right and the bottom edge, Quake III showed a similar problem. Hmmm... I haven't seen any problems with OpenGL here (in mergedfb and non-mergedfb modes), other than the corruption I'm seeing with a 3d window that's 2048 pixels wide . But at least the snow is now gone thanks to Hui's patch. That means I can finally upgrade XFree86 my 2nd PC with a radeon 7200sdr - the snow was unbearable with XFree86 4.3 on that machine. Roland __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Multiple VTs with DRI
As I recall, no. As it is now, only a single instance of Xfree86 can use the DRI. I think it might be possible by adapting the resume code to reinitialize state and agp on a VT switch, however, I may be wrong. Alex --- Jon Smirl [EMAIL PROTECTED] wrote: If I am running two copies of Xfree/DRI on different VT's and both are using the same hardware, is 3D state maintained on VT switch? Including all of the texture memory? = 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: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
I'll take a look at it if I get some free time this week. Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Hey guys, That did it. I moved libint10.a out of the way on my linux installation, and now X is failing to start just as it did under FreeBSD (while validating modes on the second head). So, in theory, you should be able to reproduce the problem really easily, Alex, by moving that file, too. Of course, I'm more than willing to test or try anything on my end. Adam On Mon, 13 Oct 2003, Eric Anholt wrote: On Mon, 2003-10-13 at 09:14, Alex Deucher wrote: it seems to crash while validaing the modes on the second head. I don't know why it should work on linux but not freebsd. you might try turning off DCC and EDID. perhaps those functions are causing a problem on freebsd, although it they wokred ok the first head, they should work on the second. Option noddc true Option IgnoreEDID true Option MonitorLayout CRT, CRT You can also try adjusting the DDC mode: Option DDCMode Alex If the mode validation interacts with the bios at all (I don't really know this stuff), one major difference between Linux and FreeBSD is use of emulation for int10. On a Linux system, you can use emulation like on FreeBSD by moving /usr/X11R6/lib/modules/linux/libint10.a out of the way so the generic (emulation) one is used. Int10 and the emulation for it is the most common cause of differences between Linux and *BSD for 2d in XFree86, I would say. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ 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: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
It's still emulating the old clone mode. it just uses the mergefb clone mode rather than the old clone mode since there were just about the same code-wise. Clone mode was on by default in the old radeon driver, so the mergedfb equivalent is on by default in mergedfb. the reason for the default to clone mode was to prevent damage to external monitors because by default the chip uses crtc1 to drive both heads. if the secondary monitor can't handle the signal it could damage the monitor. hence clone mode looks at the DDC/EDID info and determines the monitor's capabilites. if it can't handle the mode it shuts it off. The problem is that the hardware is kind of quirky (especially with OEM stuff) when it comes to DDC and which head is which. I can switch back to the old order in the mean time, however, I'm not sure if it is any more or less reliable than the current code. both work fine on my hardware. testing will prove what works best I suppose. Alex --- Michel D�nzer [EMAIL PROTECTED] wrote: On Tue, 2003-10-14 at 21:58, Alex Deucher wrote: The reason mergedfb is enabled by default is to emulate the clone behavior in the old driver. perhaps this should be changed in the future? In the mean time, I may switch back to validating the modes on crtc2 before crtc1. that was the way I had it initially and the way it was for clone mode. So you are no longer actually emulating the former clone mode. Reverting that sounds like a very good idea. Experimental changes should probably be done on a branch. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
That's fine with me. we can revert back to xfree86 CVS for the trunk and I can move to a branch. I wouldn't have put it on the trunk if I had know the mode stuff was cause so much trouble, but then again, it's been working fine for me and those who initially tested it, so I need to more testers to find the bugs :) if we move to a branch, perhaps we could add it to the snapshots? Alex --- Keith Whitwell [EMAIL PROTECTED] wrote: Michel Dänzer wrote: On Tue, 2003-10-14 at 21:58, Alex Deucher wrote: The reason mergedfb is enabled by default is to emulate the clone behavior in the old driver. perhaps this should be changed in the future? In the mean time, I may switch back to validating the modes on crtc2 before crtc1. that was the way I had it initially and the way it was for clone mode. So you are no longer actually emulating the former clone mode. Reverting that sounds like a very good idea. Experimental changes should probably be done on a branch. I have to say I agree with Michel here. In hindsight, this work should have been done on a branch to start with -- the trunk isn't the place to be debugging new code. I'm not sure how much work is left in this, but I'm coming to share the opinion that it is still worthwhile to move it to a branch until the glitches are ironed out. Keith __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
Sounds good. I may play around with it when I get a chance. Any other thoughts on what it might be if not clears? Alex --- Michel D�nzer [EMAIL PROTECTED] wrote: On Tue, 2003-10-14 at 06:44, Alex Deucher wrote: I've uploaded some screenshots as an example: http://www.botchco.com/alex/2048-error/ the new version of xscreensaver displays a separate instance on each head of a xinerama desktop. so in this case only the context running up again the 2048 limit (the right side) shows the error. When I turn off xinerama or run an older version of xscreensaver the corruption shown on the right side of the above images shows across the entire screen. Looks like a clearing problem. you can see there seems to be remnants of old whales and glxgears overlayed on the new scene. Doesn't look like what I'd expect if clears didn't work though, but you may still want to start digging in radeon_cp_dispatch_clear(). -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
perhaps for the time being I can set mergedfb to default to false rather than the true clone mode it does now. that should prevent the mergedfb code paths from being taken and those that want to try it can simply turn it on. I don't think anyone has had a problem with it turned off. speak up if you do... Alex --- Keith Whitwell [EMAIL PROTECTED] wrote: Alex Deucher wrote: That's fine with me. we can revert back to xfree86 CVS for the trunk and I can move to a branch. I wouldn't have put it on the trunk if I had know the mode stuff was cause so much trouble, but then again, it's been working fine for me and those who initially tested it, so I need to more testers to find the bugs :) I'm sympathetic to this argument: People generally don't bother with downloading stuff on a branch, so it doesn't get anything like the testing exposure as the trunk code. if we move to a branch, perhaps we could add it to the snapshots? That's a reasonable idea - but it still wouldn't have caught the freebsd problems. Keith __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Wed, 2003-10-15 at 22:12, Alex Deucher wrote: perhaps for the time being I can set mergedfb to default to false That's probably a good idea, but then it should default to clone mode as pre-MergedFB. Driving both heads with a single CRTC is nasty. ugh... that's gonna take some work... I eliminated all the old clone code because it was mostly duplicated code paths. when I initially wrote mergedfb, I had left in all the old clone stuff as well, but everyone who reviewed the code said it was duplicated and should be eliminated if I wanted it to be accepted upstream... I guess it can go back... __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Wed, 2003-10-15 at 22:58, Alex Deucher wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: On Wed, 2003-10-15 at 22:12, Alex Deucher wrote: perhaps for the time being I can set mergedfb to default to false That's probably a good idea, but then it should default to clone mode as pre-MergedFB. Driving both heads with a single CRTC is nasty. ugh... that's gonna take some work... I eliminated all the old clone code because it was mostly duplicated code paths. when I initially wrote mergedfb, I had left in all the old clone stuff as well, but everyone who reviewed the code said it was duplicated and should be eliminated if I wanted it to be accepted upstream... I was probably one of them, but I was thinking along the lines of reusing the existing code, not dumping it. :) It is reused :) it's just that I got rid of alot of the if (info-Clone) and replaced them with if (info-MergedFB). A lot of stuff had to be nixed or extended to handle modes besides clone (leftOf, rightof, etc.) and the data structures that hold the relevant data changed a bit. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... Alex --- Ville_Syrjälä [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote: Has any one checked the PC IDs in each driver? For example I'm not sure that all of the cards I added to the MGA driver are 3D capable. The driver only supports G200/G400/G550. Remove the rest. I'm not sure about the G200 PCI entry. The driver doesn't work on PCI cards. Hmm... Why aren't we using the AGP GART to support PCI cards? At least on my system PCI cards can see the AGP aperture... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: VIA's Savage Drivers
the 3D drvier needs to be updated to mesa 5.x. Not much work has been done on it and I think there are some issues with the 2D driver. There's no way it will make it into 4.4.0. the current code is on a branch in DRI cvs. If you are interested in helping, please do. Alex --- Tim Roberts [EMAIL PROTECTED] wrote: Some months ago, VIA released an XFree86 Savage driver in source form that included, among other things, a DRI driver and XvMC support. Has that code been integrated into the XFree86 source tree? Will it make XFree86 4.4? Or is it still waiting in limbo for someone to do the integration? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: VIA's Savage Drivers
Alan, that's the CLE266/via driver, right? the savage driver is still barely touched as far as I know. there was some talk of shelving the old savage_1-0-0 branch and starting a new one on savage_1-0-1 since the old one needed so many changes to get synced up to the trunk. Alex --- Alan Cox [EMAIL PROTECTED] wrote: On Mer, 2003-10-15 at 21:07, Alex Deucher wrote: the 3D drvier needs to be updated to mesa 5.x. Not much work has been done on it and I think there are some issues with the 2D driver. There's no way it will make it into 4.4.0. the current code is on a branch in DRI cvs. If you are interested in helping, please do. 2D is stable. AlanH added some core infrastructure bits that will improve it but its current form has only two known bugs. The 3D is another matter - the last code I threw at people runs glxgears sometimes and thats it 8) __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Alex --- Martin Spott [EMAIL PROTECTED] wrote: Ville Syrj?l? [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote: there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do address translation just like the AGP GART. G200/G400 don't have that bridge. I'm not sure if the agpgart driver in that link you posted uses that bridge or some generic PCI GART stuff available on some architectures. Hey, the guy's a good friend of mine - but he never told me he was tweaking DRI stuff I'm pretty shure he wrote the driver for use on his UP2000 Alpha mainboard he used for visualization purpose, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ 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: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Thu, 2003-10-16 at 08:36, Alex Deucher wrote: Log message: Clean up of the mode validation code for MergedFB. Does it behave the same as pre-MergedFB by default now? I haven't put back the old clone code, although the code that's there should work (it's an almost identical code path, the only real difference is how the crtc2 modes are stored in the driver). It works for me, but it may not work perfectly for others. This was mostly a clean up I've been working on for a while. Unfortunately, it still crashes when you run mergedfb mode without libint10.a. I haven't been able to track that down yet. Also enable MergedFB autoconfig which will automatically set the virtual desktop size and/or metamodes if you forget to specify them. Also added MergedFBAuto option which will automatically run single head or dualhead depending on whether it detects one or two attached monitors. Is that option really needed? Shouldn't that be the default? Yeah, I guess it should :) it was late, when I finally got it working. I'll make that the default tonight. PS: The name of Option NoMergedXinerama is broken. The option handling code will automatically treat NoXXX as XXX off. I'll take a look. thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
no worries... I was just curious. --- Martin Spott [EMAIL PROTECTED] wrote: Alex Deucher [EMAIL PROTECTED] wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Sorry, currently he's forced to finish his dissertation. He says you might have to wait at least a month until he'll be able to deal with that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
Before I go grepping through the tree, where would I find this code (in the DRM, DRI, or 2D)? Also is it for r100 or r200 or both? is there a r200_cp_dispatch_clear()? thanks, Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Tue, 2003-10-14 at 06:44, Alex Deucher wrote: I've uploaded some screenshots as an example: http://www.botchco.com/alex/2048-error/ the new version of xscreensaver displays a separate instance on each head of a xinerama desktop. so in this case only the context running up again the 2048 limit (the right side) shows the error. When I turn off xinerama or run an older version of xscreensaver the corruption shown on the right side of the above images shows across the entire screen. Looks like a clearing problem. you can see there seems to be remnants of old whales and glxgears overlayed on the new scene. Doesn't look like what I'd expect if clears didn't work though, but you may still want to start digging in radeon_cp_dispatch_clear(). -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] cool merge/diff app
I just noticed this app today: http://meld.sourceforge.net/index.html Looks pretty nice. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Fri, 2003-10-17 at 04:41, Alex Deucher wrote: Log message: *Re-wrote MergedFB validate mode function from scratch based on crt1 validation rather than the old clone validation code. So does it work more or less like the old clone mode by default now? :) Should work more like it :) *Fixed mode validation on systems without libint10.a; MergedFB should work on Freebsd, however, I don't have such a system to test on. It works fine on linux without libint10.a. Note that AIUI, the problem was never a missing libint10.a, but the generic one vs. the Linux specific one. That's what I meant, sorry for any confusion. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Fri, 2003-10-17 at 05:14, Eric Anholt wrote: Log message: - Converted Linux drivers to initialize DRM instances based on PCI IDs, not just a single instance. Moved the PCI ID lists from card_drv.c in BSD to card.h. The PCI ID lists include a driver private field, which may be used by drivers for chip family or other information. Based on work by jonsmirl. - Make tdfx_drv.c and tdfx.h match other drivers. - Fixed up linking of sis shared files. Tested with Radeon and SiS on Linux and FreeBSD, including a Linux setup with 2 SiS cards in a machine, but only one head being used (with DRI) The case I was concerned about was multiple Radeon cards, that used to fail rather spectacularly. I thought that had something to do with rom loading on secondary cards, although you may be speaking of a different issue. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI + Radeon + LCD has framerate cap
you need to change the DRI config settings: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure perhaps we shouldn't make sync to refresh the default. Alex --- Paul Zaremba [EMAIL PROTECTED] wrote: Hello, I have a Radeon 8500 LE with an LCD attached to the CRT output. I've been compiling the DRI to test against NwN, glxgears, and bzflag. So first of all, great work! However, as of last week when I downloaded and compiled the DRI it appears that my glxgears framerate is capping at the vSync rate (70fps) and the hardware NwN fps is a little over half what it used to be, lighting/texture glitches and all. I suspect that it's idling the CPU waiting for vSync in both. I re-tested by using the latest trunk as of this morning and it's still capped. It also appears that R200_NO_TCL no longer functions. It was the only thing that allowed me to play NwN at all with the DRI since I prefer not to use the ATI binary drivers. I haven't learned how to use what appears to be the DRI config file yet, but that's on my list of things to do this weekend. In the source it looks like I can set TCL_mode to 0 in the config file to achieve the same effect that R200_NO_TCL used to give me. Is my deduction correct about the config file? If you want, when I get the time (read: tomorrow) I will use cvs update -D to binary search through the tree of the last 45 days and find when it changed. I'm willing to dig into the code and find out what's wrong. I design and implement software for a living and as my second favorite hobby. So, while I'm not familiar with the code I believe I can be of more use than the usual it's broken, help? statements. Just in case they may be useful I have logs available at: http://treeofice.net/~pez/logs/ XFree86.0.log (50K) glxinfo.log (4.1K) I figure I'll sacrifice some outgoing bandwidth to keep from spamming the list with files unnecessarily. System info; Athlon 1800+, 512MB RAM, Radeon 8500LE, gentoo linux (ACCEPT_KEYWORDS=~x86), 2.4.20-gentoo-r7 with kernel module not built in kernel. Using the DRI CVS kernel module. The LCD monitor has a CRT connector and is connect to the CRT output. I have a DVI to CRT convertor somewhere if testing through the DVI port is desired. Note: I used to get ~1450 out of glxgears, 36 fps out of NwN with the ugly hardware acceleration. Now it's 70/19. The cap happens with or without page flipping (makes sense). The logs are without page flipping. Thanks, Paul --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ 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 sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI + Radeon + LCD has framerate cap
plus there is a certain machismo element to the number of FPS your card can render... --- Mike Mestnik [EMAIL PROTECTED] wrote: --- Felix Kühling [EMAIL PROTECTED] wrote: On Fri, 17 Oct 2003 12:10:05 -0700 (PDT) Alex Deucher [EMAIL PROTECTED] wrote: you need to change the DRI config settings: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure perhaps we shouldn't make sync to refresh the default. IIRC there was a similar discussion after the texmem-0-0-1 merge. I was hoping that a well defined configuration system would finally allow us to make the default comply with the spec. The default setting should not affect the frame rate if it was below the vertical refresh rate without vsyncing. Only for benchmarks it is useful to disable vsync. For everyday work/game play you never need more than 75 or 80 Hz, do you? Alex Regards, Felix There may be allot I don't know about OpenGL, but I do know video games. In games you want to hear/see the latesed info about game state that exists, this adds(subtracts) to your hand eye cordination(Things like network anticipation are great). You also want what you hear to be synched with what you see. It's important for these 2 reasons that OpenGL allways present the user with the most current data. The way things should work is... The card tells the game when the NEXT vsync should happen, deduced by Current + RefreshRate. Then the game should predict what things will look like and send that to the card to be rendered. However things AFAICG work... The game renderes as many FPS as the card can and the card draws the last one to the sceen. Maby not the best way but the most feasable with what(drivers) we have today. Thus synch to vblank ?may? make frames appere 1/RefreshRate of a seconds too late. Thought for most gamers this may be fine, I think my eyes are faster. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ 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 sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] new 2048 limit code...
I've had several mergedfb users complain about the 2048 DRI limit
put in yesterday:
else if ( pScrn-virtualX 2048 || pScrn-virtualY 2048 ) {
info-directRenderingEnabled = FALSE;
xf86DrvMsg(scrnIndex, X_WARNING,
Direct Rendering Disabled --
Virtual resolution exceeds 2048
(hardware limitation)\n);
}
I'm not sure what the best way around this is...
While that is the limit, you can have a desktop larger than 2048 in
either dimension and 3D will work as long as the 3D windows are within
those limits. Often times users have a desktop larger than 2048 and
then when they use 3D (game, etc. using xvidmode), they switch to a
clone mode of less then 2048 and everything works fine. people rarely
run any apps larger than 2048 (other than screen savers maybe...).
I don't really care which way we go on this issue, I'm just pointing
out that's it's there...
perhaps we can not disable the DRI if mergedfb is active and the viral
is larger than 2048?
Anyone have any thoughts?
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---
This SF.net email sponsored by: Enterprise Linux Forum Conference Expo
The Event For Linux Datacenter Solutions Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; in the Server Room
http://www.enterpriselinuxforum.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Sorry. I documented the MergedDPI option. Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2003-10-18 at 18:53, Alex Deucher wrote: Log message: Update radeon man page. Sorry to be pedantic, but this log message is redundant: Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon.man It would have been interesting what changed though. -- 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 sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ 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 sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
Alex
--- Ian Romanick [EMAIL PROTECTED] wrote:
Jens Owen wrote:
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.
Oh goodie! There's a whole ton of crap that will get ripped out of
lib/GL/glx/glx{cmds,ext}.c then! All of the stuff for determining if
the client-side driver supports glcontextmodes and bindContext2 /
unbindContext2 will go bye-bye. :) This is the best news I've heard
all
day...
---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here:
http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-develceforge.net
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: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: new 2048 limit code...
I'll give keith's suggestion a shot, but I don't really understand how it's supposed to work. I'm not really much of an expert when it comes to the 3D driver. If someone could give me some pointers as to where to look and maybe a 500 foot description of how it should work, I'll see what I can come up with. Also, regarding the rendering errors at 2048, I looked at the clearing code in the DRM, but nothing really seemed amiss. I don't see why it would work at resolutions up to 2047, but not at 2048. Does anyone else have thoughts on that? Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2003-10-24 at 23:39, Mike A. Harris wrote: On Fri, 24 Oct 2003, Alex Deucher wrote: ... Why doesn't somebody implement one of the discussed workarounds in the 3D drivers? :) __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r300 question...
it's hard to say if it's worth pursuing or not since no one that I know of has the docs for the 3D engine on r300. Alex --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: I'm curious if anyone has attempted to get an R300 card working with the r200 driver? :-) I was fooling around today with a clean install of FreeBSD, and thought I'd give it a try. I added the device ID for my radeon 9800 to the radeon_drv.c file, and recompiled the radeon kernel module. It loads fine... I modified my XF86Config-4 file and set the ChipID in my Device section to 0x4242 (Radeon 8500 of some sort). X starts, and the following shows up in my X log file: (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xd59ad000 (II) RADEON(0): [drm] mapped SAREA 0xd59ad000 to 0x28276000 (II) RADEON(0): [drm] framebuffer handle = 0xc800 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000207 [AGP 0x/0x; Card 0x1002/0x4e48] (II) RADEON(0): [agp] 131072 kB allocated with handle 0xc1602f18 (II) RADEON(0): [agp] ring handle = 0xc000 (II) RADEON(0): [agp] Ring mapped at 0x3040 (II) RADEON(0): [agp] ring read ptr handle = 0xc0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x28273000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xc0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x30501000 (II) RADEON(0): [agp] AGP texture map handle = 0xc0302000 (II) RADEON(0): [agp] AGP Texture map mapped at 0x30701000 (II) RADEON(0): [drm] register handle = 0xd802 (II) RADEON(0): [dri] Visual configs initialized ... (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 3 (II) RADEON(0): [drm] Initialized kernel agp heap manager, 130023424 (II) RADEON(0): Direct rendering enabled Unfortunately, nothing displays on my monitor. It just blanks. The machine doesn't lock up, as I can still ssh in, so that may just be something easily fixed (I haven't messed around with it since then). Is this worth pursuing? Can anyone definatively say nothing positive is going to come from this? Adam --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Please read if you are having problems with dualhead on radeon IGP chips
I've talked to quite a few people that have had problems getting dualhead to work on radeon IGP chips. Specifically, the crt port seems to go into powersave mode when dualhead is enabled. I talked to Hui Yu at ATI about the problem and he hasn't seen it on his IGP boards using the lastest code from cvs. So, for those of you that are having problems please send me or Hui the output of this radeon register dump program: http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/hy0/radeon_dump.tgz To run this program, configure the non-working dualhead setup as usual, login as root, startx or xinit, run radeon_dump in a xterm, redirect the output to a file. Hopefully we will be able to pinpoint any anomolies and fix the driver. Please set up regular xinerama based multi-head rather than my mergedfb version of multi-head. Thanks, Alex __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: 3D for SMI WAS: Re: XrandR
--- Robert Woerle [EMAIL PROTECTED] wrote: Hi I am now in contact with Keith packard and checked out his latest stuff .. it looks promising since there is already a SMI Server there .. unfortunately it crashes when i use the hw acceleration ...without it works .. Alex Deucher schrieb: there is a patch for support of the 731 in bugzilla: http://bugs.xfree86.org/show_bug.cgi?id=754 No other drivers support roation in hardware at the moment, so it's up to you to implement it from scratch I suspect. Keith Packard did much of the work for xrandr for PDAs. You might want to look at the kdrive/tinyx servers for reference. Any chance you'd be interested in adding dualhead or 3D support? :) hmm .. i am no video guru ... also these are my first attempte`s with X-Server coding ... i did make a touchscreen driver and such stuff until now . Since i got the doc`s from SMI .. i have the reference to look at ... what is a good starting point for 3 D ??? is there any easy to read driver which i could derive the code from ? It depends on the how the engine works and what features it supports. The r128 or i810/80/45 driver may be a good reference point. The best way to start is to copy another driver and then slowly fill in the functions with SMI specific code. I admit I'm no expert when it comes to 3d though... Alex --- Robert Woerle [EMAIL PROTECTED] wrote: Hi I want to start implementing the Siliconmotion chips into the XRandR extension ... Can someone point me to a chip which already supports this extension and is able to rotate on the fly ?? I recieved the hardware specs and PCI registers from siliconmotion and i am ready to spent time on that ... i also revieved the doc`s for the latest SMI 731 chip which is even not supported at all at XFREE ... how do i get into that ... main issue is the XRANDR then comes the new 731 ... Cheers Rob -- __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: new 2048 limit code...
Hopefully I'll have some time this weekend to look into this, what files in the r200 client driver should I be looking at? Having looked at the code I'm guessing r200_state. Scissor and cliprect stuff. Although thinking about it more, there are probably more changes required since I guess every part of the 3D pipeline must be updated (or at least where the commands are issued to the card) depending on which 2048 zone the rendering falls into. Would it be better to make the solution more generic? I.e., introduce the concept of zones of cliprects, the extents of which would be determined based on the limitations of the hardware. the driver would then render based on zones. Maybe I'm overthinking it... Any other pointers? I'm sure I'll have more questions once I dig into it a bit more. Alex --- Keith Whitwell [EMAIL PROTECTED] wrote: Michel Dänzer wrote: On Sat, 2003-10-25 at 17:25, Alex Deucher wrote: I'll give keith's suggestion a shot, but I don't really understand how it's supposed to work. I'm not really much of an expert when it comes to the 3D driver. If someone could give me some pointers as to where to look and maybe a 500 foot description of how it should work, I'll see what I can come up with. AIUI (I trust in Keith correcting me if I'm clueless :), the 3D drivers would divide the cliprects at multiples of 2048 and then iterate over the divided zones when emitting rendering commands, adapting the buffer offsets and viewport parameters for each zone (which wasn't possible with my idea of doing the division in the server). Correct - I believe that you'd need to do this in the client. Keith __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
I'll take a look at fixing this in the radeon driver. What needs to be done to play nice with the DRI? Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 Potentially - yes. But the DRI parts need a little more work to play nicely with the Linear allocator. Alan. __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 M7 Documentation?
I tried to add dualhead support for this chip a while back, but got no where with docs from S3/VIA. I was able to find out basically how it worked, but I was never able to get it working (I think I wasn't setting the second DAC right). I eventually got databooks for the duoview portion of the virge MX (I was assuming M7 and virge MX were similarly architected), but by then I didn't have the time to mess with it anymore. S3/VIA released the source to a driver for the savage chips, but there was no dualhead support and the 3D portion only supports the savage 4 cores. for the older ones like the M7, you'll need to look in utah-glx. there was a 3D driver there. If you want to start working on dualhead support again, I'd be happy to help out. I can try and explain how it supposed to work, but you may already have a pretty good idea. Alex --- Michael Larson [EMAIL PROTECTED] wrote: I have an old S3 M7 dual head card that I would like to port my portrait code onto for XF86 for a hardware accelerated portrait dual display system. I used to write drivers for the M7 and I am familiar with the part but I am lacking documentation on it, this part is old so is there still documentation available for it? I am asking in the DRI list as the hardware rotate uses the texture engine... Thanks, Mike Larson __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage and 2D problems
sounds good to me. Alex --- Felix Kühling [EMAIL PROTECTED] wrote: ... Does anyone object if I make a new savage-2-0-0-branch with the (for me) working 2D driver and kernel module? __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] thoughts about radeon_emit_clip_rect()
Interesting... could these be used in combination? perhaps to get around the 2048 limit? or if we were to implement the iterative zone approach, process serveral zones at once? I just requested r200 databooks from ati now that I'm a registered developer (got my fingers crossed). Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: ... Last but not least, as Keith pointed out a rather long while ago, at least the R200 engine (but the docs I have suggest this goes back to Rage128 even) has three more sets of scissor registers, has anyone played with those yet? __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Changing DRM IOCTLs to get FB and IO memory info
you might consider putting your project on freedesktop.org rather than sourceforge...at least for CVS. Alex --- Michael Dreesen [EMAIL PROTECTED] wrote: Do you have an ATI card? The ATI proprietary driver has pbuffers implemented. pbuffers would let you avoid a lot of the swapping. If you run out of room for pbuffers you could go back to swapping. I do have an ATI card, I'm developing on a mobility 9200 w/64MB ( also testing on nVidia Quadro). That's an interesting question. pbuffers weren't implemented for the nvidia card when I started last June, so I didn't consider them. Do you know how they're implemented? The question is what is faster, changing drawables for the pbuffer context or one call to glCopyTexSubImage, drawing one solid fill clearing rect (less costly than glClear()), and one textured polygon. FYI, you have to use the closed source drivers to get a high-performance glCopyTexSubImage. I've been running my implementation at 1920x1200 and it's quite fast. Would it be better to use xfs to cache the fonts? Not sure about that one. I'm going for a stand-alone system that can run on top of X (or any system with OpenGL conforming to POSIX standards for the IPC). The only thing I use X for is the toplevel window and device input. The application model for my system is similar to X, albeit simpler. I'm glad to see people are interested. That replacement for X I always hear about on /. could be just around the corner. I'll have to get my code up on sourceforge. Cheers, Mike __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RADEONWaitForIdleMMIO
that's the weirdest thing! I swear I remember seeing it defined, now I can't find it anywhere. Alex --- Jon Smirl [EMAIL PROTECTED] wrote: Can someone give me a clue as to where RADEONWaitForIdleMMIO is defined? I can't find it via grep, maybe a macro is building it. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RADEON_AGP_MAX_MODE
Didn't keith do some agp 8x work a while back? --- Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2003-11-08 at 18:32, Jon Smirl wrote: This is set to 4, should it be 8 now? #define RADEON_AGP_MAX_MODE 4 No, it means 'maximum AGP mode supported by the radeon driver', not 'maximum AGP mode available in the universe'. :) http://penguinppc.org/~daenzer/DRI/radeon-agp8x.diff is a patch by Hui Yu to add 8x support, but I'm not sure how (un)finished it is - what's with the TODO? __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] alan cox savage driver does not enable direct rendering on my computer
make sure you add the dri and glx modules under the modules section of your config file. It doesn't look like anything dri related is loading in the driver. Did you apply the latest code drop from alan or VIA to your xfree86 tree? you might want to try the code in the savage-2-0-0 branch of the DRI cvs tree. Alex --- Giustiniano [EMAIL PROTECTED] wrote: Hi :) I've used the patch of alan cox on kernel 2.4.22 and selected the S3 driver module from menuconfig: I've tried both to build it inside the kernel and to create it as a module, however, glxinfo says I've direct rendering disabled, even if lsmod displays the module savage as loaded. I use xfree 4.2.1.1. I attach the /var/log/XFree86.log, hoping it can be helpful __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Xv Gamma adjustment in the radeon driver
I recenly wrote a patch (with some help from Andreas) to a allow for gamma adjustment of the video overlay. It adds the XV_GAMMA attribute. The current patch works, but I'm not sure I'm programming the registers right. Could someone with databooks verify how they should be programmed? The relevant gamma table is in radeon_video.c. I asked ati about it, but I haven't heard anything back as of yet. I have a patch against DRI cvs here: http://www.botchco.com/alex/radeon/xv_and_gamma/gamma_v3.diff Also according to the source r100 chips can only adjust the lower four and upper 2 gamma registers (which I assume map to points on the gamma curve). r200 can adjust all 18. The current code adjusts all 18 no matter which core is being used. will this cause a problem? I haven't seen any problems yet with my test systsm (m6 and 9200), however, the radeon video code in mplayer sets up the default gamma curves for them (r100 vs. r200) separately. Any ideas are appreciated. Alex __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
--- Ville_Syrj�l� [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: Ville Syrj�l� wrote: I must say that I am very impressed with how far the MGA driver has come since you started working on it. Now the only thing that's missing is support for PCI cards. ;) A quick fix would be simply enabling PCI cards but keep the agpgart restriction. The only change required would be changing the access type to PCI in the DMA registers. I think it should work but I don't have a PCI card to test with so I can't be 100% sure. There was a webpage with code for G450 PCI support but the author seems to be incommunicato. I haven't really looked at the changes. I don't know how different it would be from g200 PCI cards. Log message: Fixed GL_NV_texture_rectangle support. Any idea how tough it will be (or if it's possible!) to add support for ARB_texture_non_power_of_two? Bascially, it just extends the regular texture modes to not require textures be a power of two. Mipmapping and all the wrap modes are still supported, and texture coordinates are still speicified as [0,1] (as opposed to [0,size] as in NV_texture_rectangle). I suspect the hardware won't support it. The G400 specs say that no mipmapping and clamp only. Which are exactly the same restrictions that NV_texture_rectangle specifies. You might be able to get the EXT_texture_rectangle, looks similar to the NV version. Log message: Texure environment updates: - Each texture unit has it's own environment color but we have only one FCOL register. - Move GL_BLEND handling to a separate function. - Remove unnecessary memcpy of TexState[0] to TexState[1]. The kernel will not upload tex1 unless a dualtex warp pipe is used. I see to recall that an older version of the DRM did not behave that way, and that's why the copy was there. That would have been a long time ago (more than 18 months), so I don't think we need to support that. However, the driver should refuse to load on that version of the DRM. Without looking back through logs and diff, I don't know what version that would have been. I don't think this is /that/ important, but it might bite somebody sometime, and when it does it will take one of us a long time to debug. I did look at the cvs logs and I think this stuff was there before XFree86 4.0. Isn't the pre 4.0 drm already incompatible with the current stuff? the breakage was between 4.0 and 4.1, so I wouldn't worry about anything older than 4.1. Alex __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] the state of Parhelia on FreeBSD
I doubt many developers are going to work on it because the rest of the drivers are closed source and few if any developers have parhelia hardware. you'd probably be best off trying to port it yourself. you can look at how the drm modules differ from linux to freebsd for other drivers (radeon, mga, etc.) and make the appropriate changes. Alex --- Mikhail Teterin [EMAIL PROTECTED] wrote: Hello! Matrox offers the sources for the Linux kernel part of mtx available. Has anyone looked into morphing those into the drm style, so an mtx.ko can be built on FreeBSD? It does not look like a big deal for someone, who knows the API already... Simply copying the mtx_drv.o into lib/modules/drivers is enough for the server to start, but, I suspect, some features are not available, because things aren't as fast as I'd expect and the x11perf's results are disappointing, compared even to a humble ``Rage 3D LT Pro AGP''. Last time this question was asked, Eric A. replied, that noone is looking into FreeBSD support for mtx, but that was a while ago... Thanks! -mi __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Planning to merge vtx-0-2-branch soon
Currently all my mergedfb work has been in the 2D driver, but I'd like to start working on some 3d stuff (time permitting). however, I don't have write access to the mesa tree. It's not real important at this point I guess, but eventually... Also isn't mesa hosted on sourceforge? will there be issues with cvs access (not that freedesktop is perfect)? will it all be in one mesa tree or will the DRI have it's own copy in our cvs? Just curious... Alex --- Keith Whitwell [EMAIL PROTECTED] wrote: OK, I'm planning to merge the vtx-0-2-branch to Mesa CVS trunk fairly shortly. At the moment, it is well tested with the X11 driver, and it compiles with the r200 driver from linux-solo. I'll make sure the r200 driver works properly before merging, but there are a lot of other drivers out there that will be affected by this in larger or smaller ways. The major changes are: - *Much* cleaner vertex handling in tnl module. - Display list compiler suitable for hardware-cached dlists. - Immediate mode code based on r200 vtxfmt code, and suitable for codegen optimizations. - Cleaner integration of VertexAttrib() and normal Color()/Normal() calls. There are a couple of downsides at the moment: - Use of floating point color everywhere has some performance issues. - The expected teething problems. In general, the bugs that I've had with this code have been very easy to track down and fix. I'm looking forward to getting it in as it clears up some of the nastiest code still in Mesa (authorship - mine...). I'm hoping that this will mark the start of doing the driver development in the Mesa tree. Can I ask everyone currently working on the DRI tree to check if they have Mesa CVS permissions if not email me and I'll work it out? Shortly I'll start a DRI branch to investigate building the dri tree with the drivers living under Extras/ with the rest of mesa. Keith __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] the state of Parhelia on FreeBSD
while it might be possible to add support for freebsd to the apparently opensource kernel module, adding support for unsupported cards to the 2D/3D drivers is impossible since it is a binary only driver! Ask matrox to add support. that's your only option right now. Alex --- Jan Eidtmann [EMAIL PROTECTED] wrote: ... So, support for three new cards in one mtx driver sounds just great, isnt it? *looks at DRI developers* PLEASE DO IT Jan -- Cannot find weapons or CIA Error Iraqi Explorer __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Another question on Fedora GL
I'd point you to the patches if I could remember when this last came up. If someone has time they might look through the dri-devel or dri-users archives. Does anyone on dri-devel remember this issue and what the fix was? glXGetProcAddressARB not being available. Alex --- Mike A. Harris [EMAIL PROTECTED] wrote: On Fri, 14 Nov 2003, Alex Deucher wrote: This was an issue with 4.3.0 as I recall. It was fixed in DRI cvs, I'm not sure if the fix has made it's way to fedora. I don't recall hearing about this issue before, so it probably isn't fixed in our packages unless it is fixed in XFree86's 4.3.0 stable branch xf-4_3-branch, as I track the branch. If someone out there is interested in seeing this fixed in a future Fedora Core XFree86 update digs the needed patches out and files a bug report in Red Hat bugzilla with patch attached, or sends them to XFree86.org to be included in xf-4_3-branch, I'd be glad to include them in an update though. Take care, TTYL --- Sergey V. Oudaltsov [EMAIL PROTECTED] wrote: Well, now all my GL libs look fine. But when I try to run Counter-Strike in OpenGL mode, I get this: err:opengl:wglGetProcAddress Warning : dynamic GL extension loading not supported by native GL library. On the web, I found this comment: This means that the glXGetProcAddressARB function seems not to be supported by your OpenGL library. But AFAIK Mesa libGL has this function. Any ideas why would it be lost in the battle by wine? Sorry if it not the right list to ask questions of that kind. In such case, private answers would be appreciated as well. -- Mike A. Harris ___ xfree86-list mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] radeon Xv alpha blending support
The attached patch adds alpha blending support to the video overlay on radeon hardware. It's been tested on my 9200. It adds three new Xv attributes: XV_ALPHA_MODE, XV_GR_ALPHA, and XV_OV_ALPHA. XV_ALPHA_MODE - (0 or 1) selects the alpha blending mode. right now it only supports key and global modes, per-pixel can be added later. 0 is key mode, 1 is global mode. Key mode blends the overlay or graphics layer with the colorkey. Global mode blends the graphics layer and the overlay. XV_GR_ALPHA - (0-255) set the alpha level of the graphics layer (everything but the overlay) (applies to either mode) XV_OV_ALPHA - (0-255) set the alpha level of the overlay (applies to either mode) The patch is against DRI cvs, but should apply pretty easily to any tree. I'm not 100% clear on the function the first two fields of OV0_KEY_CNTL, perhaps someone out there could explain it to me. see my comments in the code. let me know if you have any comments or questions. Is it worth opening a bug in bugzilla for this? The patch and binaries also are available here: http://www.botchco.com/alex/radeon/xv_alpha/ Look out for an improved Xv gamma patch soon. Thanks, Alex __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree radeon_xvalpha.diff Description: radeon_xvalpha.diff
[Dri-devel] Fwd: Your message to Dri-devel awaits moderator approval
Is anyone else having problems posting to the list? Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/---BeginMessage--- Your mail to 'Dri-devel' with the subject Re: [Dri-devel] Latest CVS in non-xinerama or dual screen mode. Is being held until the list moderator can review it for approval. The reason it is being held: Message has a suspicious header Either the message will get posted to the list, or you will receive notification of the moderator's decision.---End Message---
Re: [Dri-devel] Latest CVS in non-xinerama or dual screen mode.
Are you using mergedfb or not? It's unclear to me. if you are using mergedfb, what problems are you having exactly? if you enable the Xinerama extenstion, tht will disable the built in mergedfb xinerama extension. that might be part of the problem. Also what problems are you having with Xv? leftOf and rightOf describe crtc2's relation to crtc1. what do you mean by backwards? also for mergedfb to use modes they have to be listed in the screen section of your config. if you are looking for two separate heads (ie, host:0.0 and host:0.1) you can't use mergedfb. mergedfb only provides a single logical screen. Alex --- Mike Mestnik [EMAIL PROTECTED] wrote: This is a MFB problem, I think. I had just setup gamecon for my nintendo controlers and wanted a fullscreen experiance. I'm told I want [EMAIL PROTECTED] for the best view. I also want to be able to use my other head for normal things. I have a radeon8900. I hooked my Xconfig up with a good asortmant of modes I might use, from http://xtiming.sourceforge.net/cgi-bin/xtiming.pl. Mostly I use 'startx -- +xinerama -layout XiLayout', I will use MFB when it becomes stable. As it is now I have problems with XV and I don't want to bounce back and forth trying to debug them. My setup is LeftOf, but for this odd layout I thought it would be ok to try RightOf. AFAIKT This worked, albeit backwards. My plan was to run sawfish only on one display and just have the nes emulator deal withought any wm. When I tryied to run 'startx -- -layout TVideoLayout' I had 2 problems. The mouse moved off my primary head onto the secondary but then it was stuck there. The second is more of a driver problem than a MFB one. Most of the modes I had defined didn't take here is that info, and my question. Modeline [EMAIL PROTECTED] 10.45 240 272 288 320 256 261 264 269 doublescan Modeline [EMAIL PROTECTED] 9.58 256 288 304 336 224 228 231 236 doublescan Modeline [EMAIL PROTECTED] 11.00 256 288 304 336 256 261 264 269 doublescan Modeline [EMAIL PROTECTED] 10.21 320 352 368 400 200 204 206 211 doublescan Modeline [EMAIL PROTECTED] 12.37 320 352 368 400 240 245 248 253 doublescan Modeline [EMAIL PROTECTED] 18.96 400 432 464 496 300 306 309 316 doublescan Modeline [EMAIL PROTECTED] 30.76 512 544 600 632 384 392 396 404 doublescan (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) SNIP (**) RADEON(0): Default mode 512x384: 22.4 MHz, 35.5 kHz, 87.1 Hz (D) (II) RADEON(0): Modeline 512x384 22.45 512 516 604 632 384 384 388 409 interlace doublescan +hsync +vsync 512x384 worked(it's a builtin mode), do I have to use interlace with doublescan? __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Latest CVS in non-xinerama or dual screen mode.
actually several people on the xfree86 ML have reported the mouse going over to one screen and not coming back, so it may be a bug with the dualhead code. I haven't had time to look into it, and the last time I ran independant heads, I don't recall having that problem. Also, regarding your modes, they may require a lower dot clock than radeon supports. I don't recall what the minimum clock is off hand. there is a patch in xfree86 cvs that lets you force the clock lower, but YMMV and it may damage your hardware. Alex --- Mike Mestnik [EMAIL PROTECTED] wrote: I would like two separate heads. Not trying to use mergedfb or xinerama. It may be that this problem exists in Xfree86, I.E. not just a DRI CVS thing. Since I'm running DRI I just want to ask before I post to the Xfree lists. I have a LeftOf setup I'm using RightOf for this Layout, this makes things backwards. When use Xv from time to time it flakes ought and I can't realy tell if it's X, the app, or the file i'm trying to play. --- Alex Deucher [EMAIL PROTECTED] wrote: Are you using mergedfb or not? It's unclear to me. if you are using mergedfb, what problems are you having exactly? if you enable the Xinerama extenstion, tht will disable the built in mergedfb xinerama extension. that might be part of the problem. Also what problems are you having with Xv? leftOf and rightOf describe crtc2's relation to crtc1. what do you mean by backwards? also for mergedfb to use modes they have to be listed in the screen section of your config. if you are looking for two separate heads (ie, host:0.0 and host:0.1) you can't use mergedfb. mergedfb only provides a single logical screen. Alex --- Mike Mestnik [EMAIL PROTECTED] wrote: This is a MFB problem, I think. I had just setup gamecon for my nintendo controlers and wanted a fullscreen experiance. I'm told I want [EMAIL PROTECTED] for the best view. I also want to be able to use my other head for normal things. I have a radeon8900. I hooked my Xconfig up with a good asortmant of modes I might use, from http://xtiming.sourceforge.net/cgi-bin/xtiming.pl. Mostly I use 'startx -- +xinerama -layout XiLayout', I will use MFB when it becomes stable. As it is now I have problems with XV and I don't want to bounce back and forth trying to debug them. My setup is LeftOf, but for this odd layout I thought it would be ok to try RightOf. AFAIKT This worked, albeit backwards. My plan was to run sawfish only on one display and just have the nes emulator deal withought any wm. When I tryied to run 'startx -- -layout TVideoLayout' I had 2 problems. The mouse moved off my primary head onto the secondary but then it was stuck there. The second is more of a driver problem than a MFB one. Most of the modes I had defined didn't take here is that info, and my question. Modeline [EMAIL PROTECTED] 10.45 240 272 288 320 256 261 264 269 doublescan Modeline [EMAIL PROTECTED] 9.58 256 288 304 336 224 228 231 236 doublescan Modeline [EMAIL PROTECTED] 11.00 256 288 304 336 256 261 264 269 doublescan Modeline [EMAIL PROTECTED] 10.21 320 352 368 400 200 204 206 211 doublescan Modeline [EMAIL PROTECTED] 12.37 320 352 368 400 240 245 248 253 doublescan Modeline [EMAIL PROTECTED] 18.96 400 432 464 496 300 306 309 316 doublescan Modeline [EMAIL PROTECTED] 30.76 512 544 600 632 384 392 396 404 doublescan (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) (II) RADEON(0): Not using mode [EMAIL PROTECTED] (bad mode clock/interlace/doublescan) SNIP (**) RADEON(0): Default mode 512x384: 22.4 MHz, 35.5 kHz, 87.1 Hz (D) (II) RADEON(0): Modeline 512x384 22.45 512 516 604 632 384 384 388 409 interlace doublescan +hsync +vsync 512x384 worked(it's a builtin mode), do I have to use interlace with doublescan? __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email
Re: [Dri-devel] Re: [GATOS]Re: DRI and GATOS - how to get the best of both worlds?
daily binary snapshots are available here: http://dri.sourceforge.net/snapshots/ --- Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 22 Nov 2003, Michel [ISO-8859-1] Dänzer wrote: However, it appears that XFree86 is in feature freeze for 4.4.0 (since yesterday), which implies that I'll try to switch to 4.4.0 as soon as I get some free time. Note that this won't be in 4.4.0. Really ? We only need the DRM and DRI .so drivers. Are there some sort of packaged releases of DRI one can work against ? I don't mind installing from CVS myself, but if GATOS ati.2 source is against DRI tree I don't want to have to package binaries for the entire DRI tree. thank you ! Vladimir Dergachev __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] convert radeon_video.c to use the CP
The attached patch converts radeon_video.c to use the CP rather than MMIO if direct rendering is enabled. I wanted to get some feedback before committing to DRI cvs. I doubt this will affect overall performance much, but it will reduce the overhead involved in stalling the CP when switching between MMIO and the CP. Patch and binaries available here: http://www.botchco.com/alex/radeon/Xv/CP/ Comments? Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ radeon_video_cp.diff Description: radeon_video_cp.diff
[Dri-devel] Re: [PATCH] convert radeon_video.c to use the CP
I would never commit any thing non-trivial with out some validation
first. that's why I posted it here. Thanks for your comments.
Alex
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Mon, 2003-11-24 at 00:31, Alex Deucher wrote:
The attached patch converts radeon_video.c to use the CP rather
than
MMIO if direct rendering is enabled. I wanted to get some feedback
before committing to DRI cvs. I doubt this will affect overall
performance much, but it will reduce the overhead involved in
stalling
the CP when switching between MMIO and the CP.
I still don't really see the point, but I do see problems:
@@ -255,6 +260,11 @@
CARD32 dwOvGCb, dwOvGCr;
CARD32 dwOvBCb, dwOvBCr;
+#ifdef ACCEL_CP
+if (info-directRenderingEnabled)
+ RING_LOCALS;
+#endif
+
if (ref = 2)
return;
ACCEL_CP is only defined in radeon_accel.c for radeon_accelfuncs.c;
you
basically added commented out code, you'd have to use #ifdef XF86DRI
instead. I'm not sure using RING_LOCALS like this would even build
though, much less work as intended. I must say it's a bit worrying
that
you don't seem to give even the most basic testing (does it get
compiled
in at all?) to new code.
@@ -370,9 +400,20 @@
min = (r 16) | (g 8) | (b);
max = (0xff 24) | (r 16) | (g 8) | (b);
-RADEONWaitForFifo(pScrn, 2);
-OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_HIGH, max);
-OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_LOW, min);
+#ifdef ACCEL_CP
+if (info-directRenderingEnabled) {
+ BEGIN_RING(2);
+ OUT_RING_REG(RADEON_OV0_GRAPHICS_KEY_CLR_HIGH, max);
+ OUT_RING_REG(RADEON_OV0_GRAPHICS_KEY_CLR_LOW, min);
+ ADVANCE_RING();
+} else {
+#endif
+ RADEONWaitForFifo(pScrn, 2);
+ OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_HIGH, max);
+ OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_LOW, min);
+#ifdef ACCEL_CP
+}
+#endif
}
void
OUT_RING_REG() writes two words to the ring, so BEGIN_RING() needs
twice
the number of register writes as an argument.
@@ -981,14 +1085,26 @@
left = (left 16) 7;
-RADEONWaitForFifo(pScrn, 2);
-OUTREG(RADEON_OV0_REG_LOAD_CNTL, 1);
-if (info-accelOn) info-accel-Sync(pScrn);
-while(!(INREG(RADEON_OV0_REG_LOAD_CNTL) (1 3)));
-
-RADEONWaitForFifo(pScrn, 14);
-OUTREG(RADEON_OV0_H_INC, h_inc | ((h_inc 1) 16));
-OUTREG(RADEON_OV0_STEP_BY, step_by | (step_by 8));
+#ifdef ACCEL_CP
+if (info-directRenderingEnabled) {
+ BEGIN_RING(3);
+ OUT_RING_REG(RADEON_OV0_REG_LOAD_CNTL, 1);
+ OUT_RING_REG(RADEON_OV0_H_INC, h_inc | ((h_inc 1)
16));
+ OUT_RING_REG(RADEON_OV0_STEP_BY, step_by | (step_by 8));
+ ADVANCE_RING();
+} else {
+#endif
+ RADEONWaitForFifo(pScrn, 2);
+ OUTREG(RADEON_OV0_REG_LOAD_CNTL, 1);
+ if (info-accelOn) info-accel-Sync(pScrn);
+ while(!(INREG(RADEON_OV0_REG_LOAD_CNTL) (1 3)));
+
+ RADEONWaitForFifo(pScrn, 14);
+ OUTREG(RADEON_OV0_H_INC, h_inc | ((h_inc 1) 16));
+ OUTREG(RADEON_OV0_STEP_BY, step_by | (step_by 8));
+#ifdef ACCEL_CP
+}
+#endif
x_off = 8;
y_off = 0;
I'm not sure you can just get rid of the register read like this, I
think it's there to make sure that double buffering works correctly.
Even ignoring these problems, it's kind of ugly in this form; some
kind
of unification scheme like in radeon_accelfuncs.c would be better. So
it's back to the drawing board I'm afraid.
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI API
--- Chris Ison [EMAIL PROTECTED] wrote: I know you can't give details under NDA, but do the specs for the r200 show any API for PCI, or has the PCI work on the driver been done by trial and error. I'll have to check the docs when I get home. The original PCI GART work does done for HP for radeon support on Alpha. At the time it was just for regular radeons. Michel did some re-arranging fairly recently to unify the gart code between PCI and AGP. Also I am wondering if there is any word on specs for r250 and r300. If not, I would like to know what the best supported card is in DRI with the least software implemented GL. I assume you are talking about r350. the r250 is just a variation of the r200 core and docs are available for that. no 3D databooks are available yet for r300 to my understanding. I don't know if that will change in the future or not. I'd say the best supported cards are r200 based radeons (8500 to 9200 cards). Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI API
Your best bet, if you can find one, is a fireGL 8800. It's basically an overclocked 8500. barring that the 8500's and 9100's are the next fastest. Alex --- Torgeir Veimo [EMAIL PROTECTED] wrote: On Fri, 2003-11-28 at 07:37, Alex Deucher wrote: I'd say the best supported cards are r200 based radeons (8500 to 9200 cards). And which one is the fastest? -- Torgeir Veimo [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MergedFB question.
the 2048 limitation of the scissor registers can be worked around. check the dri-devel archives for messages with 2048 in the subject. basically what we need to do is look at the cliprects in the client driver and everytime they are a multiple of 2048 divide into a zone. then when you are rendering iterate over those zones. I've looked into it, but I haven't had the time dig into the DRI driver enough to fully understand how the current code works and then how best to implement this on top of it. Someday... Anyone can submit a patch if they get to it first :) Also you can run an desktop of 2560x1024 with the option no2048limit (I should just remove that option and just start the xserver with DRI anyway...) and 3D will work fine up to 2048. if you extend beyond 2048, then window just goes blank. Also you can specify metamodes and switch the resolution of both crtcs on the fly. also if you specify clone modes in your metamodes, you can run your desktop at 2560x1024 and then when you start a game it will select one of the clone modes using the vidmode extension and then your game will run fine in 1024x768 or 1280x1024 on both heads. really the only time you will have a problem is if you try and run a 3D window that is larger than 2048; anything smaller works fine. Alex --- Mike Mestnik [EMAIL PROTECTED] wrote: Not at this time, however the work around I have been using is setting up more than one layout in my XF86Config. Then I write scripts for common apps/tasks that call the right xSession and layout. I had a dream that apps would be free from persecution of color depth and of screen/root number/size. That one day layouts could be change on the fly and apps could roam freely from server to server. I'm prepared for X11R7 or X12 if thats what it takes. --- Adam K Kirchhoff [EMAIL PROTECTED] wrote: I'm curious if MergedFB can be modified so that you can run with a resolution of 2560x1024 normally, and then drop it down to 2048x768 if you want to do anything 3D related? Adam __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fealing ought the Merged FB.
--- Mike Mestnik [EMAIL PROTECTED] wrote: I attached my log and config, just incase. This is a short list of the things I have found odd with DRI. 1. Screen size and DPI, I never understood how this was going to work with dual heads. 2. A bug that won't let me use 256x240 in MFB, workes great in xineramia. 1: The screen size(in pixels or mm) is now x1 + x2 by (y1 y2) * y1 + (y1 y2) * y2. Swap (y and x) and (1 and 2) where needed. Then the DPI should be calculated using the largest or the default metamode. This is what I see. (**) RADEON(0): MergedFB: Display dimensions: (330, 240) mm (**) RADEON(0): MergedFB: DPI set to (255, 152) ?255? Oviously wrong! Xfree86 doesn't really have a way of setting different DPI values for each head in a single logical screen scenario like xinerama or mergedfb. what xinerama does is kind of take an average of DPI values from each head. mergedfb works similarly. it tries to get the values from DDC and barring that, it attempts to calculate a sane base. it works in most instances. however if you are not getting the value you want, you can specify it as an option option MergedDPI 100,100 for example... You can see how it gets calulated in radeon_mergedfb.c: RADEONMergedFBSetDpi(). if you find anything that looks off let me know, however I haven't had any problems with it and I don't see anything off hand that looks off. 2: I just can't get 256x240 and 1400x1050 to 1656x1050, it skips it and uses the next one 1024x768 and 1024x768 to 1024x768 (Clone). I have no idea what is going on here, nothing is left ought of the log. I have set pll-min_pll_freq = 3000 and that got it working for xineramia. If you want to use a special 256x240 mode ([EMAIL PROTECTED] for example) then you need to specify that mode name in your metamodes and the modes sub-section of your screen config as well as defining the modeline. eg: SubSection Display Depth 16 Virtual 3320 1440 Modes 1920x1440 # 1856x1392 # 1792x1344 1600x1200 1400x1050 1280x1024 # 1280x960 # 1152x864 1024x768 800x600 640x480 320x240 [EMAIL PROTECTED] ^^ add this! this is because the metamodes draw from the modes listed in the screen section of your config. also you may have to specify a different crtc2 hsync/vrefresh range for your custom modes since it seems to be too high for your mode: (II) RADEON(0): Not using mode [EMAIL PROTECTED] (vrefresh out of range) Also if you want to use the DRI, you will need to add option no2048limit true to your config otherwise the DRI is disabled the current 3d client code only supports 3D up to 2048x2048: (WW) RADEON(0): Direct Rendering Disabled -- Virtual resolution exceeds 2048 (hardware limitation) you can enable it with larger modes, but it will only owrk up to 2048. beyond that you will get an empty window. Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XGI Volari driver development
XGI is a joint venture from the trident and sis people. Sis has released zero documentation in the past. trident is somewhat better. As far as I know XGI has not released any databooks for these chips. they may be developing drivers in house. whether they will be opensource or binary (or developed at all) remains to be seen. for 2D the chips may work with the exisiting sis or trident drivers. if you are inclined to develop a driver you can ask them and see what they say. unfortunately unless they contract with a DRI developer, I doubt much will happen with regard to a new driver since there are already limited opensource developers furhter limited by lack of time and resources. we'll see though... Alex --- Goyo Roth [EMAIL PROTECTED] wrote: Is anyone working on a driver for the new XGI Volari? I've heard speculation about XGI's reluctance to cooperate with the Linux community, but has anyone actually tried? Goyo __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
