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