Why does kwin_wayland not start?

From time to time I get contacted because kwin_wayland or startplasmacompositor doesn’t work. With this blog post I want to show some of the most common problems and how to diagnose correctly what’s going wrong.

First test nested setup

If you want to try Wayland please always first try the nested setup. This is less complex and if things go wrong easier to diagnose than a maybe frozen tty. So start your normal X session and run a nested KWin:
export $(dbus-launch)
kwin_wayland --xwayland

This should create a black window. If it works you can send windows there, e.g.:
kwrite --platform wayland

When things go wrong

Xwayland missing

KWin terminates and you get the error message:

FATAL ERROR: failed to start Xwayland

This means you don’t have Xwayland installed. It’s a runtime dependency of KWin. Please get in contact with your distribution, they need to fix the packaging 😉

Application doesn’t start

KWin starts fine but the application doesn’t show because of an error message like:

This application failed to start because it could not find or load the Qt platform plugin “wayland”in “”.

Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, xcb.

Reinstalling the application may fix this problem.

This means QtWayland is not installed. Please install it and try again.

Platform plugin missing

KWin terminates and you get the error message:

FATAL ERROR: could not find a backend

This means that the platform/backend plugin is not installed. KWin supports multiple platforms and distributions put them in multiple packages. For X11 you need e.g. on Debian based systems the package kwin-wayland-backend-x11. For the “real thing” you need: kwin-wayland-backend-drm.

XDG_RUNTIME_DIR not set

KWin terminates and you get the error message:

FATAL ERROR: could not create Wayland server

This means that KWin failed to create the Wayland server socket. The most common reason for this is that your environment does not contain the XDG_RUNTIME_DIR environment variable. This should be created and set by your login system. Please get in contact with your distribution. The debug output should also say something about XDG_RUNTIME_DIR.

Platform fails to load

KWin terminates and you get the error message:

FATAL ERROR: could not instantiate a backend

You hit the jackpot. Something somewhere went horribly wrong. Please activate all KWin related debug categories, run it again and report a bug against KWin – ideally for the platform you used. The debug output hopefully contains more information on why it failed. If not we need to try to look into your specific setup.

Trying on the tty

KWin works fine in the nested setup: awesome. In most cases this means that KWin will also work on the DRM device. Before trying: make sure that you don’t use the NVIDIA proprietary driver, if you do: sorry that’s not yet supported. If you are on Mesa drivers everything should be fine.

Log in to a tty and setup similar to nested setup – I recommend the exit-with-session command line option to have a nice defined setup to exit again:

export $(dbus-launch)
export QT_QPA_PLATFORM=wayland
kwin_wayland --xwayland --exit-with-session=kwrite

Ideally this should turn your screen black, put the mouse cursor into the center of the screen and after a short time show kwrite. You should be able to interact with it and when closing kwrite KWin should terminate. If that all works you are ready to run startplasmacompositor. It will work.

But what if not. This is the tricky situation. The most often problem I have heard is that KWin freezes at this point and gdb shows KWin is in the main event loop. This most likely means that KWin tries to interact with logind DBus API, but your system does not provide this DBus interface. Please get in contact with your distribution on how to get the logind DBus interface installed (this does neither require using systemd nor logind). I would like to handle this better, but I don’t have a system without logind to test. Patches welcome.

Running KWin on the weird systems

Yes one can go crazy and try running KWin on devices like the Nexus 5, Virtual Machines or NVIDIA based systems. Here the experience differs and I myself don’t know exactly what is supported on which hardware and in which setting combination. Best get in contact with us to check what works and if you are interested: please help in adding support for it.

A task manager for the Plasma Wayland session

Plasma 5.7 will ship with a new taskmanager library. One of the reasons to implement a new taskmanager library is the port to Wayland. Our old code base was heavily relying on X11 and didn’t support the concept of multiple windowing systems. You can read more on that in Eike’s blog post about the new task manager. In this blog post I want to focus a little bit on the Wayland side of a task manager.

Architectural difference to X11

