Announcement

I just checked the gitorious source tree and they still have not reenabled Mesa threaded rendering by default even though the xcb fixes to the bugs that led them to disable it in the first place have had fixed patches for over a year.

I have to imagine a huge chunk of general Qt users are on Linux with Intel graphics. When the hell are they intending to turn it back on?

**haagch** · 17 March 2015, 12:41 PM

Thanks, that looks promising, probably especially the first one.

That was the single biggest reason I stopped using plasma 5. Every time I was trying to do something with the oculus rift (and automatically disabling my other 2 monitors), a lot of qt5 applications would segfault including konsole, plasmashell and krunner and sometimes kwin would also crash.

Did people not care about this, or was it just so hard to fix that it took way over a year?

**smani** · 17 March 2015, 01:00 PM

Originally posted by haagch View Post

Did people not care about this, or was it just so hard to fix that it took way over a year?

Frankly I asked myself the same question. The backtraces allowed to pin-point the most severe crashes pretty rapidly. I can only guess that not enough people were running Qt5 based applications prior to plasma5 starting to land in various distros.

**carewolf** · 17 March 2015, 01:56 PM

Originally posted by zanny View Post

I just checked the gitorious source tree and they still have not reenabled Mesa threaded rendering by default even though the xcb fixes to the bugs that led them to disable it in the first place have had fixed patches for over a year.

I have to imagine a huge chunk of general Qt users are on Linux with Intel graphics. When the hell are they intending to turn it back on?

The problem is that xcb provides no way to check the version at runtime. That makes it impossible to fix without a compile time flag breaking older xcb versions.

**zanny** · 17 March 2015, 02:07 PM

Originally posted by carewolf View Post

The problem is that xcb provides no way to check the version at runtime. That makes it impossible to fix without a compile time flag breaking older xcb versions.

I don't know why saying Qt 5.5 depends on Xcb >= 1.11 or whatever you want (I'm not sure the exact version the fix went in, but I know 1.11 was August of last year) would be a bad thing, versus crippling QtQuick2 performance on the majority of hardware any distro runs on. It seems so backwards to say "our software is just broken and does not work as intended for all users of this modern graphics library, because we want to make sure users of Ubuntu 14.04 can run Qt 5.5 without Canonical having to push an updated libxcb along with it... when older versions of that library are known to be broken?"

**carewolf** · 17 March 2015, 02:16 PM

Originally posted by zanny View Post

I don't know why saying Qt 5.5 depends on Xcb >= 1.11 or whatever you want (I'm not sure the exact version the fix went in, but I know 1.11 was August of last year) would be a bad thing, versus crippling QtQuick2 performance on the majority of hardware any distro runs on. It seems so backwards to say "our software is just broken and does not work as intended for all users of this modern graphics library, because we want to make sure users of Ubuntu 14.04 can run Qt 5.5 without Canonical having to push an updated libxcb along with it... when older versions of that library are known to be broken?"

Because then Qt 5.5 apps would not run on the vast majority of Linux distributions.

**zanny** · 17 March 2015, 02:25 PM

Originally posted by carewolf View Post

Because then Qt 5.5 apps would not run on the vast majority of Linux distributions.

Why are distributions shipping Qt 5.5 but not libxcb 1.11? (especially if Qt 5.5 depended on libxcb > 1.11?

Announcement

Qt 5.5 Alpha Finally Released

Qt 5.5 Alpha Finally Released

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment