--- 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?
> > > > > > > > > > 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. > > > > > > > > > > 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 __________________________________ 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