On X11 every application is able to read every aspect of every other window. This allows to implement a task manager. The task manager can get notified when a window is added, when a window is removed and install event filters for the changes of the window properties. That’s the basics for a task manager.

On Wayland the world is different. An application is not able to see the windows of other applications. This means by default Plasma is not able to see what windows exists, the taskmanager would be empty. The only application which knows about the existing windows is the Wayland compositor.

Merging Desktop Shell and Wayland compositor?

A possible solution to this problem could be to merge the desktop shell and the compositor into one process. This is the architecture used in e.g. Unity and GNOME Shell on X11.

But such an architecture has also disadvantages. It violates the concept of separating concerns and of “doing one thing and do it right”. We have an excellent task manager, an excellent window manager and an excellent desktop shell.

Also it would make code sharing between platforms more difficult. A task manager for Wayland would be very different from a task manager on X11. All the business logic and presentation should be the same. No matter which windowing system is used.

By merging the code bases together we would also make the code less reusable. One couldn’t use KWin/Wayland in another desktop environment (e.g. LXQt) nor could one use Plasma/Wayland with another compositor (e.g. sway). While we of course recommend to use KWin as the Wayland (and X11) compositor we don’t enforce it and also don’t want to enforce it.

Protocols, protocols

So a different solution is needed and that is done through a custom Wayland protocol which is called org_kde_plasma_windowmanagement. We have a few interfaces prefixed with Plasma. This does not mean that it can only be used by Plasma. It just means that the interface was first designed and developed for Plasma’s needs. We are happy to share the interface with other desktop environments.

The protocol is provided by KWin and it announces whenever a new window gets created. Once a new window gets created a bound client can bind an org_kde_plasma_window interface and get notified about all the states of the window.

The protocol exposes pretty much all the information KWin has about the window and it gets updated automatically whenever the state in KWin changes. In addition the protocol has requests the task manager needs, like “close the window”, “minimize it”, “maximize it”, etc. etc. KWin also listens to these requests and honors them.

Although the protocol is added to Wayland, it is windowing system agnostic. The created Plasma Window does not expose the actual windowing system resource (after all on Wayland another client cannot get access to it). KWin exposes a Plasma Window for both X11 managed windows and Wayland windows. By that the task manager is able to manage tasks from multiple windowing systems without knowing that it does so.

Evolution of the protocol

We added the Plasma window protocol initially for the work on the Plasma phone about a year ago. Also on the Plasma phone we had the use case of switching windows and using the X11 based task manager was just no option on a Wayland only device 😉

While the protocol worked fine for our initial needs, it was not yet sufficient for the use in the desktop task manager. So over the last weeks we introduced further support and improved the API to make it work more reliable. Also quite some changes went into KWin to ensure that only “interesting” windows are exposed. E.g. a context menu should not be shown in the task manager.

Our KWayland library of course has support for this protocol through the classes PlasmaWindowManagement and PlasmaWindow on client side. In addition there is a model exposed as PlasmaWindowModel.

Future work

The work on the interface is not done yet. There are still changes to the API needed and the upcoming KDE Frameworks 5.23 release will include new API calls in PlasmaWindow. As well we have already the first change scheduled for KDE Frameworks 5.24. And we also know that we need to expose a few more data elements in the protocol to get the task manager to the same level as on X11.

There is also an interesting idea floating around to use the – windowing system agnostic – Wayland implementation on both X11 and Wayland. For this KWin (on X11) would need to create a dummy Wayland server for the task manager to connect to. It’s an idea which we might or might not implement.

Security considerations

Currently every Wayland client is able to bind this interface, which means that some of the security improvements of Wayland are not available in Plasma/Wayland. We are fully aware of that and were also fully aware of the consequence when we added the interface. I do have ideas on how to address this and this will be implemented before we will recommend the Plasma/Wayland session for daily usage. The design allows to add security checks in these areas. Unfortunately my priority list did not allow me to implement this for Plasma 5.7, next chance 5.8.

Tragt Fahrradhelme

