Bug 244306 - x11-servers/xorg-server: starting OpenGL application freezes the display (regression with 1.20.7)
Summary: x11-servers/xorg-server: starting OpenGL application freezes the display (reg...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
URL: https://gitlab.freedesktop.org/xorg/x...
Depends on:
Reported: 2020-02-22 11:10 UTC by Philippe Michel
Modified: 2020-04-15 19:51 UTC (History)
19 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)

Restore xorg-server's FIXDRM option (1.42 KB, patch)
2020-02-22 12:48 UTC, Vladimir Kondratyev
no flags Details | Diff
Update mesa to 19.0.8 (4.67 KB, patch)
2020-02-25 17:36 UTC, Niclas Zeising
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Michel 2020-02-22 11:10:08 UTC
Since upgrading xorg-server to 1.20.7 (built and installed with default settings), starting an OpenGL application seems to grab input events and freeze before any window is realized.

This happens for instance with firefox and mpv and I was able check the apparent relation to OpenGL with a self-maintained application that I can build with or without GL support (freezes in the first case, works fine in the latter).

The pointer moves normally but neither mouse or touchpad clicks or regular keyboard inputs work (ctrl-alt-Fn does).

This is on a Lenovo X220 with FreeBSD 12.1 stable and relevant ports up to date.
Comment 1 Vladimir Kondratyev freebsd_committer 2020-02-22 12:48:34 UTC
Created attachment 211830 [details]
Restore xorg-server's FIXDRM option

I have seen very similar bug in the past with xfwm-4.12. It went away after xfwm updating to 4.14 but it is possible that it still exists in some other WMs.

There were several options for me to workaround this at xfwm-4.12 times:
1. Downgrade drm-kmod to 4.11
2. Replace xfwm compositor with compton/picom.
3. Use xf86-video-intel instead of modesetting driver.
4. Rebuild xorg-server with FIXDRM option enabled after enclosed patch has been applied.
Comment 2 Philippe Michel 2020-02-22 18:09:38 UTC
Option 4 from the list of workarounds fixed the issue.
I didn't try 1 and 3, and 2 is irrelevant (I use fluxbox as WM).

I'm not particularly attached to fluxbox, so I suppose I'll look for another window manager that works seamlessly, but for now the workaround is hardly onerous.

Thanks for the quick response.
Comment 3 Joseph Mingrone freebsd_committer 2020-02-22 23:49:01 UTC
Option 3 works on

- an X220 running 12.1 and stumpwm
- a T530 running 12.1 and fluxbox.

Thank you both.
Comment 4 rkoberman 2020-02-22 23:57:42 UTC
I probably see the same issue. My system freezes the moment firefox starts, long before any window is drawn, but glxgears runs fine. I probably should test a few other things like mpv and virtualbox. In any case, it's not just the use of mesa-libs.

I will try the patch shortly and see how that works for me.

Please update the ticket to "Affects some people".
Comment 5 Joseph Mingrone freebsd_committer 2020-02-23 00:02:25 UTC
Uninstalling xf86-video-intel and installing the patched xorg-server with the fixdrm knob turned on also fixes the problem (on the X220).
Comment 6 rkoberman 2020-02-23 00:37:00 UTC
I can confirm that FIXDRM fixes the problem for me. All drivers and servers are up to date.

