From owner-freebsd-x11@freebsd.org Thu Aug 2 13:13:37 2018 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 686BD10671DF for ; Thu, 2 Aug 2018 13:13:37 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD04988A41 for ; Thu, 2 Aug 2018 13:13:36 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:subject:to:message-id; s=default; bh=CUW6ad3OZn+8ouacWNVszmEnGh8OhI6PUMNcmKc7UdQ=; b=iKtK0/IG1o7bIKp2jqazcf+k16zs+jcFZWsTV4xqWk+y31LAyKmloPUcbkLLoqH+Apv6djykaArXB1sFionNrj+df5LZprE2uGkAuos7q2Iw5AwH0Ii5CVgqTDrnZ/vM2ZCGFqq6mAe//QxqqpBbdaFsgXjfHdpdkJff06di5jw= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 71561932 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 2 Aug 2018 13:13:25 +0000 (UTC) Date: Thu, 02 Aug 2018 16:13:19 +0300 From: Greg V Subject: Re: X11 not working on 11-STABLE with AMDGPU To: Pete Wright Cc: CL Moonriver , freebsd-x11@freebsd.org, pkubaj@anongoth.pl Message-Id: <1533215599.23824.0@hraggstad.unrelenting.technology> In-Reply-To: <67630578-f418-b435-9bb0-b40f12e9d881@nomadlogic.org> References: <20180801092849.GA75303@KGPE-D16> <95b8cfa0-0908-3321-5155-ef49b1bb0a64@equinedreams.art> <20180801141207.GA5202@smtp.iq.pl> <4266f156-3a83-a45d-fab0-cde090c139ba@equinedreams.art> <67630578-f418-b435-9bb0-b40f12e9d881@nomadlogic.org> X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:13:37 -0000 On Wed, Aug 1, 2018 at 8:54 PM, Pete Wright wrote: > > > On 8/1/18 10:29 AM, CL Moonriver wrote: >> The only thing that actually worked for me was the kms module loaded >> in rc.conf. Any attempt to configure the display in xorg.conf >> resulted in an X server that would not start, but would continue >> running for awhile and appear in the process list before it finally >> gave up. But again, I must have an older AMD GPU because it uses >> the radeonkms driver instead of amdgpu. (It's an AMD A10-7860k with >> Radeon R7 graphics) >> >> On another note, I'm using UEFI boot. Based on my limited >> understanding, I think that means X is actually using the scfb >> driver, which is not ideal from what I understand (no accelerated >> graphics). But it works fine for what I do, and it's the only >> configuration I could get working. >> > > (removing freebsd-stable@ from this thread as this is X specific) > > hrm, booting UEFI should not restrict which Xorg driver is used for > graphics. For example, on my intel i915 systems I boot UEFI and use > the modesetting driver once Xorg launches. The scfb driver does all > rendering in software and does not make use of the GPU at all. > > I'm not super familiar with AMD GPU - do you see any lines in your > Xorg.0.log referring to errors attempting to load the modesetting > driver? that might be a good place to start looking. Hi everyone, Please keep in mind that both radeonkms and amdgpu from drm-*-kmod currently conflict with the EFI framebuffer. https://github.com/FreeBSDDesktop/DEPRECATED-freebsd-base-graphics/issues/170 I currently have hw.syscons.disable=1 in boot/loader.conf to work around that. That knob literally turns the EFI framebuffer off, so in between the boot loader screen and the GPU driver loading, there will be garbage on screen :) if the driver fails to load, you keep the garbage. If you want to debug the driver with this workaround on (read dmesg, try loading, etc.) you have to SSH into the box.