hansdegoede | Entries tagged with xorg

As mentioned in an earlier blogpost, I have been working on fixing many games showing a small image centered on a black background when they are run fullscreen under Wayland. In that blogpost I was moslty looking at how to solve this for native Wayland games. But for various reasons almost all games still use X11, so instead I've ended up focussing on fixing this for games using Xwayland.

Xwayland now has support for emulating resolution changes requested by an app through the randr or vidmode extensions. If a client makes a resolution change requests this is remembered and if the client then creates a window located at the monitor's origin and sized to exactly that resolution, then Xwayland will ask the compositor to scale it to fill the entire monitor.

For apps which use _NET_WM_FULLLSCREEN (e.g. SDL2, SFML or OGRE based apps) to go fullscreen some help from the compositor is necessary. This is currently implemented in mutter. If you are a developer of another compositor and have questions about this, please drop me an email.

I failed to get this all upstream in time for Fedora 31 final. But now it is all upstream, so 've backported the changes and created an update with the changes. This update is currently in updates-testing, to install this update run the following command:

sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2019-103a594d07

First of all I do not want people to get their hopes up about $subject of this blogpost. Improving gaming support is a subjects which holds my personal interest and it is an issue I plan to spend time on trying to improve. But this will take a lot of time (think months for simple things, years for more complex things).

As I see it there are currently 2 big issues when running games under Wayland:

1. Many games show as a smal centered image with a black border (letterbox) around the image when running fullscreen.

For 2D games this is fixed by switching to SDL2 which will transparently scale the pixmap the game renders to the desktop resolution. This assumes that 2D games in general do not demand a lot of performance and thus will not run into performance issues when introducing an extra scaling step. A problem here is that many games still use SDL1.2 (and some games do not use SDL at all).

I plan to look into the recently announced SDL1.2 compatibility wrapper around SDL2. If this works well this should fix this issue for all SDL1.2 2D games, by making them use SDL2 under the hood.

For 3D games this can be fixed by rendering at the desktop resolution, but this might be slow and rendering at a lower resolution leads to the letterbox issue.

Recently mutter has has grown support for the WPviewport extension, which allows Wayland apps to tell the compositor to scale the pixmap the app gives to the compositor before presenting it. If we add support to SDL2's Wayland backend for this then, this can be used to allow rendering 3D apps at a lower resolution and still have them fill the entire screen.

Unfortunately there are 2 problems with this plan:

SDL2 by default uses its x11 backend, not its wayland backend. I'm not sure what fixes need to be done to change this, at a minimum we need a fix at either the SDL or mutter side for this issue, which is going to be tricky.

This only helps for SDL2 apps, again hopefully the SDL1.2 compatibility wrapper for SDL2 can help here, at least for games using SDL.

2. Fullscreen performance is bad with many games.

Since under Wayland games cannot change the monitor resolution, they need to either render at the full desktop resolution, which can be very slow; or they render at a lower resolution and then need to do an extra scaling step each frame.

If we manage to make SDL2's Wayland backend the default and then add WPviewport support to it then this should help by reducing an extra memcpy/blit of a desktop-sized pixmap. Currently what apps which use scaling do is:

render lower-res-pixmap;

scale lower-res-pixmap to desktop-res-pixmap

give desktop-res-pixmap to the compositor;

compositor does a hardware blit of the desktop-res-pixmap to the framebuffer.

With viewport support this becomes:

render lower-res-pixmap;

give low-res-pixmap to the compositor;

compositor uses hardware to do a scaling blit from the low-res-pixmap to the desktop-res framebuffer

Also with viewport support, the compositor could in the case of there only being the one fullscreen app even keep the framebuffer in lowres and use a hardware scaling drm-plane to send the low-res framebuffer scaled to desktop-res to the output while only reading the low-res framebuffer from memory saving a ton of memory bandwidth. But this optimization is going to be a challenge to pull off.

Thank you all for the large amount of feedback I have received after my previous Wayland Itches blog post. I've received over 40 mails, below is an attempt at summarizing all the mails.

Highlights

1. Middle click on title / header bar to lower the Window does not work for native apps. Multiple people have reported this issue to me. A similar issue was fixed for not being able to raise Windows. It should be easy to apply a similar fix for the lowering problem. There are bugs open for this here, here and here.

