Bug#257285: FB support should not be disabled by default for all Sparc systems
retitle 257285 FB support should not be disabled by default for all Sparc systems
submitter 257285 aragorn@tiscali.nl
thanks
(Changing submitter to better keep track of this issue.)
Probably because of reports like this one, debian-installer/framebuffer is
currently set to _false_ by default for all sparc installs.
This change has been made in rootskel 0.74 (r14530, r14540). The best
explanation is in [1]:
* Problem with sparc support for Creator 3D and all SBUS and UPA
framebuffer devices.
Do we have a sparc kernel to fix this? Alternatively, this is worked
around by rootskel 0.74.
The svn log lays the blame with bterm (better references for this claim welcome!):
Disable debian-installer/framebuffer for sparc64. It's broken in the way
that bterm uses it, sayeth upstream.
However, some systems (like my U10 with an ati mach64) actually _need_
framebuffer support for correct display (d-i is still usable, but very
ugly and seriously annoying).
Having the default set false is very confusing as everyone expects problems
to result from it being _enabled_, not disabled. This can (and has) lead to
extremely fruitless searches when tracing problems.
The best solution would of course be fixing either the fb drivers or
bterm. If fb support really needs to be disabled, it should be done only for
affected systems and not for the whole arch.
[1] http://lists.debian.org/debian-boot/2004/05/msg01825.html
Reply to: