Posted on

Entscheidung des Presserats zum Chip Artikel Betriebssysteme im Härtetest

Man erinnert sich vielleicht noch an den Betriebssystem Test zwischen Windows 7, MacOS Snow Leopard und Kubuntu in nicht definierter Version letztes Jahr in der CHIP und auf Focus Online. Ich hatte den Artikel damals auch etwas auseinandergenommen. Zusätzlich hatte ich auch eine Beschwerde beim Presserat gegen den Artikel bei Focus Online eingelegt. Motiviert hat mich vor allem, dass über Tage hinweg jedes mal die selbe Werbeanzeige zu sehen war und immer noch zu sehen ist:

Ich sah in der Werbeanzeige für Windows 7 einen klaren Verstoß gegen den Trennungsgrundsatz von redaktionellem und inhaltlichem Bereich wie er nach Ziffer 7 des Pressekodex nicht gestattet ist. Zusätzlich habe ich mir einen der vielen redaktionellen Fehler herausgepickt und eine Beschwerde wegen Verstosses der Sorgfaltpflich (Ziffer 2) eingelegt. Dazu hab ich den Bereich ausgewählt, bei dem ich mich am Besten auskenne und auch persönlich involviert bin (mittlerweile bin ich Miturheber der angeblich fehlenden Funktion und würde daher nun zum Mittel der Gegendarstellung greifen statt den Presserat anzurufen):

Nach nun etwa einem Jahr kam die endgültige Enscheidung: "Beschwerde begründet, keine Maßname, Ziffer 2"

Eine Verletzung des Trennungsgrundsatzes liegt nicht vor, da die Platzierung der Werbung angeblich nicht beeinflusst werden kann. Als Informatiker halte ich diese Aussage für nun ja nennen wir es schwachsinnig. Ein einfaches Tag-System würde bereits ausreichen um zu garantieren, dass bei einem Artikel zu Windows 7 keine Werbung dafür erscheint. Wäre für die Redaktion sehr hilfreich, da man dann nicht annehmen würde, dass der Artikel gekauft ist.

In Bezug auf die KWin Funktionalität hat die Redaktion dem Presserat auch eine Geschichte aufgedeckt, die – ich kommentiere das hier nicht weiter sonst wird es unfreundlich. Der Presserat hatte diese Geschichte der Redaktion abgekauft und die Beschwerde ursprünglich als unbegründet zurückgewiesen. Nun ja ich mag es nicht wenn man über meine Arbeit lügt und habe daher noch einmal geantwortet und Widerspruch eingelegt. Habe die Stellungsnahme der Redaktion auseinandergenommen und darauf hingewiesen, dass ich ehrenamtlicher Entwickler der Anwendung bin, die besagter Funktion, welche nicht existiert, bereitstellt. Der Presserat hat daruafhin die Beschwerde wieder aufgenommen. Im weiteren Verlauf hat die Redaktion ihre Meinung geändert und bestätigt, dass Kubuntu die Vorschaufunktion besitzt, aber sich auch ein neues Märchen ausgedacht, von wegen auf Ati funktioniert das nicht (hmm welche Karte verwende ich? Ach richtig Ati). Für mich ist das eine weitere Bestätigung, dass die Redaktion eine Entwicklerversion getestet hat, bei der manchmal halt der Catalyst Treiber nicht verfügbar ist. Schwachsinn ist das ganze dennoch, da ich bereits in meiner Stellungsnahme auf die XRender Funktionalität hingewiesen hatte. Ich spiele mit dem Gedanken nun noch einmal an den Presserat zu schreiben ohne erneut Widerspruch einzulegen. Im Gesamten sieht der Presserat nun aber doch die Sorgfaltpflicht verletz und hält die Beschwerde für begründet. Jedoch wird keine Maßnahme ergriffen, da online die Bildbetitelung abgeändert wurde:

Kubuntu-Linux: Eine Übersichtsfunktion für offene Fenster ist serienmäßig auf Systemen ohne OpenGL-Grafikbeschleunigung nicht verfügbar.

Nun ist das eigentlich immer noch genauso falsch, denn serienmäßig ist XRender verfügbar, jedoch standardmäßig nicht aktiviert. Die gesamte Entscheidung des Presserats hab ich als PDF hinterlegt.

Fazit: der Presserat ist ein Papiertiger. Bei einer Beschwerde schenkt er der Redaktion mehr Glauben als dem Beschwerdeführer und führt keinerlei unabhängige Überprüfung durch. Selbst nach einem Widerspruch wird die Aussage der Redaktion nicht noch einmal gegengeprüft (ich hätte das mit der Ati Karte gerne noch einmal auseinandergenommen bevor der Pressearat berät). Für mich war das meine erste Beschwerde beim Presserat und ich vermute, dass es auch meine letzte bleibt.

=-=-=-=-=
Powered by Blogilo

Posted on

Neustart des KDE Commit-Digest braucht Helfer

Bis zum Februar 2009 gab es eine wöchentliche Zusammenfassung aller KDE Commits im Commit-Digest. Danach hat Danny Allen die Arbeit alleine nicht mehr stemmen können. Mittlerweile arbeitet er daran es neu zu starten mit der Hilfe von vielen Freiwilligen und hat dazu eine Webplattform aufgebaut. Nun braucht es Freiwillige, die mitarbeiten die Commits durchzugehen und wichtige Commits herauszuheben. Mehr Infos dazu in Dannys Blog.

