Bugzilla Bug 93339

If you emerge Xorg 6.8.2r1 using the minimal flag the driver sunffb cannot work
because the lack of lot of drivers.

Reproducible: Always
Steps to Reproduce:
1.USE="-minimal" emerge xorg-x11
2.
3.

Actual Results:  
X cannot run because modules XF8_32Wid XF8_32Bpp etc are not disponible

Expected Results:  
display a nice interface :)

Portage 2.0.51.19 (!/usr/portage/profiles/default-linux/sparc/sparc64/2005.0,
gcc-3.3.5-20050130, glibc-2.3.3.20040420-r2, 2.4.30-sparc sparc64)
=================================================================
System uname: 2.4.30-sparc sparc64 sun4u
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, May 19 2005, 17:56:48)]
dev-lang/python:     2.3.5
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.9.5, 1.8.5-r3, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.4.23
ACCEPT_KEYWORDS="sparc"
AUTOCLEAN="yes"
CFLAGS="-O2 -mcpu=ultrasparc"
CHOST="sparc-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -mcpu=ultrasparc"
DISTDIR="/mnt/gentoo/distfiles"
FEATURES="autoaddcvs autoclean autoconfig candy ccache distlocks moo sandbox"
GENTOO_MIRRORS="http://architect/gentoo
http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/
ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/
rsync://ftp.belnet.be/gentoo/ http://gentoo.mirror.sdv.fr
http://ftp.rhnet.is/pub/gentoo/ ftp://ftp.rhnet.is/pub/gentoo/
rsync://ftp.rhnet.is/gentoo"
MAKEOPTS="-j2"
PKGDIR="/mnt/gentoo/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/mnt/gentoo/portage"
PORTDIR_OVERLAY="/mnt/gentoo/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="sparc X arts avi bitmap-fonts bootsplash crypt cups dlloader encode esd fam
fbcon foomaticdb fortran gcc64 gdbm gif gtk2 imlib ithreads java jpeg justify
libwww mad mikmod motif mozilla moznocompose moznoirc moznomail moznoxft mpeg
mpeg4 mplayer mysql ncurses nls nptl oggvorbis opengl oss pam pdflib perl png
python qt readline sdl spell ssl tcpd tiff truetype truetype-fonts type1-fonts
ultra1 xml2 xmms xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

The point is that you only get minimal drivers and therefore you don't need
most
modules, but this hasn't been fully implemented on sparc yet -- either because
nobody cares or the people who care weren't aware of it.

If the sparc folks could post a very short list of minimal drivers consistent
with the x86 list and reassign to x11, I'd appreciate it.

Here's what happens for x86:
                echo "#define XF86CardDrivers vmware vesa vga dummy \
                    XF86OSCardDrivers XF86ExtraCardDrivers" >> ${HOSTCONF}

where XF86OSCardDrivers is fbdev and v4l on Linux.

Let me know of any of those that don't work for sparc or any additional
"generic" drivers.

1.  The only other XF8sOSCarDriver needed for sparc is sisusb.
2.  I can't find where these symbols come from.  Could you please attach your
/var/log/Xorg.0.log file from a failing run?

Got it.  The missing modules are:
libxf8_16bpp.so
libxf8_32bpp.so
libxf8_32wid.so

For sparc, with minimal, apparently this part of the 
if use minimal ; then

			# Weird crap we don't need
			echo "#define XF8_32Wid NO" >> ${HOSTCONF}
			echo "#define XF8_32Bpp NO" >> ${HOSTCONF}
			echo "#define XF8_16Bpp NO" >> ${HOSTCONF}
			echo "#define XF24_32Bpp NO" >> ${HOSTCONF}
