Re: XFree86 5.0 TODO

On Fri, Mar 21, 2003 at 04:21:09PM +0100, Egbert Eich wrote:
> The configuration file should be made optional having reasonable
> defaults allowing for setting things at runtime.
> However  I don't think these plans are concrete yet.

Ok, ...

>  > BTW, do your work have anything in common with the DRI configurator
>  > project ?
> 
> No.

There can be no common work between both ? i guess that the DRI
configurator essentially is for speaking to the client side opengl
library, not the X driver.

>  > We are thinking about using a common framebuffer for both heads.
>  > This mean that both heads would have the same x/y space for both heads,
>  > if the chip supports it (it does for me, and will probably for future
>  > chips). But then, i am not (yet) familiar with Xinerama.
> 
> Xinerama only becomes an issue when you want to pass the screen
> coordinates of the window from the application to the driver.
> The application gets the coordinates relatively to the origin
> of the entire screen - not the specific display it is on.
> So you'd have to do some calculation in the application.
> The application should get enough information from the server
> to do this  calculation.

Ah, but only in the true Xinerama case, not in the dual-head, same
entity, shared framebuffer case, where the driver also has coordinates
relative to the origin of the screen (framebuffer).

>  > > This should work too with what I propose. Your application just
>  > > whould have to query for a certain attribute that is hopefully
>  > > registered.
>  > > A generic interface that is not aware of the nature of this attribute
>  > > would just give you slider elements for (x,y,w,h) so you can set
>  > > your coordinates by hand. A little clumbsy but it should work.
>  > 
>  > But would it be sane to do so ? The configurator app needs to know the
>  > window id (as used by the server). The user would designate it by
>  > cliking on a window or something such, same as when we kill a window or
>  > something such, and then the server code moving the window would have a
>  > callback or something that would call, if supported, an XAA accel hook
>  > which set the viewport. We can even simply use AdjustFrame for this,
>  > with a bit of extension or something such. Adjust Frame is mostly only a
>  > few register calls so it would be quite fast. 
> 
> No, the model I have in mind is not window driven. The driver only
> gets the information to zoom a part of the screen. It doesn't care
> what is displayed there. Your application has the notion of a window.

What application are you speaking of here ? The window manager ? The
specific app that own the window ? The configurator app ? A special
zooming app ?

> It has to do the proper things if this window is enlarged, obscured,
> closed.

Mmm, what would be the behavior here in case the window is partially
hidden ? With the technical solution i propose, the second head would
simply be a viewport into the framebuffer of the first head, so there
would be no way it could un-hide the window content.

> I wouldn't involve XAA in this. If you want to do it on the
> driver level you'd have to wrap some of the window functions. In this
> case you could pass in the WID, that would probably work, too.

Sounds good, i would have to look into that too when i get time.

Friendly,

Sven Luther