Re: XFree86 5.0 TODO

Egbert Eich <[email protected]>
Newsgroups gmane.comp.xfree86.forum
Message-ID <[email protected]>
Sven Luther writes:
 > On Fri, Mar 21, 2003 at 10:38:03AM +0100, Egbert Eich wrote:
 > > Sven Luther writes:
 > >  > 
 > >  > BTW, how would these attributes be compatible with the config file
 > >  > option ? Could it be possible to set them in the config file, or is it
 > >  > unecessary as 5.0 will have no control file whatsoever and this is going
 > >  > to replace it ?
 > >  > 
 > > If it makes sense to set these attributes in the config file we should
 > > definitely have a way to allow to set initial values in a config file.
 > > The fate of the config file is not decided - however I expect it will 
 > > be a lot less mandatory.
 > 
 > But you would still need it to set things like resolution and such, no ?
 > 
 > Or maybe will your attribute querying system replace it ? I agree that
 > the configuration file should go away, but something should replace it,
 > at least for some basic information (what video card to use, use both
 > heads or only one, what depth, ...) at least for the first launch. A
 > configuration tool can take over after that, and the information
 > provided should be easily writable by the configuration tool.

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.

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

No.

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

 > 
 > > 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.
It has to do the proper things if this window is enlarged, obscured,
closed. 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.

 > 
 > But then, i am really not all that familiar with X outside of the driver
 > stuff, if i get a bit of free time i will try to look at this more.
 > 

OK.

Egbert.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.