--- Mike Mestnik <[EMAIL PROTECTED]> wrote: > > --- Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote: > > > Thank you for your informative reply. > > > > > > --- Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > > > > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote: > > > > > > > > > > The problem I have is that my settup is lopsided, one monitor > has > > > > > better > > > > > modes than the other. The *larger* monitor is on the right, > thus > > > > > making > > > > > it the secondary for GL applications. > > > > > > > > If you'd prefer it be on the left, you can always switch the > > > > orientation of the crtcs. in my set up, crtc2 is left of > crtc1. > > > the > > > > orientation of the crtcs doesn't really matter. > > > > > > > xv then becomes a problem. Right now I have it so (g)mplayer > uses my > > > primary head(0), there dose not appere to be a config option for > what > > > monitor is used when going FS. > > > > The radeon overlay can be displayed on either head and the driver > > provides a pseudo-xinerama extension. if the video app is xinerama > > aware it will do the right thing depending on which head the app is > on. > > xine and tvtime work fine for me. I can go full screen on either > > head. The only limitation is that there is only one overlay so you > can > > only use it on one head or the other. > > > I have not this experiance. The right(0) head is allways where > fullscreen > goes. I'm using gmplayer-k7 from debian sid. The pseudo-xinerama > workes > perfectly and it correctly filles this display. Could it be that my > left(1) display is smaller and/or has a scrolling viewport?
I doubt it. perhaps a gmplayer bug? I have a dualhead mode with a different mode on each head (1280x1024 and 1024x768). whichever head more of the output window is in gets FS which I switch to FS mode. > > > > > > > > > > > > > > Another fix would be to make the center be zero and every > thing > > > > > left(negitive singed) of that being larger(unsigned) then > that on > > > the > > > > > right. What is needed is to run full-screen apps (1600x1200) > on > > > the > > > > > right > > > > > side with (1400x1050) only partaly(1600 - 2047 + 1400 = 953 > > > unused > > > > > columns) being used for hardware GL. This solution althought > > > more > > > > > correct > > > > > is more tedious. > > > > > > > > This isn't really feasible from the 2d drivers perspective. > you > > > could > > > > move the start of the 3d viewport over so that its "0" would be > on > > > the > > > > right half of the framebuffer. > > > > > > > This is what I think I was getting at. Can I move the 3d > viewport > > > during > > > runtime? Wait I think you covered this, It would be nice if it > would > > > move > > > like a normale viewport based on 3d client location as a first > step. > > > > that's sort of how the fix to the 3d driver would work. However, > you > > would want it to cover the whole front buffer because you could > > theoretically render to any part of it. why move it around when > you > > could just iterate across the whole desktop? > > > It sounds to me like iterate would be another step, for both CPUs. I > say > avoid it since it's easy todo so. yes, it would be another step, but how else could you enable 3d across the entire desktop? I suppose you could have each app contend for the 3d engine, and then move the 3d viewport to which ever app had access at the time. however, I'm not sure the 3d engine could work that way. > > > > > > > > > > > > > > Is any one interested in seeing this goin? > > > > > > > > If you are going to go through that effort, you might as well > just > > > > solve the problem for real and have the 3d driver just iterate > over > > > > each block of 2048x2048. see the dri-devel archives: "2048 > limit > > > code" > > > > > > > This then would be step 2? > > > > > > My only other question is where would this code live, hopefully > not > > > the 2d > > > X driver? > > > > You wouldn't need a step one. It would all be handled in the 3d > > driver. The limitation is in the clipping registers. > > > > http://marc.theaimsgroup.com/?l=dri-devel&m=106727717303407&w=2 > > > Thank you for the pointer. > > > > > > > > Alex > > > > > > > > > > > > > __________________________________ Do you Yahoo!? Yahoo! Domains – Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