2. Running graphical apps via sudo or pxexec does not work. There are numerous examples of apps breaking because of this, such as lshw-gui and usbivew. At least for X11 apps this is not that hard to fix. But sofar this has deliberately not been fixed. The reasoning behind this is described in this bug. I agree with the reasoning behind this, but I think it is not pragmatic to immediately disallow all GUI apps to connect when run as root starting today.

We need some sort of transition period. So when I find some time for this, I plan to submit a merge-requests which optionally makes gnome-shell/mutter start Xwayland with an xauth file, like how it is done when running in GNOME on Xorg mode. This will be controlled by a gsettings option, which will probably default to off upstream and then distros can choice to override this for now, giving us a transition period

Requests for features implemented as external programs on X11

There are various features which can be implemented as external programs
on X11, but because of the tighter security need to be integrated into the
compositor with Wayland:

Hiding of the mouse-cursor when not used à la unclutter-xfixes, xbanish.

Rotating screen 90 / 270 degrees à la "xrandr -o [left|right]" mostly used through custom hotkeys, possible fix is defining bindable actions for this in gsd-media-keys.

Mapping actions to mouse buttons à la easystroke

Some touchscreen's, e.g. so called smart-screens for education, need manual calibration. Under X11 there are some tools to get the callibration matrix for the touchscreen, after which this can be manually applied through xinput. Even under X11 this currently is far from ideal but at least it is possible there.

Keys Indicator gnome-shell extension. This still works when using Wayland, but only works for apps using Xwayland, it does not work for native apps.

Some sort of xkill and xdotool utility equivalents would be nice

The GNOME on screen keyboard is not really suitable for use with apps which are not touch-enabled, as it lacks a way to send ctrl + key, etc. Because of this some users have reported that it is impossible to use alternative on screen keyboards with Wayland. Not being able to use alternative on screen keyboards is by design and IMHO the proper fix here is to improve GNOME's on screen keyboard.

App specific problems

Citrix ICA Client does not work well with Xwayland

Eclipse does not work well with Xwayland

Teamviewer does not work with Wayland. It needs to be updated to use pipewire for screencapturing and the RemoteDesktop portal to inject keyboard and mouse events.

Various apps lack screenrecording / capture support due to the app not having support for pipewire: gImageReader, green-recorder, OBS studio, peek, screenrecorder, slack

For apps which do support pipewire, there is not an option to share the contents of a window, other then the window making the request. On Xorg it is possible to share a random window and since pipewire allows sharing the whole desktop I see no security reason why we would not allow sharing another window.

guake window has incorrect size when using HiDPI scaling, see this issue

Miscellaneous problems

Mouse cursor is slow / lags

Drag and drop sometimes does not work, e.g. dragging files into file roller to compress or out of file roller to extract.

Per keyboard layouts. On X11 after plugging in a keyboard, the layout/keymap for just that one keyboard can be updated manually using xinput, allowing different keyboard layouts for different keyboards when multiple keyboards are connected

No-title-bar shell extension, X button can be hit unintentionally, see this issue

Various issues with keyboard layout switching

Hard to fix issues

Alt-F2, r equivalent (restart the gnome-shell)

X11 apps running on top of Xwayland do not work well on HiDPI screens

Push-to-talk (passive key grab on space) does not work in Mumble when using native Wayland apps, see this issue

Problems with other compositors then GNOME3 / mutter

I've also received several reports about issues when using another Wayland compositor as GNOME / mutter (Weston, KDE, Sway). I'm sorry but I have not looked very closely into these reports. I believe that it is great that Linux users have multiple Desktop Environments to choose from and I wish for the other DEs to thrive. But there are only so many hours in a day so I've chosen to mainly focus on GNOME.

The just released 5.2-rc1 kernel includes improved support for Logitech wireless keyboards and mice. Until now we were relying on the generic HID keyboard and mouse emulation for 27 MHz and non-unifying 2.4 GHz wireless receivers.

Starting with the 5.2 kernel instead we actually look at the devices behind the receiver. This allows us to provide battery monitoring support and to have per device quirks, like device specific HID-code to evdev-code mappings where necessary. Until now device specific quirks where not possible because the receivers have a generic product-id which is the same independent of the device behind the receiver.

The per device key-mapping is especially important for 27MHz wireless devices, these use the same HID-code for Fn + F1 to Fn + F12 for all devices, but the markings on the keys differ per model. Sofar it was impossible for Linux to get the mapping for this right, but now that we have per device product-ids for the devices behind the receiver we can finally fix this. As is the case with other devices with vendor specific mappings, the actual mapping is done in userspace through hwdb.

