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>