Der Commit-Digest ist ein unglaublich wichtiges Instrument, da er die KDE Entwicklung noch transparenter macht. Die Anwender können dadurch gut die Entwicklung verfolgen und sehen woran die Entwickler arbeiten. Ich erinnere mich daran, dass ich wöchentlich den Digest verfolgte als es zum KDE 4.0 Release ging und der Digest war somit ein wichtiger Faktor, dass ich überhaupt mit der Entwicklung begonnen habe.

Also hier nun auch von mir der Aufruf: helft bitte mit den Commit-Digest wieder mit Leben zu füllen! Danke.

=-=-=-=-=
Powered by Blogilo

Posted on

Die Hoffnung stirbt zuletzt – oder wie man versucht auf freie Treiber umzusteigen

Wie einige vielleicht wissen, haben wir in KDE Plasma Workspaces 4.5 leichte Probleme mit den freien Grafikkartentreiber. Die einzige Möglichkeit so etwas für die Zukunft zu verhindern, ist dass wir mehr testen und größere Änderungen am Rendering Stack nur zu Beginn des Release Zyklus implementieren, so dass diese etwa 6 bis 7 Monate getestet werden können. Ich selbst nutzte nun KWin von trunk und nicht mehr von branch um mögliche Probleme möglichst schnell zu bemerken. Dies kann man aber nur wenn man auch die freien Treiber benutzt. Und hier wird es problematisch:

Bis vor Kurzem war mein Hauptsystem ein Notebook mit einer NVIDIA 9600M. Eine andere Grafikkarte einzubauen ist durch die Tatsache "Notebook" schon mal nicht möglich. Man hat also die Wahl zwischen dem proprietären Treiber und Nouveau. Als Distribution setze ich Debian Testing aka Squeeze ein. Die Version von Nouveau in testing unterstützt nur 2D was den Ansprüchen eines Entwicklers am OpenGL Compositing Bereich nicht genügt. Da Squueze bereits Feature Frozen ist, wird sich da auf absehbare Zeit nichts ändern. Jedoch existiert auch eine neuere Version in experimental, welche auch die neuste Kernel Version aus experimental benötigt. Damit bekomme ich OpenGL zum Laufen, sogar GLSL funktioniert recht gut, jedoch ist der Treiber für den Einsatz auf einem Notebook noch ungeeignet, da die Stromsparmechanismen noch nicht vollständig implementiert sind. Die Akkulaufzeit ist deutlich schlechter und Suspend to RAM ist bei mir gescheitert. Somit leider wieder zurück zum NVIDIA Treiber.

Seit ein paar Wochen habe ich ein neues System mit einer ATI R710 Grafikkarte, die ich vor etwa zwei Jahren gekauft hatte um neben NVIDIA auch mit Mesa und fglrx testen zu können. Leider hat sich seit damals die Situation nicht wirklich verbessert – zumindest unter Debian Testing. Mit dem freien radeon Treiber erreiche ich maximal einen Kernel oops beim Starten vom X Server – ein wirklich schönes Bild man startet zum ersten Mal und sieht nur einen schwarzen Bildschirm und kann auch nicht auf ein Terminal wechseln. Mit den Treibern und Kernel aus X sieht es etwas besser aus: X startet zwar immer noch nicht aber es gibt zumindest keinen oops, aber in dmesg findet man einen Crash Trace. Nun ist Testing natürlich mit Mesa 7.7 etwas alt (meine Vermutung warum ich die Probleme in 4.5 mit dem Intel System das mir zum Testen zur Verfügung steht nicht reproduzieren kann, ist dass Testing zu alt ist) und man könnte Mesa von Hand bauen. Wenn man KDE baut, sollte man das wohl auch schaffen. Hmm Wiki etwas veraltet: "Under some newer distributions, like Ubuntu 7.04". Mit längerem Suchen findet man dann doch eine Anleitung die recht aktuell aussieht, jedoch möchte ich einfach nicht Dateien unter /usr austauschen und X zu erklären, wo es mesa findet will irgendwie nicht – zumindest ändert sich am Ergebnis nichts: kein X Server.

Nun gibt es ja nicht nur einen, sondern zwei freie Treiber: radeonhd. Diesen könnte man auch mal ausprobieren, also installiert, xorg.conf angepasst und kdm neugestartet und wieder nichts. Also Rechner komplett neustarten und siehe da, es gibt Verbesserungen: X startet zwar nicht, aber man fällt zumindest auf ein Terminal zurück. Mit Hilfe einer größeren Suchmaschine war das Problem schnell gefunden: radeonhd funktioniert nicht mit Kernel Mode Setting (KMS). Nur wie deaktivieren? Die Suchmaschine sagt was von "nomodeset" in grub übergeben, jedoch sieht man beim Hochfahren sehr schön, dass KMS aktiviert wird. Tja unter Debian wird KMS dynamisch aktiviert, wenn der radeon Treiber geladen wird. Man muss also die Datei /etc/modprobe.d/radeon-kms.conf anpassen (völlig offensichtlich, oder?), danach startet auch X und siehe da, es wurde Farbe. Nur mein primärer Bildschirm hatte leicht verzehrte Farben. Login und sogar Desktopeffekte sind aktiv und nach Spielen mit XRandR sind die Bildschirme korrekt eingerichtet, nur wird der falsche Bildschirm als primär angesehen – aber OK. Leider ist die OpenGL Version nur 1.5 und da KMS ja nicht unterstützt ist, funktionieren Funktionen wie Shader (ARB und GLSL) und Framebuffer Objects leider nicht. Keine guten Voraussetzungen für die KWin Entwicklung mit diesem Treiber. Damit hätte ich noch arbeiten können, jedoch gab es leichte Probleme nach dem Suspend Test: der größere der beiden Bildschirme wollte einfach nicht mehr. Egal was ich in XRandR eingestellt hatte, ließ er sich nicht dazu überreden etwas anzuzeigen. Dieser Fehler hat sogar erfolgreich einen Neustart von X überlebt.

