Switching g-i from DirectFB to X11 -- general reflections

[Frans Pop]

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

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?

DirectFB:
+ 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

X.Org:
+ 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 [1]?
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 [2]. 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.

Cheers,
FJP

[1] 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 
was dropped.
[2] 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 
documentation.