Mein Fahrrad hat heute morgen gemeint, mich nicht mehr zu mögen. Das Vorderrad hat blockiert und mich vornĂŒber geworfen. Wie man merkt, geht es mir ganz gut und bin mit einer Platzwunde am Kinn davon gekommen. Ich möchte aber nicht wissen, wie es mir gehen wĂŒrde, wenn ich keinen Helm getragen hĂ€tte, denn ich bin auf den Kopf gestĂŒrzt.

Daher einfach an alle: tragt bitte einen Fahrradhelm. Egal wie sicher ihr euch auf dem Fahrrad fĂŒhlt – es gibt immer auch unaufmerksame Autofahrer oder nachlassendes Material, wie in meinem Fall. Ach und auch wichtig: neuen Fahrradhelm kaufen nach jedem Sturz (ich lasse jetzt mein Fahrrad stehen bis ich einen neuen habe (das Fahrrad mit dem ich gestĂŒrzt bin, wird verschrottet)).

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

Studium Vorbei

Heute war das letzte große Ereignis meines Studiums: Abschlussvortrag mit anschließender mĂŒndlicher PrĂŒfung. Nun warte ich nur noch auf die Note fĂŒr die Masterarbeit 🙂 Zumindest gibt es nur noch zwei Möglichkeiten fĂŒr die Endnote, wer wissen will, welche darf gerne persönlich nachfragen 😉

Nun ist also das schöne Studentenleben vorbei und nach Ostern beginnt der Ernst des Lebens. Bin ja mal gespannt

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

Abklappern der Copyshops

Woran merkt man, dass man mit der Abschlussarbeit fast fertig ist? Man holt Samstags KostenvoranschlĂ€ge fĂŒr den Druck der fĂŒnf Exemplare ein. Die Preise waren so heftig, dass ich den Anhang komplett noch einmal in schwarz/weiß generiert habe. Am Montag werde ich das Werk dann wohl in den Druck geben, so dass ich entweder am Dienstag oder Mittwoch die Arbeit abgeben kann. MĂŒsste erst am Mittwoch, aber mittlerweile hab ich einfach keine Lust mehr daran zu arbeiten und fĂŒrchte, dass ich entweder verkorrigiere oder das Layout zerstöre.

Insgesamt 183 Seiten habe ich zu Papier gebracht, ohne den bloat (Verzeichnisse, Anhang) immer noch 106 Seiten. Darunter sind 39 Abbildungen, 11 Tabellen und 26 Listings. Insgesamt fast 6 Monate hab ich daran gearbeitet, seit Anfang Januar aber keinen Quellcode mehr geschrieben und meine Implementierung im Produktiveinsatz getestet. Allein im Januar hat der Filter 416 Spammails rausgeholt – im Februar deutlich mehr (zumindest zeigte die Tendenz bis zum 15.02. dies an – der Vallentinstag).

Neben den 41.000 Wörtern (laut wc) im Dokument, hab ich laut sloccount etwa 8.000 Zeilen Code geschrieben (UI nicht mitgezĂ€hlt). Sloccount meint, man brĂ€uchte dafĂŒr etwa 1,5 Personenjahre und die Entwicklung wĂŒrde mehr als USD 200.000 in kommerzieller Entwicklung kosten. Naja das Tool liefert komische Werte 😉 Meine EinschĂ€tzung vor der Arbeit war, dass ich zwischen 5.000 und 10.000 Zeilen Code schreiben kann in der kurzen Zeit. Das hab ich dann doch ziemlich genau getroffen. Gut war einfach hochzurechnen, da ich ja weiß wieviel ich fĂŒr KDE geschrieben habe in vergleichbaren Zeitspannen (Alt+Tab hat 2,6 KSLOC, Aurorae hat 1,9 KSLOC, Cube hat 3,2 KSLOC).

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

How to write a KWin effect

This blog post has been in my drafts folder for weeks and I just thought it’s time to publish it – ready for Akademy 🙂 And if somebody is really interested we could have a BOF session at Akademy. I think Plasma devs want us to write a slide effect to replace their custom popup animation. That would be a perfect example to get your hands dirty.