Tja da steh ich nun ich armer Tor und bin so klug als wie zuvor. Auf beiden Systemen läuft wieder der proprietäre BLOB. In der Gesmatheit meiner Feature Anforderungen sind die proprietären Treiber für mich weiterhin die einzige Wahl, kurz zusammengefasst gibt es folgende Showstopper:

  • Nouveau überlebt Suspend auf Notebok nicht
  • Radeon endet in Kernel oops
  • Radeonhd mag meinen Full-HD Bildschirm nicht

Nun gäbe es noch eine Möglichkeit das ganze Problem auf die Distribution zu schieben: laut der Meinung einiger Leute im Phoronix Forum sei das ja der Hauptgrund für die Probleme in 4.5, da ich die falsche Distribution nutze. Jedoch habe ich in regelmäßigen Abständen die Ati Karte mit verschiedenen Distributionen ohne Erfolg getestet. Zuletzt auch Kubuntu Maverick Beta, diese sollte ja das neueste mitbringen, was es so aktuell gibt. Und ja, X startet, jedoch startet X sich auch neu, wenn man Desktop Effekte aktiviert. Also kann ich auch bei einer Distribution bleiben, welche ich kenne und schätze. Rolling Release ist für mich undenkbar, da Treiber Probleme implizieren, dass ich nicht mehr an KWin entwickeln kann. Ein gewisses Grad an Stabilität benötige ich halt doch

=-=-=-=-=
Powered by Blogilo

Posted on

Demystifying OpenGL Desktop Effects

My last blog post about the driver situation in the KDE Plasma Workspaces in version 4.5 caused quite some discussion. This is great and really required. But it also showed that there are quite some incorrect information about the current and future OpenGL compositing being spread. With this post I want to address some of the wrong assumptions I read, so that they won’t be spread any further and causing grieve to both the KWin developers and the driver developers.

1. The Plasma Workspaces require at least OpenGL 2:
Nothing changed: KWin still supports no compositing, XRender compositing and OpenGL compositing. Compositing is still an optional feature (but enabled by default if feasible) and that won’t change in the next years. Given the experience we have with enabling compositing by default it would be irresponsible in my opinion to require OpenGL for desktop computing. Being able to disable effects on the fly is an important and often used feature. The minimum OpenGL requirement is somewhere between OpenGL 1.1 and 1.3 and this has not changed since our first compositing release 4.0. OpenGL 2 features are only used for further optional features in 4.5, which are only enabled if the graphics driver supports it. In case of blur effect there is no requirement to OpenGL 2 at all as it only requires extensions already available for OpenGL 1.x.

2. KWin uses extensions unsupported by free drivers in 4.5:
In 4.5 we added two new optional features which require framebuffer objects (FBO) and GLSL shaders (lanczos) or framebuffer objects and GLSL shaders or ARB shaders (blur). Both are no new optional requirements. Already in 4.0 we shipped several optional effects which required GLSL (invert, blur, sharpen, looking glass and explosion) and framebuffer objects (blur, sharpen, looking glass). The first GLSL based effect was imported to SVN in March 2007, so three and a half years ago. In 4.2 we added two more optional effects using GLSL: sphere and cylinder and in 4.3 we added an optional FBO requirement to the logout effect (which is enabled by default). This one had been committed in February 2009, so 1.5 years ago. The funny thing is that the blur effect in 4.0 required more from the graphics driver than the blur effect we added to 4.5. At the time of 4.0 this did not cause any problems while running 4.0 with modern free drivers would result in the same breakage as we see with the 4.5 variant. In fact we already saw the external breakage in case of the logout effect. If I would use bugzilla I would be able to draw a nice graph when we added an optional effect and when it started to be broken.

3. KWin developers only care about proprietary drivers:
Both new effects have been implemented by a developer not using proprietary drivers. In fact both effects did not work with NVIDIA at the time when they were committed to trunk as we hit a bug in the proprietary driver. The lanczos filter explicitly checked in the source code if the NVIDIA driver is used and was disabled for it. So we did the same thing as we do for free drivers at that moment: we blacklisted the driver. In opposite to the blacklist for free drivers we added that to the code so the user would not have had the chance to change it and also a new driver version would not have re-enabled it (this is ensured in the blacklist solution for mesa drivers). Luckily I was able to find a workaround so that it works with NVIDIA, too. Personally I would like to test more with free drivers, but my Laptop has an NVIDIA card and my desktop has an Ati R700 card which are both unsupported with mesa drivers in the distribution of my choice.

4. KWin should not have delivered the effects enabled by default or at all:
The effects are optional and do not get enabled if the driver does not support the required extensions. In case that the required extension is supported but does not work the protection mechanism does not work (and I cannot think of any other mechanism to make that work with all drivers). This would also be the case if we would not have enabled the effects by default. So I do not see the advantage by disabling them. Not delivering the effects at all would be unfair to the users who can use the effects without problems (both mesa users and proprietary driver users) and also to the developers working on the effects. Last but not least we would have had to remove all the effects listed in section 2, because they require the same optional requirements.

5. KWin developers did not communicate with the Mesa developers:
More communication is always a good thing and it is true that there is hardly any communication. But we do not live in a perfect world and there are many reasons for bad communication and non-existing communication always requires two parts (btw blogging about the problems is also a form of communication ;-). For our given problems I do not see how more communication would have helped. As shown in section 2 we did not add new requirements and we have seen external breakage before (better said: now we know that it has been external breakage). I truly believe that communication between GNOME Shell developers and Mesa developers helps GNOME Shell, but GNOME Shell is in the lucky situation to develop for future driver versions. We have to live with the current driver versions. And communicating does not fix the drivers shipped by the distributions at the moment. The only recommendation we would have received would have been to not ship the effects by default – to that see section 4.

