Recommended modesetting driver for Intel graphic cards

Tue Nov 21 00:50:39 GMT 2017

I've been using the modesetting driver for over a year and a half now
- on Sandy Bridge, Ivy Bridge, Broadwell and now Kaby Lake hardware.
I've *never* come across a bug all this while (in fact, I was forced
to switch due to GPU lockups on Sandy Bridge with xf86-video-intel).

I haven't had a perceptible difference in performance, everything is
tear-free by default (I had to tinker with xorg.conf to enable
sync-to-vblank with SNA on the Intel DDX) - overall a much smoother
out of the box experience with the modesetting driver than the intel
one.

My 2c, experience on Arch Linux.
Thanks,
Boudhayan Gupta
KDE e.V. - Community Working Group
+49 151 71032970

On 21 November 2017 at 00:27, Milian Wolff <mail at milianw.de> wrote:
> On Montag, 20. November 2017 23:40:38 CET Milian Wolff wrote:
>> On Montag, 20. November 2017 17:28:06 CET Martin Flöser wrote:
>> > Am 2017-11-20 11:59, schrieb Milian Wolff:
>> > > On Samstag, 18. November 2017 15:34:16 CET Friedrich W. H. Kossebau
>> > >
>> > > wrote:
>> > >> Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker:
>> > >> > On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote:
>> > >> > > Am 2017-11-07 20:08, schrieb Martin Koller:
>> > >> > > >> Are you aware that KWin uses QtQuick for all its UI elements,
>> > >> > > >> such
>> > >> > > >> as
>> > >> > > >> Alt+TAB?
>> > >> > > >
>> > >> > > > I have deactivated the compositor since sadly it simply does not
>> > >> > > > work
>> > >> > > > on my laptop (the intel graphics driver just freezes the whole
>> > >> > > > machine).
>> > >> > >
>> > >> > > I did not talk about compositor, I talked about QtQuick! Yes, KWin
>> > >> > > uses
>> > >> > > QtQuick for rendering it's UI, that is unrelated to compositing.
>> > >> > >
>> > >> > > Now you mention that your intel graphics driver freezes the whole
>> > >> > > system. I'm using Intel on all my systems and it's the most used
>> > >> > > driver
>> > >> > > out there. We get many, many, many bug reports in KWin about
>> > >> > > issues.
>> > >> > > Freezing systems has not been in the list for now something like
>> > >> > > two
>> > >> > > years.
>> > >> > >
>> > >> > > Given that I am very certain that you have a hardware issue where
>> > >> > > people
>> > >> > > can help you with. Intel GPUs are good enough to run the Plasma
>> > >> > > session
>> > >> > > without any negative impact.
>> > >> > >
>> > >> > > So let us help you fix your issues that you can enjoy our work
>> > >> > > without
>> > >> > > having to spend time on writing your own shell.
>> > >> > >
>> > >> > > First thing: are you using the xorg-modesettings driver? If not:
>> > >> > > install
>> > >> > > it, problems solved. Do not (I repeat) do not use the xorg-intel
>> > >> > > driver.
>> > >> > >
>> > >> > > For kernel I recommend at least version 4.13 as this comes with the
>> > >> > > atomic modesettings driver stack enabled by default. If you do not
>> > >> > > have
>> > >> > > such a kernel version yet I highly recommend to give it a try.
>> > >> >
>> > >> > Martin, thanks a lot for your advice!
>> > >> >
>> > >> > I've suffered from freezes since I updated my openSUSE 13.2 to
>> > >> > Tumbleweed
>> > >> > some time ago (and much longer on my laptop where I've switched to
>> > >> > Leap
>> > >> > and
>> > >> > later Tumbleweed much earlier).
>> > >>
>> > >> Same here, happy to finally see someone with correlated experience. I
>> > >> never
>> > >> got any useful hints in the log files, so was close to consider my
>> > >> hardware
>> > >> broken. Strange enough all freezes seemed to happen while moving the
>> > >> mouse
>> > >> though, which kept the hope alive it was something software-related.
>> > >>
>> > >> Curious to see if my daily freeze will now be a thing of the past now
>> > >> that I
>> > >> changed the driver. Though I am on a 2nd gen 915 device, while all the
>> > >> modesettings driver talk I came across on a quick search seemed to be
>> > >> only
>> > >> about gen4 and later? No issues seen for one hour so far, hope grows
>> > >>
>> > >> :)
>> > >> :
>> > >> > The switch to the modesetting driver seems
>> > >> > to have fixed those issues. It took me some time to find out how to
>> > >> > enable
>> > >> > the modesetting driver. To save others the time here's how to do it:
>> > >> > Write
>> > >> > #=====
>> > >> > Section "Device"
>> > >> >
>> > >> >    Identifier  "Intel Graphics"
>> > >> >    Driver      "modesetting"
>> > >> >
>> > >> > EndSection
>> > >> > #=====
>> > >> > to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure
>> > >> > that
>> > >> > this is the only (or at least the first) "Device" section in any of
>> > >> > the
>> > >> > files in /etc/X11/xorg.conf.d/.
>> > >>
>> > >> Another approach seems to be to uninstall xf86-video-intel, that way
>> > >> the
>> > >> seemingly hardcoded driver-auto-match logic will skip forward to the
>> > >> modesetting driver:
>> > >>
>> > >> [    12.125] (==) Matched intel as autoconfigured driver 0
>> > >> [    12.125] (==) Matched intel as autoconfigured driver 1
>> > >> [    12.125] (==) Matched modesetting as autoconfigured driver 2
>> > >> [    12.125] (==) Matched fbdev as autoconfigured driver 3
>> > >> [    12.125] (==) Matched vesa as autoconfigured driver 4
>> > >> [    12.125] (==) Assigned the driver to the xf86ConfigLayout
>> > >> [    12.125] (II) LoadModule: "intel"
>> > >> [    12.127] (WW) Warning, couldn't open module intel
>> > >> [    12.127] (II) UnloadModule: "intel"
>> > >> [    12.127] (II) Unloading intel
>> > >> [    12.127] (EE) Failed to load module "intel" (module does not
>> > >> exist, 0)
>> > >> [    12.127] (II) LoadModule: "modesetting"
>> > >> [    12.127] (II) Loading
>> > >> /usr/lib64/xorg/modules/drivers/modesetting_drv.so
>> > >
>> > > I've also recently come across this. According to [1] the performance
>> > > is
>> > > supposedly much worse. Is this still true for more recent mesa/kernel
>> > > versions?
>> >
>> > You quoted Phoronix. I hope you don't expect Phoronix to be able to get
>> > proper measurements. That's something Phoronix still hasn't succeeded
>> > after all those years. Just for fun I clicked that link and the first
>> > graph shows a benchmark showing a game one running at 22.15, the other
>> > at 22.13 fps. This difference is kernel sneezing. So much to that. But
>> > the real issue is that a game running at 22 fps is unplayable. It has
>> > nothing to do in the benchmark, the setup is broken. This has been the
>> > issue as long as I followed Phoronix benchmarking. From an academic
>> > point of view - which you understand as much as I do - it's just all
>> > extremely horrible.
>> >
>> > Don't take any numbers serious. Michael doesn't understand how to do
>> > benchmarking. He just runs his tools. He doesn't think about what a
>> > benchmark should show, what he wants to show. And he doesn't interpret
>> > the numbers. He just gives numbers. Do they matter? Who knows. You
>> > derived from his numbers that the "performance is much worse". Is that
>> > the case? I don't know because I don't see this in the benchmark. I just
>> > see numbers. We would have to ask someone understanding the system
>> > whether it makes sense. I assume there are not many people who might be
>> > able to answer the question. Maybe the authors of GtkPerf, maybe Keith
>> > Packard as the author of glamor, but certainly not Michael from
>> > Phoronix.
>> >
>> > Hadn't done a Phoronix benchmarking rant for years ;-) Sad that it still
>> > is needed.
>> >
>> > For reference I point to a blog post from 2012 where I discuss Phoronix
>> > benchmarking in detail:
>> > http://blog.martin-graesslin.com/blog/2012/09/why-i-dont-like-game-renderi
>> > ng -performance-benchmarks/
>> >
>> > Everything written there still fully applies to the benchmark in
>> > question
>>
>> Thanks for the rant :) I rarely look at graphic related Phoronix stuff since
>> I don't know the tools and what they measure. For some I/O and CPU stuff,
>> the tools are useful and thus the numbers reported are, too.
>>
>> So since the tools used here are apparently useless, could you or someone
>> else please answer the actual question: Is there any perceived performance
>> difference between modesetting driver and intel driver? I assume it isn't
>> from the way you respond. Just wanted to make sure.
>
> Well, I tried it out myself now that tosky said it works for him. Indeed, it
> does for me too - and some glaring bugs are resolved on top! Most notably I'm
> finally able to launch secondary X sessions, nice :)
>
> Thanks everyone for recommending this. I bet more people have this old driver
> installed out of habit (like I did), without a clear understanding of what
> they are doing.
>
> Cheers
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de