[Xcb] XCB/AIGLX Matchbox/GTK

[Matthew Allum]

Hi;

If you are serious about porting matchbox-window-manager to use XCB,
you should look at the beginnings of matchbox-window-manager-2 ( in
matchbox SVN ). I initially started coding that with purely XCB but
then fell back to xlib ( XCB was missing some functionality I needed
at the time - error trapping I think ). The plan was then to use the
nice stuff async stuff in XCB if running atop an xcb based xlib if not
do the same kind of thing not so nicely with Xlibint.h. This is
abstracted out though - it would be pretty easy to add the XCB bits
and make it a compile time option.

  -- Matthew



On 11/2/06, Josh Triplett <josh at freedesktop.org> wrote:
> Guillaume FORTAINE wrote:
> > Hello,
> >
> >  I am French Engineer in Informatics and I would want to build a start
> >  up to  manufacture mobile phones ( OEM level ). I am currently in discussion
> > with investors.
> >
> > We would want to port Matchbox to use AIGLX and XCB..
> >
> > http://projects.o-hand.com/matchbox/
>
> Note that a program does not need to do any specific porting to AIGLX; a
> program designed to use GLX will run with or without AIGLX.
>
> As far as I can tell, matchbox does not currently use OpenGL at all.  What
> exactly do you want to use OpenGL to do?  Compositing effects, transitions,
> and (possibly functional) eye candy?  It looks like matchbox has a structure
> conducive to porting, which would probably make it relatively straightforward
> to port to GLX.  However, depending on what you want, you may achieve a better
> result by implementing the desired effects directly.
>
> On the other hand, porting Matchbox to XCB seems relatively straightforward,
> as it already has a straight Xlib port.
>
> > And GTK to use XCB.
>
> Several people have worked on that at different times; the general consensus
> seems to point to this task just needing some simple programming effort thrown
> at it.
>
> Do you actually want GTK+-on-XCB for this, or just as a vehicle for porting
> Matchbox via the GTK+ port?  You may just want a straight XCB port, similar to
> Matchbox's existing Xlib port.
>
> > And we would want to use this platform :
> >
> > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX27&nodeId=
> > 0162468rH311432973ZrDR
>
> You will likely want to figure out if an X driver already exists to make use
> of the video hardware on this system, and if not, you may want to get someone
> to write one, rather than just using it as a plain framebuffer.  For example,
> it looks like this hardware has accelerated MPEG* video support, which may
> help in this area, such as to implement the XVideo extension (the ivtvdev
> driver does this, for example); alternatively, if you want to offload this
> type of video processing entirely, you may need to bypass the X server for
> videos, or come up with some X extension (probably in conjunction with XVideo)
> to offload full MPEG* decoding and display.
>
> > How we will be able to use OpenGL without a GPU ? ( someone from the XeGL
> >  team told me that it was possible to use compiz without hardware accelerated
> >  OpenGL )
>
> Previously (before AIGLX), on systems with hardware-accelerated OpenGL,
> applications had to use direct rendering (bypassing the X protocol) to take
> advantage of hardware acceleration.  AIGLX (Accelerated Indirect GLX), as the
> name suggests, adds the ability for the X server to use hardware acceleration
> for indirect rendering, meaning that OpenGL calls can pass through the X
> protocol but end up going through hardware OpenGL acceleration rather than
> Mesa's software implementation of OpenGL.  However, if you don't have hardware
> acceleration, this becomes moot, because no hardware acceleration exists for
> AIGLX to take advantage of, so you end up with ordinary indirect GLX rendered
> via software.
>
> A software implementation of OpenGL may not actually have a performance
> problem with some applications, depending on what you want to do with it and
> how well the software implementation you choose can perform on your chosen
> hardware.
>
> (Also, note that compiz provides the functionality of a window manager itself;
> do you mean that you want to add compiz-like effects to Matchbox?)
>
> > How many people/much time ( full-time developers) are/is needed to success in
> > this enterprise ?
> >
> > What is the best background they need to have to work on this ? ( C, Xserver,
> > Linux ? )
> >
> > ( we need these informations for our partners ).
>
> The answers to these two questions would depend greatly on which of the above
> ports you actually end up wanting or needing.
>
> A port of Matchbox from Xlib to XCB would probably take the least time; I
> don't have a good concept of the size of the Matchbox codebase, but I suspect
> that someone with a good background in C and in programming X clients could
> likely make a port in a couple of full-time weeks, including time to get
> familiar with the Matchbox codebase, and that includes some overestimation to
> account the possibility of adding support to XCB for an additional X
> extension, or for adding a new utility library to supply a replacement for
> non-protocol-related Xlib functionality.
>
> A port of GTK+ to XCB, if you end up needing it, would likely require somewhat
> more time, due to the size of the GTK+ codebase and potential dependencies on
> other libraries.  If I had to guess, I'd (over)estimate this one at a couple
> of person-months, accounting for the same uncertainties given above for
> Matchbox.
>
> Adding OpenGL functionality to Matchbox would depend on what kinds of things
> you want to add.  This task would require finishing up the Mesa port to XCB
> (unless you want to port some other software implementation of GL to XCB), and
> for a time estimate on that, I'd suggest asking Jeremy Kolb, who actively
> develops and maintains that port.  Meanwhile, adding various OpenGL effects to
> Matchbox would require minimal time for anyone experienced in the use of
> OpenGL.
>
> > We look forward to your answer,
>
> Hope that helps,
>
> - Josh Triplett
>
>
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
>
>