There is a lot of bugs reported about KDE4, which is natural for system in heavy development. The problem is that many of them are graphic adapter related.
The previous version of KDE was designed few years ago and it used graphic capabilities that were available at that time. That means large part of KDE3 stability on wide variety of hardware platforms can be attributed to well tested hardware drivers.
The desktop, like KDE, GNOME or any other lesser known, is third layer of software, sitting at the top of X server, which is at the top of kernel. The hardware drivers are kernel business, so if they fail all other layers will fail as well. The effects can range from failure to display some element on the screen, that is using missing or buggy feature, to system lockup where only power button can help, with all kinds of weird behavior in between those two.
KDE4 is attempting to use newer features, which has as a consequence that now we can see bugs that are mix of genuine Qt, KDE and X server bugs, and hardware driver bugs that before went unnoticed. That is the worst possible mix for debugging, specially for guys that are not familiar with heavy duty debugging tools and procedures, like me, but there is some help.
People that can use distribution configuration tools, and tell Xorg (X server) what driver to use can use open source driver and eliminate at least that from equation.
I'm using Nvidia legacy graphics, FX 5200 and even older MX 4000.
Consequence is that I have to wait until Nvidia developers find time to fix, or backport fixes, to those drivers, or use the opensource nv driver. The legacy drivers are not top priority at Nvidia, as they want to fix current (recently sold) drivers first.
The other option, nv driver, is halfway help.
It will help to see is it proprietary (commercial) driver at fault, or some other component above in the stack, but you and KDE will miss 3D capabilities of your graphic card.
No comments:
Post a Comment