I wrote a new Kwin effect and thought this is the ideal effect for writing a small howto. It is an effect which helps resizing windows by colouring the changed geometry. I was told that resizing is not optimal in KWin, that is if the window content is shown while resizing it is slow and if the window content is not shown it is ugly. This effect should fill the gap. Unfortunately the current code will only work with the slow show window content while resizing (the API has to be changed). Nevertheless I decided to show the code in this tutorial.

Von KWin

The effect has been committed to trunk. So you can have a look at it and if you’re running trunk you can even try it. The effect which we will write has the name “Resize”. It will support both backends: XRender and OpenGL. Each effect has an own directory in kwin/effects so we create a new directory resize. There we create the following files:

  • CMakeLists.txt
  • resize.h
  • resize.cpp
  • resize.desktop

We have to include this directory into the build, so we edit the CMakeLists.txt in the effects directory. We just add the following line to the section marked as “Common effects”:

include( resize/CMakeLists.txt )

If it were an OpenGL only effect we would place this line in the section marked as “OpenGL-specific effects”.

So at this point we are finished with the preparation. So let’s start looking at the files. First the desktop file:

[Desktop Entry]
Name=Resize Window
Icon=preferences-system-windows-effect-resize
Comment=Effect to outline geometry while resizing a window

Type=Service
X-KDE-ServiceTypes=KWin/Effect
X-KDE-PluginInfo-Author=Martin GrĂ€ĂŸlin
X-KDE-PluginInfo-Email=kde@martin-graesslin.com
X-KDE-PluginInfo-Name=kwin4_effect_resize
X-KDE-PluginInfo-Version=0.1.0
X-KDE-PluginInfo-Category=Window Management
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=false
X-KDE-Library=kwin4_effect_builtins
X-KDE-Ordering=60

Most of it is self explaining and just needed for the “All effects” tab in the compositing kcm. The most important value is the “X-KDE-PluginInfo-Name”. This is the name used to load the effect and has to start with “kwin4_effect_” followed by your custom effect name. This last part will be needed in the source code.

Each effect is a subclass of class Effect defined in kwineffects.h and implements some of the virtual methods provided by Effect. There are methods for almost everything the window manager does. So by implementing those methods you can react on change of desktop or on opened/closed windows. In this effect we are interested in resize events so we have to implement method “windowUserMovedResized( EffectWindow *w, bool first, bool last )”. This method is called whenever a user moves or resizes the given window. The two boolean values indicate if it is the first, last or an intermediate resize event.

But there are more methods we have to implement. The effect should paint the changed geometry while resizing. So we have to implement the methods required for custom painting. KWin’s painting pass consists of three stages:

  1. pre paint
  2. paint
  3. post paint

These stages are executed once for the complete screen and once for every window. All effects are chained and each effect calls the stage for the next effect. How this works we will see when looking at the implementation. You can find a good documentation in the comments of scene.cpp

Now it’s time to have a look at the header file:

#ifndef KWIN_RESIZE_H
#define KWIN_RESIZE_H

#include <kwineffects.h>

namespace KWin
{

class ResizeEffect
    : public Effect
    {
    public:
        ResizeEffect();
        ~ResizeEffect();
        virtual void prePaintScreen( ScreenPrePaintData& data, int time );
        virtual void paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data );
        virtual void windowUserMovedResized( EffectWindow *w, bool first, bool last );

    private:
        bool m_active;
        EffectWindow* m_resizeWindow;
        QRegion m_originalWindowRect;
    };

}

#endif

We see that there are three member variables. The boolean is used to indicate if there is a window being resized, that is if we have to do some painting. The EffectWindow is a pointer on the window being resized and the QRegion stores the windows’s geometry before the start of resizing.

So now we can have a look at the implementation. I will split the code in small parts and explain the code. So first let’s look at the includes:

#include "resize.h"

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
#include <GL/gl.h>
#endif                                               
#ifdef KWIN_HAVE_XRENDER_COMPOSITING                 
#include <X11/Xlib.h>
#include <X11/extensions/Xrender.h>
#endif                                                                