If you have a 27 MHz device (often using this receiver, keyboard marked as canada 210 or canada 310 at the bottom). Please give 5.2 a try. Download the latest 60-keyboard.hwdb file and place it in /lib/udev/hwdb.d (replacing the existing file) and then run "sudo udevadm hwdb --update", before booting into the 5.2 kernel. Then run "sudo evemu-record" select your keyboard and try Fn + F1 to Fn + F12 and any other special keys. If any keys do not work, edit 60-keyboard.hwdb, search for Logitech and add an entry for your keyboard, see the existing Logitech entries. After editing you need to re-run "sudo udevadm hwdb --update", followed by "sudo udevadm trigger" for the changes to take effect. Once you have a working entry, submit a pull-req to systemd to get the changes upstream. If you need any help drop me an email.

We still have some old code for the generic HID emulation for 27 MHz receivers with a product-id of 046d:c50c, these should work fine with the new code, but we've been unable to test this. I would really like to move the 046d:c50c id over to the new code and remove all the old code. If you've a 27 MHz Logitech device, please run lsusb, if your device has a product-id of 046d:c50c and you are willing to test, please drop me an email.

Likewise I suspect that 2.4GHz receivers with a product-id of 046d:c531 should work fine with the new support for non-unifying 2.4 GHz receivers, if you have one of those also please drop me an email.

Now that GNOME3 on Wayland is the default in Fedora I've been trying to use this as my default desktop, but until recently I've kept falling back to GNOME3 on Xorg because of various small issues.

To fix this I've switched to using GNOME3 on Wayland as day to day desktop now and I'm working on fixing any issues which this causes as I hit them, aka "The Wayland Itches project". So far I've hit and fixed the following issues:

1. TopIcons

The TopIcons extension, which I depend on for some of my workflow, was not working well under Wayland with GNOME-3.30, only the top row of icons was clickable. This was fixed in GNOME-3.32, but with GNOME-3.32 using TopIcons was causing gnome-shell to go into a loop leading to a very high CPU load. The day I wanted to start looking into fixing this I was chatting to Carlos Garnacho and he pointed out to me that this was fixed a couple of days ago in gnome-shell. The fix for this is in gnome-shell 3.32.2 .

2. Hotkeys/desktop shortcuts not working in VirtualBox Virtual Machines

When running a VirtualBox VM under GNOME3 on Wayland, hotkeys such as alt+tab go to the GNOME3 desktop, rather then being forwarded to the VM as happens under Xorg. This can be fixed by changing 2 settings:

gsettings set org.gnome.mutter.wayland xwayland-allow-grabs true
gsettings set org.gnome.mutter.wayland xwayland-grab-access-rules "['VirtualBox Machine']"

This is a decent workaround, but we want things to "just work" of course, so we have been working on some changes to make this just work in the next GNOME version.

3. firefox-wayland

I've been also trying to use firefox-wayland as my day to day browser, this has lead to me filing three firefox bugs and I've switched back to regular
firefox (x11) for now.

If you have any Wayland Itches yourself, please drop me an email at hdegoede@redhat.com explaining them in as much detail as you can and I will see what I can do. Note that I typically get a lot of emails when asking for feedback like this, so I cannot promise that I will reply to every email; but I will be reading them all.

There have been questions about the Fedora 30 Flicker Free Boot Change in various places, here is a FAQ which hopefully answers most questions:

1) I get a black screen for a couple of seconds during boot?

1.1) If you have an AMD or Nvidia GPU driving your screen, then this is normal. The graphics drivers for AMD and Nvidia GPUs reset the hardware when loading, this will cause the display to temporarily go black. There is nothing which can be done about this.

1b) If you have a somewhat older Intel GPU (your CPU is pre Skylake) then the i915 driver's support to skip the mode-reset is disabled by default (for now) to fix this add "i915.fastboot=1" to your kernel commandline. For more info on modifying the kernel cmdline, see question 7.

1c) Do "ls /sys/firmware/efi/efivars" if you get a "No such file or directory" error then your system is booting in classic BIOS mode instead of UEFI mode, to fix this you need to re-install and boot the livecd/installer in UEFI mode when installing. Alternatively you can try to convert your existing install, note this is quite tricky, make backups first!

