FreeBSD+Xorg+KDE+7174 freezes if the "RenderAccel" is "true"

[AndrewM]

If option "RenderAccel" is "true", at start of the KDE-programs(not gtk), the Xorg freezes, and does not react to the keyboard and mouse.

NV18B NVIDIA GeForce MX440 with AGP8X
nvidia-driver-1.0.7174,
5.4-RELEASE, Xorg-6.8.2,KDE-3.4.0
And as on
5.4-STABLE, Xorg-6.8.99.5

А.М.

[gilboa]

Can you access the machine using SSH?
Do you get Xid messages in the kernel/system log?

I wonder if the Xid problem also plagues FreeBSD as well as Linux.

Cheers,

[Linuxhippy]

this is a (known?) driver bug, happens on my GF488Go/Linux-2.6.9 too.
Since GTK is not as advanced as QT and does not use RENDER althought its available the bug does not occur, turn it off and it will work fine.

(I went back to 6629 since it works stable and I have FULL ACCERLATION withought drawbacks)

lg Clemens

[AndrewM]

Can you access the machine using SSH?
Do you get Xid messages in the kernel/system log?

$ dmesg | grep -i nv
-------
nvidia0: <GeForce4 MX 440 with AGP8X> mem 0xe0000000-0xe7ffffff,0xec000000-0xecffffff irq 11 at device 0.0 on pci1
-------

I start the Xorg and KDE.
After the Xorg+KDE has frozen.
$ dmesg | grep -i nv
-----------
NVRM: agp_find_device failed, chipset unsupported?
NVRM: agp_find_device failed, chipset unsupported?
NVRM: Xid: 13, 0000 02005600 00001796 00000c2c 00010001 00000080
----------
Whether and it will be corrected in the new version of the driver? And when to wait the new version?

[LubosD]

If it Xids under FreeBSD too the bug must be definitely in X.org or nvidia driver.
Let me think:

