Directfb Xorg server

[Adam Jackson]

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.

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.

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

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

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

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

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060530/dbbf1c9e/attachment.pgp>