6. KWin developers do not report bugs:
I can only write for myself: I do not have a card supported by mesa drivers so I cannot report bugs. I could proxy between our users and the mesa developers but I think there are more useful ways to spent my time. Therefore we tell the users to report the bugs upstream. Oh and of course if we see the same crash being reported for the 50th time we do not tell them to report it as duplicates in the mesa bugtracker are as useless as in the kwin bugtracker.

7. KWin developers do not contribute patches:
It is difficult to develop drivers for hardware you don’t have. Furthermore I develop KWin and not drivers. I keep the development of drivers to the people competent in that area. If wine developers are competent enough to develop both wine and drivers they have all the respect I can give them. But I am not able to do it and I do not want to develop drivers.

8. It is common knowledge that hardware cannot support OpenGL 2, so you should not check for OpenGL 2:
Yes, that’s why we don’t check the version but the actually required extension. We know that the R300 chips do not support NPOT textures and that’s why we check if NPOT textures are supported before creating a texture.

9. It is common knowledge that the drivers do not fully support the extension just to be able to say they support OpenGL 2 to make broken games work:
What? Seriously? I have never read about it in all the OpenGL documentation I have read so far. I thought that’s why there is an extension system and the experience with proprietary drivers show that this is not how it is done in practice. If that is the way how it is in mesa than I am not surprised that Valve does not want to release Steam for Linux.

10. Mesa drivers need to ship the broken extensions as that makes some more games work:
That’s a little bit unexpected as that breaks the checks we have been using since 4.0. Maybe it would have been an idea to see what the important downstreams require? I am also a little bit surprised that supporting games seems to be more important than not breaking a desktop environment. Reading such arguments really hurts.

11. Because of adding blur my desktop freezes when changing KWin settings:
The change in KWin triggering a mesa bug causing the freeze is completely unrelated to blur and/or lanczos. The change makes KWin use direct rendering when it is supported and not just always enforcing indirect rendering for mesa drivers. With direct rendering enabled the desktop freezes when KWin restarts compositing and crashes with indirect rendering. Given the current state of investigation there might be a bug in KWin which triggers the mesa bug. But this is still unconfirmed and it seems that fixing the KWin bug does not solve the freezing bug in all situations. The only relation to blur is, that with indirect rendering mesa drivers are reporting support for extensions which do not work with indirect rendering which makes the complete desktop unusable. Just for the record: this does not happen with NVIDIA or fglrx driver.

12. KWin will require OpenGL 3 in 4.6:
No, please see my blog post where I wrote that I want to have OpenGL 3 support in 4.7.

13. KWin will require OpenGL 3 in 4.7:
No, this will also be only an additional feature. KWin supports multiple backends and it does not make any sense to remove a working backend which is required for all mesa users and users of graphic cards which cannot handle OpenGL 3.

14. OpenGL 3 does not add anything needed by a compositing manager:
Well let’s not talk about OpenGL 3 but about programmable pipeline (OpenGL 3) and fixed functionality (OpenGL 1). Anybody who has worked with both understands why I want to have a backend based on the programmable pipeline. I want to port KWin to OpenGL ES 2 which requires a programmable pipeline backend, so the OpenGL 3 port is more or less for free. So most of the things we need from OpenGL 3 are also supported by OpenGL 2, nevertheless OpenGL 3 gives some useful things: geometry shaders, forward compatible profiles to ease the porting, a required hardware standard and (sorry to say so) mesa does not support it. Given the experience we have made in 4.5 we would not be able to add a programmable pipeline backend without risking unease situations for our users. Therefore it is better to go for version 3 directly and lower the requirement to 2 when mesa is ready. This gives hopefully the best to both involved groups: our development is not stopped by mesa and mesa is not bothered with problems caused by our to high requirements.

15. KWin wants OpenGL 3 just for FBO:
I am able to read specifications and as shown in this summary, we have been using FBOs since 4.0.

16. KWin should add a legacy backend for Mesa:
Our backend is legacy. The forward compatible profile is not yet developed. The effects can make use of more functionality if the driver supports it.

17. KWin should use the last major OpenGL version before the one drivers announce:
So for 2.1. we would use 2.0, for 2.0 we would use 1.5 and for 1.5 we would use 1.4. Does that solve any of our problems? I doubt it as GLSL is around since 2.0, so dropping back to 2.0 does not help and FBOs are supported since 1.5? I just tried to look it up and it’s not really trivial to find information when an extension was added. So that approach just is not possible. It would also mean that we would remove functionality for users where it is working (e.g. proprietary drivers) as for code maintainability doing yet another fuzzy check on renderer would not work. Not to mention that the renderer string is not stable at all in mesa development.

To summarize the most important points of this post: KWin has not started requiring new unsupported features from the drivers, but has been using this optional requirements since our 4.0 release. Since the early days we had ensured that the optional requirements work and that KWin does not break when an optional requirement is not supported. Our code can handle two situations: supported and not supported. We now had to learn that there is a third unspecified state, which could be called "maybe supported", which we do not handle, cannot handle and won’t be able to handle. Given this historic background all claims about we should have known better or if we just had communicated better the problems would not have appeared are just wrong as our checks used to work in the past. The only possible solution would have been to remove existing functionality because the drivers upgraded their support from unsupported to maybe supported. I know that this sounds like finger-pointing and blaming others, but I just do not feel responsible for this external breakage. I completely understand that users are pissed-off and I would recommend them to talk to their distributions to ensure that when they release the next version which includes 4.5 it can be ensured that a driver is shipped that does not maybe support extensions. There are also more fun things to do than reading the bug reports by disappointed users and spending lot’s of my spare time on working around driver bugs.

