Created attachment 180560 [details]
I'm running the drm-next branch on a Lenovo Thinkpad T450s with Intel HD 5500 graphics.
When testing the CFT for the Xorg 1.18 update gl worked as expected and modesetting+glamor worked flawlessly, however the Xorg+Mesa update has resulted in the following:
* X fails to start with the modesetting driver reporting
MESA-LOADER: failed to retrieve device information
Require OpenGL version 2.1 or later.
Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 0
on the console.
* X starts with the intel driver but glxgears causes the screen to stop updating (except for the mouse pointer. glxinfo prints the same MESA-LOADER error and also reports "OpenGL renderer string: Mesa DRI Unknown Intel Chipset".
I've observed this behavior on drm-next and TrueOS.
Created attachment 180561 [details]
"glxinfo" output from my Skylake notebook
Same here on "FreeBSD 12.0-CURRENT #0 83893485a9c(drm-next)-dirty: Mon Mar 6 15:15:39 CET 2017".
Reverting to "libdrm-2.4.74_1,1" and keeping "dri" up-to-date don't help.
Reverting to "dri-13.0.4,2" and keeping "libdrm" up-to-date doe't help.
Reverting to "dri-13.0.4,2" and to "libdrm-2.4.74_1,1" don't help.
Reverting my kernel to "drm-next-4.7"-branch and keeping "libdrm" + "dri" up-to-date is working (apart from graphical artifacts), so I think, that something is changed/broken in "drm-next".
I've attached a "truss"-Log from the "glxinfo" execution...
Created attachment 180563 [details]
"truss" log of the "glxinfo" execution...
Created attachment 180565 [details]
Can you show "ls -lL /dev/dri" output and try the attached workaround?
root@discofox:/root/#ls -lL /dev/dri
crw-rw---- 1 root video 0x16f Mar 6 15:19 card0
crw-rw---- 1 root video 0x1af Mar 6 15:19 controlD64
crw-rw---- 1 root video 0x1ef Mar 6 15:19 renderD128
I've applied your workaround, and it works (s. attachment) - thank you very much...
Created attachment 180566 [details]
Output of "glxinfo" with workarounded "libdrm-2.4.75_1,1"
That workaround helps me, too. Thanks!
Confirmed here too with drm-next.
Worked around by rezny in ports r436156. The proper fix is likely to follow up on the following: