4 ms·
Two issues with that, the atomic modesetting regressions are in the DRM part. Also, I've tried the generic modesetting X11 drivers, and that one's very bad, doe
by cm3 10y ago
Two issues with that, the atomic modesetting regressions are in the DRM part. Also, I've tried the generic modesetting X11 drivers, and that one's very bad, does heavy tearing and is unusable on my machines. The best setup right now is to use the intel ddx with TearFree enabled plus vsync forced with compton. If you don't enable TearFree plus vsync via glx via a compositor, there will be heavy tearing.
New issues since Arch Linux's update to Mesa 12 are some weird drawing bugs that surface as flickering of the content for a few cycles (redraws) a couple times during the day. It's not screen flickering. The content is sometimes displayed partially and then, say, you type something, content flicker on each event for a few redraw cycles until it cures itself. If I had to guess, I'd guess something in mesa 12 and/or current X11 intel stack is very buggy.
How bad is this with the binary nvidia drivers? I couldn't use Wayland with that, but if there's zero tearing with nvidia, there's less incentive to use Wayland anyway.
- TingPing 10y agoAnecdotally most people seem to have a much more stable experience with modesetting, distros like Debian have even been promoting over Intel for a while. I use Arch myself and have had no issues. Also DRI3 is a far better solution than the various TearFree hacks, less performance overhead, better integration with the compositor, and not hardware specific. Nvidia drivers don't support DRI3 but they have their own double compositing hack that work as well as any other.
- cm3 10y agoNo, DRI3 is default in Arch and with that there's also heavy tearing, and I must enable tearfree plus vsync. DRI3 actually has a weird bug when opening a video with mpv, where you can watch for a split second how a small rectangle is resized to the desired video window's size. This doesn't happen with DRI2 or Wayland. All of this is most likely very GPU-dependent, so Debian cannot make a decision like that with confidence. I understand that the simple modesetting driver relies on Mesa and there's no UXA or SNA code which can introduce bugs, but I can assure you that when I tried the generic modesetting driver, it was one big tearing party. BTW, DRI2 and DRI3 in Glamor mode is pretty much the same as the generic modesetting driver, because the SNA code isn't used at all. I've been tyring my best to migrate to Wayland compositors, but Xwayland integration is still too buggy. But it might be an easier solution than messing around with xorg.conf.