Another important point from this post is: KWin will not require OpenGL 3 in future. The complete OpenGL 1 based code will not be removed. There is a lot talking about what KWin should do or should have done without checking the facts like e.g. seeing when KWin started to use GLSL.

=-=-=-=-=
Powered by Blogilo

Posted on

Warum Flattr auf Planet nichts zu suchen hat

In letzter Zeit sieht man immer häufiger Links auf Flattr in Blogposts. Flattr ist für die, die es nicht kennen, ein Dienst bei dem man monatlich einen bestimmten Betrag für Mikrospenden bereitstellen kann und durch Klicks auf die Links die Verteilung festlegen kann. Klingt doch eigentlich ganz gut. Jedoch hat es einen unglaublichen Haken: 10 % bleiben bei Flattr. Ich mache mal eine kleine Rechnung: 1000 Menschen spenden monatlich 5 Euro, damit bleiben 500 Euro bei Flattr. Ein sehr lukratives Geschäftsmodell. Von Flattr profitieren weder die Spender, noch die die Spenden erhalten, sondern einzig und alleine Flattr – ein kommerzieller Anbieter.

Wenn ich spende, dann möchte ich, dass möglichst viel bei den Leuten ankommt, die davon profitieren. Wenn ich spende möchte ich nicht, dass meine Spendengelder in Bürokratie versinken, daher suche ich mir sehr genau aus wofür und über wen ich spende. Ein Wasserkopf von 10 % wäre für mich nicht akzeptabel!

Nun sieht man auch im ubuntuusers Planet in letzter Zeit immer häufiger Flattr Buttons und das ist ein wirkliches Problem. Das gesamte Ubuntuusers Portal hat einen nicht kommerziellen Charakter, der in den Regeln festgelegt ist und jeder mit der Anmeldung zustimmt. Werbung oder Support nur gegen Geld sind nicht erlaubt. Hier wird auch intern im Forum sehr schnell vom Moderatorenteam gehandelt. Berücksichtigt man die Tatsache, dass Flattr 10 % der Spenden für sich behält, ist es ein klar kommerzielles Angebot und somit sind Flattr Links nicht erlaubt. Dies gilt selbstverständlich auch für den Planeten.

Bei den Buttons und Links ergibt sich auch noch ein anderes Problem: es ist Werbung für Flattr. Jeder der einen Flattr Link platziert, betreibt automatisch kostenlose Werbung für flattr – wirklich ein sehr cleveres Geschäftsmodell. Werbung ist wie gesagt auch nicht erwünscht. Niemand würde unter jedem Post einen Microsoft Button sehen wollen – diese Links stören mich in den Planeten ungemein, weil ich auf die Planeten gehe um eben keine Werbung zu sehen (ich sollte mal meine Werbefilter anpassen).

Nun wurde in letzter Zeit auf dem ubuntuusers Planet die Autoren angeschrieben wenn sie Flattr verwenden, informiert dass dies nicht erwünscht ist und die Artikel ausgeblendet bis der Link entfernt wird. Dies entspricht dem Vorgehen für alle Artikel, die den Regeln nicht entsprechen und z.B. anstößige Bilder enthalten, etc. Dies ist – nur falls das jemand meint – keine Zensur. Ubuntuusers hat das Hausrecht und die Blogger müssen sich an die Regeln von ubuntuusers halten. Ähnlich wird es ja auch im Forum und Wiki umgesetzt.

Nun stören sich die Blogger zum Teil daran, dass Flattr Links nicht erlaubt sind und dass man dies mit den Bloggern besprechen muss, weil diese ja den Content liefern. Diesem muss ich klar widersprechen. Das ubuntuusers Portal ist bekannt für seinen nicht-kommerziellen Charakter und dass es werbefrei ist. Daran müssen sich alle halten – nicht nur im Forum und im Wiki. Auch im Forum erbringen die unzähligen Supporter den Content und nicht ein abstraktes Gebilde wie ubuntuusers. Daher gibt es meiner Meinung nach da überhaupt nichts zu besprechen. Ubuntuusers ist keine Demokratie – um mal einen bekannten Open Source Menschen leicht adaptiert zu zitieren. Die Regeln werden vom Team aufgestellt. Der nicht-kommerzielle Charakter wurde gerade auch mitaufgebaut von einem der Blogger, die sich jetzt daran stören, dass Flattr nicht erlaubt ist. Dieser Blogger wollte auch Flattr Links in den Signaturen haben. Da frage ich mich schon: warum hilft man? Um ehrenamtlich zu helfen oder um daran zu verdienen? Es spricht überhaupt nichts gegen Geld verdienen mit Open Source – ich unterstütze das und helfe regelmäßig auch Firmen – auch ehrenamtlich. Jedoch die Ehrenamtlichkeit verlohnt zu bekommen, finde ich nicht akzeptabel. Das ist scheinheilig. Für mich wäre das aufkommen von flattr Links in Signaturen der Punkt wo ich keinen Support mehr leisten würde.

Wenn sich in Zukunft der ubuntuusers Planet nicht mehr betreiben lässt ohne Links auf Flattr, dann muss der Planet in der Schlussfolge eingestellt werden. Das wichtigste Charakterstika von ubuntuusers wegen dem Profitstreben einiger Blogger aufzugeben, ist allen Lesern gegenüber nicht zu verantworten.

