This is a running report on the status of xorg-x11-6.8.0 release on sparc systems (sparc64 kernels 2.4.xx & 2.6.xx, sparc32 kernel 2.4.xx). I am assigning to x11@gentoo.org because a patch to the ebuild resolves the issues which otherwise make this xorg version very hard to use on sparc. With the (to be attached) patch to the ebuild for 6.8.0, 6.8.0 seems to build and run fine for sparc. Here are the problems I know about with comments. Generally, however, the problems here are summaries; please see generally: http://dev.gentoo.org/~fmccor/files/xorg-x11-6.7.99.903-build_notes.txt http://dev.gentoo.org/~fmccor/files/xorg-status-tests.txt 1. Keyboard issues with kernel 2.4.xx and the new keyboard driver. Please see Bug 61940 and the patch for a workaround (which is to build the old driver, too). This seems to be an xorg problem in the kbd driver, but someone else might know better. 2. On sparc32, the build might run into a manifestation of Bug 46593. The patch to the ebuild eliminates this. 3. If you happen to be using the hardened gcc compiler, for sparc, at least, you currently must "soften" it to get a good xorg-x11 build. If this applies to you, just apply the patch and build with "USE='hardened'" 4. There are various issues with Creator (ffb) video and dri. Some good, some not. a. ffb_dri (the libGL dri module) now loads. However, it is not quite complete yet, and it might or might not work for you. If you have problems, just export LIBGL_FORCE_XSERVER='yes' ; setenv LIBGL_FORCE_XSERVER 'yes' ; or whatever. b. If you are using kernel-2.6.7, you (I, at least) cannot get at drm for ffb, no matter how you configure your kernel. This seems to be a kernel problem. 5. Otherwise, 6.8.0 seems clean for sparc. See generally Bugs 60292, 61063. (Do make sure to upgrade to ttmkfdir-3.0.9-r2, however.)
Created attachment 39575 [details, diff] xorg-x11-6.8.0.ebuild patch to help with building on sparc. With this patch applied to 13.ix.04 version of xorg-x11-6.8.0.ebuild, the resulting ebuild works correctly for me on: 1. U2 (2x300), ffb2+, kernel-2.4.26-r1 2. U2 (2x400), ffb2+, kernel-2.6.6-rc2 3. U60 (2x450), afb, kernel-2.6.7-gentoo-r14 4. U60 (2x300), ffb2+, kernel-2.6.6 5. SS20 (2x75), cg6, kernel-2.4.27-sparc Resulting xorg-x11-6.8.0 installations work-for-me(tm) (All built with USE='hardened bitmap-fonts' because all my compilers are built hardened, and I want to exercise the entire build.)
I guess this is a tracker, at least for me, and it does include a patch which helps out a lot on sparc. So I'll try out a couple keywords.
Created attachment 39653 [details, diff] Replacement patch to the ebuild (better citizenship & provide for mach64 testing) 1. Better citizenship ('config/cf/host.def' now has a name: ${HOSTCONF}) 2. By popular demand, if built with USE='insecure-drivers', the mach64_dri module will be created for sparc. Since I am using this bug for status tracking, here are some comments about mach64. a. Currently, I cannot test this module myself. The people who have asked about it will have to help with that. b. To use it, you will probably need support compiled into the kernel. This appears to be: CONFIG_DRM_RADEON=y (or maybe CONFIG_DRM_R128=y. Or just use both. Or use =m. xorg should load it if needed.). c. If you don't have it already, you will want to 'Load "drm", Load "dri", Load "glx"' in xorg.conf It's the glx module that loads the dri module, and your xorg mach64 driver might want the others. d. Useful environment variables: LIBGL_ALWAYS_INDIRECT="don't use mach64_dri under any circumstances if set" LIBGL_DEBUG="verbose" MESA_DEBUG="not unset" MACH64_DEBUG=<bit-string>, chosen from: #define DEBUG_ALWAYS_SYNC 0x001 #define DEBUG_VERBOSE_API 0x002 #define DEBUG_VERBOSE_MSG 0x004 #define DEBUG_VERBOSE_LRU 0x008 #define DEBUG_VERBOSE_DRI 0x010 #define DEBUG_VERBOSE_IOCTL 0x020 #define DEBUG_VERBOSE_PRIMS 0x040 #define DEBUG_VERBOSE_COUNT 0x080 #define DEBUG_NOWAIT 0x100 If you're going to play with mach64, make sure everything is compiled in to the kernel and all needed modules are present in xorg.conf. Then, examine the Xorg log file carefully to see what it says about its graphics support. Next, make sure LIBGL_DEBUG='verbose' and carefully examine what glxinfo says. If this all looks good, you are ready to become a pioneer for Gentoo sparc.
Comment on attachment 39575 [details, diff] xorg-x11-6.8.0.ebuild patch to help with building on sparc. Updated by replacement.
no, mach64 needs the mach64 kernel module, not r128 or radeon. this isn't in the stock linus kernel yet because it's horribly insecure; might be in x11-drm or something though.
i'm on x11@ now, unccing myself
Yeah, it's in x11-drm.
With VIDEO_CARDS='mach64' x11-drm-20040827 does build a kernel module for mach64. Depending on your existing kernel configuration, you might have to modify the configuration to get it to load. It builds with both kernel-2.4.xx and 2.6.xx; whether it works with either, I do not know. And, you probably want to make sure you use the correct compiler for kernel generation, because this is a module you are going to load into the kernel.
6.8.0-r1 builds and works fine on my u5 w/ 2.4.27-sparc-r2 with ferris's patches & recommendations (old keyboard driver). x11-drm builds, but has unresolved symbols due to the mach64 dri driver using virt_to_bus which is deprecated in favor of pci_map. Other pci dri drivers use this, i think mga, savage and maybe others, and it's broken for all, not just sparc as long as they're on the pci bus.
Created attachment 39875 [details, diff] Corresponding patch for xorg-6.8.0-r1 Corresponding patch for xorg-6.8.0-r1, as of 2004/09/18 10:26:25. Only difference it an adjustment of line numbers and keywords. This version of xorg-x11 (6.8.0-r1) is not known to work on sparc yet, however.
Let me modify that a bit: It is known to work, just not by me, yet. Sorry to speak before remembering status.
Comment on attachment 39653 [details, diff] Replacement patch to the ebuild (better citizenship & provide for mach64 testing) No longer needed; #39875 works for xorg-x11-6.8.0-r1, and it seems fine to me.
To expand on that, xorg-6.8.0-r1 seems OK on sparc, and could satisfy the concerns in Bug 64152. Sparc people, if you haven't. please feel free to grab the latest little ebuild mods and play.
I finally got a chance to play with this and it builds and runs on a Blade 100 with the ATI Mach 64 Framebuffer. No problems so far. I'll keep playing with it and see how it goes.
I won't be able to get to this tonight as anticipated, sorry. It was a 12-hour day of work plus some mind-numbing reading afterwards, and I'm too tired. I'll try for tomorrow night. I do have a couple of questions/comments about the patch, though: 1) Neither the ffb nor the mach64 DRI drivers are built without that hack forcing them into DevelDRIDrivers? 2) The kernel check isn't quite good enough yet. It really needs to check for kernels <2.6, not kernels !=2.6. Otherwise, in the event of >=2.7 kernels, it will unexpectedly break. The easiest way to do this may prove to be splitting the version into major and minor, then doing if [ MAJOR -lt 2 -o MAJOR -eq 2 -a MINOR -lt 6 ], or something along those lines. kmod.eclass or kernel-2.eclass may have some good ideas worth stealing to xfree.eclass (yeah, bad name, I know) or just adding to the ebuild. Maybe enhance is_kernel() to do both the /usr/src/linux check and the uname fallback, or create some new function incorporating both is_kernel() and the fallback.
Thanks for the comments. In response, 1. ffb should always be built. I put it in the DevelDRIDrivers on insecure-drivers use in anticipation of Gentoo driver development and testing. ffb_dri is still an xorg "work in progress" (Ajax, please correct me if I am wrong.). But we (Gentoo sparc linux) are about the only people in a position to work on it and test it, simply because of who has what systems. (We know of problems, but can't really expect xorg to jump right on them, because last I knew, they couldn't verify.) I have not checked on just what gets built for different permutations of the DevelDRI... possibilities because (1) Build cycle for xorg on sparc takes a long time and (2) I really do want to provide for the ffb_dri-is-even-more-DEV-than-usual option. 2. You are right about the kernel check. I would suggest one of three approaches: a. Leave it as it is, for now at least, because it is intended as a temporary work-around for existing bugs (one apparently in xorg kbd, one in kernel) and should disapper. b. Just do it unconditionally. It works fine on any system. It's just tacky if you don't need it. (I found this out by accident, because the original test --- [ ! `is_kernel "2" "6"` ] --- does not quite work as intended and so the !( `is_kernel "2" "6"` ) alternative, and for one round of testing put the 2.4 workaround into a 2.6 system.) This has the additional advantage of allowing easy alternation between kernels. c. Split it up. Just do the echo-comment-line unconditionally (See Seemant's Comment 14 at Bug 46593), and leave the kernel check as-is for the kbd driver. I expect this to be a temporary problem (between xorg & us it should get resolved), but it can't be high priority on anyone's list right now because it doesn't block anything. Anyway, I would not like to get hung up on the kernel check, because the keyboard problem I am having with kernel-2.4 is really the only thing keeping us from ~sparc-ing 6.8.0-r1 (most sparc systems right now are kernel-2.4.27 or 2.4.26-r?) Anyway, this is intended as a temporary solution to facilitate testing and migration while we work with xorg to eliminate the reasons for it. 6.8.0 offers enough potential benefit for us that we want to move rather quickly on it. (Unfortunately, you know how "temporary solution" goes....)
Oh, to the original question. As to mach64 -- it really does require that special treatment, because it is the sort of thing 'insecure-driver' describes, apparently. The people interested in it are Weeve, gustavoz, Skunky, and me (and for all I know, a silent majority of other sparc people --- but if so, they are, well, silent.)
If you need to compare versions, you could always use versionator.eclass...
OK. If you'd like to translate your DevelDRIDrivers stuff to a patch of xc/config/cf/, that's what will be needed. Procedure here will basically be, (1) finding where and which drivers are put in DevelDRIDrivers on sparc, and (2) adding ffb and mach64 to the list, if they aren't already there. Then all we have to do is enable DevelDRIDrivers, same as we do for the other USE=insecure-drivers (I think).
BTW: If you can't get the config/cf/ stuff figured out, I'll look at it. Just let me know.
In xorg.cf, it gets set one of two places: Thus, # ifndef DevelDRIDrivers # define DevelDRIDrivers ffb mach64 savage unichrome # endif But this is inside an #if defined(i386Architecture) || defined(ia64Architecture) Otherwise, xorg.cf uses /**/ later on by default. There are no other possibilities. A quick check shows that in any case, just setting BuildDevelDRIDrivers doesn't add anything at all, and except for i386, there's nothing to add (and if i386 happens to try ffb, results will be dissapointing). For other architectures, you don't set up DevelDRIDrivers anywhere, you just say to build them. For sparc, a check at lib/GL/mesa/drivers/dri/Makefile shows that by default the build list is nothing at all, as one would expect because the only way to get any at all is to ask to build them and to be on i386/ia64. So, the sparc-specific DevelDRIDrivers aren't defined anyplace at all. The alternatives are to put the Devel drivers in host.cf, or to patch xorg.cf thus: ==================================================================== antaresia cf # diff -u xorg.cf- xorg.cf --- xorg.cf- 2004-09-21 18:15:53.000000000 +0000 +++ xorg.cf 2004-09-21 18:17:03.000000000 +0000 @@ -608,6 +608,10 @@ #endif +#ifndef DevelDRIDrivers +#define DevelDRIDrivers ffb mach64 +#endif + /* Sparc64 Drivers */ #if defined(OpenBSDArchitecture) && defined(Sparc64Architecture) /* Amiga framebuffer module */ ==================================================================== Which is in the SparcArchitecture-specific block of xorg.cf (It does work, by the way.) Since xorg doesn't have any DevelDRIDrivers for sparc, it still seems more straightforward to define them in host.def rather than to generate a patch against xorg.cf, but it doesn't matter to me one way or the other. Strictly speaking, we don't need ffb in that list because it gets built anyway, but it seems cleaner to leave it, since right now it can be considered both available and in development. In any event, mach64 definitely should be in the sparc DevelDRIDriver list. As previously metioned, 'insecure-drivers' is precisely what it is one of, and it does build for sparc.
It already defines DriDrivers ffb, you shouldn't need to have it twice (once there, once in DevelDRIDrivers). You should just be able to have mach64 in DevelDRIDrivers, and have both be built when DevelDRIDrivers is turned on.
Just to clarify: having ffb in two places is redundant and makes it harder to figure out what's going on. Things should live in one or the other, not both.
Could you expand on point 2b, please?
Committed as ebuild rev 1.8. I'd like to finish discussing 2b before closing this, however.
Concering point 2b (Ajax, please correct details) and keyboard drivers: The thrust of this is to make sure xorg-x11-6.8.0+sparc+kernel-2.4.xx works as seamlessly "out of the box" as possible. Specifically: 1. You always get the "kbd" driver, whether you ask for the Deprecated driver or not; 2. If you don't ask for the deprecated driver, then the kbd driver is set up with a module record for "keyboard" as well as for "kbd", so that it is always used both for 'Driver "keyboard"' and for 'Driver "kbd"'. And, xf86Init sets up the structures necessary to get at the built-in driver. 3. So far as I can tell, right now the built-in (deprecated) driver is always built, and Deprecated... determines only whether you can get at it or not. 4. The current problem (for me, at any rate) is that with kernel-2.4.xx and a sun keyboard, you need to specify 'XkbRules "sun"', and right now, the "kbd" driver has problems with that. (With kernel-2.6, a sun keyboard wants "xorg" rules, and that works fine. The kernels define keycodes sent from the keyboard differently, and with kernel-2.6, a sun keyboard looks like any other keyboard.) 5. No matter what kernel, you can always ask xorg to set up for the Deprecated keyboard driver. 6. The physical driver files /usr/X11R6/lib/modules/input/[kbd_drv.o, keyboard_drv.o] are always the same. It's just that if you ask for Deprecated driver and for "Driver 'keyboard'", keyboard_drv.o cannot be used (no driver record), but Init will have set up a driver record for the built-in driver for you as a fallback. If you haven't specified Deprecated at build time, keyboard_drv.o will have a driver record for keyboard, and you will actually be using "kbd" in any case. In fact, if, like me, you need to switch between kernels for some reason, you need to build with UseDeprecatedKeyboard = YES (so that you can always get at the driver you want.) I think there is a problem in the kbd driver which causes this; it might or might not be worth fixing (that's between xorg & Gentoo x11 herd; it's all the same to sparc.) I cannot rule out that the problem is a user error on my part. But if it is, when you use {the "kbd" driver+sun keyboard+kernel-2.4}, what you need to specify in the xorg.conf file for that keyboard is so incompatible with existing requirements that nothing rational I can think of makes it work. (As for the other point about double specification of ffb. No, you don't need it in both places and it is redundant. I did it as a note to myself that ffb_dri.so right now is in an intermediate state between ready for use and you get it only if you know you want it. I really want it always there because it is so easy to disable on a case-by-case basis if you have a program it doesn't work for; on the other hand, I know it has problems. On the third hand, before this release, it wouldn't even load so nobody (but me) could make it work at all. .....)
calling ffb_dri.so a work in progress might be a bit generous, as it assumes progress is being made. if you find anyone sufficiently motivated to fix it feel free to point them at me and/or #dri-devel. as for the kbd driver issue on 2.4, if you could post an X log of trying to use it and failing, i'll open a bug for it upstream.
OK, thanks for explaining that, Ferris. One last, little question: Why'd you have to change the kernel test to have parentheses around the ! part?
Lots of questions. Here are some comments. 0. xorg-x11-6.8.0-r1 now seems fine. Thanks, Donnie. (This message is generated from it). 1. I need !(`is_kernel...`) after a lot of experimentation. is_kernel succeeds or fails, it turns out, so I needed to check its exit status rather than its value. For that, I finally figured out that !(...) was what was needed. For ciaranm, this would have been obvious. For me, it took a lot of experimenting. I discovered it by accident when I saw that a kernel-2.6 build had DeprecatedKeyboard set. (I ended up just extracting the little is_kernel stuff from xfree.eclass and trying everything that seemed reasonable.) 2. ajax -- as for kbd driver. The log file looks fine. When you use sun-kbd+kernel-2.4+kbd-driver, it opens the keyboard fine. The problem comes up like this: With kernels earlier than 2.6, the kernel uses KEYMAP="sunkeymap" (2.6 uses ="us", say). With the deprecated keyboard driver, this translates into KbdRules "sun", so, for example, here is a working keyboard specification: Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "Protocol" "Standard" Option "XkbKeycodes" "sun(type5)" Option "XkbModel" "type5" Option "XkbRules" "sun" Option "XkbLayout" "en_US" Option "XkbTypes" "types/complete" Option "XkbCompat" "compat/complete" Option "XkbGeometry" "sun(type5unix)" EndSection taken from a kernel-2.4.27 U60 running xorg-6.8.0-r1 right now (Deprecated Driver). Here is the corresponding definition from a 2.6.6-rc2 kernel U2 sitting right beside it: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "type5" Option "XkbRules" "xorg" Option "XkbLayout" "en_US" Option "XkbGeometry" "sun(type5)" EndSection Now, in the first case, if instead you use "kbd" for the Driver, it almost works: There is a key map shift for some keys, like this: q-key --> 'w', w-key -->'e', a-key --> 's', and so on. Also, z-key, x-key, space-key, etc --> <dead> If you play much with the InputDevice specification (and I've played with it a lot), things can become exciting: E.g., (both true!) xinit -> <reboot> Lshift-key --> <reboot> and other asocial behavior. As I said, I might just be doing something wrong, but if so, it is far from obvious (to me, at least), and I have been more concerned with making sure 6.8.0 would cleanly and easily install. (That is, it loads & uses "kbd" -- "kbd" just seems to get sun rules a little wrong.) 3. sun_ffb "work in progress" -- that's because I'm working on it :)
Not sure you need parentheses or backticks in that case. Similar to "! use foo"
By the time I hit on something that worked, I was beyond searching for elegance. :)
Comment on attachment 39875 [details, diff] Corresponding patch for xorg-6.8.0-r1 Since it's incorporated into the ebuild, there is no reason for anyone to use it.
Patch no longer needed, as its functionality is now a part of xorg-6.8.0-r1.ebuild itself.
Nothing left but tracking unless (until) bugs for someone come up.
6.8.0-r1 works for me [ultra5/mach64], the only small gotcha I found (thanks ferris) was with the sunmouse moving randomly. Unplug/replug the mouse back into the keyboard then restartx and it's fine. Two thumbs up.
xorg-x11-6.8.0-r1 is now going stable, clearing Bug 64152 for sparc.
Created attachment 48470 [details, diff] Apply the xorg Bug 1891 xaa-for-sunffb patch to sunffb, optionally on USE=xaa Alex Jackson (ajax) recommends the body of the patch for sunffb. You can try it by applying the patch in x11-base/xorg-x11, then building with USE='xaa ...' See https://bugs.freedesktop.org/show_bug.cgi?id=1891 for background. My observations: 1. The resulting sunffb_drv does work and supports xaa; 2. glx (direct) is not available if this patch is used (indirect is fine); 3. For some applications --- like xchat-2, reading this bug, xclock, etc. --- color scheme is different. 4. cfb is still required, despite comments to the bug at xorg. Patch is available for anyone who whats to play and comment back. It should not be incorporated until points 2, 3 can be explained satisfactorily.
Created attachment 48515 [details, diff] Apply xorg Bug 1891 xaa-for-sunffb patch to sunffb, activate with USE=xaa Fix a couple typographical errors. Do not imply in comments that all references to cfb are removed from sunffb: they are not.
The xaa "different color scheme" seems to be simply [r,g,b,alpha] <--> [b,g,r,alpha] for gtk+ applications in some circumstances. geoman@gentoo.org provides this example, which is the same as what I am seeing. http://beerandrocks.net:8080/~spbecker/newportcolors-funky.png (Reference, comment 37, #3.)
The RGB/BGR color issue sounds exactly like: https://bugs.freedesktop.org/show_bug.cgi?id=1895
It seems related. In fact, with xaa-patch installed, libSDL works correctly with ffb. So, I suppose, a patch for xaa patch which corrected colors for things like xchat-2 would cause ffb+SDL to fail again? Actually, then, a double sort of patch would be required. xaa needs to get colors right for things like what this bug report looks like on my screen right now, then on top of that xorg's patch at 1895, maybe? I can easily apply that patch and see what happens (1895).
I'm too pessimistic. If you take the xaa patch and add the patch ajax mentions at Comment 40, then colors for xchat & friends are correct, and libSDL is correct, too. I'll merge the xorg 1336 patch with the xaa patch (48515) in a bit, although I think we always want 1336?
Created attachment 48609 [details, diff] Apply xorg Bug 1891, 1895 xaa-for-sunffb patch to sunffb, activate with USE=xaa Incorporate patches from both xorg's bugs 1891, 1895 into patch to activate xaa. Note that with both applied, with xaa, all colors (xchat & friends, libSDL) seem correct. Without the xaa patch at 1891, libSDL remains broken (because sunffb does not use fb at all without xaa patch, so correcting fb will not help sunffb unless xaa patch is present.)
xorg-x11-6.8.0-r4 is now marked stable for sparc, and it should be the last release denoted "6.8.0". Therefore, I am closing this as there is nothing more to track. Any xorg-x11-6.8.0-r{x} problems should now be reported as individual bugs.
Created attachment 49674 [details, diff] Enable xaa in sunffb driver for ffb/afb. [r,g,b]<->[b,g,r] portion no longer needed. Same patch, but do not actually apply the 072 patch for [r,g,b] <--> [b,g,r] because it is in the master patch set now.