It Xids more if NvAGP is set to 1 (now I've played ET with AGP GART for more than 3 hours w/o crashes!).
X.org probably doesn't directly depend on AGP GART or nvidia AGP. So the bug must be in the nvidia driver.

Yeah but:

Xid is little bit confusing. NVidia's code may look like this (if it is in C++...):

while(true)
{
	try
	{
		do_work();
	}
	catch(const UniversalException& e)
	{
		printk("<%d>NVRM: Xid %d: %08x %08x %08x\n", KERN_ERR, e.code, e.a, e.b, e.c);
		while(rand() > 20);
	}
}

If Xid is a totally universal error, the bug may be in nvidia and X.org too

[SuLinUX]

Originally Posted by Linuxhippy

this is a (known?) driver bug, happens on my GF488Go/Linux-2.6.9 too.
Since GTK is not as advanced as QT and does not use RENDER althought its available the bug does not occur, turn it off and it will work fine.

(I went back to 6629 since it works stable and I have FULL ACCERLATION withought drawbacks)

lg Clemens

We did you get the idea that GTK is not as advanced as QT, the theming is far superiour and RENDER has been used in GTK for sometime now.

[Linuxhippy]

Originally Posted by SuLinUX

We did you get the idea that GTK is not as advanced as QT, the theming is far superiour and RENDER has been used in GTK for sometime now.

* No z-ordering at all
* no lazy painting algorythms
* over-locking through trying to provide a tread-safe library
* no intelligent dirty-area handling

I am not a fan of QT, this is just compared to many toolkits out there (lets say fox-toolkit, qt, win32, ...) GTK performs terrible due to its design.
There exist several papers from Gnome hackers about this problems and suggestions for a fix. I really hope that things will become better in GTK-3.0.

lg Clemens

[SuLinUX]

Originally Posted by Linuxhippy

* No z-ordering at all
* no lazy painting algorythms
* over-locking through trying to provide a tread-safe library
* no intelligent dirty-area handling

I am not a fan of QT, this is just compared to many toolkits out there (lets say fox-toolkit, qt, win32, ...) GTK performs terrible due to its design.
There exist several papers from Gnome hackers about this problems and suggestions for a fix. I really hope that things will become better in GTK-3.0.

lg Clemens

Thats not the point, you can talk about code all day but the fact is that GNOME/GTK works much better with xcompmgr and Renderaccl. KDE/QT is very unstable with xcompmgr, logining out when loading up konqueror or other kde fuctionallity. If you want a discussion about KDE/GNOME theming then lets start another thread but there is no contest when it comes to theming and installing them, see GTK2 themes , QT you have to compile themes (unless you can find RPMS for them)

[Linuxhippy]

Ahhn, I did not talk about theming at all - I did talk about GTK in general and some of its weaks.

Btw. you started discussing about themes which is totally off-topic and you also did not add a single on-topic post to this thread, so maybe you should go and open another thread?

cu Clemens

btw. compiled themes have the great advantage that they can use their own rendering-code which saves memory, allows effects bitmap themes never can do and is WAY FASTER since you do not have to blit 4-10 images in average to get something looking nice. So from the technically point of view, bitmap themes really suck.

[Ironi]

Originally Posted by SuLinUX

GNOME/GTK works much better with xcompmgr and Renderaccl.

Perhaps so, but personally I don't care. I keep composite enabled, but only use it for the occasional screenshot. When I want to show off "real" transparency, then I simply launch kompmgr, enable the trans settings in window prefs, take a ss, then disable the settings and kill kompmgr. Maybe that's too much effort for some people, but I don't find it much of a bother considering how often I do so (not very).

We did you get the idea that GTK is not as advanced as QT, the theming is far superiour

How is it superior? Be warned -- If you so much as mention the word "usability," I'm going to shoot your ass with a tranq dart.

FWIW, I prefer KDE themes largely because the widgets and the coloring are separate. Thus, I can use any widget design that I like and choose to color it how ever I will. I can't (easily) do that with GTK themes.

[SuLinUX]

Originally Posted by Ironi

Perhaps so, but personally I don't care. I keep composite enabled, but only use it for the occasional screenshot. When I want to show off "real" transparency, then I simply launch kompmgr, enable the trans settings in window prefs, take a ss, then disable the settings and kill kompmgr. Maybe that's too much effort for some people, but I don't find it much of a bother considering how often I do so (not very).


How is it superior? Be warned -- If you so much as mention the word "usability," I'm going to shoot your ass with a tranq dart.

FWIW, I prefer KDE themes largely because the widgets and the coloring are separate. Thus, I can use any widget design that I like and choose to color it how ever I will. I can't (easily) do that with GTK themes.

1. You have to compile kde themes or look around for a rpm.

2. There are no themes that even come close to the link I put above, QT cannot even do a MacOSX theme proper and even then it took agers to develope.

3. GTK/GNOME themes can be dragged from a webpage as tar.gz and installed instantly, this is even easier than XP's lack luster theme support.

Thats usability.

[Ironi]

Maybe someone should start a new thread...

Originally Posted by SuLinUX

1. You have to compile kde themes or look around for a rpm.

3. GTK/GNOME themes can be dragged from a webpage as tar.gz and installed instantly, this is even easier than XP's lack luster theme support.

So, to summarize, GTK themes are easier to install and KDE themes are easier to customize. I know which I prefer.

2. There are no themes that even come close to the link I put above, QT cannot even do a MacOSX theme proper and even then it took agers to develope.

Eh? Beauty is in the eye of the beholder. Besides, Baghira worked fine and looked fairly accurate (until I customized it, that is) the last time I tried it.

Thats usability.

Please don't use that word -- it's quite vague and extremely overused. I prefer KDE over GNOME because its apps are far more customizable and contain more features.

Also, GNOME isn't exactly the holy grail of "usability." There are quite a few instances in which -- OMG! -- you have to edit text configuration files. I haven't had to do that for KDE apps in years.