Differences between revisions 93 and 95 (spanning 2 versions)
Revision 93 as of 2007-07-27 13:24:32
Size: 9999
Editor: ?fiandro
Comment: Removed reference to bug 407035, fixed upstream in gtkdfb 2.10.x
Revision 95 as of 2008-02-14 16:39:02
Size: 9442
Editor: Lunar
Comment: General update
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Line 12: Line 11:

* '''pointrelease''' A cdebconf-gtk-entropy plug-in is needed if we want to be able to install on encrypted volumes using random keys with the the GTK frontend too.
 * A cdebconf-gtk-entropy plug-in is needed if we want to be able to install on encrypted volumes using random keys with the the GTK frontend too.  [http://people.debian.org/~lunar/fe_gtk-plugin-entropy.c Code has been written] but needs integration and testing.
Line 16: Line 13:
  * For partitioning one option is porting gparted to C. Work on this was already started by [http://lists.debian.org/debian-boot/2006/06/msg01358.html Xavier Oswald]. Current code is available [http://svn.debian.org/wsvn/parted/gdisktool/trunk/?rev=0&sc=0 on alioth].

* Try to find a way to present information in columns despite using a proportional font. This may require extensions to the debconf protocol. This should also be generally useful for frontends used in the installed system for configuring packages. This idea could be extended to providing basic support for buleted or numbered lists.
  * For partitioning one option is porting gparted to C. Work on this was already started by [http://lists.debian.org/debian-boot/2006/06/msg01358.html Xavier Oswald]. Current code is available [http://svn.debian.org/wsvn/parted/gdisktool/trunk/?rev=0&sc=0 on alioth].
 * Try to find a way to present information in columns despite using a proportional font. This may require extensions to the debconf protocol. This should also be generally useful for frontends used in the installed system for configuring packages. An [http://lists.debian.org/debian-boot/2007/10/msg00400.html implementation has already been proposed] but needs a little more work before being integrated.
Line 21: Line 16:
Line 23: Line 17:

 * Touchpad support in linux_input was added to DFB in CVS and then backported to 0.9.25-5 via a patch i wrote; Ville Sryala produced an updated, better, patch which we weren't able to include in our sources because of time constrains.[[BR]]As we want to give best support possible to laptop users Ville's patch should be fixed and backported in our sources. [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400579 #400579][[BR]]This issue will get automatically fixed when we switch to DFB 1.0, which natively includes the fix.

 * Diagnostic tool dfbinfo is now provided by libdirectfb-udeb, later we should move it to a specific udeb, possibly with the df_input tool [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390437 #390437]
Line 31: Line 20:
Line 36: Line 24:
Line 43: Line 30:
 * '''pointrelease''' DirectFB's linux_input input module seems particularly willing to crash on this architecture, and as a result we had to selectively disable such module basing on experiments on on various PPC boxes.[[BR]]This resulted in the inclusion into rootskel and rootskel-gtk packages of ad hoc startup scripts that take care of picking the correct DirectFB input driver depending on the architecture.[[BR]]My plans are (if i will ever be able to put my hands on a PPC box) to fix the linux_input module bug upstream in DFB, backport the patch to debian sources (or awaiting to switch to newer DFB version), switch to linux_input input module for al architectures and eventually get us rid of all those messy startup scripts.[[BR]][[BR]]Read also this long [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422146 thread] about the g-i on PPC machines, mainly due to the crashing of linux_input module on most PPC boxes.[[BR]]It's explained that a patch to this bug may exist, but PowerPC testers are needed.[[BR]][[BR]]A table with test results for a variety of PowerPC systems can be found at ["DebianInstaller/GUIPowerPC"]. Feel free to add results for any configuration that's not yet listed.
Line 45: Line 31:
 * On PPC the framebuffer device has a fixed size that cannot be set at boot like it's done on i386, so the GTK frontend should adapt itself to go "fullscreen". [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401693 #401693]  * DirectFB linux_input input module cannot correctly detect the keyboard on most PowerMacintosh models, so we had to disable it relying on the legacy ps2mouse and keyboard input dr.[[BR]]This required the inclusion into rootskel and rootskel-gtk packages of some ad hoc startup scripts that take care of picking the correct DirectFB input driver depending on the host architecture.[[BR]]A prper addressing of this issue requires fixing the linux_input module so that we can switch to linux_input input module for all supported architectures and drop some startup scripts.[[BR]][[BR]]
 * Another issue is related to the fact that apparently DirectFB cannot run on top of the nvidia framebuffer: no more information are available because not much light was made on this problem yet.[[BR]][[BR]] This [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422146 thread] is about the two above mentioned issues, while a g-i on PowerPC compatibility list can be found here ["DebianInstaller/GUIPowerPC"]: feel free to add entries for any configuration that's not yet listed.[[BR]][[BR]]
 * The framebuffer device has a fixed size that cannot be set at boot like it's done on i386, so the GTK frontend should adapt itself to go "fullscreen". [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401693 #401693]
Line 50: Line 38:
Line 57: Line 46:
Line 65: Line 55:
Line 68: Line 59:
Line 70: Line 62:
Candidates for inclusion need to have a limited set of dependencies, preferable only those that are already included in g-i, use directfb for graphics, eventually using SDL, sound should be optional, and not need more input device than already detected by g-i. The [http://lists.debian.org/debian-boot/2007/08/msg00560.html cdebconf-gtk-tetris] udeb is a start, but having a separate entry in the menu does not seem the best way to do it.

Other c
andidates for inclusion need to have a limited set of dependencies, preferable only those that are already included in g-i, use directfb for graphics, eventually using SDL, sound should be optional, and not need more input device than already detected by g-i.
Line 75: Line 69:
 
Line 77: Line 70:
Line 79: Line 71:
Line 81: Line 72:
Line 83: Line 73:
Line 85: Line 74:
Line 87: Line 75:
Line 89: Line 76:
Line 91: Line 77:
Line 93: Line 78:
Line 95: Line 79:

Introduction

This is an overview of some of the bugs and issues left open or workarounded only in Etch and that i hope will be fixed later in a point release.

Items tagged as pointrelease are desiderata for next Etch pointrelease (mainly bugfixes), all other items refer to issues which will be addressed in Lenny only.

This is no way meant to be an exhaustive list of every bug somehow related to the graphical installer: for a complete buglist see packages [http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=cdebconf-gtk-udeb cdebconf-gtk-udeb], [http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=directfb directfb], [http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libdirectfb-0.9-25-udeb libdirectfb-0.9-25-udeb], [http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libgtk-directfb-2.0-0 libgtk-directfb-2.0-0], [http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libgtk-directfb-2.0-0 libgtk-directfb-2.0-0-udeb], [http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=rootskel rootskel], [http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=rootskel-gtk rootskel-gtk]

?TableOfContents([2])

Architecture independent issues

Per-architecture issues

We're trying to inventory bugs affecting the g-i on a per-architecture base, architectures considered here are i386, PowerPC, AMD64 .

i386 specific

  • For historical reasons the vga16fb module is still loaded even if a framebuffer device is already provided by vesafb: this forced us to check that DirectFB actually accesses the framebuffer device provided by vesafb , better would be not starting at all two fb devices concurrently (this also wastes little memory). [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401685 #401685]

  • Some popular video chips, like intel i810, are not supported by the vesafb framebuffer module and hw-specific modules are not available in the installer, so we cannot currently support those chips. We need to either build into the kernel or provide as loadable modules hw specific framebuffer modules, and load them on the base of the found hardware [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405737 #405737].

AMD64 specific

PowerPC specific

  • DirectFB linux_input input module cannot correctly detect the keyboard on most ?PowerMacintosh models, so we had to disable it relying on the legacy ps2mouse and keyboard input dr.?BRThis required the inclusion into rootskel and rootskel-gtk packages of some ad hoc startup scripts that take care of picking the correct DirectFB input driver depending on the host architecture.?BRA prper addressing of this issue requires fixing the linux_input module so that we can switch to linux_input input module for all supported architectures and drop some startup scripts.?BR?BR

  • Another issue is related to the fact that apparently DirectFB cannot run on top of the nvidia framebuffer: no more information are available because not much light was made on this problem yet.?BR?BR This [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422146 thread] is about the two above mentioned issues, while a g-i on PowerPC compatibility list can be found here ["DebianInstaller/GUIPowerPC"]: feel free to add entries for any configuration that's not yet listed.?BR?BR

  • The framebuffer device has a fixed size that cannot be set at boot like it's done on i386, so the GTK frontend should adapt itself to go "fullscreen". [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401693 #401693]

Ideas for future development

Porting

The graphical version of the installer is currently available for Intel x86, AMD64 and PowerPC. The PowerPC port [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341597 needs work] to get different types of system correctly supported. Other architectures the graphical installer could be ported to include Sparc, Alpha and HPPA.

Fonts

For font information, please see ["DebianInstaller/GUIFonts"]

Usability

  • Interface should adapt itself so that text blocks are never too wide for optimal readability.
  • Improve accessability (for the visually handicapped). One way to do this is to [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339735 support different themes] (color schemes). (Note: should not lead to a major increase in initrd size.)

  • Alternative (graphical) ways to start a shell or browse log files
  • Logfile-viewer (in split window) in expert mode as default, if screen resolution permits
  • Interface design.
  • Create custom plug-ins for cdebconf to improve handling of some dialogs and make optimal use of possibilities offered by the graphical environment.

Interface design

Most of the work on the graphical side has been done by Eduardo Silva. He has set up a [http://www.geocities.com/jobezone/d-i_gtk.html webpage] with images he designed and some comments about possible future changes.

Games

It would be nice for g-i to have some games to help kill time during lengthy install sessions.

The [http://lists.debian.org/debian-boot/2007/08/msg00560.html cdebconf-gtk-tetris] udeb is a start, but having a separate entry in the menu does not seem the best way to do it.

Other candidates for inclusion need to have a limited set of dependencies, preferable only those that are already included in g-i, use directfb for graphics, eventually using SDL, sound should be optional, and not need more input device than already detected by g-i.

This excludes c++ implemented games linked against libstdc++, or other language whose runtime is not-available in g-i, as well as all those that link with the gnome libs or other such. A preliminary list follows, out of them, icebreaker sounds like a very good candidate. It is only depending on libsdl, easy to understand, using only the mouse and not the keyboard, and not controversial in any way.