Directfb Xorg server

[Mike Emmel]

On 5/30/06, Adam Jackson <ajax at nwnk.net> wrote:
> On Sunday 28 May 2006 23:00, Mike Emmel wrote:
> > XF86VidMode
> > I don't need this X has no control of the screen or display depths in
> > this implementation its strictly a network window manager in rootless
> > mode it should not be mucking with any video settings.
> >
> > XF86Misc
> > Same X does not control the hardware and has no access
>
> These extensions are only ever built for the xfree86 DDX.  The code for them
> won't even get linked into the other DDXes:
>
> ~/xserver/xorg% nm hw/vfb/Xvfb | grep VidModeExtensionInit
> ~/xserver/xorg% nm hw/xfree86/Xorg | grep VidModeExtensionInit
> 080ba5f0 T VidModeExtensionInit
>
> > Composite
> > External composite managers are not supported
>
> That's fine; do like the other DDXes and don't enable it.  It's not on by
> default, and even when we switch it on by default for the xfree86 DDX we
> certainly won't be able to enable it for Xnest and Xdmx for a while yet.
>

Okay now I'm not clear what the offending change is I thought you
wanted me to support it.

> The goal here is to be _capable_ of building every DDX at once.  You can
> always choose to build fewer, or build them in multiple passes with different
> options for each (kdrive has no need for Xinerama, eg) but reducing the
> number of compile-time conditionals is an explicit goal for us.
>
> > there is no reason in a
> > rootless implementation to support composite managers
>
> I strongly disagree.  Think OSX.
>
I'm all for a composite manager just not a X11.
Directfb is a composite manager thats basically all it does.
Let me get the directfb one done then I'll reconsider the interaction problem.


> > composite operations like window alpha
> > are supported internally via the directfb api's. Since directfb
> > modifies the window alpha according to its own algorithm its
> > impossible to correctly support composite in the rootless case with
> > windows thate are already being managed by the directfb window
> > manager.
> >
> > Note external X11 windowmanagers are not  supported either.
>
> This seems like a design failing in the dfb DDX then, the darwin DDX manages
> this just fine.
>
Nope its done on purpose. Its one of the best features of the port.
Instead the approach is a builtin wm that can be loaded as a shared lib.
So far in reworking metacity this approach is massively simplyfing the wm.
The fact that its synchronous makes it a lot easier.



> > The goal of this server is to support X11 applications integrated with
> > the native apps not server extensions that interfere with the native
> > window manager.
>
> Again, quartz-wm is a mixed-mode app, this is completely doable.
>

And I'm sure someone else who is intrested can take the code base and use it
to add support. And I'll prob do it a bit later after I get the new
approach done.


> > WindowManager
> > As I noted earlier traditional X11 window managers are no longer
> > supported in this server.
> > I think you haven't realized that I'm sure it will raise some eyebrows.
>
> I'm not philosophically opposed to this, but are you doing this for deep
> reasons, or are you doing it because you can?
>
> > The new window manager is based on metacity and will manage both
> > native directfb windows and x11 windows. Basically I'm spliting
> > metacity in half moving all the X11 specific code into the server  and
> >  porting metacity to directfb. The directfb wm will then interface
> > with the x11 side via  a api. This is one of the big reasons I needed
> > to be a shared lib since I'm actually loading the X11 server into the
> > directfb wm which itself is a shared lib.
>
> I don't see what problem this solves.
>
The directfb wm and X11 wm are the same.

> > > I'm not sure what the changes to dix/window.c and dix/dispatch.c are
> > > intended to do, but they certainly look intentional.  Can you clarify
> > > them?
> >
> > CreateWindow returns before registering the window  in CreateRoot its
> > done the way I did it. This was one of the changes needed to allow a
> > traditional client to be builtinto the window server in my case the
> > window manager clipboard and composite manager etc will end up being
> > builtin. I'm doing some pretty radical stuff with the changes but I
> > think having for example the composite manager builtin could be a
> > performance boost esp if you want to use the 3D hardware.
>
> I'd prefer to see numbers before believing that.  I've had no trouble keeping
> the GPU saturated with the current split-process WM model.
>
I said could its by far not the important point and in our case it
also related to the rootless
directfb design and access to hardware. Maybe to be clearer for the
directfb port this could be faster.

The important thing is the changes in dix are a must have for my
approach and don't effect other ports.



> > I hope we can figure out a way for me to build my server on the same
> > code base with no patches you may not agree with it but I've done
> > nothing that requires me to fork the code if your willing to make some
> > changes that won't impact the main implementation.
>
> I think integrating the dfb ddx is possible without requiring yet more N-way
> compilation of the DIX.  This really is important to get right.
>
> You may be right that main() should be a DDX-side function though.  I'll think
> about it.
>
Thanks that would really help me.

To clarify a bit whats going on here. The core api is Directfb the
desktop is directfb.
At the same time we want to support X11 user applications not X11 wm
or composite managers etc just plain olde apps. If composite managers
are used inside a application window to manage its children that
something I can prob support I think thats the approach that OSX
supports let me think about it. The bigger problem in a sense is there
is no good approach to telling X11 about external windows that may
exist i.e register a directfb window with the xserver I've thought
about this but making every dfb window a x11 window seems overkill.

Thanks


Mike



> - ajax
>
>
>