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.