has to be quilified with
an if ! use sparc test
because sparc needs that bit of weird crap.
(Again, if Dnix could attach the Xorg log file, we could see if this is all
that's missing.)

Regards,
Ferris

sisusb is a non-generic driver that I don't consider appropriate for minimal.
Similar holds true for sunffb. The only ones that should be built are stuff like
vga, vesa, fbdev, unless there are zero generic drivers that work for X on sparc.

I posted the following question to the gentoo-sparc mailing list:
==================================================================
> I'm sending this on for comments before responding on the bug.  Is xorg-x11 useful
> at all on sparc without the sparc drivers? (sunffb, suncg6, sunleo, etc.?)  Right
> now, with USE=minimal they get built; you just can't use them.  Read the Bug for
> background.
====================================================================
And have two responses, confirming what I suspected.  First, from Jason Wever
(weeve@gentoo.org):
-------------------------------------------------------
In my experience, vesa and vga drivers simply do not work on non-PCI
framebuffers, either when it comes to console or X.
-------------------------------------------------------
And the definitive response from David Miller, who along with Jakub Jelinek,
wrote the sparc video drivers, and actually has access to Sun's internal
hardware specs (he's the sparc kernel expert, for those not in the know):
--------------------------------------------------------
 No, it isn't.  Because:

1) All SBUS sparcs lack any VGA driver.
2) The generic "FB" driver does not work with SBUS frame buffers
3) Even on PCI with a VGA card, the VGA X driver does not work on sparc
--------------------------------------------------------

So, for USE=minimal to be minimally useful on sparc, it seems we still need the
sunxxxx drivers (which, unfortunately, also means the "Weird crap").

Hope this clarifies; usually davem gets this sort of thing right when he
comments on it, and weeve is speaking from experience.
-- 

(In reply to comment #5)
> 1) All SBUS sparcs lack any VGA driver.
> 2) The generic "FB" driver does not work with SBUS frame buffers
> 3) Even on PCI with a VGA card, the VGA X driver does not work on sparc

I wasn't assuming all three of vesa, vga, fbdev would work on sparc, but I was
hoping at least one would.

Is there some sort of generic Sun framebuffer driver that would work for all
Sparcs, since apparently fbdev won't? I presume sunffb doesn't work on everything.

From what I'm reading, it sounds like fbdev would work fine for non-SBUS fb's,
but not for SBUS ones? Is there a single driver that could be added for the SBUS
case?

Not that I am aware of.  With minimal, all the sunxxx get built now.  It's just
that sunffb (driver for Creator, Elite graphics) is probably the most heavily
used driver, and it's the one that needs the libfx8_... helpers.  (The others
don't.)

So do you think we can get away with fbdev, sunffb and the xf* stuff?

Not quite, because of sunleo, suncg6, and suncg3, and maybe some other subxxx
drivers, depending on what people have.  They are very small drivers and don't
use anything extra.  I don't know if others are needed or not: the sunxxx
drivers are needed if anyone actually has the corresponding video cards (they
are the sbus framebuffers davem was talking about), but minimal builds them now
and they are quite small.

(I know we have sunleo users, suncg6 users, probably cg3 as well, but I've never
taken a survey.  I can ask on gentoo-sparc if you like, or we can leave it as it
is for minimal now and just make sure to pick up the libxf8_* bits for sunffb.)

I'd really like to make USE=minimal an opt-in thing rather than opt-out,
meaning
we start with nothing and add to it as necessary.

So it seems like we'll minimally need fbdev and sunffb. vga apparently works
sometimes, vesa doesn't I assume. We can either wait for other people to say
they use minimal and add drivers as requested, or just add all of 'em now. The
former solution may cause a bit of confusion, but I expect people using it to
know what they're doing.

Thoughts?

That makes sense, although I'd include suncg6 and sunleo, too (building X on
systems with those cards can be pretty painful because they are slow, so I'd
like minimal to work out of the box for them.). 

Another thing to note is that fbdev doesn't appear to work for graphics cards
that are outside of PCI domain 0.  So if someone with a PCI video card (say a
XVR-100 for instance) emerged xorg-x11 with the minimal use flag, they'd be stuck.

However I think fbdev should accomidate all of the ati based framebuffers if
they fall in PCI domain 0. 

OK, committed with your added requests, to 6.8.2-r2 and 6.8.99.13.