amd64: Please test the drm now that it works with 2.6 kernels. sparc: There is what appears to be an ffb drm module for sparc-only hardware. Please confirm this and keyword if it is. Thanks to both of you.
I'll look at it for sparc+ffb+kernel-2.6.x in the next two or three days, unless someone else is anxious to get into X11+ffb.
On sparc, a simple build test is not successful. Let me know what I am missing or what you would like me to try: ================================= Build environment: Ultra2-SMP (ffb2+ installed), kernel=2.6.7 (SMP); In /usr/src, linux -> linux-2.6.7/ In linux-2.6.7, a kernel is configured and built, and for the ffb (Creator), configured: CONFIG_DRM=y CONFIG_DRM_FFB=m CONFIG_FB_FFB=y And, the original kernel build did build: find /usr/src/linux-2.6.7 -name ffb.ko /usr/src/linux-2.6.7/drivers/char/drm/ffb.ko ================================== Now, for the requested test: x11-drm-20040827.ebuild does contain support for ffb, available only on sparc. So, for the test we keep things very simple: Add ~sparc to the KEYWORDS and FEATURES='keepwork' VIDEO_CARDS='ffb' ACCEPT_KEYWORDS='~sparc' emerge -vB x11-drm The build starts fine, figures out the kernel, decides ffb is OK on this system, and builds dristat. Then, however, it terminates abnormally, thus: * Building DRM... mkdir -p /var/tmp/portage/x11-drm-20040827/work/drm/tmp/.tmp_versions cp //usr/src/linux/.tmp_versions/*.mod /var/tmp/portage/x11-drm-20040827/work/drm/tmp/.tmp_versions make -C //usr/src/linux MAKEFILES=/var/tmp/portage/x11-drm-20040827/work/drm/tmp/.config M=/var/tmp/portage/x11-drm-20040827/work/drm SUBDIRS=/var/tmp/portage/x11-drm-20040827/work/drm DRMSRCDIR=/var/tmp/portage/x11-drm-20040827/work/drm \ MODVERDIR=/var/tmp/portage/x11-drm-20040827/work/drm modules make[1]: Entering directory `/usr/src/linux-2.6.7' Building modules, stage 2. MODPOST make[1]: Leaving directory `/usr/src/linux-2.6.7' gcc -mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe -g -ansi -pedantic -DPOSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -I. -I../../.. dristat.c -o dristat bzip2: Output file environment.bz2 already exists. >>> Test phase [not enabled]: x11-base/x11-drm-20040827 >>> Install x11-drm-20040827 into /var/tmp/portage/x11-drm-20040827/image/ category x11-base * Installing DRM... make: *** No rule to make target `ffb.ko', needed by `install'. Stop. !!! ERROR: x11-base/x11-drm-20040827 failed. !!! Function src_install, Line 120, Exitcode 2 !!! Install failed. !!! If you need support, post the topmost build error, NOT this status message. (Note that this kernel version has ffb dri problems independent of x11-drm generally. I will test also with a kernel-2.6.6 build, but I am posting this now to supply you some instant gratification.)
Same result on sparc with linux --> linux-2.6.6-rc2. I don't want to give this a ~sparc keyword until we can figure out how to actually build x11-drm's ffb.ko. But I would like to test this, so ideas are welcome.
Can you post your `uname -a` please? tia
Here's one: Linux lacewing.inforead.com 2.6.7 #2 SMP Mon Aug 23 20:56:29 UTC 2004 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux lsmod gives Module Size Used by sr_mod 21420 1 isofs 43880 1 ffb 52528 0 cdrom 43560 1 sr_mod (ffb (kernel version, not x11-drm version, is not used because of a kernel problem in 2.6.7; it is built.) Failure also seen on kernel 2.6.6, but I don't have a uname for that system right now.
MACHINE := $(shell uname -m) # Modules for all architectures MODULE_LIST := tdfx.o r128.o radeon.o mga.o sis.o savage.o via.o mach64.o # Modules only for ix86 architectures ifneq (,$(findstring 86,$(MACHINE))) ARCHX86 := 1 MODULE_LIST += i830.o i810.o i915.o endif ifneq (,$(findstring sparc64,$(MACHINE))) ARCHSPARC64 := 1 MODULE_LIST += ffb.o endif ------------- This is the Makefile logic used. Apparently it isn't finding sparc64 from uname -m. Unless I'm missing something, it should be sufficient logic. I'll do some testing locally to see what's going on and maybe ask around.
Absolutely ancient bug with no recent activity, closing. Anyone with current problems should update the bug with recent information - thanks.
