Solution: Distorted / Garbled Graphics in Fedora 22 with Pre-SandyBridge Intel Graphics Chips

Fedora 22 was released recently on 26th May 2015 and continuing the trend since version 20 (at least for me), it has been a rock solid release for the most part. It features Linux Kernel 4.0, Gnome 3.16, KDE Frameworks 5.3 with Plasma Workspaces, XFCE 4.12, Mate 1.10 etc along with all the usual developer goodies like latest versions of compilers/interpreters including GCC 5, Python 2 and 3, OpenJDK 8 etc. The default package manager has been changed from Yum to DNF in this release and is extremely fast at dependency resolution because of the underlying libsolv library from the openSUSE gang. I've been using this release since its Alpha came out on Virtual Box and on bare metal since RC1, my usual timings.

Some folks at FedoraForums.org, which by the way is a great community for Fedora users, enthusiasts, evangelists and developers alike, have reported having  garbled / distorted graphics on some of the Intel Integrated Graphics chips. On analyzing further, I noticed that these chips are mostly from the Intel 4 series of chipsets (for ex. the G41 chipset with GMA X4500 graphics) or in other words, chipsets from pre-Sandybridge era. Have a look at the screenshot below to understand what I am talking about:

Now this, is pretty bad and almost unusable and I could sense the agony of the users upgrading to or trying switching to Fedora 22. So I thought may be I can be of some help and researched a little on it, for the sake of the great Fedora community's growth and well being. It has done so much for me and I would be glad if I could give back anything at all.

My first suspect was the Intel driver itself, xorg-x11-drv-intel but the one strange fact was that the same version of driver and the same version of kernel were working just fine on Fedora 21 on these machines. So this issue is confined to Fedora 22 and it changes, that's for sure. I think it could be the result of one of the two changes introduced in Fedora 22:

1. As part of the changes for Wayland and other stuff, the X server now runs in a root-less mode. This can have implication on applications that access the graphics stack at lower levels.
2. If I am not wrong, GCC 5 compiler collection has support for C++14 which introduced ABI (Application Binary Interface) changes and many of the components including the Intel driver itself has been recompiled with GCC5 for maintaining binary compatibility. So even though the version of the driver is same, its not binary compatible with the driver present in Fedora 21.

 Anyways, this is something still to be discussed with the Fedora/Intel teams but for now there is a solution you can use. I am not sure if it can be used with Live CDs written on optical disks but I think it can be used on Live CDs written to USB drives and on installed systems.

Create a new text file called /etc/X11/xorg.conf.d/20-intel.conf with your favorite text editor (or edit it if it is already present) and enter below text in it:

Section "Device"
        Identifier  "card0"
        Driver       "intel"
        Option      "AccelMethod"  "uxa"
EndSection

 If the section for intel card is already present, just add the Option   "AccelMethod"   "uxa" line in it. Save this file and reboot. Please note that since this file resides in /etc folder and not your home directory, you will need root / sudo access to create or edit this file.

Atleast 5+ users at Fedora Forum have confirmed that this "fix" has resolved their issue. What this essentially does is it asks the Intel driver to use the "UXA (Unified Acceleration Architecture)" for graphics acceleration instead of the "SNA (Sandybridge New Acceleration)" architecture. SNA is the new and preferred way of doing accelerated graphics on Intel chips and it's supposed to be backward compatible with older cards as well (and it was till F21), however, there is some regression introduced to it in Fedora 22 probably because of the mentioned changes.

Here is the link for the original forum thread for those who want to check out the whole discussion that took place :

http://forums.fedoraforum.org/showthread.php?t=304718

So that's that, all's well and no harm done. Enjoy the awesome Fedora 22 release and do upgrade your hardware whenever you can :)

Cheers!

When it comes to MTP, Dolphin is a bitch! Konqueror to rescue

KDE is great desktop environment and I use it everyday since the time I got introduced to it in 2001. It's free, it's open source, its highly configurable and its really fun to use.  Since version 4.10, KDE has inbuilt support of the MTP protocol which most of the smart phones in the market are using nowadays for connecting to PC. Mass Storage has become a thing of the past with MTP offering easier access, in built support in Windows and Linux OS and transfer speeds comparable to mass storage mode.

KDE in Linux offers MTP support using its robust, feature rich and pluggable I/O layer, KIO. It uses a a kio-slave called kio-mtp which is now pretty standard in almost all the current distributions. kio-mtp is supposed to provide a complete and seamless integration of MTP protocol in KDE using whatever file management tool you use. Dolphin is the default file manager these days on all distributions and its a great piece of software for the most part.

Until it comes to MTP. Unfortunately, as per my experience, the MTP implementation in Dolphin is broken and has a multitude of issues. I use distributions based on Ubuntu mostly (Kubuntu, Linux Mint etc.) so this holds true for those only. I have no idea about distros like Fedora and OpenSUSE. Some of the issues that I have faced are:

• Not able to connect at all.
• Can connect but waiting forever to show the contents of the device.
• While copying files getting stuck for a long time and then giving error 'MTP Protocol has died unexpectedly'.
• and some more...

If you go searching, you will find a lot of posts with people whining about these issues and mostly suggestions given to them include using a different version of libmtp, using a different access driver altogether. But it seems, there is no luck if you want to use the plain-jane kio based integration.

Then today, I accidentally put my foot over Konqueror and  just out of curiosity I switched it to File Manager profile. I tried accessing my MTP devices and viola! everything worked as it should. I am able to copy to and from the device, both single files/folders as well as a bunch of them.

So I think the issue lies in the way Dolphin accesses MTP devices and not in the KIO layer itself. I have marked it as a solution for time being for myself. Just create shortcut for konqueror with command line:

konqueror ~

You can replace ~ with any other path. Use this shortcut whenever you want to access MTP devices. If you would like to set konqueror as your default file manager, you can do so from System Settings > Default Applications > File Manager and choosing Konqueror there in the list.

One last thing to keep in mind for Android device owners: The KIO based MTP implementation is a bit quirky about USB Debugging so turn that option off on your device when you are connecting for file management tasks.

Let me know in comments whether these worked out for you or not.

Cheers!