Log in

No account? Create an account
Hans de Goede
A while back Debian has switched to using the modesetting Xorg driver rather then the intel Xorg driver for Intel GPUs.

There are several good reasons for this, rather then repeating them I'm just going to point to the Debian announcement.

This blog post is to let all Fedora users know that starting with Fedora-26 / rawhide as of today, we are making the same change.

Note that the xorg-x11-drv-intel package has already been carrying a Fedora patch to not bind to the GPU on Skylake or newer, even before Debian announced this, this just makes the same change for older Intel GPUs.

For people who are using the now default GNOME3 on Wayland session, nothing changes, since Xwayland always uses glamor for X acceleration, just like the modesetting driver.

If you encounter any issues causes by this change, please file a bug in bugzilla.

The "for all recent Intel GPUs" in the subject of this blog post in practice means that we're making this change for gen4 and newer Intel GPUs.
Tags: ,
Hans de Goede
As blogged about already by Christian for Fedora 25 we've been working on improving hybrid gfx support, as well as on making it easier for users who want to, to install the NVidia binary driver.

The improved hybrid gfx support using the default opensource drivers was ready in time for and is part of the Fedora 25 release. Unfortunately the NVidia driver work was not ready in time. This has lead to some confusion.

Let me start with a FAQ to try and clarify things:

1)  I want to use Fedora 25 on a laptop with hybrid graphics, will this work?

Yes Fedora 25 supports hybrid graphics out of the box using the opensource drivers included with Fedora. A lot of work has been done to make this as smooth as possible. If you encounter any problems with hybrid graphics under Fedora 25 using the default opensource drivers, please file a bug in bugzilla and put me in the Cc.

2) I want to use the NVidia driver with Fedora 25, I heard it would be available in gnome-software?

It is our intend to make the NVidia driver available in gnome-software (for users who have 3th party sources enabled), but this is not ready yet, I hope to announce some progress on this on this blog soon. see below for a progress report on this.

3) I've an NVidia GPU which driver is better for me?

If you want maximum performance for e.g. gaming, you will likely want the NVidia driver. But be aware that on Optimus laptops using the NVidia driver will result in much higher power consumption / shorter battery life, as all rendering then is done on the NVidia GPU, which means that it cannot be powered down while your doing light work.

If your workload does not need maximum 3D rendering performance your likely better of with the default opensource drivers. On Optimus laptops these offer much better batery life and the opensource drivers do not have the risk of breaking when upgrading your kernel, or upgrading to the next Fedora release.

4) I want to have good battery life, but I also want to play the occasional game with good performance?

As part of the work on making it easy to use the NVidia driver with Fedora, I'm also planning to add a utility which will allow you to easily switch between nouveau and the NVidia driver. Note this will require a reboot each time you switch.

5) What is the status of making the NVidia driver available for easy installation in Fedora 25?

This biggest issue with the Nvidia driver is that it will not work out of the box on optimus enabled laptops, installing it on such a laptop will typically result in the laptop booting to a black screen, which is NOT the user experience we want to offer.

I've just finished a set of patches for the xserver, which will allow the NVidia driver rpm to install a xorg.conf snippet which will make the xorg autoconfigure code automatically set things up the right way for the nvidia driver on optimus enabled laptops.

Depending on the upstream review of these patches I will prepare an updated xserver package with these patches for Fedora 25 soon. Once that is in place, the negativo17.org rpms can be updated with the xorg.conf snippet.

When that is done, there still are some other issues to tackle:

  • Mesa in F25 is not yet glvnd dispatch enabled, which means that the negativo17.org rpms need to play ldconfig path tricks, which means that if the rpms get installed on a system with an unsupported GPU, and Xorg falls back to the open-source driver things go boom because apps end up loading the wrong libGL.so

  • We want to have some mechanism in place to automatically load the nouveau kernel-module before starting gdm if the nvidia kernel module did not load for some reason (e.g. it failed to compile against a new kernel)

  • The negativo17.org rpms currently use dkms or akmod, building the nvidia kernel module from source on your system, we want to switch things over to having pre-built kmods available

Note not all of these are necessarily blockers for adding the Nvidia driver
to gnome-software.

6) I want to try out the nvidia driver now, is that possible ?

First of all, if you've an optimus enabled laptop, please do not do this (yet), we should have a solution ready for you in a couple of weeks.

If you have a system which is only using a *single* nvidia GPU, then you can install the nvidia driver using the following commands:

  sudo dnf update 'kernel*'
  sudo dnf config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia.repo
  sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686

Then reboot and you should be running the nvidia driver, to get back to the opensource driver do:

  sudo dnf remove nvidia-driver
Hans de Goede
Recently I've been working on improving hybrid graphics support for the upcoming Fedora 25 release. Although Fedora 25 Workstation will use Wayland by default for its GNOME 3 desktop, my work has been on hybrid gfx support under X11 (Xorg) as GNOME 3 on Wayland does not yet support hybrid gfx,

