Bug 98631

Without trying to defend the suckiness, the nv30 driver is kinda crap and WAY lower quality than what these modern desktops expect. And that's on x86 -- BE PPC is largely untested, although I have made some efforts to get it kinda-working again.

Instead of booting with noaccel=1 you could try removing nouveau_dri.so. That way you still get the X-based accel, but nothing tries to use 3D accel.

(In reply to Ilia Mirkin from comment #1)
> Without trying to defend the suckiness, the nv30 driver is kinda crap and
> WAY lower quality than what these modern desktops expect. And that's on x86
> -- BE PPC is largely untested, although I have made some efforts to get it
> kinda-working again.

Please accept my applaud with your faster-than-light reply.

Where exactly could the latest efforts be obtained? I will be more than happy to test out the results with my machine (also, if you would need SSH access, I would quite happily provide that).

> Instead of booting with noaccel=1 you could try removing nouveau_dri.so.
> That way you still get the X-based accel, but nothing tries to use 3D accel.

I will try that later today, thanks very much!

As a follow up, after removing nouveau_dri.so, I no longer get GPU lock up when starting Plasma desktop.

However, I am still getting weird colors (for example, my KSplash setting has a background of dark green color, but it showed up as bright blue, and there is a black border around the KDE logo and the spinner (I will attach a photograph when I get back to my room).

Apropos Xfce 4.12, notice two variants of the Xfwm4:

= Xfwm4 4.12.3 "released" - Xrender driven compositor,
  it can be run on virtually any machine

$ xfwm4 --version
	...
	Build configuration and supported features:
	- Render support:                               Yes
	- Embedded compositor:                          Yes


= Xfwm4 "not released" - GL(X) driven compositor,
  https://git.xfce.org/xfce/xfwm4/commit/?id=fee08ea
  it can run on NV50 family (Tesla),
  https://nouveau.freedesktop.org/wiki/CodeNames/#NV50
  on e.g. NV30 is slow, i.e. not very useful,
  although it may have to do with the performance of the CPU.

$ xfwm4 --version
	...
	Build configuration and supported features:
	- Embedded compositor:                          Yes
	- Epoxy support:                                Yes



LightDM GTK+ Greeter (lightdm-gtk-greeter) is not accelerated,
therefore it can be run on virtually any machine.


KF5/KDE5 i.e. KWin also provides two variants of the compositor, GL and XRender driven.


One important difference is that Xrender driven compositors aren't tear-free.

For me this sounds like #98039 related

Quote: "After a minute or two, the display responds again, but only showing a black background with several randomly colored pixels, and some white blocks."

Yes, this is exactly what i had on x86_64.
It would be great if you could create a gdb log. With such a log the developers could see if its the same problem like i had here:

https://bugs.freedesktop.org/show_bug.cgi?id=102349

Side note: I had to change from tty to the x-server and move the mouse around to cause a segfault error. Then change back to the tty and read out the gdb log with "thread apply all bt"

Thanks

(In reply to caguduzexi from comment #6)
> Quote: "After a minute or two, the display responds again, but only showing
> a black background with several randomly colored pixels, and some white
> blocks."
> 
> Yes, this is exactly what i had on x86_64.
> It would be great if you could create a gdb log. With such a log the
> developers could see if its the same problem like i had here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=102349
> 
> Side note: I had to change from tty to the x-server and move the mouse
> around to cause a segfault error. Then change back to the tty and read out
> the gdb log with "thread apply all bt"
> 
> Thanks

It will be two weeks before I could get to working with my PowerMac again. Will try and produce one then.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/298.