#include <KColorScheme>

As our effect should support both XRender and OpenGL we have to include the headers for both. As it is possible that the effect is compiled on a system which does not support one of both we use ifdef. We can be sure that at least one of both is available or the effects wouldn’t be compiled at all. If you write an OpenGL only effect you do not have to bother about such things. Also if you only use KWin’s high level API you don’t need to include those headers. But we want to paint on the screen using OpenGL or XRender directly.

So let’s have a look at the next part:

namespace KWin
{                    

KWIN_EFFECT( resize, ResizeEffect )                                                                                                                                                            

ResizeEffect::ResizeEffect()
    : m_active( false )                                                                                                                                    
    , m_resizeWindow( 0 )                                                                                                                                         
    {                                                                                                                           
    reconfigure( ReconfigureAll );                             
    }                                                                                                                           

ResizeEffect::~ResizeEffect()
    {                                                                                         
    }

Here we see the use of a macro. This has to be included or your effect will not load (it took me ten minutes to notice I forgot to add this line). The first value is the second part of X-KDE-PluginInfo-Name – I told you we will need it again. The second value is the class name. Following is constructor and deconstructor.

So let’s look at the pre paint screen stage:

void ResizeEffect::prePaintScreen( ScreenPrePaintData& data, int time )
    {                                                                                                                           
    if( m_active )                                             
        {                                                                                                                       
        data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;           
        }                                                                                                                       
    effects->prePaintScreen( data, time );                                                                                                                     
    }

Here we extend the mask to say that we paint the screen with transformed windows when the effect is active. That’s not completely true – we don’t transform a window. But this flag indicates that the complete screen will be repainted, so we eliminate the risk of artefacts. We could also track the parts which have to be repainted manually but this would probably be more work for the CPU than the complete repaint for the GPU. At this point we see the chaining for the first time. The effects->prePaintScreen( data, time ); will call the next effect in the chain. effects is a pointer on the EffectsHandler and a very useful helper.

So now we start looking at the heart of the effect:

void ResizeEffect::paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData& data )              
    {                                                                                                                           
    effects->paintWindow( w, mask, region, data );                                                   
    if( m_active && w == m_resizeWindow )                                                                                                                 
        {                                                                                                                       
        QRegion intersection = m_originalWindowRect.intersected( w->geometry() );                                                                                                                
        QRegion paintRegion = m_originalWindowRect.united( w->geometry() ).subtracted( intersection );                                                                                                                                                          
        float alpha = 0.8f;                                                                                                                                              
        QColor color = KColorScheme( QPalette::Normal, KColorScheme::Selection ).background().color();

We first continue the paint window effect chain – this will paint the window on the screen. Now we check if we are in resizing mode (m_active) and if the currently painted window is the window which is repainted. In that case we calculate the region which has to be painted. We just subtract the intersection of current geometry with saved geometry from the union of those two. The next two lines are for the color definition. We use the background color of a selection with 80 % opacity.

Now we have to do a little bit OpenGL. In most effects where you just transform windows you don’t have to write OpenGL at all. There is a nice high level API which allows you to translate, scale and rotate windows or the complete screen. Also transforming single quads can be completely done without knowing anything about OpenGL.

#ifdef KWIN_HAVE_OPENGL_COMPOSITING
        if( effects->compositingType() == OpenGLCompositing)                                  
            {                                                                                                                   
            glPushAttrib( GL_CURRENT_BIT | GL_ENABLE_BIT );                                                                                                                                    
            glEnable( GL_BLEND );                              
            glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );                                                                                                                               
            glColor4f( color.red() / 255.0f, color.green() / 255.0f, color.blue() / 255.0f, alpha );                                                                                                                      
            glBegin( GL_QUADS );                               
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                {                                                                                                               
                glVertex2i( r.x(), r.y() );                                                                                                                                                  
                glVertex2i( r.x() + r.width(), r.y() );           
                glVertex2i( r.x() + r.width(), r.y() + r.height() );                                
                glVertex2i( r.x(), r.y() + r.height() );          
                }                                                                                                               
            glEnd();                                                                        
            glPopAttrib();                                                                  
            }                                                                                                                   
#endif

We check if KWin uses OpenGL as a backend. We enable blending in the OpenGL state machine (needed to have translucent colors) and set the color for our rects. OpenGL clamps colors in the range [0,1] that’s why we can’t use the values from QColor directly. Last but not least we just paint one quads for each rect of our regin.

Now just the XRender part is missing. This part is taken from show paint effect – I don’t know anything about XRender 😉

#ifdef KWIN_HAVE_XRENDER_COMPOSITING
        if( effects->compositingType() == XRenderCompositing)                                 
            {                                                                                                                   
            XRenderColor col;                                                                      
            col.alpha = int( alpha * 0xffff );                                                                 
            col.red = int( alpha * 0xffff * color.red() / 255 );                       
            col.green = int( alpha * 0xffff * color.green() / 255 );                   
            col.blue= int( alpha * 0xffff * color.blue() / 255 );                      
            foreach( const QRect &r, paintRegion.rects() )                                                                                                  
                XRenderFillRectangle( display(), PictOpOver, effects->xrenderBufferPicture(),                                                                                                                          
                    &col, r.x(), r.y(), r.width(), r.height());
            }
#endif
        }
    }