Bei meinem letzten Post auf Planetkde wurde ich in den Kommentaren gefragt wo mein Flattr Button sei. Ich habe auf die 10 % Problematik hingewiesen und gesagt, dass man das Geld sinnvoller einsetzen kann, wie z.B. dem KDE e.V. zu spenden. Der nächste Kommentar von dem Leser war: done so.

Dies kann ich nur allen ans Herz legen: wenn ihr die Community unterstützen wollt, dann spendet z.B. an den KDE e.V. oder die GNOME Foundation. Join the Game und Become a friend of GNOME. Davon profitieren alle, denn es wird umgesetzt in die Finanzierung von Sprints. Ein Danke bedeutet mir übrigens auch mehr als dass ich fünf oder zehn Euro mehr im Monat habe.

=-=-=-=-=
Powered by Blogilo

Posted on

Driver dilemma in KDE workspaces 4.5

KDE is currently blamed for errors in external components: the graphic drivers. I am lately reading quite some crap (e.g. on it news today) that we KWin devs knew about problems in the drivers and shipped 4.5 nevertheless with changes enabled which trigger the driver bugs. That is of course not true.

First let’s have a look on the checks KWin performs in desktop effects:

  • Desktop effects are only enabled if the driver is on a whitelist of known working drivers
  • The capabilities of the driver are verified by an external helper application
  • If KWin crashes while initializing the driver (you have to access OpenGL to know if OpenGL is supported), KWin will not try to enable desktop effects again
  • If KWin crashes twice in a row (not during driver initialization), desktop effects get disabled to prevent further crashes
  • Each effect verifies the required capabilities by testing against the supported OpenGL extensions. So for example the blur effect requires GLSL with fragment shaders and frambebuffer objects. Only if the driver supports these extensions the effect gets activated. If a driver does not support the extension it should not claim support for it. The extensions are the only reliable information we have from the graphics driver.
  • We have a test in 4.5.0 (removed in 4.5.1 – reason given below) that ensures that framebuffer objects are working in case the driver claims incorrectly support for the extension
  • We have a dynamic blacklist that disables effects which require an extension the driver claims incorrectly support for it
  • KWin has a selfcheck to test if desktop effects work at all, if not they are disabled
  • KWin has a runtime performance check. If the performance is bad, desktop effects are disabled on the fly

The most important fact in this list is, that KWin does not enable any functionality the driver does not claim support for it! Furthermore we have several runtime checks to ensure that our users have a smooth experience even if the drivers are claiming support for extensions they do not support. Many of these checks have been added in the 4.4 and 4.5 release cycle.

Now that I have explained all our checks we did to ensure a smooth user experience, I want to explain how it could happen that there are regressions in 4.5. In 4.5 we introduced two new features which require OpenGL Shaders: the blur effect and the lanczos filter. Both are not hard requirements. Blur effect can easily be turned off by disabling the effect and the lanczos filter is controlled by the general effect level settings which is also used for Plasma and Oxygen animations. Both new features check for the required extensions and get only activated iff the driver claims support for it. So everything should be fine, shouldn’t it?

Apparently not when it comes to the free graphics drivers (please note and remember: we do not see such problems with the proprietary NVIDIA driver!). We used to use indirect rendering for Intel drivers. In that case the driver still claims support for all the extensions which cannot work with indirect rendering, that is for example framebuffer object and shaders (NVIDIA does not support such extensions if direct rendering is not enabled). If we ask the driver if it is supported it says: "yes sure, everything is fine", till you try to use it. This caused serious problems with the blur effect. The effect checks at startup what is supported, sees that everything is supported and tells Plasma that blur is available. Plasma uses therefore the blur optimized theme and then blur just does not work. We do not see the problem on initial startup or creation of the resources, such as compiling the shader, we see it only during the painting pass. This results in completely transparent and impossible to read windows.

Of course this is unacceptable. Disabling the blur effect by default would not have been an option as users would have enabled it and have run into this driver issue. So we had to check it. I added a test to try to get a framebuffer object during initialization. If it fails KWin does not enable the blur effect. Fixed the issue for all Intel users. But this caused other problems, so for some drivers when using a "strange" resolution (e.g. multi screen) compositing cannot be enabled at all. We still do not know what is happening there and cannot debug due to missing hardware. This check had been removed in 4.5.1 again as it was causing problems.

We could drop the check because we had found a better solution: the free drivers also support direct rendering and so we activated it. Of course only when our test application running outside of KWin verifies that direct rendering works. So everything is fine: blur works and no more problems.

Well not if we have the graphics stack in X11. We saw some new problems appearing out of nowhere. The Intel driver seems to be able to support shaders for hardware that is not programmable, that means: software emulation. That’s a rather stupid idea. You use shaders because you want to have the power of the GPU, not the slow general purpose CPU. A GPU (even a bad one) is magnitudes faster in image processing tasks than a CPU and is highly parallel. We also saw issues like windows being rendered upside-down (this issue had already been fixed in mesa git master before we were aware of this problem). This issue hit for example all users of radeon driver in OpenSUSE 11.3. A very nice problem seems to exist for Intel drivers. Given the bug reports we can only conclude that the driver is not able to handle more than one GL context at the same time or started shortly after each other.

When I see these problems I think: "it looks like we are the first one to actually use the drivers". And then I start to think about it and realize: yes we are. Compiz does not yet use GLSL (Compiz’s Blur effect is written in GPU assembler. KWin blur also has an assembler part which is a fallback in case the driver does not claim support for GLSL), so we are probably the first ones to use these driver capabilities in a real world application. Now why are we using something that new? Because it is quite old: this is OpenGL 2 we are speaking about, a standard specified in 2004! Btw. Microsoft made use of blur by default when they introduced Vista, that was in 2006. So we are talking about functionality specified since six years and used by default by our competition for four years. Oh and please note: the same hardware runs fine in Vista or Windows 7 – at least that’s what we can see from the bug reports.

