Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Dec 2015 14:33:40 +0300
From:      Greg <greg@unrelenting.technology>
To:        freebsd-x11@freebsd.org
Subject:   Testing i915 update on Haswell (ThinkPad X240)
Message-ID:  <20151230113340.GA91889@unrelenting.technology>

next in thread | raw e-mail | index | archive | help
Hello!

So I bought a Haswell ThinkPad, specifically to run FreeBSD.
Here's my report on Haswell graphics.


When I load `i915kms` (via kldload or kld_list in rc.conf, loading it 
from the EFI loader == unbootable), it repeats this error for less than 
a second:

error: [drm:pid51453:intel_sbi_read] *ERROR* timeout waiting for SBI to 
complete read transaction
error: [drm:pid51453:intel_sbi_write] *ERROR* timeout waiting for SBI to complete write transaction

Then it shows this and works fine:

info: [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2
info: [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
banging on pin 5

Occasionally, the GPU is hung after boot.
Power consumption is high in the console, and startx results in a black 
screen with working mouse, but nothing else.
Switching back to vt, pressing Ctrl-C, and running startx again fixes 
the problem and everything works fine.
(dmesg reports "GPU hung" after killing the first Xorg.)


My Xorg.conf section for the GPU:

Section "Device"
	Option      "AccelMethod"        	"sna"
	Option      "TripleBuffer"       	"true"
	Option      "HotPlug"            	"true"
	Option      "TearFree"           	"false"
	Identifier  "Card0"
	Driver      "intel"
	BusID       "PCI:0:2:0"
EndSection

UXA acceleration results in text corruption on screen and application 
crashes, IIRC it's an old method & shouldn't be used with Haswell.
SNA acceleration works great -- WITHOUT the TearFree option!
The TearFree option immediately crashes Xorg.

To make it tear-free, I use compton:

compton --backend xr_glx_hybrid --vsync opengl-swc

Compton's "glx" backend crashes Xorg (or hangs... I don't remember 
exactly).
Compton's "drm" vsync method (and probably other fancy options like 
glx-no-stencil and paint-on-overlay) makes the whole system hang often.
But with "xr_glx_hybrid" and "opengl-swc", everything is stable!


Brightness adjustment works via both graphics/intel-backlight
and acpi_video (sysctl hw.acpi.video.lcd0.brightness).
Brightness Fn keys don't work though. The raise brightness (F6) key does 
nothing, the lower brightness (F5) key resets brightness to maximum, and 
shows this in dmesg when drm.debug is on:

[drm:KMS:pid12:intel_panel_get_max_backlight] max backlight PWM = 852
[drm:KMS:pid12:intel_panel_actually_set_backlight] set backlight PWM = 841
[drm:pid12:intel_opregion_gse_intr] PWM freq is not supported


3D performance is fine (well, for a mobile GPU), e.g. this WebGL demo 
https://www.shadertoy.com/view/Ms2SD1 in Firefox is ~40 FPS (in the 
small window, of course, fullscreen is slower).

HDMI output works with a Mini DisplayPort adapter.
1080p video playback on an HDMI TV using `mpv` is smooth.

VAAPI video output and hardware accelerated decoding works.
With mpv --vo=vaapi --hwdec=vaapi, CPU usage is around 20% for a 1080p 
H.264 video (vs. 60% with software decoding), the fans stay silent.

OpenCL doesn't work. clinfo shows that it does nothing instead of 
running the computation:

> Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (3, 7, 5)

Here's my dmesg (and sysctl hw.dri.0.info after GPU hung): 
https://gist.github.com/myfreeweb/262b20777ccfdb8d5168

Also, I couldn't get suspend/resume to work on the X240.
With the UEFI firmware the laptop came with, suspend worked, but it 
didn't resume (didn't react to the power button at all).
After a firmware update, suspending causes a kernel panic.


Thanks for your work, graphics team! I'm glad I don't have to use the 
penguin operating system :-)

~ greg



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151230113340.GA91889>