Re: Switching g-i from DirectFB to X11 -- general reflections
On Monday 08 February 2010, Cyril Brulebois wrote:
> this is a summary of the needed steps to switch from DirectFB to X11.
> After some time hacking in the wild, I then looked into providing
> (possibly) clean patches for each package, which I've just finished.
Sorry for the delay in replying. Things kept coming up that prevented me
sitting down and writing things up.
I'll split my reply over several mails to hopefully keep any following
discussions more separate. This is the only reply I'll cross-post. My more
detailed replies will be sent only to d-boot; I'll leave it up to Cyril or
Julien to take back things to the X.Org or Gnome lists if they feel it
needs wider discussion. I'll try to provide some background in my replies
for some issues.
Note that anything in my replies is nothing more than my personal current
take on the proposal and patches. As far as I'm concerned everything is
open for discussion. I'm no expert on X.Org or libraries, so please
correct any mistakes.
A small correction on Josselin's original blog post. Losing G-I does *not*
mean losing support for RTL languages. Both Hebrew and Arabic are
supported in the newt frontend, with proper RTL display.
As I've said before I'm very impressed with how the X.Org-bases graphical
installer currently works. Cyril and all others who've contributed to that
deserve huge thanks.
General reflections on DirectFB versus X.Org for D-I
The DirectFB and the X.Org solutions both have positive and negative
The DirectFB implementation has been remarkably stable and reliable for
both Etch and Lenny and there have been no real issues with it on any x86
hardware. But the lack of upstream support, both for directfb itself and
its integration in cairo and gtk, is a real problem and is the direct
cause for the current situation.
We've had excellent help from various people getting DirectFB working for
D-I, but unfortunately the D-I team no longer has (and has never really
had) anyone willing to fill that gap in upstream support.
So what are, from my PoV, the main characteristics of both?
+ relatively simple and lightweight solution
+ requires only a few (additional) source packages to provide udebs
- has proven to be more difficult to port than initially expected (but
that's mostly due to lack of development)
- Debian is only user of cairo and gtk integration
- lack of upstream support is constant threat
+ should be easier to port
+ much better upstream and Debian packaging support
+ much less risk of breakage in integration with cairo and gtk
- heavyweight and complex solution; X.Org is designed for much more
complex tasks and environments than the installer will ever need
- in current implementation means significant size increase of initrd
- explosion of number of source packages that need to build udebs
- possibly greater risk of weird breakages after e.g. X.Org updates
that will need to be investigated and followed up on
- effectively requires a switch to console-setup-udeb which still has
important technical and usability issues for use in D-I
A few quick comments on some of the negative points mentioned for X.Org.
* You may have noted that I mention initrd size and not memory usage as
issue. For me this is a major issue; I'll explain why in a later mail.
* The explosion of the number of udebs is a lesser problem now than it
would have been for Lenny. This is due to the fact that we now have
(basic?) support in britney for migration of udebs to testing. However,
it *will* create a heavier workload for both Debian and D-I RM,
especially in the final stages before a new Debian stable release.
I'm very happy that the new X.Org based implementation will continue to use
the framebuffer. Needing to include and support all the various (kernel)
video drivers would IMO have been a disaster.
> - Even if someone steps in to fix some bugs (I heard somebody has
> started to publish some patches recently), it might lead to a
Is that true? Are there patches and do they fix the current breakage ?
Who worked on it? I'd very much like to see his input.
> dependency on a very single person, who might vanish at any
> time. Going the X11 way ensures that we have a few more folks
> working on it on the long run.
Dependency on a single person is a fact of life in various FOSS
(sub)projects. Very often a new person only steps up if there's a real
need. And IIUC the X.Org Debian packaging team currently also has a
manpower problem. But yes, in general it should be a lot better.
My conclusion after the past few weeks is that from a *functional*
perspective there's no real difference between the two. From a *technical*
perspective DirectFB is still the better solution for D-I and if there is
someone willing to work on the issues I'd personally prefer sticking with
DirectFB, at least for Squeeze . But from a *practical* perspective, a
switch to X.Org is probably unavoidable in the long run, and necessary now
if the DirectFB breakage is not fixed very soon.
I also think that once we do switch to X.Org there is little reason to keep
DirectFB support for the installer. It is broken now and I doubt anybody
will put any effort in it when it's no longer used. Better to remove the
libdirectfb related udeb from the archive and clean up the source code.
For my more detailed replies, please see the d-boot list.
 Note there's also still #543590; I've no idea what the status of
directfb 1.4 is and if that still could go ahead for Squeeze if the udeb
 Main consideration is the release planning. There's still significant
work needed for the switch. Time that would possibly be better spent on
polishing X.Org, fixing RC issues, testing migrations and updating