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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
