Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
1.42ghz overclocked to 1.5 with 1gb ram, and original 40gb spinner.

Cheers
I wanted to get an eMac to use arctic fox on, (as a daily use machine) but it can't run Linux (graphic issues that were never solved) is the arctic fox on tiger/leopard as good as the Linux version?
 
I wanted to get an eMac to use arctic fox on, (as a daily use machine) but it can't run Linux (graphic issues that were never solved) is the arctic fox on tiger/leopard as good as the Linux version?

The working PPC OS X build of Arctic Fox is buggy and unfinished. The Linux version is more or less in the same camp as the Snow Leopard build (although maybe slightly more stable) as a fast, reliable, fully-featured web browser.

For Tiger / Leopard, I suggest trying AquaWeb or TFF with the new universal optimized prefs available on AquaWeb's page. From what I remember, AquaWeb and Arctic Fox are in about the same ballpark in terms of speed.

I'm actually using my 1.42 eMac now as primary machine, and it's pretty good with the aforementioned apps. Gets the job done. :)
 
  • Like
Reactions: dextructor
It would be nice if we could port Quantum to 32bit PPC too.

I have it at least building. It appears that more patching will be needed in xptcall, but I might figure it out depending on how much time I have. The primary issue was that the Rust compiler on ppc32 had some bugs that prevented a specific module in FF from being built, and patches now exist for that (previously it could be worked around by cross-compiling from another host). The rest is mostly patching the C++ code that has broke since (to my awareness it's just xptcall, also webrtc does not build but that's disableable and could probably also be fixed).
 
I have it at least building. It appears that more patching will be needed in xptcall, but I might figure it out depending on how much time I have. The primary issue was that the Rust compiler on ppc32 had some bugs that prevented a specific module in FF from being built, and patches now exist for that (previously it could be worked around by cross-compiling from another host). The rest is mostly patching the C++ code that has broke since (to my awareness it's just xptcall, also webrtc does not build but that's disableable and could probably also be fixed).

I wonder if it will also show the blue tint issue on ppc32.
 
I wonder if it will also show the blue tint issue on ppc32.
So it may just be something in Debian.

Oh, that's definitely an issue everywhere (regardless of GPU), and it will also be an issue on 32-bit (it's an endianness-related color handling bug).

In the past, the issue used to be global (the culprit here is largely Google's Skia library, which is written only for little endian and Mozilla gradually patched these problems out, but not yet completely - in the past Firefox used to use the Cairo library, which is why old versions of FF don't show the issue), at this point it's only with some specific CSS transforms (which is why only parts of certain sites look broken).

As far as I know it's being worked on, so a complete fix should be expected in a future release.
 
Oh, that's definitely an issue everywhere (regardless of GPU), and it will also be an issue on 32-bit (it's an endianness-related color handling bug).

In the past, the issue used to be global (the culprit here is largely Google's Skia library, which is written only for little endian and Mozilla gradually patched these problems out, but not yet completely - in the past Firefox used to use the Cairo library, which is why old versions of FF don't show the issue), at this point it's only with some specific CSS transforms (which is why only parts of certain sites look broken).

As far as I know it's being worked on, so a complete fix should be expected in a future release.
Thanks for the in depth insight.
 
Yes, that's correct. G5 requires a monitor to be detected/connected at boot time, so I kept the 6600 in, and once Linux comes up, the R5 235 takes over.

Did you have to make a custom Xorg configuration file?

I have a GeForce 6600 and a PC X600, but had issues getting the X600 to play nice, seem by default Xorg wants to use the AMDGPU driver, but only the older radeon driver seem to work with the X600.
 
Did you have to make a custom Xorg configuration file?

I have a GeForce 6600 and a PC X600, but had issues getting the X600 to play nice, seem by default Xorg wants to use the AMDGPU driver, but only the older radeon driver seem to work with the X600.