1d) Your system may be using the classic VGA BIOS during boot despite running in UEFI mode. Often you can select BIOS mode compatility in your BIOS settings aka the CSM setting. If you can select this on a per component level, set the VIDEO/VGA option to "UEFI only" or "UEFI first", alternatively you can try completely disabling the CSM mode. On some systems you can disable the classic VGA BIOS by disabling / unselecting the "Legacy Option ROMs" option.

2) The vendor-logo/firmware-splash looks squashed or has the wrong size?

Your system may be using the classic VGA BIOS during boot despite running in UEFI mode, see answer 1d.

3) I get a black background instead of the firmware splash while Fedora is booting?

Do "ls /sys/firmware/acpi/bgrt" if you get a "No such file or directory" error then try answers 1c and 1d. If you do have a /sys/firmware/acpi/bgrt directory, but you are still getting the Fedora logo + spinner on a black background instead of on top of the firmware-splash, please file a bug about this and drop me a mail with a link to the bug.

4) Getting rid of the vendor-logo/firmware-splash being shown while Fedora is booting?

If you don't want the firmware-splash to be used as background during boot, you can switch plymouth to the spinner theme, which is identical to the new bgrt theme, except that it does not use the firmware-splash as background, to do this execute the following command from a terminal: "sudo plymouth-set-default-theme -R spinner"

Note that the kernel will restore the vendor-logo early on at boot in case it got damaged by e.g. option ROM messages. If you are switching to the spinner theme you may also want to add "video=efifb:nobgrt" to your kernel commandline. See 7 below for how to edit the kernel commandline.

5) Keeping the firmware-splash as background while unlocking the disk?

If you prefer this, it is possible to keep the firmware-splash as background while the diskcrypt password is shown. To do this do the following:

"sudo mkdir /usr/share/plymouth/themes/mybgrt"

"sudo cp /usr/share/plymouth/themes/bgrt/bgrt.plymouth /usr/share/plymouth/themes/mybgrt/mybgrt.plymouth"

edit /usr/share/plymouth/themes/mybgrt/mybgrt.plymouth, change DialogClearsFirmwareBackground=true to DialogClearsFirmwareBackground=false, change DialogVerticalAlignment=.382 to DialogVerticalAlignment=.6

"sudo plymouth-set-default-theme -R mybgrt"

Note if you do this the disk-passphrase entry dialog may be partially drawn over the vendor-logo part of the firmware-splash, if this happens then try increasing DialogVerticalAlignment to e.g. 0.7 .

6) Get detailed boot progress instead of the boot-splash ?

To get detailed boot progress info press ESC during boot.

7) Always get detailed boot progress instead of the boot-splash ?

To always get detailed boot progress instead of the boot-splash, remove "rhgb" from your kernel commandline:

Edit /etc/default/grub and remove rhgb from GRUB_CMDLINE_LINUX and then if you are booting using UEFI (see 1c) run:
"grub2-mkconfig -o /etc/grub2-efi.cfg"
else (if you are booting using classic BIOS boot) run:
"grub2-mkconfig -o /etc/grub2.cfg".

For those of you who want to give the new Flicker Free Boot enhancements for Fedora 30 a try on Fedora 29, this is possible now since the latest F29 bugfix update for plymouth also includes the new theme used in Fedora 30.

If you want to give this a try, add "plymouth.splash_delay=0 i915.fastboot=1" to your kernel commandline:

Edit /etc/default/grub, add "plymouth.splash_delay=0 i915.fastboot=1" to GRUB_CMDLINE_LINUX

Run "sudo grub2-mkconfig -o /etc/grub2-efi.cfg"

Note that i915.fastboot=1 causes the backlight to not work on Haswell CPUs (e.g. i5-42xx CPUs), this is fixed in the 5.0 kernels which are currently available in rawhide/F30.

Run the following commands to get the updated plymouth and the new theme and to select the new theme:

"sudo dnf update plymouth*"

"sudo dnf install plymouth-theme-spinner"

"sudo cp /usr/share/pixmaps/fedora-gdm-logo.png /usr/share/plymouth/themes/spinner/watermark.png"

"sudo plymouth-set-default-theme -R bgrt"

Now on the next boot / installing of offline-updates you should get the new theme.

Fedora 30 now contains all changes changes for a fully Flicker Free Boot. Last week a new version of plymouth landed which implements the new theme for this and also includes a much improved offline-updates experience, following this design.

At boot the display will seamlessly transit from the firmware boot-splash into the new plymouth theme, which uses the firmware boot-splash as background:

