Date: Mon, 18 Jul 2016 21:31:29 +0000 From: Natasha Kerensikova <natbsd@instinctive.eu> To: freebsd-x11@freebsd.org, Juan =?iso-8859-1?Q?Ram=F3n?= Molina Menor <listjm@club-internet.fr> Subject: Re: How to have accelerated graphics with Intel Celeron J1800 (Bay Trail) ? Message-ID: <20160718213129.GR13253@nat.rebma.instinctive.eu> In-Reply-To: <578C8934.2010705@club-internet.fr> References: <578C8934.2010705@club-internet.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, on Monday 18 July 2016 at 09:45, Juan Ramón Molina Menor wrote: > Hi Natasha. Thanks a lot for taking the time to answer. > Matthew Macy has done a lot of work recently to support relatively > recent Intel GPUs in CURRENT. The development branch is in GitHub, I > suggest you to start here: > https://github.com/FreeBSDDesktop/freebsd-base-graphics/wiki I did encounter that page, though I admit digging seriously into it after posting to the ML. However, it looks like rather experimental stuff, which is fine by me but slightly besides my original questions. So just to be clear and be sure I correctly understood everything I came across: - Is vanilla FreeBSD 11.0 supposed/planned to support Haswell, or have I misunderstood something at some point? - Is there any definite information one way or the other about whether vanilla FreeBSD 11.0 is supposed to support Bay Trail ? - If not, was it a stretch to assume Bay Trail support when the both immediate successor (Haswell) and immediate predecessor (Ivy Bridge) are supported? I honestly thought that my 11.0-BETA1 was supposed to handle my Bay Trail, albeit with a beta-level of quality. When that outright didn't work, I tried with the vanilla 11.0-BETA1 kernel and userland the newer ports from http://www.bsddesktop.com/images/xserver-next-pkgs/, with similar results. Then I did try to compile the drm-next-4.6 branch, using wiki instructions, and found a build error beyond my understand a few hours later. > As for your Bay Trail chip, there is an open bug: > https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/6 Only an hour ago did I finish downloading the CFT image labelled 2016062423, and I think I can reproduce the bug. The funny thing is that the corruption I see "heals" over time, so I first I thought it was a fancy effect from the desktop environment (I'm not well acquainted to these fancy UIs). I guess it does dampen the motivation to try and make it work on a more vanilla release, if that's the best that can be achieved with current code... In case it is unexpected for anyone, here the difference in Xorg.0.log between CFT and 11.0-BETA1. The following line are the last common lines: [ 140.072] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: [long list snipped] [ 140.074] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000 [ 140.074] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100 [ 140.074] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300 [ 140.074] (--) Using syscons driver with X support (version 16777218.0) [ 140.074] (--) using VT number 9 following that, 11.0-BETA1 immediately complains that there is no device and no screen and aborts, while the CFT gives: [ 140.078] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20160229 Also, it might or might not be related to the corruption healing, I have (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. (EE) [mi] mieq is *NOT* the cause. It is a victim. [ 164.765] [mi] Increasing EQ size to 1024 to prevent dropped events. [ 164.767] [mi] EQ processing has resumed after 857 dropped events. [ 164.767] [mi] This may be caused by a misbehaving driver monopolizing the server's resources. [ 170.463] (EE) intel(0): Failed to submit rendering commands (Input/output error), disabling acceleration. > Concerning the scfb driver, I’ve used it with success (but only in a > Haswell chip) by just adding the following lines to xorg.conf: > > Section "Device" > Identifier "Generic FB" > Driver "scfb" > # Option "NoAccel" "True" # Both work, test it > EndSection Thanks exactly what I did, but X couldn't start, again complaining about lack of screen. scfb driver itself reported an error "FBIOGTYPE" about an inappropriate ioctl. Unfortunately I lost the exact line when installing the CFT image, I thought it was in the backuped data but I was wrong. I can rebuild the 11.0-BETA1 given some time, if there is interest. Which leads me to the naive question: is there any reason to use scfb when vesa fits my need? The only thing I miss from 10.3-RELEASE vesa is the 2D acceleration (and maybe the video decoding, not sure how the celeron CPU fares), but I thought I read somewhere that scfb isn't really accelerated either. Am I missing something? Thanks a lot for your help, Natasha
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160718213129.GR13253>