--- Mike Mestnik <[EMAIL PROTECTED]> wrote: > Thank you for your informative reply. > > --- Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote: > > > I'm currently unable to define a clone mode where one screen is > > > smaller > > > then the other. My thoughts are "1024x768_1024x768" == > "1024x768" vs > > > "1024x768-1024x768". > > > > You can, but you can't mix and match multi-sized clone modes with > > multi-sized dualhead modes. I was thinking of doing something > like: > What do you mean here? multi-sized dualhead is not realy posible at > all, > the viewports are merged, joined at the hip.
what I mean is multi-head with 2 different modes. for instance a leftof and a clone mode with 1024x768 on one head and 800x600 on the other. The hardware supports it, but you can't configure it at the moment. > > It might be nice, if you had more then one pointer or something? > > > option "metamodes" "1024x768-800x600-clone 1024x768-800x600-left" > > adding the orientation to the metamode and then removing the > > orientation option. they problem is you then need to add checks to > > make sure you have enough framebuffer for all of the modes listed > and > > you might end up with some huge or weirdly sized virtual desktops. > > PLus it just adds to the confusion. I also wanted to keep > consistency > > with other mergedfb drivers. > > > I would find it vary distracting. I'l referance x2x style east and > west > ect. If I needed west, but used east of north for that matter. So > to > switch I'd also need to swap VGA cables. > The real solution would be dynamic runtime re-configuration. maybe something like Xv attributes, but for modes instead of the overlay. > > > > > > 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. > > > > > > > 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? > > > > > > > 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 > > > 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