If you are using full-disk encryption then the unlock dialog will look like this:

Last, but not least the new plymouth theme looks like this in offline-updates mode:

ATM the texts in the offline-updates theme are not translated. They are rendered using pango + cairo, so we have the capability to make this fully translatable into all languages, I just need to add gettext support to plymouth for this. I plan to do this next week.

This all assumes that you are booting your machine with UEFI and your firmware supports the BGRT extension (which almost all firmware does). Otherwise you will get a dark-grey background instead of the firmware boot-splash.

If you are running rawhide and are seeing a totally different boot-theme then you likely have changed your plymouth theme away from the "charge" default at one point in time; and in that case you are not automatically updated to the new plymouth theme. To switch to the new theme run:

sudo plymouth-set-default-theme -R bgrt

If you do not like the firmware-splash being used as background, you can use the new theme on a dark-grey background instead by running:

sudo plymouth-set-default-theme -R spinner

i've just landed a big milestone for the Flicker Free Boot work I'm doing for Fedors 30. Starting with todays rawhide kernel build, version 5.0.0-0.rc4.git3.1, the fastboot option for the i915 Intel display driver is enabled by default on systems with a Skylake CPU/iGPU and newer, as well as on Valleyview and Cherryview (Bay- and Cherry-Trail) systems.

This means that the last modeset / flicker during boot of UEFI systems using the integrated Intel GPU for display output is now gone.

As discussed in my previous blog post one of my TODO list items for plymouth is creating a new plymouth theme.

Since the transition to plymouth is not entirely smooth plymouth by default will wait 5 seconds (counted from starting the kernel) before showing itself so that on systems which boot under 5 seconds it never shows. As can be seen in this video, this leads to a very non-smooth experience when the boot takes say 7 seconds as plymouth then only shows briefly, leading to a kinda "flash" effect while it briefly shows.

Another problem with the 5 second wait, is now that we do not show GRUB the user is looking at the firmware's bootsplash for not only the often long firmware initialization time, but also for the 5 seconds plymouth waits on top, making it look as if nothing is happening.

To fix this I've been working on a new plymouth theme which draws a spinner over the firmware boot splash, eliminating the ugly transition from the firmware boot splash to plymouth. This also allows removing the show-delay, so that we provide feedback that something is happening as soon as plymouth starts.

Firmware being firmware getting this done right was somewhat harder then I expected, but I've a first "draft" of a new theme doing this now. I've created some videos showing 2 different systems booting the new theme:

My workstation booting, plain version of the theme

My workstation booting, Fedora branded version of the theme

My laptop with diskcrypt booting, plain version of the theme

My laptop with diskcrypt booting, Fedora branded version of the theme

Note the videos with diskcrypt where paused when I entered my passphrase. So there is a bit of a jump in them because of this.

I've built a test version of plymouth for Fedora 29, to give this a try download all rpm files from here except the .src.rpm and -devel files and then from a directory with all those files in it, run:

sudo rpm -Uvh plymouth*.rpm

Since plymouth is part of your initrd, you also need to regenerate your initrd:

sudo dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

This regenerates the initrd for the kernel you are currently running, so if you've installed a kernel update and have not rebooted since then you may not get the new theme when rebooting. In this case rerun the dracut command after rebooting.

Note if you've previously followed my instructions to test flickerfree boot, then you need to remove "plymouth.splash_delay=20" from your kernel commandline, since we now no longer want to have a splash-delay.

Now reboot and you should get the new spinner on firmware-boot-splash theme, with Fedora branding.

If you give this a try and the new theme somehow does not look correct, please mail at hdegoede@redhat.com. If you mail me about the theme not displaying correctly please attach the /run/plymouth.log file which this test-build generates to the email and a video of how the theme misbehaves would be great too.

I still need to discuss the idea of using a new theme incorporating the firmware boot splash with the GNOME design team so this is all subject to change.

A big project I've been working on recently for Fedora Workstation is what we call flickerfree boot. The idea here is that the firmware lights up the display in its native mode and no further modesets are done after that. Likewise there are also no unnecessary jarring graphical transitions.

Basically the machine boots up in UEFI mode, shows its vendor logo and then the screen keeps showing the vendor logo all the way to a smooth fade into the gdm screen. Here is a video of my main workstation booting this way.

Part of this effort is the hidden grub menu change for Fedora 29. I'm happy to announce that most of the other flickerfree changes have also landed for Fedora 29:

There have been changes to shim and grub to not mess with the EFI framebuffer, leaving the vendor logo intact, when they don't have anything to display (so when grub is hidden)

There have been changes to the kernel to properly inherit the EFI framebuffer when using Intel integrated graphics, and to delay switching the display to the framebuffer-console until the first kernel message is printed. Together with changes to make "quiet" really quiet (except for oopses/panics) this means that the kernel now also leaves the EFI framebuffer with the logo intact if quiet is used.

There have been changes to plymouth to allow pressing ESC as soon as plymouth loads to get detailed boot messages.

With all these changes in place it is possible to get a fully flickerfree boot today, as the video of my workstation shows. This video is made with a stock Fedora 29 with 2 small kernel commandline tweaks:

Add "i915.fastboot=1" to the kernel commandline, this removes the first and last modeset during the boot when using the i915 driver.

Add "plymouth.splash-delay=20" to the kernel commandline. Normally plymouth waits 5 seconds before showing the charging Fedora logo so that on systems which boot in less then 5 seconds the system simply immediately transitions to gdm. On systems which take slightly longer to boot this makes the charging Fedora logo show up, which IMHO makes the boot less fluid. This option increases the time plymouth waits with showing the splash to 20 seconds.

So if you have a machine with Intel integrated graphics and booting in UEFI mode, you can give flickerfree boot support a spin with Fedora 29 by just adding these 2 commandline options. Note this requires the new grub hidden menu feature to be enabled, see the FAQ on this.

The need for these 2 commandline options shows that the work on this is not yet entirely complete, here is my current TODO list for finishing this feature:

Work with the upstream i915 driver devs to make i915.fastboot the default. If you try i915.fastboot=1 and it causes problems for you please let me know.

Write a new plymouth theme based on the spinner theme which used the vendor logo as background and draws the spinner beneath it. Since this keeps the logo and black background as is and just draws the spinner on top this avoids the current visually jarring transition from logo screen to plymouth, allowing us to set plymouth.splash-delay to 0. This also has the advantage that the spinner will provide visual feedback that something is actually happening as soon as plymouth loads.

Look into making this work with AMD and NVIDIA graphics.

Please give the new flickerfree support a spin and let me know if you have any issues with it.

Hi All,

First of Thank you to everyone who has been sending me PSR test results, I've received well over a 100 reports!

Quite a few testers have reported various issues when enabling PSR, 3 often reported issues are:

flickering

black screen

cursor / input lag

The Intel graphics team has been working on a number of fixes which make PSR work better in various cases. Note we don't expect this to fix it everywhere, but it should get better and work on more devices in the near future.

This is good news, but the bad news is that this means that all the tests people have so very kindly done for me will need to be redone once the new improved PSR code is ready for testing. I will do a new blogpost (and email people who have send me test-reports), when the new
PSR code is ready for people to (re-)test (sorry).

Regards,

Hans

Hi All,

Update: Thank you everyone for all the test-reports I've received. The response has been quite overwhelming, with over 50 test-reports received sofar. The results are all over the place, some people see no changes, some people report the aprox. 0.5W saving my own test show and many people also report display problems, sometimes combined with a significant increase in power-consumption. I need to take a closer look at all the results, but right now I believe that the best way forward with this is (unfortunately) a whitelist matching on a combination of panel-id (from edid) and dmi data, so that we can at least enable this on popular models (any model with atleast one user willing to contribute).

As you've probably read already I'm working on improving Linux laptop battery live, previously I've talked about enabling SATA link powermanagement by default. This is now enabled in rawhide / Fedora 28 since January 1st and so far no issues have been reported. This is really good news as this leads to significantly better idle power consumption (1 - 1.5W lower) on laptops with sata disks. Fedora 28 will also enable HDA codec autosuspend and autosuspend for USB Bluetooth controllers, for another (aprox) 0.8W gain.

But we're not done yet, testing on a Lenovo T440s and X240 has shown that enabling Panel Self Refresh (PSR) by setting i915.enable_psr=1 saves another 0.5W. Enabling this on all machines has been tried in the past and it causes problems on some machines. So we will likely need either a blacklist or whitelist for this. I'm leaning towards a whitelist to avoid regressions, but if there are say only 10-20 models which don't work with it a blacklist makes more sense. So the most important thing to do right now is gather more data, hence this blog post.