yes, but the problem is different (it won't really attempt to use a "wrong" driver, that stuff is controlled via pciids and so on), xorg doesn't like when it sees two GPUs (even if the other has a blacklisted module, it will still appear in lspci), and you need to help it decide which one to use. That's why I created a file /etc/X11/xorg.conf.d/21-gpu.conf, with contents like this https://clbin.com/FSXZ0

The BusID numbers need to be adjusted per-machine, e.g. for my lspci listing: https://clbin.com/LZHEO , 0001:06:00.0 becomes PCI:6@1:0:0, 0000:0a:00.0 becomes PCI:a@0:0:0.

You're free to use another xorg driver, of course. I use the modesetting default, using another DDX (ati, nouveau) may give you say, legacy-style 2D accel paths, I never bothered myself.
 
  • Like
Reactions: dextructor
yes, but the problem is different (it won't really attempt to use a "wrong" driver, that stuff is controlled via pciids and so on), xorg doesn't like when it sees two GPUs (even if the other has a blacklisted module, it will still appear in lspci), and you need to help it decide which one to use. That's why I created a file /etc/X11/xorg.conf.d/21-gpu.conf, with contents like this https://clbin.com/FSXZ0

The BusID numbers need to be adjusted per-machine, e.g. for my lspci listing: https://clbin.com/LZHEO , 0001:06:00.0 becomes PCI:6@1:0:0, 0000:0a:00.0 becomes PCI:a@0:0:0.

You're free to use another xorg driver, of course. I use the modesetting default, using another DDX (ati, nouveau) may give you say, legacy-style 2D accel paths, I never bothered myself.
Modsetting gives you GPU acceleration?
[automerge]1570893301[/automerge]
I also have an issue with FFQ that text from code boxes disappears when I try and select it to copy.

Also the reply box on this forum seems to do that, sometimes when I am replying here, the text disappears, since the forum software upgrade.

Also, embedded Youtube video plays just fine, tho with the blue tent issue, however if I go to Youtube.com and try and play the same video, or any video, it just never loads.
 
Last edited:
Modsetting gives you GPU acceleration?

modesetting is basically "leave everything to the low level stack", a minimal xorg driver that will work with any KMS kernel driver - which, with modern kernels, means any kernel driver. So basically similarly to e.g. wayland (you don't have any hardware-specific userland drivers there either). Technically, you don't even need a display server to get accel nowadays, you can run hardware accelerated stuff directly in your virtual terminal.

But, the xorg-specific ddx drivers still exist for 1) old kernels that don't have kernel modesetting 2) hardware-specific 2D acceleration paths that are not implemented elsewhere and exist purely in userland on xorg side, e.g. XAA/EXA/UXA/SNA - with modesetting your 2D acceleration will be done generically over OpenGL using GLAMOR instead (which works fine on anything reasonably modern where the opengl impl is not extremely buggy, but ymmv)

--

for youtube: there are some switches in about:config one needs to flip to false (media.webm.enabled and media.mediasource.webm.enabled, i think), also color in youtube and other videos is fine but it needs a patch (which I ship in Void but not sure about other distros like Debian)
 
modesetting is basically "leave everything to the low level stack", a minimal xorg driver that will work with any KMS kernel driver - which, with modern kernels, means any kernel driver. So basically similarly to e.g. wayland (you don't have any hardware-specific userland drivers there either). Technically, you don't even need a display server to get accel nowadays, you can run hardware accelerated stuff directly in your virtual terminal.

But, the xorg-specific ddx drivers still exist for 1) old kernels that don't have kernel modesetting 2) hardware-specific 2D acceleration paths that are not implemented elsewhere and exist purely in userland on xorg side, e.g. XAA/EXA/UXA/SNA - with modesetting your 2D acceleration will be done generically over OpenGL using GLAMOR instead (which works fine on anything reasonably modern where the opengl impl is not extremely buggy, but ymmv)
Thanks, cool, I'll give it a try with the X600 when I have time and see how it works.

I don't know why Apple made these G5's that won't boot without a display connected to a FCode ROM video card, annoying.

Was it only the PCI-E G5's or do the AGP G5's also not boot without a display?

I had a AGP 1.8Ghz SP G5 back in the day when they were new, and don't recall this being an issue.
 
Was it only the PCI-E G5's or do the AGP G5's also not boot without a display?

no clue about that, the only G5 I own is a PCIe dualcore one. I mostly deal with modern/little endian POWER hardware (POWER9 and so on), the old ones are mostly for testing (Macs are the easiest and cheapest way to get access to some legacy PowerPC, e.g. IBM IntelliStations are much harder to get :p)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.