This does the same as the OpenGL part just with XRender.

Last but not least we have to track the window resizing:

void ResizeEffect::windowUserMovedResized( EffectWindow* w, bool first, bool last )
    {
    if( first && last )
        {
        // not interested in maximized
        return;
        }
    if( first && w->isUserResize() && !w->isUserMove() )
        {
        m_active = true;
        m_resizeWindow = w;
        m_originalWindowRect = w->geometry();
        w->addRepaintFull();
        }
    if( m_active && w == m_resizeWindow && last )
        {
        m_active = false;
        m_resizeWindow = NULL;
        effects->addRepaintFull();
        }
    }

} // namespace

So and that’s all. When a resize event is started we activate the effect and trigger a repaint of the window (probably not needed, but doesn’t hurt). And when the resizing is finished we deactivate the effect and trigger another repaint of the complete screen just to make sure that there are no artefacts left.

The CMakeLists.txt could just be taken from any other effect and be adjusted. So here’s the example:

#######################################
# Effect

# Source files
set( kwin4_effect_builtins_sources ${kwin4_effect_builtins_sources}
    resize/resize.cpp
    )

# .desktop files
install( FILES
    resize/resize.desktop
    DESTINATION ${SERVICES_INSTALL_DIR}/kwin )

#######################################
# Config

Now you can compile and try your new effect.

Urlaub und Semesterbeginn

Letzte Woche hatte ich endlich – nach vier Jahren – mal wieder eine Woche Urlaub. Bin mit ein paar Freunden/Bekannten nach Paris gefahren. War sehr schön und sehr erholend. Leider war das Wetter nicht ganz so toll mit der Auswirkung, dass ich mir einen leichten Schnupfen eingefangen habe.

