Please record comments regarding the 6.8.99.x (6.9.0 candidate) releases of xorg-x11 here. I am especially interested in: 1. Mesa (libGL & friends) issues; 2. Keyboard issues. At this point, there are no local patches for sparc, and it does not appear that any will be required.
sunleo support is working in 6.8.99.3, however the XAA patch does not appear to be applied at this time (or there is nothing in the logs to indicate that it is active like there is for sunffb).
I am not sure which log you are talking about. Nothing in the sunleo xaa patch forces xaa to be loaded. The reason you see an entry in Xorg.0.log for xaa and sunffb is this (in sunffb/ffb_driver.c): if (xf86LoadSubModule(pScrn, "xaa") == NULL) { the sunffb driver explicitly loads and uses xaa. For sunleo, the big change seems to be a conversion from using cfb32 --> fb. You might have to load xaa explicitly to get it used, if at all (sunleo doesn't create a record of what accelerations xaa could perform for xaa to look at, as sunffb does.) But the changes themselves seem to be the same as the ones at https://bugs.freedesktop.org/show_bug.cgi?id=1259 --- it appears that xaa acceleration for sunleo indeed has not made it to xorg-x11 yet, but it doesn't look as if it has ever been available. If you have information to the contrary, please let me know, because I am not finding anything. (I don't know if the comments on the freedesktop bug report indicate a commitment to support sunleo+xaa or not; more to the point, I do not know what has been committed to you.)
It's probably just my confusion on there being XAA with sunleo. The log I was refering to was Xorg.0.log and sunleo does appear to be using fb now rather than cfb32.
xorg-x11-6.8.99.8 will not build on all sparc systems. On systems which build xc/programs/Xserver/hw/xfree86/input/evdev, build fails. Specifically, evdev.c is changed from .99.5 --> .99.8 like this: ========================================== --- /var/tmp/portage/xorg-x11-6.8.99.5/work/xc/programs/Xserver/hw/xfree86/input/evdev/evdev.c2005-01-18 20:18:09.000000000 +0000 +++ evdev.c 2005-05-11 00:13:15.000000000 +0000 @@ -61,10 +61,6 @@ #define MODEFLAG 8 #define COMPOSEFLAG 16 -#ifndef EV_RST -#define EV_RST EV_SYN -#endif - static int wheel_up_button = 4; static int wheel_down_button = 5; static int wheel_left_button = 6; @@ -156,7 +152,7 @@ } break; - case EV_RST: + case EV_SYN: break; } } @@ -490,11 +486,17 @@ return EvdevInit(device); case DEVICE_ON: + if (ioctl(pInfo->fd, EVIOCGRAB, (void *)1)) + xf86Msg(X_WARNING, "%s: Grab failed (%s)\n", pInfo->name, + strerror(errno)); xf86AddEnabledDevice(pInfo); device->public.on = TRUE; break; case DEVICE_OFF: + if (ioctl(pInfo->fd, EVIOCGRAB, (void *)0)) + xf86Msg(X_WARNING, "%s: Release failed (%s)\n", pInfo->name, + strerror(errno)); xf86RemoveEnabledDevice(pInfo); device->public.on = FALSE; break; ========================================================== With this change, the compilation fails with undefined symbols, like this ============================================= sparc-unknown-linux-gnu-gcc -O2 -mcpu=ultrasparc3 -pipe -fno-strict-aliasing -ansi -pedantic -Wno-return-type -w -fPIC -I. -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/hw/xfree86/loader -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/include -I../../../../../../programs/Xserver/mi -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../.. -I../../../../../../exports/include -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DRANDR -DXFIXES -DDAMAGE -DCOMPOSITE -DXEVIE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DDLOPEN_HACK -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DXResExtension -DX_BYTE_ORDER=X_BIG_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((8) * 100000) + ((99) * 1000) + 8)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -c evdev.c evdev.c: In function `EvdevReadInput': evdev.c:155: error: `EV_SYN' undeclared (first use in this function) evdev.c:155: error: (Each undeclared identifier is reported only once evdev.c:155: error: for each function it appears in.) evdev.c: In function `EvdevProc': evdev.c:489: error: `EVIOCGRAB' undeclared (first use in this function) make: *** [evdev.o] Error 1 ================================================== 6.8.99.5 does compile, and it's being used to generate this comment. System is an SB1000, thus. fmccor@polylepis ferris [2]% uname -a Linux polylepis 2.6.11-gentoo-r7 #1 SMP Wed May 4 12:21:22 UTC 2005 sparc64 sun4u TI UltraSparc III (Cheetah) GNU/Linux
Wanna check out your <linux/input.h>? $ grep /usr/include/linux/ -r -e EVIOCGRAB /usr/include/linux/input.h:#define EVIOCGRAB _IOW('E', 0x90, int) /* Grab/Release device */ $ grep /usr/include/linux/ -r -e EV_SYN /usr/include/linux/input.h:#define EV_SYN 0x00 /usr/include/linux/input.h: input_event(dev, EV_SYN, SYN_REPORT, 0);
On sparc, any kernel, linux/input.h: 1. #define EV_RST 0x00 2. Does not define EV_SYN 3. Does not define EVIOCGRAB 4. No file in /usr/include mentions EVIOCGRAB at all. 5. The kernel version of this file /usr/src/linux/include/linux/input.h matches your results; 6. But sparc uses sys-kernel/linux-headers-2.4.23 7. Most other architectures use linux-headers-2.6.8.1-r2 8. On sparc, though, linux-headers-2.6.8.1-r2 cause problems (because kernel-2.6 causes problems?), and last I knew it was not recommended. In any case, the xorg ebuild needs a dependency (on systems that build an evdev module. I am not sure how xorg decides to built that: U60(kernel-2.4) doesn't; SB1000(kernel-2.6) does.) It looks like the decision is made on OSMinorVersion.
> In any case, the xorg ebuild needs a dependency (on systems that build an evdev > module. I am not sure how xorg decides to built that: U60(kernel-2.4) doesn't; > SB1000(kernel-2.6) does.) It looks like the decision is made on OSMinorVersion. known bug in the evdev build logic. EVIOCGRAB was introduced somewhere around 2.6.10 when i thought it was introduced in 2.5.x. feel free to add a #ifndef/ #define/#endif for it to evdev.c, i'll be doing the same upstream shortly.
Thanks for the information. In fact, the problem was introduced into xorg between what we are calling xorg-x11-6.8.99.5 (compiles fine), and xorg-x11-6.8.99.8 (doesn't compile because of header files mismatch.). And, just lifting the #define EV_SYN, #define EVIOCGRAB works, to, as you say.
Created attachment 59793 [details, diff] patch xorg-x11-6.8.99.8.ebuild and evdev.c --- Comment 8 This patch modifies the -6.8.99.8 ebuild and provides a file to patch evdev.c in order to let -6.8.99.8 build on a kernel-2.6.xx system which has installed linux-headers-2.4.xx. It conditionally #defines the symbols EV_SYN and EVIOCGRAB in the 2.6 headers if necessary. This operation should be safe, because the evdev module is built only on kernel-2.6 systems. OPERATION: 1) get the patch; 2) In x11-base/xorg-x11, do: 'patch -b -z- -p0 < {path to}/xorg-x11-6.8.99.8-evdev.patch' 3) ebuild xorg-x11-6.8.99.8.ebuild digest 4) Build X NOTE: Comment 7 indicates this will be part of the distribution; HOWEVER It is not sufficient to define EVIOCGRAB. You must define EV_SYN, too, or else you will still get compilation errors if you are using -2.4 headers; AND this is common on sparc because only -2.4 headers are marked stable, but kernel-2.6 is used experimentally.
(In reply to comment #9) > this is common on sparc because only -2.4 headers are marked stable, but > kernel-2.6 is used experimentally. that's revolting.
Created attachment 59869 [details, diff] evdev.c patch without the auto-generation wrapper 1. I realized that some people reading this want to see the patch rather than to set it up for installation. So that's all this attachment is: the patch to evdev.c. 2. I gather that Adam doesn't like running kernel-2.6 + headers-2.4. The reason we do it, as I understand it, goes like this. We run as stable both kernel-2.4 and kernel-2.6 because kernel-2.6 runs fine on some systems but is unusable on others. However, right now headers-2.6 are considered unstable (and there are people who can jump in and explain why; I am not one, and this particular bug is not the place because it has nothing to do with xorg status. If ajax or anyone else wants an explanation, best would be to ask on #gentoo-sparc until someone who knows responds.). In any case, the attachment associated with this comment is what we need. Honest. :)
Starting with xorg-x11-6.8.99.8 (using Ferris' second patch on this bug), using a Creator3D (FFB2+ mode #501-4788) in a Blade 1000 shows everything in blue overtones (like there's way too much blue and not enough green and red). KDE and XFCE4 both showed this behavior, either when selected through KDM or when setup in a user's .xinitrc file and started via the "startx" command. This behavior was not seen in xorg-x11-6.8.99.5 or xorg-x11-6.8.2-r[1-2].
Another note to add is I tested the XVR-100 card on xorg-x11-6.8.99.8 (rebranded Radeon 7000 VE) and was unable to get it to work using either the radeon or fbdev drivers. Using fbdev, X just exited out with no noticible errors in the log, but using the radeon driver, X reported that it could not find any cards. I talked to ajax about this on IRC and he thinks it might be a result of some PCI domain issues that still need to be adjusted. He also suggested I try the patch attached to the Xorg bug at https://bugs.freedesktop.org/show_bug.cgi?id=2368, but two hunks were unable to apply due to changes made to the xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c driver (these are the only hunks that apply to this file). The last word from ajax was that he'd try to work on a new copy that applies against xorg-x11-6.8.99.8 and have it ready in the next few days.
I'll mention that Weeve's Comment 12 "too much blue in 6.8.99.8" also shows up in xchat-2; specifically, with 6.8.2-r2, my posts are noted by <fmccor> in some sort of dull reddish-purple angle-brackets. With 6.8.99.8, the brackets are bright blue. (xchat-2 uses gtk+-2 + render; I would not be surprised to see render in Weeve's "too-blue" applications,as well.)
Oops, my comment 14 is incorrect. I made a special effort to remember what colors I was seeing from xchat, and still got them wrong. Maybe I should have written them down; sorry for the panic about angle brackets. That said, I do see blue highlighting on this 6.8.99.8 system for the background for xchat, and with 6.8.2-r2, it is not present (and it shouldn't be).
Updating linus 2.4.28-gentoo-r9 like this: emerge -ua world insists on: [ebuild U ]x11-misc/lineakd-0.8.3 [0.7.2] and fails to compile because: evtest.c:168: error: `EV_SYN' undeclared (first use in this function) The question is this - should lineakd version be limited under 2.4 so that this problem is not encountered? In other words Does lineakd need to be upgraded to a version that uses in symbol EV_SYN for 2.4 kernels? I seem to recall that there is some way to make ebuild updates depend also upon the kernel version in use. Thus when compiling under a 2.4 kernel lineakd should use an older version.
Concerning Comment 16: I am not sure why it is part of this particular bug, but the point is valid. For now, I've removed the ~sparc keyword from lineakd-0.8.3 because this version will not build on a system using the stable sparc linux-headers. lineakd-0.8.2 still builds fine.
I decided my u10 was too stable, so I figured I'd try this out... I'm using the Mach64 on my u10: atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c] atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK atyfb: fb0: ATY Mach64 frame buffer device on PCI Section "Device" Identifier "ATI" Driver "ati" EndSection xorg-x11-6.8.2-r1 worked fine xorg-x11-6.8.99.14 system locks up when starting X (L1-A still responds, but the display is corrupt, so it's not very helpful). I'll start testing older betas to see when the bug was introduced.
xorg-x11-6.8.99.{5,8} have the same problem mentioned in comment #18 (system lockup) xorg-x11-6.8.99.3 startx X, but gtk2 applications take _forever_ to start. gdm took about 3 minutes to bring up the login window compared to about 10s normally. During this load time, it had 100% CPU usage. [ebuild U ] x11-base/xorg-x11-6.8.99.14 [6.8.2-r2] (-3dfx) (-3dnow) +bitmap-fonts -cjk -debug +dlloader -doc +font-server -insecure-drivers +ipv6 -minimal (-mmx) +nls -nocxx +opengl +pam +sdk (-sse) -static +truetype-fonts +type1-fonts (-uclibc) +xprint +xv 0 kB Portage 2.0.51.22-r1 (default-linux/sparc/sparc64/dev, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.12-gentoo-r4 sparc64) ================================================================= System uname: 2.6.12-gentoo-r4 sparc64 sun4u Gentoo Base System version 1.6.12 dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.14.90.0.8-r1, 2.15.92.0.2-r8, 2.16-r1, 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="sparc ~sparc" AUTOCLEAN="yes" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /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="-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe" DISTDIR="/mnt/raid0/gentoo/distfiles" FEATURES="autoconfig ccache confcache distlocks sandbox sfperms strict userpriv" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/mnt/raid0/gentoo/packages-sparc" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://10.0.10.8/gentoo-portage" USE="sparc X Xaw3d aac accessibility acl aim alsa ao apache2 asterisk audiofile avi berkdb bidi bitmap-fonts bmp bonobo brltty c++ cap caps cddb cdparanoia chroot clamav crypt cups curl dlloader dmx dnd dv dvd dvdread edl eds emacs emacs-w3 encode erandom esd evo expat ext-png ext-zlib extlib f77 faac faad fam fastcgi fbcon fbdev ffmpeg fftw firefox flac flash fltk fluidsynth font-server foomaticdb foreign-package fortran freetype fullrpc gcc64 gcl gd gdbm gif gimpprint glade glgd glut gnome gnomedb gnutls gpm gstreamer gtk gtk2 gtkhtml hdf hdf5 idea imagemagick imap imlib imlib2 innodb input_devices_wacom ipv6 jabber jack java javamail javascript jbig jdepend jikes joystick jpeg junit justify kde ladcca lcms leim libg libgda libwww live lzo mad maildir makecheck mikmod mmap mng motif moznocompose moznoirc mozsvg mpeg mpeg4 msn mule multislot music mythtv ncurses net network nls nptl oav objc odbc offensive ogg oggvorbis oldworld openal opengl operanom2 oscar oss pam parse-clocks pcre pdflib perl png portaudio prelude propolice pthreads python qhull qt readline rtc samba sasl sdk sdl serial silc slp sndfile socks5 sox speex spell sqlite ssl tcltk tcpd tga theora tiff timidity transcode truetype truetype-fonts type1 type1-fonts unicode usb userlocales videos vim-with-x virus-scan vorbis wxwindows xaa xchattext xemacs xml xml2 xmms xosd xprint xv xvid yahoo zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
> xorg-x11-6.8.99.3 startx X, but gtk2 applications take _forever_ to start. gdm > took about 3 minutes to bring up the login window compared to about 10s > normally. During this load time, it had 100% CPU usage. Do you have an infinitely looping /usr/share/fonts/fonts link?
Yeah... that infinite loop was the problem for me with .3... so the problem is coming in between .3 and .5
Is this also tracking modular X?
xorg-x11 7.1 was now marked stable on sparc. Maybe it's time to close this bug?
(In reply to comment #23) > xorg-x11 7.1 was now marked stable on sparc. Maybe it's time to close this bug? > Yes. You are moving faster than I am. :) Closing as no longer relevant to anything, as Henrique observed.