So no Wayland, still there are a lot of noticable hybrid gfx support and users of laptops with hybrid gfx using the open-source drivers should have a much smoother userexperience then before. Here is an (incomplete) list of generic improvements:

  • Fix the discrete GPU not suspending after using an external monitor, halving laptop battery life

  • xrandr --listproviders no longer shows 3 devices instead of 2 on laptops with 2 GPUs

  • Hardware cursor support when both GPUs have active video outputs, previously X would fallback to software cursor rendering in this case which would typically lead to a flickering, or entirely invisible cursor at the top of the screen

Besides this a lot of work has been done on fixing hybrid gfx issues in the modesetting driver, this is important since with Fedora we use the modesetting driver on Skylake and newer Intel integrated gfx as well as on Maxwell and newer Nvidia discrete GPUs, the following issues have been fixed in the modesetting driver (and thus on laptops with a Skylake CPU and/or a Maxwell or newer GPU):

  • Hide HW cursor on init, this fixes 2 cursors showing on some setups

  • Make the modesetting driver support DRI_PRIME=1 render offloading when the secondary GPU is using the modesetting driver

  • Fix misrendering (tiled vs linear) when using DRI_PRIME=1 render offloading and the primary GPU is using the modesetting driver

  • Fix GL apps running at 1 fps when shown on a video-output of the secondary GPU and the primary GPU is using the modesetting driver

  • Fix secondary GPU video output partial screen updates (part of the screen showing a previous frame) when the discrete GPU is the secondary GPU and the primary GPU is using the modesetting driver

  • Fix secondary GPU video output updates lagging (or sometimes the last frame simply not being shown at all because no further rendering is happening) when the discrete GPU is the secondary GPU and the primary GPU is using the modesetting driver

Note coming Thursday (November 3th) we're having a Fedora Better Switchable Graphics Test Day, if you have a laptop with hybrid gfx please join us to help further improving hybrid gfx support.
Hans de Goede
So I've a RK3188 tablet which accelerometer calibration was completely off. I've spend quite some time figuring out how to fix this so I wanted to share the fix. Note this will only work on some tablets. First lets see if this fix will work for your tablet, from an adb shell do:

cat /proc/acc_info

If that file exists it will contain something like this:

root@rk31board:/ # cat /proc/acc_info                                        
offset:8 0 -4

If it does not exist, the this fix will not work for you. If the numbers after offset are all close to 0 like above, then likely you do not need this fix, but you can still try it.

So rockchip tablets with this particular file store accelerometer calibration data in something which rockchip calls the "sys sector" of nand, if you look in dmesg you will see "rknand_sys_storage_ioctl" messages there. The problem with this approach is that the "sys sector" data survives a factory reset so once the calibration data is off, it stays off, unless we manually force a recalibrate.

Note the next steps need root, make sure that the tablet is flat on a level service, and that it is not sleeping
(otherwise it will not calibrate until you wake it up, registering the powerbutton press during the calibrate)
then do:

echo 1 > /proc/acc_cal

Now run "dmesg | grep acc", you should see something like this:

<4>[ 1497.846716] acc calibrating 1
<4>[ 1497.875330] acc new offset 8 0 0

If you do congrats, you've successfully recalibrated your tablet.
Hans de Goede
All modern laptops have a gpu integrated into their processor (the igpu), some models also have a more powerful dedicated gpu (dgpu), this is called switchable graphics.

By default all apps will run on the more energy efficient igpu and the OS can choose to switch to the dgpu when more gpu-power is necessary, trading battery time for graphics performance. On most laptops the default gpu can be changed to the dgpu so that everything will always run on the dgpu.

Linux support for switchable graphics currently is not very good. E.g. on many laptops some of the external connectors are only connected to the dgpu and to be able to use those external connectors without issues users need to change the default gpu to the dgpu, resulting in a hot running laptop and the battery draining much faster.

So I will be working on improving switchable graphics support under Linux, allowing the igpu to be used as default, allowing maximum batter life, while keeping everthing working normally. Specifically the following should all work: external outputs, suspend / resume (including suspend/resume with external monitors connected / while docked) and suspending the dgpu when not used.

Some fixes for this have already landed in Fedora 24, if you've a laptop with switchable graphics, please give Fedora 24 a try. Make sure you've all updates installed, and that you're running a 4.6.x kernel (from updates-testing). Then everything should just work, specifically recently I've fixed several issues with external connectors which are only connected to the dgpu, including the dgpu not suspending after a monitor is unplugged from the external connector.

If you're still having issues using Fedora 24 (with the default open source drivers) on a laptop with switchable graphics, please file a bug and put me in the Cc, or if you already have a bug open, just put me in the Cc.

One known issue is that plymouth (the boot splash screen) in Fedora 24 does not Work well with switchable-graphics, in some cases you may
get a black screen instead of the boot splash until the graphical login manager shows. This is esp. a problem if you've a crypted disk, because the dialog asking for the disk-crypt password will not show. You can press ESC to drop to text mode as a workaround. This is fixed in the Rawhide / Fedora 25 plymouth packages, but the changes are too invasive for an update. An alternative workaround is manually installing the F25 plymouth on F24.