Einige Empfhelungen/Erfahrungen, die ich gemacht habe:

  • Auf den Eifelturm kurz vor der DĂ€mmerung hochfahren. So sieht man die Stadt sowohl im Hellen als auch im Dunkeln und das ist einfach nur schön.
  • Wenn man bei den Tuilerien den Triumphbogen sieht und denkt, so weit ist das nicht, sollte man daran denken, dass der Bogen 50 m hoch ist und ja die Straße ist lang
  • Die Mona Lisa ist etwas enttĂ€uschend. Man kommt nicht wirklich nah dran und im Panzerglas vor dem Bild spiegeln sich die Lampen. Abgesehen davon hat der Louvre ein schönes CafĂ©, in dem sich die nicht Kunstinteressierten verstecken können, bis der Zeitpunkt zum Treffen mit der Gruppe erreicht ist.
  • Louvre und auch Versaille erschienen mir vom GebĂ€ude her kleiner als das Mannheimer Schloß (Architektonisch definitiv: das Mannheimer Schloß hat ein Fenster mehr als das Versailler). Zumindest von außen finde ich persönlich das Mannheimer Schloß auch schöner. Von innen kenne ich in Mannheim halt nur die VorlesungssĂ€ale und die sind nicht mit Gold verzirt. Muss jetzt doch mal das Schloßmuseum besuchen.
  • Geht einer in das Restaurant und fragt nach PlĂ€tzen fĂŒr sieben Personen und ruft den Rest danach mit “Allez les enfantes”, dann muss man sich nicht wundern, wenn der Tisch zu einem Kindertisch verwandelt wird.
  • Wenn am Bahnhof sich eine Person von der Gruppe entfernt und das GepĂ€ck stehen lĂ€sst, wĂ€hrend der Rest der Gruppe sich gemeinschaftlich zum Zug begibt, dann muss man sich nicht wundern, dass das nun herrenlose GepĂ€ck von Soldaten umstellt wird (nein ich hatte nicht mein GepĂ€ck stehen lassen).
  • Man kann mit Latein doch mehr Französich lesen als ich erwartet hatte.
  • Wenn Martin Hunger hat, sollte er essen. Warten fĂŒhrt zu dem unangenehmen Effekt, dass der Magen sich irgendwie weigert Essen aufzunehmen. Man hat dann gleichzeitig Hunger und SĂ€ttigungsgefĂŒhl beim Essen. Macht die ganze Sache dann nur noch schlimmer.
  • Ein Internettablet dabei zu haben ist ganz praktisch. Vor allem OpenStreet Map mit GPS macht sich gut 😉

Da der Urlaub nun vorbei ist, hat man wieder Zeit zum Studieren. Heute war Vorlesungsbeginn in Mannheim und wie es sich fĂŒr gute Studenten gehört, hatte ich heute keine Vorlesungen. Ändert sich leider sobald in Heidelberg das Semester beginnt. Insgesamt ist mein Vorlesungsplan doch etwas voll geworden. Muss mich jeden Tag an die eine oder die ander Uni quĂ€len. Neues Semester heißt auch, dass ich jetzt wieder mit Lernen beginnen muss, da ich Ende des Monats noch eine PrĂŒfung zum letzten Semester habe.

Das ewige gehupe – oder warum mich die EM solangsam annervt

Wie einige wohl wissen, wohne ich in der Mannheimer Innenstadt. Wie allgemein auch bekannt ist, gibt es in Mannheim sehr viele MitbĂŒrger, die aus anderen europĂ€ischen LĂ€ndern stammen oder aus LĂ€ndern, die man bei bestimmten Wettbewerben zu Europa dazu zĂ€hlt. Wie auch bekannt, findet zur Zeit solch ein bestimmter Wettbewerb, die Euro 2008, statt.

Nachdem sich die Vorrunde nun zu Ende neigt, beginnen die Spiele um 20:45 Uhr. Also enden sie gegen 22:40 Uhr mit der obligatorischen Nachspielzeit. Der ideale Zeitpunkt um die Autos zu besteigen in die Innenstadt zu fahren und krĂ€ftig auf die Hupe zu drĂŒcken. Man hat auch Ausdauer: eine halbe Stunde? eine Stunde? zwei Stunden? Alles kein Problem. Interessiert es mich, dass es in Mannheim auch Menschen gibt, die um 01:00 Uhr Nachts schlafen und nicht gehupe hören wollen? Vielleicht, aber unsere Mannschaft hat doch gewonnen!

Angefangen hat alles mit dem Spiel Schweiz gegen TĂŒrkei. In der Nachspielzeit erzielen die TĂŒrken den Siegtreffer: das ist ein Nationalereignis: “Ja wir haben einen Sieg”. Hat man zu dem Zeitpunkt schon etwas erreicht? Nein – ein Sieg im zweiten Spiel, noch nicht fĂŒr das Viertelfinale qualifiziert. Trotzdem das muss gefeiert werden.