As those new problems appeared I worked on another solution. Just in case that you didn’t know: I don’t have such hardware, I could not reproduce any of these issues. It’s also important to know that we need special combinations of hardware, driver version, mesa version, X server version, kernel version and distribution to have either failed or working setups. So there are easily thousands of possible combinations. Testing everything is just impossible. We introduced a blacklist to workaround the most prominent issues concerning blur and lanczos filter. Lanczos is more important as it cannot be disabled as easy as blur. The blacklist is implemented in a way so that it can easily be extended. I tried to cloud source the problem of finding all broken drivers. This did not work out for 4.5 and for 4.5.1 I just did not find the time to write a new kconfig update script. I hope to get an update ready for 4.5.2.

So far I discussed about the problems we saw and new about before 4.5.0. Given that we introduced several additional checks to ensure a good and smooth setup and all the work we put into ensuring a smooth user experience, I am rather disappointed being blamed for what we did. In my opinion we did everything that is possible. The only other option would have been to withdraw blur completely (as explained: disabling by default would not have solved the problem). This would be rather bad given that we have a large user base which wants blur and have a working driver!

An issue we were not aware of before the release (bug was opened during beta phase, but not confirmed before the release) are freezes when changing any KWin related settings. In fact it is not a freeze. You can still use Alt+Shift+F12 to disable compositing and enable it again and everything works fine. We still do not know what caused the problem, but it seems to be related to enabling direct rendering by default. Unfortunately I am unable to reproduce this problem on the only Intel based hardware I have access to. The only solution so far is to disable direct rendering in general again, but this would be a regression for all users where it is working fine (see above: it cannot be reproduced on each Intel hardware).

So we are in a situation where each of the possible ways to go, is wrong. And it is all caused by the drivers claiming support for functionality they do not support. If they would not do that, we would not have those problems. It is a rather disappointing situation. I can only repeat what is listed in the release note: use the latest drivers.

I hope this brings some light on the problems and shows that we did everything that is possible to work around the driver bugs. The issues have to be fixed in the drivers!

=-=-=-=-=
Powered by Blogilo

Posted on

Crash statistics for KWin

KWin is one of those parts of the KDE workspace which receives crash parts for all parts of the stack. We see crashes in Plasma (kind of upstream to us), Qt and most likely in the graphics drivers and X itself. My subjective feeling was that we receive more for us useless crash reports than valid ones. So I just used the bugzilla search to get some numbers for the last year (August 1st, 2009 till today). As you should not trust any statistics you haven’t faked yourself, I used the search to set some more bugs to upstream, duplicate and so on 😉

  • Reported crashes: 330
  • Still open: 31
  • Fixed: 47
  • Set to duplicate: 159 (~ 50 %)
  • Upstream bug: 44
  • Missing backtrace: 37
  • Other (waiting for info, Compiz bug, etc): 12

What’s really bad is that half of the reported crashes are duplicates. And that’s although DrKonqui finds the right reports. In most cases I just copy&paste the bug number reported as a possible duplicate (thanks a lot for this feature). Among those duplicates we have one issue during the 4.4 cycle which caused 31 duplicates and which is now on number two of crashes with most duplicates. In lead is still the crash report for Compiz’ KDE4-Window-Decorator (I said we get crashes for the complete stack including competitive window managers 😀 ).

