This is a tracker bug for recording X-modular status on sparc systems. At this point, I have successfully installed X-modular on three systems: U2(2x400), kernel 2.4.31, U60(2x450), kernel 2.6.14, and SB1000(2x900), kernel 2.6.3-rc3. For the U2, I used the script at http://dev.gentoo.org/~fmccor/files/X-modular.sh (except for the option to have the script take a stab at populating the required files in /etc/portage). Here are some initial observations (all mentioned in emails previously). 1. At this point, sunffb must be rebuilt by hand if you need it; details at https://bugs.freedesktop.org/show_bug.cgi?id=4890 . I am generating a gentoo-specific patch in form of a candidate ebuild replacement, and will attach it to this bug once it works to my satisfaction. Until then, you really must rebuild xf86-video-sunffb by hand (and that's why my script installs it with FEATURES='keepwork'). 2. Except for point (1) (and below), the install seems to go very cleanly, and X-modular mostly works fine. 3. VTswitching does not appear to work. 4. On kernel 2.6 (but not 2.4) systems, AltGraph does not seem to be operational. I think mapping the key to Mode_switch should cure this, but it does not. 5. A few libraries (libXss, libdps, libdpstk, maybe more) seem to be missing. I don't know if anything actually depends on them. 6. A few obscure utilities (pswrap, gccmakedep, maybe more) seem to be missing. pswrap (for DPSgtk) and gccmakedep (for some games) are currently required (pswrap is a libdps helper; I have no idea what gccmakedep is for). Please record sparc status on this bug as you gain experience with X-modular on sparc. Thanks, Ferris
Created attachment 72026 [details] Replacement ebuild to generate a working version of sunffb_drv.so Attached ebuild is a replacement candidate for xf86-video-sunffb-1.0.0.1.ebuild. It generates a version of sunffb_drv.so which actually can drive afb/ffb (Elite/Creator) graphics cards. See above, https://bugs.freedesktop.org/show_bug.cgi?id=4890, and lots of emails for details.
Created attachment 72028 [details] Same fix for sunffb, but remove a couple irrelevant lines. Same as previous comment, but take out a couple lines which represented an unsuccessful attempt to fix this a little more simply.
My original point 5 does not indicate any problems. libXss is provided by libXScrnSaver, and the dps stuff is obsolete. Thanks to dostrow for pointing this out to me.
The dps stuff will not be released in 7.0, and we'll have to restore the external dps packages to the tree because there are a few packages depending on them, one of which actually gets used. gccmakedep already has a bug. I can reproduce the VT switching on x86 and ppc, so that's not sparc-specific.
/usr/bin/rman does not appear to be provided by X modular at the moment (or its well hiddien in a package with a different name. At least one program appears to need this at build time (tightvnc). Is there a bug open for this? A two second search didn't look like there was one, but it might be disguised as something else if the package containing rman is named differently.
app-text/rman provides rman. It's no longer packaged as part of X. Not quite sure how ya missed it. =)
I noticed that, but since everything else that used to be a part of X is under x11-*, I kind of figured rman might be as well. Thanks for the info though :)
rman was never an X-specific utility. Xorg just imported it (similar to xterm, fontconfig, zlib, etc), so it was never the "proper" source for it.
Add a dependency to the (new) general tracker for X-modular.
Corresponding patch for xf86-video-sunffb-1.0.1 fails for reasons unknown. Apparently, the 'eautoconf' step generates an unusable configure file, or the default unpack is changed. Same fix is required one way or the other, because sunffb as distributed is still completely unusable. If you already have a working sunffb driver, keep it.
(In reply to comment #10) > Corresponding patch for xf86-video-sunffb-1.0.1 fails for reasons unknown. > Apparently, the 'eautoconf' step generates an unusable configure file, or the > default unpack is changed. Same fix is required one way or the other, because > sunffb as distributed is still completely unusable. If you already have a > working sunffb driver, keep it. Does 1.0.0.1 still work fine with the current version of the eclass?
Yes.
OK, so then we know it's an actual source change (or build system, which is close enough).
Created attachment 72721 [details, diff] sunffb.diff Here's the diff between the two versions, for easier perusal.
Created attachment 72722 [details, diff] sunffb-no-generated.diff Here's the same thing, with autogenerated files ignored.
I'm pretty sure the original failure was related to these changes in configure.ac --- +XORG_DRIVER_CHECK_EXT(RANDR, randrproto) +XORG_DRIVER_CHECK_EXT(RENDER, renderproto) +XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto) However, now I can't duplicate it. So, I suspect some sort of problem on my original test system, or I did the sunffb check before all of the X-modular cycle of updates was complete, so that something was out of sync. I'll play with it some more on the original system later, but for now, there is nothing more to do. Note: My 'Yes' in Comment 12 does apply to the system on which I saw the failure.
This was just a firedrill. When I started testing, xf86-video-sunffb-1.0.1 most definitely would not build with the patch and forcing the 'eautoreconf'. However, today everything is fine. I suppose I started testing before everything had hit the mirrors, or something. Anyway, it builds now as expected. Embarrassed, Ferris
Regression in xorg-server-0.99.4: Building hw/xxree86/common, when compiling xf86Configure.c, we get: ============================ xf86Configure.c:56:22: xf86Sbus.h: No such file or directory ============================ And indeed, there is not. This is a regression: It is an old problem which was fixed and is now reappearing.
(In reply to comment #18) > Regression in xorg-server-0.99.4: Building hw/xxree86/common, when compiling > xf86Configure.c, we get: > ============================ > xf86Configure.c:56:22: xf86Sbus.h: No such file or directory > ============================ > And indeed, there is not. > This is a regression: It is an old problem which was fixed and is now reappearing. Clearly, the right thing to do would be to reopen the freedesktop bug for it, then. Thanks!
Comment on attachment 72028 [details] Same fix for sunffb, but remove a couple irrelevant lines. This is no longer a problem with xf86-video-sunffb-1.0.1.2; replacement ebuild is obsolete.
As of date/time of this note, following are only problems I know of with X-modular on sparc: 1. xorg-server-1.0.0 needs help building because of missing xf86Sbus.h header file --- see https://bugs.freedesktop.org/show_bug.cgi?id=4128 for details, a copy of the file, and where it needs to be for xorg-server to build; 2. VTswitch doesn't (apparently, not sparc-specific). 3. With kernel-2.6, Alt-Graph (== Mode_Switch) doesn't do anything (probably not sparc, since with kernel-2.6, the keyboard looks like a standard xorg-type keyboard). With kernel-2.4 (where the keyboard looks like a sun keyboard), AltGraph (Mode_Switch) does indeed map onto an alternate character set (quick check is whether or not AltGraph-c maps onto cents-sign, AltGraph-shift-3 (AltGraph-#) maps onto Pounds-stirling symbol, etc.). Again, this is probably not sparc specific (indeed, sparc keyboard with 2.4 kernel gets it right). I don't know off hand if this is a well-known problem, or what.
Created attachment 75131 [details, diff] Patch to add xf86Sbus.h into hw/xfree86/os-support/bus Attach patch inserts xf86Sbus.h into hw/xfree86/os-support/bus directory. Put it in xorg-server/files directory, and point PATCHES="${FILESDIR}/xorg-server-1.0.0-Sbus.patch" in xorg-xerver-1.0.0.ebuild to it, and it seems to install fine and build for sparc. Verified by doing just that, then: ebuild xorg-server-1.0.0.ebuild digest ebuild xorg-server-1.0.0.ebuild unpack ebuild xorg-server-1.0.0.ebuild install
https://bugs.gentoo.org/attachment.cgi?id=75131 is in xorg-server-1.0.1. Any reason for this to stay open?
Please note https://bugs.freedesktop.org/show_bug.cgi?id=5622 --- in particular, when building xorg-server with gcc-3.4.5, one way or another __GLX_ALIGN64 must be defined; otherwise, you will see random Bus errors from libGL (Mesa) applications.
Created attachment 77283 [details, diff] Ebuild patch to correct libglx data alignment problems. Attached patch modifies the xorg-server ebuild so that it forces correct data alignment when building libglx.so.
Hi, after building Xorg 7.0 on my U10 I tried to startx and this is what happened: =================================== # startx xauth: creating new authority file /root/.serverauth.20928 xauth: creating new authority file /root/.Xauthority xauth: creating new authority file /root/.Xauthority X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.16-gentoo sparc64 Current Operating System: Linux dfrwadm37 2.6.16-gentoo #1 Thu Mar 23 11:49:41 CET 2006 sparc64 Build Date: 24 April 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 24 17:16:54 2006 (==) Using config file: "/etc/X11/xorg.conf" (EE) end of block range 0xc0000b < begin 0x2c00008 (EE) end of block range 0xc0001b < begin 0x2c00018 (EE) end of block range 0xc0000b < begin 0x2c00008 (EE) end of block range 0xc0001b < begin 0x2c00018 (WW) ****INVALID IO ALLOCATION**** b: 0x2c00400 e: 0x2c004ff correcting Read from remote host dfrwadm37: Connection reset by peer Connection to dfrwadm37 closed. =================================== Now the machine is dead....well, at least it's not pingable anymore. I'm going to look after it tomorrow. I used gcc-3.4.6-r1 to build X.org. The graphics driver is "ati".
Hello, I try to follow http://dev.gentoo.org/~fmccor/files/X-modular.sparc-upgrade and I had to add this lines in my /etc/portage/package.keywords file. >=sys-apps/portage-2.1_pre4 ~sparc >=dev-python/pycrypto-2.0.1-r5 ~sparc >=sys-apps/man-1.6b-r2 ~sparc They are not in http://dev.gentoo.org/~fmccor/files/X-modular.files. is this expected ?
(after reading http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml) argh sorry for the noise (feel so stupid)
xorg-x11-7.1 & friends now all stable on sparc. Please make new X-modular related bugs on sparc block this one (makes bookkeeping a bit easier); if nothing shows up after a reasonable amount of time, I am going to close this as no longer relevant.
(In reply to comment #29) > xorg-x11-7.1 & friends now all stable on sparc. Please make new X-modular > related bugs on sparc block this one (makes bookkeeping a bit easier); if > nothing shows up after a reasonable amount of time, I am going to close this as > no longer relevant. > Closing. It's been about 3 months, and nothing new has shown up here.