Dank des italienischen Unentschieden und der deutschen Niederlage hatte man in Mannheim erst mal wieder Ruhe. Bis, nun ja, bis die TĂŒrken wieder spielten. Sie lagen bereits 2:0 zurĂŒck gegen stark spielende Tschechen. Man freute sich auf eine ruhige Nacht… und was passiert: der tschechische Torwart greift daneben und die TĂŒrkei dreht das Spiel und qualifiziert sich fĂŒr das Viertelfinale. An dem Punkt etwas erreicht? Den Titel gewonnen? Trotzdem ein Grund zu feiern – wieder eine schlaflose Nacht.

NĂ€chster Abend: Deutschland gegen Österreich. Deutschland spielt schlecht, schwach. Das Highlight der Rausschmiss der Trainer auf die TribĂŒne. Deutschland gewinnt und qualifiziert sich auch fĂŒr das Viertelfinale. Stellt das Erreichen des Viertelfinales wirklich ein fĂŒr Deutschland bereits angemessenes Ziel da? Ist alles unter Erreichen (falls Deutschland nicht weiter kommt) des Finales nicht eine Niederlage? Gibt es also einen Grund zu hupen? Dennoch – man muss ja zeigen, dass die deutsche Bevölkerung mit den TĂŒrken es aufnehmen kann. Die Herausforderung wurde angenommen – auch wenn beim LautstĂ€rkeduell klar die TĂŒrken (noch) vorne sind.

Dienstag: Man freut sich – heute gibt es fĂŒr keine MinoritĂ€t einen Grund zu feiern. Holland wird schön brav verlieren (sind ja sicher Gruppensieger) und Italien und Frankreich fahren nach Hause. Tja Rechnung geht nicht auf: Holland gewinnt, Italien gewinnt. Italien qualifiziert sich ebenfalls fĂŒr das Viertelfinale. Ist das Erreichen des Viertelfinales wirklich ein Grund zu feiern, wenn man von Holland abgeschlachtet wurde (im ersten Spiel) und man amtierender Weltmeister ist? Offensichtlich ja: es wurde wieder gehupt.

Heute: ja heute: Es spielt Griechenland, Spanien, Rußland und Schweden. Meine Hoffnung liegt darin, dass die MinoritĂ€ten zu klein sind um mich wach zu halten…

Und die Zukunft: Morgen spielt Deutschland. Übermorgen die TĂŒrkei. Hoffnung: der tĂŒrkische Torwart ist gesperrt – er war gegen Tschechien klar der beste Mann. Ja die Hoffnung stirbt zu Letzt. Liebe Kroaten schmeißt die TĂŒrken raus – ich möchte schlafen. Am Sonntag spielt Italien gegen Spanien. Auch hier gibt es Hoffnung – ĂŒberzeugen konnte ja Italien bei dieser EM noch nicht.

Zum GlĂŒck ist am Dienstag – am Tag vor einer Klausur – spielfrei. Da werde ich also schlafen können. Und dann nur noch drei Partien… Es gibt Hoffnung auf ruhige NĂ€chte – und wenn Deutschland gewinnt: dann muss ich auch nicht schlafen 😉

Martin ist zu dumm…

… auf Worpress 2.5 upzugraden 🙁
Ich hab wp-content anstatt vom backup ins neue WordPress, vom neuen ins backup kopiert. Daher fehlen nun einige Bilder, etc. Ich hoffe noch ein altes Backup zu finden und werde in Zukunft auch das WordPress Verzeichnis in mein Backup Skript miteinschließen 😉

Also hier lÀuft jetzt auch WordPress 2.5. Fehler, die sich nicht aus obigem erklÀren, bitte melden.

Ich sehe grau

Ich habe einen neuen Monitor gekauft und kann endlich Graustufen erkennen 🙂 Es war fĂŒrchterlich. Gerade in KDE 4 konnte ich ĂŒberhaupt keine ÜbergĂ€nge erkennen. Jetzt kann ich es richtig genießen.

Und nie wieder kaufe ich irgendetwas technisches bei einem Discounter 🙁