- 1 Corrupted fonts after resume from ram
- 2 There is no i915.powersave option
- 3 GUC?
- 4 [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A
- 5 The new intel driver is a little bit faster than modesetting
- 6 Backlight is not adjustable after trying various acpi_osi values
- 7 DRI3 confusion
Corrupted fonts after resume from ram
I've finally found searching across many forums the solution for my i915 graphic card.
My card is: "Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)".
The problem is: After resuming from ram, some letter have a missing orizzontal line, for example I see ¦ instead of |. Another thing is that sometime, after resuming, the cpu goes to 100% of usage with no apparent reason.
The solution is: Create the file /etc/modprobe.d/local.conf (if it doesn't already exist) and add to it the line "options drm_kms_helper poll=N".
There is no i915.powersave option
It's probably some mistake. I have an HD Graphics 4000 and I note no "powersave" option in output of
modinfo -p i915 and
systool -m i915 -av commands. This is the output of both commands: modprobe, systool.
- Lack of powersave parameter for i915 confirmed as of today with xf86-video-intel 1:2.99.917+691+ga77397a-1 (on both an Atom Pineview and Core i3 Ivy boxes). Also by dmesg:
[ 0.980110] i915: unknown parameter 'powersave' ignored [ 1.069323] [drm] Initialized i915 1.6.0 20160229 for 0000:00:02.0 on minor 0
- Article now looks OK to me after Tharre contribution as September 24, 2016 00:55. --kozaki (talk) 11:16, 24 September 2016 (UTC)
What is this: https://01.org/linuxgraphics/downloads/sklgucver43 and do we need it? Greyltc (talk) 19:53, 7 January 2016 (UTC)
[drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A
Maybe the solution to get rid of the above dmesg log spamming could be mentioned? You just add `options i915 enable_psr=0` to the file `/etc/modprobe.d/i915.conf`. Bjourne (talk) 17:04, 19 August 2016 (UTC)
The new intel driver is a little bit faster than modesetting
Modesetting was faster and better then xf86-video-intel, but after 09/04 upgrade, xf86-video-intel is 10%-20% faster. Do you noted the difference?
- Nope, unfortunately the driver is still to buggy to see any real progress happening. I am fighting screen stuttering without any success, see Talk:Dell XPS 13 (2016)#Screen stuttering. -- Edh (talk) 08:24, 16 September 2016 (UTC)
Backlight is not adjustable after trying various acpi_osi values
Full details on Stack Exchange.
I've seen in the forum people ask from time to time how to enable DRI3 on their system.
As stated many times there, DRI3 should be on for most (if not all) of them. But people keep telling them to check
cat /var/log/Xorg.0.log | grep DRI
which shows up this message:
GLX: Initialized DRI2 GL provider for screen 0
which is *not accurate*.
If you run this command instead:
LC_ALL=C LIBGL_DEBUG=verbose glxinfo | grep DRI
you might stump with this other message:
libGL: Using DRI3 for screen 0
which proves you are using DRI3 even though X11 doesn't reply with the correct information.
The command was adapted from xorg mailing list.
So, it think adding this information in the page could be of major interest. What do you think?