The upstream bugs are mostly driver related bugs. The number does not reflect reality perfectly as some driver crashes are set to duplicate. So we see that we have more crashes in drivers than crashes we fixed! The open bugs contain mostly crash reports where I think that they are also not valid, e.g. crash in malloc. Most of them are also missing a way to reproduce the crash or it is clearly wrong (yes kwin backtraces can tell what you were doing 😉

Oh and we could use a bug day. Since I started to work I don’t have the time any more to search for duplicates and the number of open bugs has increased by > 60 since the 4.4 release. And yes also those are mostly duplicates. It just needs someone to filter them 🙁

=-=-=-=-=
Powered by Blogilo

Posted on

Beautiful Screenshots

This weekend I finally sat down and wrote a screenshot effect for KWin. This effect redirects the rendering of any window into an off-screen texture and saves the texture into the home directory. The advantage of this effect is that it is hooked into the normal rendering process and so we can also capture the shadow and the translucency to get beautiful screenshots. If we capture a transparent window it does not show the windows below but only the captured window with the alpha channel turned on correctly. See for example:

Translucent Konsole with Oxygen shadows

Of course the effect is not meant to replace KSnapshot. Instead I prepared a patch which allows KSnapshot to use this effect when the user selected window under mouse cursor. The screenshot shown above was captured with this change to KSnapshot. I hope I will be able to merge this change, soon 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

Next generation OpenGL compositing in 4.6

In this blog post I want to give an overview on what I am planning and working on for KWin in KDE SC 4.6. The big topic for 4.6 is performance – in 4.5 we introduced the blur effect and our designers want to extend the usage of blur to all windows. This is currently not yet recommendable (yes there are widget styles on kde-look which offer this function, but KWin is not ready for it!), so we have to work on it.

In general there are three topics I will address in the next cycle:

  1. Mobile edition: port compositing stack to OpenGL ES 1.1 and/or 2.0
  2. Improve performance: render less, render faster and more frames per seconds during animations
  3. Stabilize the effect ABI to be able to provide BC latest in 4.7 (if it makes sense)

These three topics are very much related to each other. For a mobile port we need to improve the performance and port to OpenGL ES. This requires to cleanup the rendering code which gives us a more modern rendering code resulting (in theory (I do not trust drivers any more)) in better performance (render less and faster). As part of this I am aiming to use forward-compatible OpenGL Shaders by default for rendering. Yesterday OpenGL 4.1 was released and it would be nice to be able to use OpenGL 2 functionality in a real world application on Linux. So this is an urge to the driver developers: please get your drivers ready for 4.6 – we will stress them. In a next step I want to go to OpenGL 3 in 4.7, but the free drivers do not yet support this generation. (That’s perhaps a point to work together with Compiz developers)

Thanks to the improvements on the rendering stack our API gets into a state where it makes sense to think about guaranteeing BC. Currently we do not and break the ABI in each cycle several times (up to now I broke BC in trunk more than five times). Our API does not yet use d-pointers and we have many pure virtual classes, which will make it difficult. But the API itself has not changed much during the last cycles, so it’s pretty stable already. With 4.6 the compositing stack will have been used three years, with two years enabled by default, so it’s really time to think about it. But this is just an idea I have and is not yet discussed with other KWin developers and it will require lots of boring work.

So where are we? I started with improving the rendering code of our Plasma styled frames and moved the rendering code into the concrete implementations for XRender and OpenGL. That made it possible to get something like the following screenshot:

Boxswitch with blurred background

Also the rendering code is improved. Instead of recreating the icons in each rendered frame by doing a QPixmap -> QImage -> GLTexture conversation, the icon texture is reused and generated using Texture From Pixmap (TFP) as used for our window pixmaps (there are still some effects forcing a recreating in each frame, but this will soon be fixed). For passing the geometry to the GPU a vertex buffer object (VBO) is used instead of the very, very old glBegin/glEnd. This VBO is also cached, so each geometry is only created once and passed to the GPU once. My abstraction for VBO is able to fall back to legacy rendering if VBOs are not available (very unlikely), which gives us just one high level API call to do legacy, normal and modern (forward compatible) rendering. The old methods are deprecated although still used by the window rendering (this requires some more useful changes as they currently stream the vertices in each frame). For rendering the effect frames (and all other textures) triangles are now used instead of quads (unavailable on ES and OpenGL 3 forward compatible profiles).

And what next? We still have many things to improve. Especially window rendering has to be changed to cache the geometries (when it makes sense) and the clip regions. The clip regions are one of the reasons why I want to switch to Shaders (other reasons are Nuno’s wishes for effects – if you want to work on awesome effects get in touch with one of us). The API still needs some more cleanup and our compositing stack has to be split into parts for GLX and EGL. Nevertheless I think the API is already in a state where I think of daring to compile KWin effect library this weekend on Maemo to see what breaks (effects would not yet compile).

=-=-=-=-=
Powered by Blogilo

Posted on

Blacklisting drivers for some KWin effects

This is mostly a post for our distributions. In 4.5 we will most likely activate the Blur effect and Lanczos filter for Taskbar Thumbnails and Present Windows by default. Unfortunately not each driver supports those correctly. We have the following possible problems:

  • Performance issues with Blur Effect
  • Upside-Down taskbar thumbnails with Lanczos filter (affects also Present Windows)
  • Too bright taskbar thumbnails with Lanczos filter (affects also Present Windows)
  • Performance issues with Lanczos filter in Present Windows

Most users won’t have problems with those two new or if there are problems they affect only one of the two. E.g. disabling blur for performance does not require to disable the Lanczos filter. Therefore I implemented a KConfig based blacklist during Akademy. It uses KWin’s default KConfig file (~/.kde[4]+/share/config/kwinrc) and uses KConfigGroup "[Blacklist]". The blur effect uses the sub-group "[Blur]", while the Lanczos filter uses the sub-group "[Lanczos]". This might be extended in future releases.

The blacklist is implemented in a way that specific driver versions for specific hardware are blacklisted. So if a new driver version is released this one won’t be blacklisted automatically in the hope that the new driver version fixes the issues (e.g. it is known that the upside-down issue is already resolved in Mesa master). On the other hand this means that if a problem is not fixed it will occur for the user as soon as the new version is installed. Which will of course cause problems and users will claim that $distribution is harming KDE because of $stupid thing.

The blacklist can be updated by a KConf update script and that’s the way we will ship a default blacklist in 4.5 (this is currently not yet implemented as we still collect information on drivers causing the problems). So if you as a distribution are informed about a problem with a specific driver please pass the information to me, so that I can update the blacklist for the final or minor release and (after the release) please ship a kconfig update script to change the blacklist. This is especially important if you update the drivers (e.g. a development release). Although I have no idea how to automatically update the blacklist if a user is getting the drivers from e.g. xorg-edgers PPA (btw this seems to cause quite some crashers).

The entries of the blacklist are normal KConfig entries with driver identifier as key (e.g. Intel or NVIDIA) and a list of strings for the values. Each list item is a concrete identifier for a combination of renderer and version separated by colon, dash, colon (:-:). Renderer and version can be read from glxinfo. Here an example blacklist:

[Blacklist][Blur]
NVIDIA=GeForce 9400M/PCI/SSE2:-:3.2.0 NVIDIA 195.36.24

[Blacklist][Lanczos]
NVIDIA=GeForce 9400M/PCI/SSE2:-:3.2.0 NVIDIA 195.36.24

Which will block my GPU on both blur effect and lanczos filter (which is of course not required). I will update the blogpost with link to the kconf update script as soon as it is implemented.

=-=-=-=-=
Powered by Blogilo