So I would like to ask everyone who runs Linux on their laptop (with a recent-ish kernel) to test this and gather some data for me:

Check if your laptop uses an eDP panel, do: "ls /sys/class/drm" there should be a card?-eDP-1 there, if not your laptop is using LVDS or DSI for the panel, and this does not apply to your laptop.

Check that your machine supports PSR, do: "cat /sys/kernel/debug/dri/0/i915_edp_psr_status", if this says: "PSR not supported", then this does not apply to your laptop.

Get a baseline powerconsumption measurement, install powertop ("sudo dnf install powertop" on Fedora), then close all your apps except for 1 terminal, maximimze that terminal and run "sudo powertop". Unplug your laptop if plugged in and wait 5 minutes, on some laptops the power measurement is a moving average so this is necessary to get a reliable reading. Now look at the power consumption shown (e.g. 7.95W), watch it for a couple of refreshes as it sometimes spikes when something wakes up to do some work, write down the lowest value you see, this is our base value for your laptops power consumption, write this down. Note beware of "dim screen when idle" messing with your brightness, either make sure you do no touch the laptop for a couple of minutes before taking the reading, or turn this feature of in your power-settings.

Add "i915.enable_psr=1" to your kernel cmdline and reboot, check that the LCD panel still works, try suspend/resume and blanking the screen (by e.g. locking it under GNOME3) still work.

Check that psr actually is enabled now (you're panel might not support it), do: "cat /sys/kernel/debug/dri/0/i915_edp_psr_status" and check that it says both: "Enabled: yes" and "Active: yes"

Measure idle powerconsumption again as described under 1. Make sure you use the same LCD brightness setting as before, write down the new value

Dump your LCD panels edid, run "cat /sys/class/drm/card0-eDP-1/edid > panel-edid"

Send me a mail at hdegoede@redhat.com with the following in there:

Report of success or bad side effects

The idle powerconsumption before and after the changes

The brand and model of your laptop

The "panel-edid" file attached

The output of the following commands:

cat /proc/cpuinfo | grep "model name" | uniq

cat /sys/class/dmi/id/modalias

Once I've info from enough models hopefully I can come up with some way for us to enable PSR be default, or at least build a whitelist with popular laptop models and enable it there.

Thanks & Regards,

Hans

For Fedora 27 I'm working on making Fedora 27 a fully integrated VirtualBox guest, the plan is to have Fedora 27 Workstation ship with the VirtualBox Guest Additions installed out of the box, so that cut and paste, file sharing, etc. all will work out of the box for users running Fedora 27 in a VirtualBox vm.

As a first step towards this I'm working on getting the VirtualBox guest kernel drivers merged into the mainline Linux kernel. Up until now this has never been done because of userspace ABI stability concerns surrounding the guest drivers.

I've been talking to VirtualBox upstream about mainlining the guest drivers and VirtualBox upstream has agreed to consider the userspace ABI stable and only extend it in a backwards compatible manner.

I'm about to finish cleaning up the vboxvideo drm/kms driver, when I started working on this the files under /usr/src/vboxguest/vboxvideo as installed by VirtualBox 5.1.18 Guest Additions had a total linecount of 52681 lines. I've been submitting cleanups to VirtualBox upstream and the current VirtualBox upstream svn code is now under 8000 lines.

Update: I've submitted the vboxvideo driver for inclusion into drivers/staging, see this mailinglist thread.

In this blog post I promised I would get back to people who want to use the nvidia driver on an optimus laptop.

The set of xserver patches I blogged about last time have landed upstream and in Fedora 25 (in xorg-x11-server 1.19.0-3 and newer), allowing the nvidia driver packages to drop a xorg.conf snippet which will make the driver atuomatically work on optimus setups.

The negativo17.org nvidia packages now are using this, so if you install these, then the nvidia driver should just work on your laptop.

Note that you should only install these drivers if you actually have a supported (new enough) nvidia GPU. These drivers replace the libGL implementation, so installing them on a system without a nvidia GPU will cause things to break. This will be fixed soon by switching to libglvnd as the official libGL provider and having both mesa and the nvidia driver provide "plugins" for libglvnd. I've actually just completed building a new enough libglvnd + libglvnd enabled mesa for rawhide, so rawhide users will have libglvnd starting tomorrow.

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.

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

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.

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.

Hello fellow Fedorians,

Good news, once you've gdm-3.16.0.1-2.fc22 (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.

Enjoy,

Hans