On Wed, Feb 26, 2003 at 09:40:18AM -0800, Linus Torvalds wrote:
>
> On Wed, 26 Feb 2003, Sven Luther wrote:
> >
> > Yes, and you have to divide the fb memory in two, one for each head, or
> > something such, and each head will have its separate offscreen memory
> > manager, possibly using different screen strides.
>
> Side note: I know that what people are mostly talking about is having two
> separate displays with different contents, but please, if you're thinking
> about this, try to make the solution generic enough that you can have two
> separate displays with the _same_ backing store content at different
> resolutions and different pointers.
Yes, this was the spirit of the proposal, see below for details. You
cannot have different depth modes though.
> Yeah, not all chips support this, but many do (and probably all that
> support multiview support this subset), and it's invaluable for having
> laptops that have small LCD's. In particular, it should be possible to
> have the pointer associated with the LCD, and scroll around on the LCD
> while the CRT output (ie usually a projector) shows the whole picture
> (obviously without scrolling or without any pointer).
See below.
> Right now, as far as I can tell, XFree86 can not do this sanely. You can
> have two separate X servers for the different outputs, or you can have the
> exact _same_ output on both CRT controllers, but you can't make the two
> displays look like "separate windows into the same area".
Well, XFree86 Does not do it, and there is no way you can configure it,
but the drivers can be made to handle such things, even dynamically i
think. After all at least the matrox proprietary driver, and i hear the
nvidia one does already.
> And it really sounds like the DRI dual-head is not that conceptually
> different from this. The only issue is whether you share the frame buffer
> or not.
Yes, because the DRI is just rendering to the framebuffer, it doesn't
know if you are displaying it or not, and doesn't even care. The only
issue is with size limits of the 3D engine, like Michel said, with the
Radeon 3D engine being limited to 2Kx2K, which would mean a maximum
resolution of 1024x768 or 1280x1024 if you stapple the screen
vertically. I don't know the radeon specs, but i guess it should be
possible to work around this by changin the base address, at least in
the vertical stapling case, in the horizontal case, screen stride may
become a problem.
> So you have several cases:
> - shared framebuffer, shared CRT control
> - shared framebuffer, but separate CRT control (and "mouse focus" or
> whatnot)
Mmm, didn't think about mouse focus.
> - separate framebuffers, and separate CRT control (and "mouse focus")
That is the traditional dual head, where the separate displayes can
later be joined via Xinerama.
> Is this what you call "mirrored viewports"?
Yes, sort of.
o you can have the traditional dualhead, with two separate
framebuffers each with only one viewport. This is what is currently
used, and the only way to do dualhead with two single head graphic
boards.
o you can have shared framebuffer dual head, with two viewports on the
same framebuffer, this is what was shown in the original diagram.
o then you can choose to have one viewport be a mirror of the second.
I believe most dual head cards boot into such modes. If one screen
as a bigger resolution than the other (1024x768 LCD screen and
800x600 video projector for example), then one of the modes (usually
the bigger one) can be set to be a zoomed version of the other, if
your hardware supports this.
o finally you can have zoomed viewports, when one is the main
viewport, and the second show a zoomed version of a windows (or
subset) of the other. I think in the matrox window driver this can
be set dynamically, where you select a window, and it get zoomed on
the second head. I don't know, but i suppose that the second display
follows, even if the window is redimensioned or something such.
The first is the current situation and cannot be emulated by the others,
but i think a more flexible framework could englobe all three others.
Basically, you would specify the framebuffer size, and the corresponding
viewports for each head separatedly and independently.
Also dynamic changing of viewports could be done by an extension of the
RandR extension maybe, which already does something such for resolution
swapping, but i did not look at it yet.
This would still only be somewhat hacky right now, but could be nicely
formalized for 5.0.
Was this what you had in mind, or do you need some other functionality.
Friendly,
Sven Luther
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