Note: System is ThinkPad T520. Sandy Bridge graphics. Just short of 9 years old.
Comment 7 rkoberman 2020-02-23 00:40:48 UTC
Also, just for the record, I have been running modesetting or a long time, so xf86-video-intel was already absent from the system.
Comment 8 Niclas Zeising freebsd_committer 2020-02-23 08:18:41 UTC
Just to confirm, this issue happens even with the latest drm-*-kmod from 20200221?
Comment 9 Joseph Mingrone freebsd_committer 2020-02-23 11:41:44 UTC
For all my tests, I had drm-fbsd12.0-kmod-4.16.g20200221 installed.
Comment 10 rkoberman 2020-02-23 19:01:04 UTC
(In reply to Niclas Zeising from comment #8)
Yes.I updated the drm-kmod-* to 20200221 during troubleshooting and the problem remained. Only after the FIXDRM patch would X survive starting firefox. Since then, there have been no problems.
Comment 11 oleg.nauman 2020-02-23 20:23:13 UTC
It fixes KDE rendering with new xorg-server.

Thank you
Comment 12 Peter 2020-02-23 22:35:01 UTC
FIXDRM patch also fixed it for me.


using drm only.

xorg-server 1.20.7,1
devd off
fixdrm on
suid on
udev on

without patch:
on laptop:
  firefox <--- screen frozen

I'd ssh into laptop from desktop, kill xinit, got my vt back as if nothing ever happened.

Also, a user not part of 'video' group could start firefox just fine
user in video group always froze up the screen.
Comment 13 Peter 2020-02-23 22:37:02 UTC
(In reply to Peter from comment #12)
window manager is i3.
Comment 14 rsmith 2020-02-23 22:41:36 UTC
Just to confirm, I also have this issue.
(modesetting driver, Intel Kaby Lake, i3 window manager)

1.18 Xorg.0.log:

[   645.255] (II) modeset(0): [DRI2] Setup complete
[   645.255] (II) modeset(0): [DRI2]   DRI driver: i965
[   645.255] (II) modeset(0): [DRI2]   VDPAU driver: i965
[   645.305] (--) RandR disabled
[   645.310] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   645.310] (II) AIGLX: enabled GLX_ARB_create_context
[   645.310] (II) AIGLX: enabled GLX_ARB_create_context_profile
[   645.310] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[   645.310] (II) AIGLX: enabled GLX_INTEL_swap_event
[   645.310] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[   645.310] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[   645.310] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[   645.310] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[   645.310] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[   645.310] (II) AIGLX: enabled GLX_ARB_create_context_robustness
[   645.310] (II) AIGLX: Loaded and initialized i965
[   645.310] (II) GLX: Initialized DRI2 GL provider for screen 0

1.20 Xorg.0.log:

[   404.294] (II) modeset(0): [DRI2] Setup complete
[   404.294] (II) modeset(0): [DRI2]   DRI driver: i965
[   404.294] (II) modeset(0): [DRI2]   VDPAU driver: i965
[   404.294] (II) Initializing extension Generic Event Extension
[   404.294] (II) Initializing extension SHAPE
[   404.294] (II) Initializing extension MIT-SHM
[   404.294] (II) Initializing extension XInputExtension
[   404.294] (II) Initializing extension XTEST
[   404.294] (II) Initializing extension BIG-REQUESTS
[   404.295] (II) Initializing extension SYNC
[   404.295] (II) Initializing extension XKEYBOARD
[   404.295] (II) Initializing extension XC-MISC
[   404.295] (II) Initializing extension SECURITY
[   404.295] (II) Initializing extension XFIXES
[   404.295] (II) Initializing extension RENDER
[   404.295] (II) Initializing extension RANDR
[   404.296] (II) Initializing extension COMPOSITE
[   404.296] (II) Initializing extension DAMAGE
[   404.296] (II) Initializing extension MIT-SCREEN-SAVER
[   404.296] (II) Initializing extension DOUBLE-BUFFER
[   404.296] (II) Initializing extension RECORD
[   404.296] (II) Initializing extension DPMS
[   404.296] (II) Initializing extension Present
[   404.297] (II) Initializing extension DRI3
[   404.297] (II) Initializing extension X-Resource
[   404.297] (II) Initializing extension XVideo
[   404.297] (II) Initializing extension XVideo-MotionCompensation
[   404.297] (II) Initializing extension GLX
[   404.300] (II) AIGLX: Loaded and initialized i965
[   404.300] (II) GLX: Initialized DRI2 GL provider for screen 0

Will try the patch and report back.
Comment 15 rsmith 2020-02-23 23:07:41 UTC
(In reply to rsmith from comment #14)

The provided FIXDRM patch fixed the issue for me as well.
Comment 16 Manuel Stühn 2020-02-25 07:35:35 UTC
(In reply to Vladimir Kondratyev from comment #1)
Option 3 (xf86-video-intel) worked, but is not desirable for me due to higher current consumption. Option 4 (FIXDRM-patch) works like a charm on my Lenovo TP T450 and fixes the problem for me, too.
Comment 17 Jan Beich freebsd_committer 2020-02-25 10:19:14 UTC
(In reply to Manuel Stühn from comment #16)
> Option 3 (xf86-video-intel) worked, but is not desirable for me
> due to higher current consumption.

Default AccelMethod is UXA which is not as efficient as SNA.
Comment 18 Mathias.Picker 2020-02-25 13:40:22 UTC
Just additional feedback: 

for me and a friend, both with X1 Tablet with FreeBSD-stable, this error popped up and the fixdrm patch/option fixed it for us.

Thanks a lot!

Comment 19 Michael Gmelin freebsd_committer 2020-02-25 14:22:45 UTC
(In reply to Manuel Stühn from comment #16)
(In reply to Jan Beich from comment #17)

I had tearing issues with modesetting in the past, that's why I
still prefer xf86-video-intel. Seems like I need to test

Thanks to both of you for your input on power consumption,
I'll try both configurations and see what gives me the
best mileage.
Comment 20 Joseph Mingrone freebsd_committer 2020-02-25 14:29:37 UTC
(In reply to Vladimir Kondratyev from comment #1)

I tested 2.

Running 'picom' triggers the problem, but running 'picom --backend glx' is a workaround (can start firefox, chrome, mpv, etc.).
Comment 21 Baptiste Daroussin freebsd_committer 2020-02-25 15:08:20 UTC
I do confirm that it is needed and it works on x1 7th gen (UHD Graphics 620 (Whiskey Lake))
Comment 22 Joseph Mingrone freebsd_committer 2020-02-25 15:12:58 UTC
Comment 23 Niclas Zeising freebsd_committer 2020-02-25 17:22:01 UTC
Do we have a list of hardware and software combinations that need this?
From what I can tell, most intel hardware, when using the modesetting driver, needs this fix, unless they are running a compositor, such as picom or compton?
It does work however, if they are using xf86-video-intel?
Is this correct?

We are looking into the proposed patch, but would like a little bit of time figuring out what's going on and why it's needed.  I have no problems with it being committed defaulting to off for now, though.
Comment 24 Joseph Mingrone freebsd_committer 2020-02-25 17:25:50 UTC
(In reply to Niclas Zeising from comment #23)

These are the system that I am aware of:

Sandy Bridge
Ivy Bridge
Kaby Lake
Whiskey Lake

You're summary sound right, except picom will trigger the problem if run without arguments, but will be a workaround if run as 'picom --backend glx'.

Could you approve the Phab diff and I'll commit it?
Comment 25 Niclas Zeising freebsd_committer 2020-02-25 17:26:54 UTC
(In reply to Joseph Mingrone from comment #24)
Is this regardless of FreeBSD version and drm-kmod version?
Comment 26 Joseph Mingrone freebsd_committer 2020-02-25 17:29:28 UTC
According to wulf@'s post (second message here), downgrading drm-kmod to 4.11 is a workaround, so all drm-kmod are not affected.
Comment 27 commit-hook freebsd_committer 2020-02-25 17:32:28 UTC
A commit references this bug:

Author: jrm
Date: Tue Feb 25 17:32:04 UTC 2020
New revision: 527097
URL: https://svnweb.freebsd.org/changeset/ports/527097

  x11-servers/xorg-server: Restore FIXDRM as an off-by-default knob

  This is a workaround for a problem with certain systems [1] after
  x11-servers/xorg-server was upgraded to 1.20.7.  Other workarounds are
  described in PR 244306.

  These systems have been reported to have problems:
  Sandy Bridge
  Ivy Bridge
  Kaby Lake
  Whiskey Lake

  PR:	244306
  Submitted by:	wulf
  Reported by:	philippe.michel7@free.fr
  Approved by:	x11 (zeising)
  Differential Revision:	https://reviews.freebsd.org/D23834

Comment 28 Niclas Zeising freebsd_committer 2020-02-25 17:36:37 UTC
Created attachment 211930 [details]
Update mesa to 19.0.8

This issue *might* be fixed by updating mesa.  I have a patch (attached) for this.  Can those of you who experience this issue please apply it, and rebuild mesa-dri and mesa-libs and xorg-server without the FIXDRM option and try it.

Thank you very much!
Comment 29 Joseph Mingrone freebsd_committer 2020-02-25 19:03:23 UTC
(In reply to Niclas Zeising from comment #28)
The mesa update doesn't solve the problem.
Comment 30 Jan Beich freebsd_committer 2020-02-25 19:19:29 UTC
(In reply to Joseph Mingrone from comment #29)
> The mesa update doesn't solve the problem.

Can you try with "export LIBGL_DRI3_ENABLE=1"? Make sure the environment variable is visible to all GL applications i.e., put it into ~/.profile or ~/.login (after converting to csh-like syntax) rather than ~/.xinitrc.
Comment 31 Joseph Mingrone freebsd_committer 2020-02-25 20:45:16 UTC
(In reply to Jan Beich from comment #30)

With `export LIBGL_DRI3_ENABLE=1` in the environment, everything seems to be working fine after a few minutes.
Comment 32 Masachika ISHIZUKA 2020-02-26 00:10:45 UTC
(In reply to Jan Beich from comment #30)

Thank you for good information.
After adding 'setenv LIBGL_DRI3_ENABLE 1' to ~/.envrc, firefox 73.0.1 works fine on 13.0-CURRENT r358308 with i7-4500U(haswell).
Comment 33 Niclas Zeising freebsd_committer 2020-02-26 09:18:21 UTC
(In reply to Masachika ISHIZUKA from comment #32)

Is this using modesetting or xf86-video-intel? Which drm-kmod version are you using?
Comment 34 Christopher 2020-02-26 15:04:00 UTC
The FIXDRM option has fixed most of this issue for me but has opened up another issue.

I have a dual monitor setup and with the FIXDRM option turned on... I get weird artifacts on the monitor opposite of the monitor displaying the mouse cursor.

Move the cursor to the other monitor and the artifacts switches to the opposite monitor.

If I rebuild xorg with the FIXDRM option turned off the artifacts go away but of course, the freezing comes back.

i5 / 915 intel, i3wm, FreeBSD 12.1-p2, all ports up to date.
Comment 35 Joseph Mingrone freebsd_committer 2020-02-26 15:29:16 UTC
I recall screen artifacts from some time ago.  I thought there is/was an issue somewhere (Gitlab, or one of the GitHub repos maybe?), but I can't find it.  If what you are describing was the same as I experienced, the problem occurred after rebooting.  If I restarted X after the reboot the artifacts went away.

In any case, it sounds like installing xf86-video-intel or forcing DRI3 with the suggestion jbeich posted might be a better solution for you.
Comment 36 Manuel Stühn 2020-02-26 18:01:10 UTC
(In reply to Niclas Zeising from comment #28)

I can confirm that the mesa-update and DRI3-Flag works here for this setup:

- Intel(R) Core(TM) i5-5300U CPU (HD Graphics 5500)
- FreeBSD 12.1-RELEASE-p2
- drm-fbsd12.0-kmod-4.16.g20200221
- mesa-dri-19.0.8
- mesa-libs-19.0.8
- xorg-server 1.20.7_1,1 FIXDRM : off
- .login_conf setting :setenv=LIBGL_DRI3_ENABLE=1:
- using modesetting-driver (xf86-video-intel not even installed)

Thank you!
Comment 37 rkoberman 2020-02-26 20:39:22 UTC
(In reply to Niclas Zeising from comment #28)
Works on my Sandy Bridge ThinkPad T520.
LIBGL_DRI3_ENABLE is set to 1.
xorg-server built without FIXDRM.
Latest drm-KMOD (20200221) installed.
Comment 38 Masachika ISHIZUKA 2020-02-28 12:18:20 UTC
(In reply to Niclas Zeising from comment #33)

I'm using modeset and drm-current-kmod-4.16.g20200221.
This is good working with i5-7500(kaby lake), too.
Comment 39 rsmith 2020-03-01 16:43:03 UTC
(In reply to Niclas Zeising from comment #28)

I can confirm that the mesa update works.

- Intel(R) Core(TM) i7-7700HQ (Intel HD Graphics 630)
- FreeBSD 12.1-STABLE r354571 GENERIC  amd64
- drm-fbsd12.0-kmod-4.16.g20200221
- gpu-firmware-kmod-g20200130
- mesa-dri-19.0.8
- mesa-libs-19.0.8
- xorg-server-1.20.7_1,1 (OPTIONS_FILE_UNSET+=FIXDRM)
- LIBGL_DRI3_ENABLE=1 is set.

The intel driver is not installed; the modesetting driver is used.

The only problem with this update is that mesa still has a build dependency on Python 2.7. (see mesa-dri/Makefile.common).

So, in mesa-dri/Makefile.common I changed "python:2.7,build" to "python:build", re-built and re-installed mesa-libs and mesa-dri and it worked fine with Python 3.7.

Other than xorg-server, libosmesa and mesa-dri I did *not* have to rebuild any of the programs that require mesa-libs.
Comment 40 Xin LI freebsd_committer 2020-03-01 18:35:00 UTC
I can confirm that the mesa update works.

- Intel(R) Xeon(R) CPU E3-1505M v6 (Intel HD Graphics P630)
- FreeBSD 13.0-CURRENT r358478 GENERIC  amd64
- drm-kmod 54164ffbc9dd6f37dae4d898bf7a516200ab3c5c
- gpu-firmware-kmod c9eb7f3ce53ae220e1c76004265593e06b5c583b
- mesa-dri-19.0.8
- mesa-libs-19.0.8
- xorg-server-1.20.7_1,1 (OPTIONS_FILE_UNSET+=FIXDRM)
- LIBGL_DRI3_ENABLE=1 is set.

However, it seems wired memory would increase rather quickly, which may or maybe not related.
Comment 41 Niclas Zeising freebsd_committer 2020-03-01 18:39:21 UTC
(In reply to Xin LI from comment #40)

The issue with wired memory is caused by https://svnweb.freebsd.org/base?view=revision&revision=358363 .

Thanks for the report!
Comment 42 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-03-03 09:56:32 UTC
Mesa patch tested successfully with the following settings:

- Intel(R) Celeron(R) CPU 1007U (3rd Gen Core processor Graphics Controller)
- FreeBSD 13.0-CURRENT r358179 GENERIC  amd64
- drm-current-kmod-4.16.g20200221
- gpu-firmware-kmod-g20200130
- mesa-dri-19.0.8
- mesa-libs-19.0.8
- xorg-server 1.20.7_1,1 FIXDRM : off
- LIBGL_DRI3_ENABLE=1 is set
- using modesetting-driver (xf86-video-intel not even installed)
Comment 43 rsmith 2020-03-07 12:15:37 UTC
(In reply to Niclas Zeising from comment #28)

One thing not solved by the mesa update is multimedia/mpv locking up the display when using VAAPI.  Additionally, mpv complains when I use VDPAU (since it's emulated by libvdpau-va-gl).

So, since this update enables the use of the vulkan API on Intel graphics hardware, I have rebuilt miltimedia/mpv with vulkan support.  This also works fine; no more lockups with mpv and somewhat lower CPU usage when using it.

And I can now play vkquake. ;-)
Comment 44 James Wright 2020-03-07 20:42:40 UTC
Hit the same issue of OpenGl apps freezing on MacBookAir (Broadwell). 
Simply setting the LIBGL_DRI3_ENABLE flag fixed it for me without changing anything else;

- Intel(R) Core(TM) i7-5650U CPU (HD Graphics 6000)
- FreeBSD 12.1-STABLE (r358483)
- drm-fbsd12.0-kmod-4.16.g20200221 (built from ports)
- mesa-dri-18.3.2_9 (pkg)
- mesa-libs-18.3.2_3 (pkg)
- xorg-server 1.20.7_1,1 (pkg)

- using modesetting-driver (configured vua /etc/X11/xorg.conf)
- added "export LIBGL_DRI3_ENABLE=1" to my ~/.zshrc
Comment 45 commit-hook freebsd_committer 2020-03-08 19:27:37 UTC
A commit references this bug:

Author: zeising
Date: Sun Mar  8 19:27:28 UTC 2020
New revision: 528071
URL: https://svnweb.freebsd.org/changeset/ports/528071

  graphics/mesa-libs: Change default to use DRI3

  Change the default mesa configuration to use DRI3 rather than the older DRI2
  interface.  This should improve performance somewhat, and alleviates the need
  for the FIXDRM option in x11-servers/xorg-server.

  Remove the FIXDRM option from x11-servers/xorg-server.

  Add an UPDATING entry for the change.

  For users of graphics/drm-legacy-kmod or the base graphics drivers, this might
  cause regressions.  If you experience problems when running OpenGL applications
  please force the use of the DRI2 backend by setting the LIBGL_DRI3_DISABLE
  environment variable to 1 before starting any OpenGL application.  This is
  easiest done by adding it to your shell startup file or .xinitrc.

  Add UPDATING entry for xorg-server, detailing the change of device
  configuration backend.

  PR:		196678, 244306 (for tracking)

Comment 46 Niclas Zeising freebsd_committer 2020-03-08 19:43:35 UTC

Thank you to all of you who have helped testing, and sorry for keeping you waiting.  I've just committed an update that makes mesa use DRI3 by default, which should alleviate the need for the FIXDRM option.  If you still have trouble, even after updating mesa-libs past 18.3.2_4, please let me know asap.

Niclas Zeising
FreeBSD Graphics Team
Comment 47 Joseph Mingrone freebsd_committer 2020-03-08 19:45:52 UTC
Will do.  Thanks Niclas.
Comment 48 rsmith 2020-03-08 20:53:29 UTC
(In reply to Niclas Zeising from comment #46)

Will the mesa ports be updated to 19.0.x?
Comment 49 James Wright 2020-03-08 21:05:00 UTC
(In reply to rsmith from comment #48)

There is already a seperate PR for that here;
Comment 50 Niclas Zeising freebsd_committer 2020-04-15 19:51:34 UTC
After the switch to use DRI3, this bug should be solved.  If the issue persists, please reopen this bug, or create a new one.