A secondary goal of my work on this is to allow people to run graphically demanding programs on the dgpu by starting them with "DRI_PRIME=1 program", note that since we do not support dynamic reclocking of nvidia GPUs this will not always result in a performance improvement. Again if you're using this and it does not work properly, please file a bug and put me in the Cc.

Hans de Goede
Hello fellow Fedorians,

Good news, once you've gdm- (currently in updates-testing) and xorg-x11-server-Xorg-1.17.1-7.fc22 installed then if you start the X server (Xorg) by logging into gdm, or from startx then it will run as user by default. It still gets started via a suid root wrapper, so if you're relying on vesa graphics, or using a binary driver, then it will still run as root.


Tags: ,
Hans de Goede
Hi All,

As described here we've been working on making xorg-x11-drv-libinput the default input driver for the Xorg xserver under Fedora 22. All the necessary changes for this are in place for the GNOME and KDE desktops. So starting with the next Fedora 22 compose new Fedora 22 Workstation installations will be using xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.

For existing installations the move to libinput will not happen automatically, as  we have not added a hard dependency on xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the old drivers until they have adopted their mouse/touchpad configuration settings tools to also work with xorg-x11-drv-libinput.

If you're running F-22 with GNOME or KDE, please do the following to switch to the new driver:

"sudo dnf install xorg-x11-drv-libinput"

And let us know if you experience any issues while using the new driver.


Hans de Goede
I spend a significant amount of time to get $subject to work, so I thought I would share a step by step howto here for others who want to do the same:

  1. Download all the .src.rpm files found here

  2. Build all the src.rpm files

  3. Install all the build packages except for the debuginfo packages, note if you already have perl-IO-AIO you need to downgrade it to the version just build, squeezebox server does not work with the newer version in Fedora

  4. Edit /etc/yum.conf and /etc/dnf/dnf.conf and to both add a "excludes=per-IO-AIO" line

  5. Download the squeezeboxserver noarch rpm here and install it

  6. Note this rpm is not really noarch, it contains some perl modules which are written in C, it comes with precompiled .so files for many different perl and cpu flavors but not one which will work with F-21 ARM.

  7. We need to replace these with system installed CPAN modules, both those we've just build + some from the Fedora repos

  8. A second problem is that the CPAN dir included with the squeezeboxserver rpm comes first in its search-path, so the .pm files shipped with squeezeboxserver will get used, together with the .so files from the system packages, and unless the module versions match this will fail. So we will need to remove a bunch of .pm files from /usr/share/squeezeboxserver/CPAN, but only those for modules which we want to replace with system ones

  9. I've made a script installing the additional perl-* packages needed, as well as removing the .pm files which need to be removed, download it here

  10. Run the script as root by doing "sh squeezeboxserver-bin-deps"

  11. As root do: "systemctl stop squeezeboxserver.service; systemctl start squeezeboxserver.service"

  12. Now you can point your browser to http://ip-of-your-ARM-box:9000/

  13. Enjoy

Tags: ,
Hans de Goede
01 July 2014 @ 12:12 pm
If like me you find the Gnome 3 window title bars too large to your taste for windows not using the headerbar, then I've a quick fix for you, you just need to make some small changes to /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml . I've prepared 2 versions of this file with the changes already applied one for Fedora-20 and one for Fedora-21. Simply download this file, copy it to /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml, and do Alt+F2, r, enter, to get smaller titlebars.


Tags: ,
Hans de Goede
At the end of 2013 I've spend 2 full months working on getting XHCI streams support and the UAS driver in the Linux kernel, which uses streams into shape. With the release of the 3.15 kernel this work now is available for end users to use.

This is good news for anyone who cares about performance of USB connected harddisks / ssds. The old usb mass-storage protocol is well known for its poor performance. UAS however allows NCQ and thus allows effectively using the full USB-3 bandwidth. If you've an UAS capable harddisk enclosure then all you need is a 3.15 kernel build with the UAS driver enabled and you should instantly get better performance. Note that most harddisk enclosures, including USB-3 enclosures do not support UAS, so if you want to use UAS double check before buying a harddisk enclosure.

One use-case of UAS I love is to have a 2.5" ssd with a full Fedora rawhide install with me so that when people ask me about hardware compatilibty issues they are having, I can simply plug in the ssd to there laptop boot rawhide and see if having the latest kernel + xorg fixes things. For a decently priced UAS capable 2.5" hdd enclosure search ebay for: "sedna usb 3.0 2.5 inch hdd enclosure". when shopping for UAS enabled devices, always check that the device description mentions UAS or UASP.

Besides UAS support, the 3.15 kernel also features support for using USB-3 bulk streams from userspace through usbfs. To use this you need the just released libusb-1.0.19 release. One use case of USB-3 bulk streams from userspace is using these for usb-redirection in qemu. With the upcoming 2.1 qemu release this will be supported allowing the use if usb-3 redirection with uas devices from within a qemu vm. This will be supported with both qemu's host usb redirection, as well as spice's network usb redirection. This means that starting with qemu-2.1 qemu's USB redirection features full USB-3.0 compatibility.