and discover that KDrive was completely masked for MIPS architecture. I guess this means I'm using X11 for a while, which I'm not sure I'll enjoy with only 160MB RAM. Well, I guess it won't be that bad, not like I'm gonna run KDE or anything...

Anyone familiar with the various alternatives to full-blown X on the MIPS hardware? Is KDrive completely foreign to MIPS, or unexplored, or unported? Is it in need of psychotic testers like me?

It looks like my second choice, XDirectFB, is in a similar state.

Any advice or suggestions on the subject of GUIs? I was thinking fluxbox or something similarly lightweight for a wm, but the server seems to be the problem...

and discover that KDrive was completely masked for MIPS architecture. I guess this means I'm using X11 for a while, which I'm not sure I'll enjoy with only 160MB RAM. Well, I guess it won't be that bad, not like I'm gonna run KDE or anything...

Anyone familiar with the various alternatives to full-blown X on the MIPS hardware? Is KDrive completely foreign to MIPS, or unexplored, or unported? Is it in need of psychotic testers like me?

It looks like my second choice, XDirectFB, is in a similar state.

Any advice or suggestions on the subject of GUIs? I was thinking fluxbox or something similarly lightweight for a wm, but the server seems to be the problem...

It's masked because no one has tested it. Use the "ekeyword" command (emerge gentoolkit-dev first if needed) to add keywords to kdrive (it might also go under the name of "xserver" too) and try to merge it. I'd be interested in how far you get, and if it does merge completely, try to set it up and get it running with something like fluxbox (fluxbox will need a mips keyword as well to merge, btw). Do this in a portage overlay so that when you emerge rsync, your keyword changes won't get lost.

One of the people in #gentoo-mips has gone as far as to run KDE-3.x on his Indy, as well as playing xmms and a small AVI (the IBM Linux Commercial) all at the same time. Goes to so these systems aren't as weak as they sometimes seem to be.

I got X working -- it's really snappy. Fluxbox works great, no problems so far. Of course, 8-bit color isn't very flattering...

I'll work with getting KDrive working later today, although it doesn't really seem worth it at this point. I thought that the main benefit should be speed, but X seems only slightly slower than on a 1GHz. I'll check out the memory usage and see how the Indy responds under heavy loads... and if I can get the KDrive ebuild working.

There has been work on integrating a 24bpp accelerated X patch into the XFree86 ebuild in Gentoo for MIPS systems, but there are some downsides with the patch. For one, it doesn't support dynamic loading, so it has to be built as a static binary, and the other issue is GTK2+ applications aparently do not work. Has something to do with the font not displaying. Hopefully these issues will get fixed in a later version of the patch, but I'm unsure of the status on this.

New 24bpp XL card went in and worked without a hitch, surprisingly enough. Just had to change default bit depth in XF86Config to 24. Just like it should be. Just like things so rarely are in Linux

Fluxbox and Windowmaker work wonderfully. How FVWM works will not be known until I figure out how to configure that intimidating wm. Scary. I got about sixteen changes in and practically broke out in a cold sweat

KDE -- that's crazy. Qt fails on mine, probably some nasty x86 assembly. I was merely curious anyway to see how far the install would get. I'm emerging Gnome right now, but that's more for comfort than anything else.

If anyone's lurking and weighing the pros and cons of using an Indy as a lite desktop, I'd say go for it. It's not got oodles of power, but Flux is in 1280x1024x24bpp and runs XMMS and compiles with two parallel makes just fine. A little skip every once in a while, but the damn thing's competitive with my Athlon :-/ I'll weigh in with success/failure stories of various applications, as I'm quite curious to see just how much this little machine can handle once it's tweaked.

I'm assuming since you got X to run in 24bpp, you used the 24bpp accel patch for the Newport driver? Did you have to build X as a static lib and do GTK2+ apps display properly for you? Checking up on these as the only other people to have run such apps (and use the accel patch) had these issues too.

As for QT, you probably had issues about branches out of range, which is a binutils issue. The trick currently being evaluated is to pass -Wa,--relax-branches (or -Wa,--relax-branch, one of the two...) to g++ during QT's build process, but QT has turned out to be one of those more interesting things to tweak CXXFLAGS on. The one guy working on this is out of town for a few more days, though, maybe he'll have more insight when he returns.

I'm assuming since you got X to run in 24bpp, you used the 24bpp accel patch for the Newport driver? Did you have to build X as a static lib and do GTK2+ apps display properly for you? Checking up on these as the only other people to have run such apps (and use the accel patch) had these issues too.

As for QT, you probably had issues about branches out of range, which is a binutils issue. The trick currently being evaluated is to pass -Wa,--relax-branches (or -Wa,--relax-branch, one of the two...) to g++ during QT's build process, but QT has turned out to be one of those more interesting things to tweak CXXFLAGS on. The one guy working on this is out of town for a few more days, though, maybe he'll have more insight when he returns.

--Kumba

OOH! Beautiful! Thanks so much!
I was confused about why so many programs would build and not Qt (and certain others). I know little about programming. Suppose I should have included the actual error messages, but that would have been too smart

EDIT: After some time has passed, I have realized that I have precisely no idea of how to pass those flags. I guess I'll do some digging later. Could be that I had it right at some point but Qt using its own flags decided to fuck me. Thanks again!