From owner-freebsd-x11@FreeBSD.ORG Sun Aug 25 00:22:32 2013 Return-Path: Delivered-To: x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2D5E898F; Sun, 25 Aug 2013 00:22:32 +0000 (UTC) (envelope-from gerald@FreeBSD.org) Received: from ref10-i386.freebsd.org (ref10-i386.freebsd.org [IPv6:2001:1900:2254:206c::16:8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B6C82CA4; Sun, 25 Aug 2013 00:22:32 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.7/8.14.7) with ESMTP id r7P0MVjY016501; Sun, 25 Aug 2013 00:22:31 GMT (envelope-from gerald@ref10-i386.freebsd.org) Received: (from gerald@localhost) by ref10-i386.freebsd.org (8.14.7/8.14.7/Submit) id r7P0MVXo016500; Sun, 25 Aug 2013 00:22:31 GMT (envelope-from gerald) Date: Sun, 25 Aug 2013 00:22:31 GMT Message-Id: <201308250022.r7P0MVXo016500@ref10-i386.freebsd.org> To: FreeBSD-gnats-submit@freebsd.org, x11@FreeBSD.org Subject: xtrans-1.2.7 conflicts with libXtrans-0.1_2 From: Gerald Pfeifer X-send-pr-version: 3.114 X-GNATS-Notify: X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 00:22:32 -0000 >Submitter-Id: current-users >Originator: Gerald Pfeifer >Organization: >Confidential: no >Synopsis: xtrans-1.2.7 conflicts with libXtrans-0.1_2 >Severity: serious >Priority: medium >Category: ports >Class: sw-bug >Environment: >Description: On one of my testers, I was just going to install both x11/xtrans and x11/libXtrans building them from sources (as part of an oooold script), and only pkg advised of a conflict: ===> Registering installation for xtrans-1.2.7 Installing xtrans-1.2.7...pkg-static: xtrans-1.2.7 conflicts with libXtrans-0.1_2 (installs files into the same place). Problematic file: $PREFIX/include/X11/Xtrans/Xtrans.c >How-To-Repeat: >Fix: 1. Add proper CONFLICTS to these two ports. 2. Obsolete one in favor of the other (or avoid the conflict)? From owner-freebsd-x11@FreeBSD.ORG Sun Aug 25 00:50:08 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9C610110; Sun, 25 Aug 2013 00:50:08 +0000 (UTC) (envelope-from edwin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 731A02DA9; Sun, 25 Aug 2013 00:50:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7P0o8RH028207; Sun, 25 Aug 2013 00:50:08 GMT (envelope-from edwin@freefall.freebsd.org) Received: (from edwin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7P0o8vr028206; Sun, 25 Aug 2013 00:50:08 GMT (envelope-from edwin) Date: Sun, 25 Aug 2013 00:50:08 GMT Message-Id: <201308250050.r7P0o8vr028206@freefall.freebsd.org> To: edwin@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org, freebsd-x11@FreeBSD.org From: edwin@FreeBSD.org Subject: Re: ports/181513: graphics/libGL needs python, but lacks explicit dependency X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 00:50:08 -0000 Synopsis: graphics/libGL needs python, but lacks explicit dependency Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: edwin Responsible-Changed-When: Sun Aug 25 00:50:08 UTC 2013 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=181513 From owner-freebsd-x11@FreeBSD.ORG Sun Aug 25 05:05:36 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E82ACD1C; Sun, 25 Aug 2013 05:05:36 +0000 (UTC) (envelope-from edwin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB73A27F2; Sun, 25 Aug 2013 05:05:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7P55ahH077536; Sun, 25 Aug 2013 05:05:36 GMT (envelope-from edwin@freefall.freebsd.org) Received: (from edwin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7P55aXi077535; Sun, 25 Aug 2013 05:05:36 GMT (envelope-from edwin) Date: Sun, 25 Aug 2013 05:05:36 GMT Message-Id: <201308250505.r7P55aXi077535@freefall.freebsd.org> To: edwin@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org, freebsd-x11@FreeBSD.org From: edwin@FreeBSD.org Subject: Re: ports/181512: x11/xtrans: xtrans-1.2.7 conflicts with libXtrans-0.1_2 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 05:05:37 -0000 Synopsis: x11/xtrans: xtrans-1.2.7 conflicts with libXtrans-0.1_2 Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: edwin Responsible-Changed-When: Sun Aug 25 05:05:36 UTC 2013 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=181512 From owner-freebsd-x11@FreeBSD.ORG Mon Aug 26 10:07:51 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 249AF1DE; Mon, 26 Aug 2013 10:07:51 +0000 (UTC) (envelope-from zeising@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ECB1F2016; Mon, 26 Aug 2013 10:07:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7QA7oWv053282; Mon, 26 Aug 2013 10:07:50 GMT (envelope-from zeising@freefall.freebsd.org) Received: (from zeising@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7QA7o68053281; Mon, 26 Aug 2013 10:07:50 GMT (envelope-from zeising) Date: Mon, 26 Aug 2013 10:07:50 GMT Message-Id: <201308261007.r7QA7o68053281@freefall.freebsd.org> To: gerald@pfeifer.com, zeising@FreeBSD.org, freebsd-x11@FreeBSD.org From: zeising@FreeBSD.org Subject: Re: ports/181512: x11/xtrans: xtrans-1.2.7 conflicts with libXtrans-0.1_2 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 10:07:51 -0000 Synopsis: x11/xtrans: xtrans-1.2.7 conflicts with libXtrans-0.1_2 State-Changed-From-To: open->closed State-Changed-By: zeising State-Changed-When: Mon Aug 26 10:07:50 UTC 2013 State-Changed-Why: Fixed by adding CONFLICTS and marking x11/libXtrans as DEPRECATED. Thank you for noticing! http://www.freebsd.org/cgi/query-pr.cgi?pr=181512 From owner-freebsd-x11@FreeBSD.ORG Mon Aug 26 10:10:01 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5485024B for ; Mon, 26 Aug 2013 10:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40D672061 for ; Mon, 26 Aug 2013 10:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7QAA15P053416 for ; Mon, 26 Aug 2013 10:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7QAA0XE053415; Mon, 26 Aug 2013 10:10:01 GMT (envelope-from gnats) Date: Mon, 26 Aug 2013 10:10:01 GMT Message-Id: <201308261010.r7QAA0XE053415@freefall.freebsd.org> To: freebsd-x11@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: ports/181512: commit references a PR X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 10:10:01 -0000 The following reply was made to PR ports/181512; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: ports/181512: commit references a PR Date: Mon, 26 Aug 2013 10:07:09 +0000 (UTC) Author: zeising Date: Mon Aug 26 10:07:01 2013 New Revision: 325381 URL: http://svnweb.freebsd.org/changeset/ports/325381 Log: Add conflicts between x11/libXtrans and x11/xtrans, they install the same files. [1] Mark x11/libXtrans as DEPRECATED, since it is obsolteted upstream, and set removal date one month from now. Nothing in ports uses x11/libXtrans anyway. PR: ports/181512 [1] Submitted by: Gerald Pfeifer [1] Modified: head/x11/libXtrans/Makefile head/x11/xtrans/Makefile Modified: head/x11/libXtrans/Makefile ============================================================================== --- head/x11/libXtrans/Makefile Mon Aug 26 09:47:12 2013 (r325380) +++ head/x11/libXtrans/Makefile Mon Aug 26 10:07:01 2013 (r325381) @@ -10,6 +10,11 @@ MASTER_SITES= http://xlibs.freedesktop.o MAINTAINER= x11@FreeBSD.org COMMENT= Network API translation layer for X applications and libraries +CONFLICTS= xtrans + +DEPRECATED= Project is obsoleted, use x11/xtrans instead +EXPIRATION_DATE=2013-09-26 + USE_BZIP2= yes GNU_CONFIGURE= yes USE_GMAKE= yes Modified: head/x11/xtrans/Makefile ============================================================================== --- head/x11/xtrans/Makefile Mon Aug 26 09:47:12 2013 (r325380) +++ head/x11/xtrans/Makefile Mon Aug 26 10:07:01 2013 (r325381) @@ -8,6 +8,8 @@ CATEGORIES= x11 MAINTAINER= x11@FreeBSD.org COMMENT= Abstract network code for X +CONFLICTS= libXtrans + LICENSE= MIT XORG_CAT= lib _______________________________________________ svn-ports-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-ports-all To unsubscribe, send any mail to "svn-ports-all-unsubscribe@freebsd.org" From owner-freebsd-x11@FreeBSD.ORG Mon Aug 26 11:06:55 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6A47B1C5 for ; Mon, 26 Aug 2013 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D95B2879 for ; Mon, 26 Aug 2013 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7QB6t9Y066147 for ; Mon, 26 Aug 2013 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7QB6sHP066145 for freebsd-x11@FreeBSD.org; Mon, 26 Aug 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Aug 2013 11:06:54 GMT Message-Id: <201308261106.r7QB6sHP066145@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-x11@FreeBSD.org Subject: Current problem reports assigned to freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/181513 x11 graphics/libGL needs python, but lacks explicit depend o ports/181318 x11 x11-servers/xorg-server does not compile or ARM o ports/181202 x11 x11-servers/xorg: xorg-7.x meta package missing o ports/181140 x11 [patch]x11/pixman fix typo & build issue on arm o ports/180096 x11 [patch] x11/xorg-libraries: add missing dependency o ports/180023 x11 x11-servers/xorg: xorg (WITH_NEW_XORG) on 10-CURRENT i o ports/178670 x11 x11/xorg: X does not refresh upper 1/4 screen in some a ports/178170 x11 [patch] x11-servers/xorg-server: xkb misbehaviour on k o ports/176705 x11 graphics/libGL : Fix complitation (not useability) on o ports/176703 x11 graphics/dri : Fix complitation (not useability) on AR o ports/175532 x11 x11/xdm: /bin/cp -n /usr/local/share/examples/xdm/Give o ports/171422 x11 graphics/libGL build error with python3.2 o ports/170852 x11 [PATCH] x11-fonts/encodings: encodings.dir includes bo o ports/170690 x11 x11-servers/xorg-server eats memory o ports/169794 x11 x11/xdm, several /usr/local/lib/X11/xdm/ files missing o ports/169561 x11 [patch] x11-toolkits/libXmu: disable specs o ports/169560 x11 [patch] x11/libICE: disable specs o ports/169559 x11 [patch] x11-fonts/fontsproto: disable specs o ports/166163 x11 graphics/dri: gthumb port crashes (SIGSEGV) within the o ports/160963 x11 [patch] x11/bigreqsproto: disable specs a ports/159792 x11 [patch] USB HID devices support for x11-drivers/xf86-i f ports/158513 x11 Broken Xvideo in x11-drivers/xf86-video-intel drivers s ports/156405 x11 x11-drivers/xf86-video-ati driver: no hardware renderi o ports/155696 x11 [patch] x11-servers/xorg-server: chase AIGLX altered d o ports/154502 x11 x11/xdm authorization failure when used with E17 windo o ports/149743 x11 x11/xorg: garbled window since Xorg-7.5 o ports/148591 x11 information note for x11-drivers/xf86-input-synaptics 27 problems total. From owner-freebsd-x11@FreeBSD.ORG Tue Aug 27 12:36:29 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E630BB92 for ; Tue, 27 Aug 2013 12:36:28 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA8D02414 for ; Tue, 27 Aug 2013 12:36:28 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VEIVV-0005f6-JS for freebsd-x11@freebsd.org; Tue, 27 Aug 2013 14:36:26 +0200 Message-ID: <521C9D2A.4070001@FreeBSD.org> Date: Tue, 27 Aug 2013 14:35:54 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130813 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-x11@freebsd.org Subject: AMD Radeon KMS driver committed to 10-CURRENT X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2BCGEKOMEKCSEWRSXNTMU" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 12:36:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2BCGEKOMEKCSEWRSXNTMU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, The AMD Radeon KMS driver is now in HEAD, as of r254885. It's available for amd64 and i386. The code is based on Linux 3.8. Supported hardware should be up-to and including Radeon HD 7xxx (Southern Islands series). The driver comes with : o "radeonkms", the main kernel module o a boat load of binary-only firmwares, installed as kernel modules prefixed with "radeonkmsfw_" To use it, you'll need ports that are not yet in the ports tree. You can find instructions on how to get them on the wiki: https://wiki.freebsd.org/AMD_GPU#How_to_test Here are the major known issues of the driver: 1. Like with i915kms, the console is unusable once the kernel module is loaded (blank screen). This prevents a user from using Ctrl-Alt-Fx from an X session, and ending its session will let the computer in an unusable state. The module can be unloaded but it won't restore the console. However, the computer can be used remotely. This problem is being worked on. And remember that you don't need to load the kernel module at boot time or manually: it'll be done automatically during X startup. 2. Suspend/resume was not tested so far. 3. Features such as GPGPU (using the GPU for general computations), power management (reclocking) or hardware-assisted video decoding are not supported. They depend on a newer kernel module (corresponding to up to Linux 3.11) and new APIs required by Mesa. 4. Configurations combining a lower-end integrated GPU and a discrete card or, more generally, several cards sharing a common set of output ports are not directly supported. You must rely on your BIOS to provide a way to select the graphic card. If the driver and the new ports are working for you or if you have problems with them, please report on the freebsd-x11@FreeBSD.org mailing list, as explained on the wiki: https://wiki.freebsd.org/AMD_GPU#Reporting Regarding patches for and/or a merge in FreeBSD 9, this is not a priority at the moment. It's non trivial due to important changes to the VM and atomic operations in FreeBSD 10. So please don't ask for patches and be patient: we already know it would be useful. Big Thanks go to: o Konstantin Belousov (kib@) and Alexander Kabaev (kan@) for their invaluable help, without which the driver wouldn't be in the tree now. o all early testers I mentionned in the commit messages, who made the driver stabilize by providing patches or bug reports. o Koop Mast (kwm@) and Niclas Zeising (zeising@) for their work on preparing newer xf86-video-ati and Mesa ports and their useful suggestions. o Alexander Rybalko (ray@) for his help on making radeonkms ready for the future newcons driver. --=20 Jean-S=E9bastien P=E9dron ------enig2BCGEKOMEKCSEWRSXNTMU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIcnUkACgkQa+xGJsFYOlNgVACgmrmPTi4CZMGfgFV2PBhKW/rC 7moAnRxvl0B/SgI/Mx2Mi03xmgkOAEKn =91zm -----END PGP SIGNATURE----- ------enig2BCGEKOMEKCSEWRSXNTMU-- From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 04:20:02 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 492A28A6 for ; Wed, 28 Aug 2013 04:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A8C227F9 for ; Wed, 28 Aug 2013 04:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7S4K1La083766 for ; Wed, 28 Aug 2013 04:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7S4K1OM083764; Wed, 28 Aug 2013 04:20:01 GMT (envelope-from gnats) Date: Wed, 28 Aug 2013 04:20:01 GMT Message-Id: <201308280420.r7S4K1OM083764@freefall.freebsd.org> To: freebsd-x11@FreeBSD.org Cc: From: Matthew Rezny Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthew Rezny List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 04:20:02 -0000 The following reply was made to PR ports/156405; it has been noted by GNATS. From: Matthew Rezny To: bug-followup@FreeBSD.org Cc: Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Date: Wed, 28 Aug 2013 05:56:45 +0200 This is a very puzzling problem that really irks me. I had perfectly working R600 DRI on very similar hardware (HD4870) as well as a laptop with similar video (HD4200), but some Xorg update at least a year ago killed it. Why the regression without any apparent attempt to fix? The last it worked properly was the point in time when setting WITHOUT_NOVEAU allowed r600_dri.so to be compiled. All worked perfect and the newer Xorg brings no new features from a user point of view, only new problems. I could almost understand if there was some actual problem with the R600 DRI, but there isn't. Starting X results in the software rasterizer, which makes KDE painfully slow . However, running certain apps I get hardware rendering. i.e. OpenArena loads r600_dri.so instead of swrast and the framerate in timedemo clearly slows hardware rendering is in fact working. Why can a game get hardware rendering but the rest of X can't? Considering how far off KMS support is, I would hope this issue would have been addressed by now. From my viewpoint, it looks like some stupid and likely trivial bug that causes Xorg to load swrast instead of r600_dri, but I haven't the time nor patience to dig through the mess that is Xorg to attempt to figure it out. Considering the recent suggestion of flipping the WITH_NEW_XORG switch, which itself is very ambiguous, I must re-iterate a previous suggestion: Instead of having a single set of ports for Xorg, PLEASE make some versioned ports for the older versions. This would allow the "legacy" hardware (as in what I think most of us are actually using) to continue to function in a useful fashion. Considering the precedent of version-named ports (e.g. postgresql, mysql, bdb, etc), I cannot fathom why this is not done for Xorg/DRI/Mesa. From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 07:24:24 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BEDA4216 for ; Wed, 28 Aug 2013 07:24:24 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C95F20C4 for ; Wed, 28 Aug 2013 07:24:24 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so6367614obc.34 for ; Wed, 28 Aug 2013 00:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xU4VIVp/SMCT1EBXFfhlpKxDXQxdTV0sK4iJfFdjE5U=; b=ZUvUk2wSAfT8bPIwX5uVIh7njHyBX21r/MORgrfatcoWHWwaGYlgc61ME6ul3h9ijo WAkDYWjbR+4TiPgijVVpejoTbAHTOU8br35vKwI0YBxOHH4t0LA/FIAPm3LM7Qwy3Cug 14JEFFuXLgBf/UOG5nuEXYokXqaI4FITZrBrFFFL+YQ4QveXAmoI/l9dkFjFmvcpyIkM ROEIDzC/swiDeNrJ5yeHKx7+n3NZhMcHaHIUpHZ7Nwxk8FY1/N6cMieSU/L9O/n27Kxy QDYBoNyxNd8LBHtOBbH4dx5HcyiESl21VhJpbSypgE/qD0S8s66PHjMrHVGDpbFohuBI a4rw== MIME-Version: 1.0 X-Received: by 10.60.60.105 with SMTP id g9mr22183643oer.8.1377674662916; Wed, 28 Aug 2013 00:24:22 -0700 (PDT) Received: by 10.182.18.200 with HTTP; Wed, 28 Aug 2013 00:24:22 -0700 (PDT) Date: Wed, 28 Aug 2013 09:24:22 +0200 Message-ID: Subject: Re: Strange scroll when pressing the right button using synaptics driver From: =?ISO-8859-1?Q?Jan_Kokem=FCller?= To: freebsd-x11@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 07:24:24 -0000 > When I press the right button (which is a segregate button) the pad > also scrolls down. If I disable the synaptics driver, the right button > doesn't trigger any scroll at all. I had the same issue. There is a kernel patch available here that works for me (the one at the bottom): http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84411 Good luck, Jan From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 08:40:02 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1E5E67F5 for ; Wed, 28 Aug 2013 08:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E690925FF for ; Wed, 28 Aug 2013 08:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7S8e1HZ047456 for ; Wed, 28 Aug 2013 08:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7S8e1O5047455; Wed, 28 Aug 2013 08:40:01 GMT (envelope-from gnats) Date: Wed, 28 Aug 2013 08:40:01 GMT Message-Id: <201308280840.r7S8e1O5047455@freefall.freebsd.org> To: freebsd-x11@FreeBSD.org Cc: From: Koop Mast Subject: Re: ports/181513: graphics/libGL needs python, but lacks explicit dependency X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Koop Mast List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 08:40:02 -0000 The following reply was made to PR ports/181513; it has been noted by GNATS. From: Koop Mast To: bug-followup@FreeBSD.org, gerald@FreeBSD.org Cc: Subject: Re: ports/181513: graphics/libGL needs python, but lacks explicit dependency Date: Wed, 28 Aug 2013 10:37:58 +0200 I think this failure should already be fixed but this commit of mva. Can you check if it is there? http://svnweb.freebsd.org/ports?view=revision&revision=324875 And if this commit is there which python ports have you installed? From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 11:42:05 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B890FDBC for ; Wed, 28 Aug 2013 11:42:05 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DE972078 for ; Wed, 28 Aug 2013 11:42:02 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 475B740003 for ; Wed, 28 Aug 2013 13:41:59 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 3CE4640004; Wed, 28 Aug 2013 13:41:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 86AE240003; Wed, 28 Aug 2013 13:41:57 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQ4mj263Wz8hVm; Wed, 28 Aug 2013 13:41:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id MUCbCg-zWb1O; Wed, 28 Aug 2013 13:41:47 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQ4mQ6NS8z8hVn; Wed, 28 Aug 2013 13:41:42 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cQ4mQ5pdKz9Ctj; Wed, 28 Aug 2013 13:41:42 +0200 (CEST) Message-ID: <521DE1F6.1030305@freebsd.org> Date: Wed, 28 Aug 2013 13:41:42 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Matthew Rezny Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> In-Reply-To: <201308280420.r7S4K1OM083764@freefall.freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:42:05 -0000 On 08/28/13 06:20, Matthew Rezny wrote: > The following reply was made to PR ports/156405; it has been noted by GNATS. > > From: Matthew Rezny > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware > rendering > Date: Wed, 28 Aug 2013 05:56:45 +0200 > > This is a very puzzling problem that really irks me. > > I had perfectly working R600 DRI on very similar hardware (HD4870) > as well as a laptop with similar video (HD4200), but some Xorg > update at least a year ago killed it. Why the regression without any > apparent attempt to fix? The last it worked properly was the point in > time when setting WITHOUT_NOVEAU allowed r600_dri.so to be compiled. > All worked perfect and the newer Xorg brings no new features from a > user point of view, only new problems. Our old xorg is blocking other ports from updating, so while it might not directly bring new features from your point of view, it is blocking new features in other areas. What versions of relevant software are you using? Do you have a xorg.log file to show us, so that we can see what's going on. > > I could almost understand if there was some actual problem with the > R600 DRI, but there isn't. Starting X results in the software > rasterizer, which makes KDE painfully slow . However, running certain > apps I get hardware rendering. i.e. OpenArena loads r600_dri.so instead > of swrast and the framerate in timedemo clearly slows hardware > rendering is in fact working. Why can a game get hardware rendering but > the rest of X can't? Once again, what version of libGL and libdri and drm ports are you using? Are your ports tree up to date? Are you using WITH_NEW_XORG or not? > > Considering how far off KMS support is, I would hope this issue would > have been addressed by now. From my viewpoint, it looks like some > stupid and likely trivial bug that causes Xorg to load swrast instead > of r600_dri, but I haven't the time nor patience to dig through the > mess that is Xorg to attempt to figure it out. Considering KMS for Ati/Radeon cards already hit the tree, I think it is safe to say we have been busy elsewhere. > > Considering the recent suggestion of flipping the WITH_NEW_XORG switch, > which itself is very ambiguous, I must re-iterate a previous > suggestion: Instead of having a single set of ports for Xorg, PLEASE > make some versioned ports for the older versions. This would allow the > "legacy" hardware (as in what I think most of us are actually using) to > continue to function in a useful fashion. Considering the precedent of > version-named ports (e.g. postgresql, mysql, bdb, etc), I cannot fathom > why this is not done for Xorg/DRI/Mesa. What is the problem with the name of the switch? It is fairly clear what it does in my opinion. The problem with versioned ports, apart from the fact that it probably would increase our workload even more, is that it is very hard to get a port to depend on different versions, with different shared libraries, functions, etc. etc. You also have to remember that xorg and mesa is a package, and mixing up versions in general won't work. And lastly, even if we would have versioned ports, binary packages still would have to depend on the default version (same for perl, databases and so on), so it wouldn't gain you very much anyway, since you would need to compile stuff from soruce to get a nondefault version. Then you might as well just select version in /etc/make.conf and then compile xorg to begin with. Regards! -- Niclas Zeising From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 15:15:36 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3EBBF88; Wed, 28 Aug 2013 15:15:35 +0000 (UTC) (envelope-from mrezny@hexaneinc.com) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD9E201C; Wed, 28 Aug 2013 15:15:34 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 02B5F47A619; Wed, 28 Aug 2013 17:15:32 +0200 (CEST) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id EE7AF41C099; Wed, 28 Aug 2013 17:15:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id BvZM13r4sZwX; Wed, 28 Aug 2013 17:15:13 +0200 (CEST) X-Originating-IP: 89.24.0.234 Received: from unknown (234-0.gprs.tmcz.cz [89.24.0.234]) (Authenticated sender: mrezny@hexaneinc.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id EEA6141C07F; Wed, 28 Aug 2013 17:15:12 +0200 (CEST) Date: Wed, 28 Aug 2013 17:15:20 +0200 From: Matthew Rezny To: Niclas Zeising Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130828171520.00004b3e@unknown> In-Reply-To: <521DE1F6.1030305@freebsd.org> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> X-Mailer: Claws Mail 3.9.0cvs98 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:15:36 -0000 On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising wrote: > On 08/28/13 06:20, Matthew Rezny wrote: > > The following reply was made to PR ports/156405; it has been noted > > by GNATS. > > > > From: Matthew Rezny > > To: bug-followup@FreeBSD.org > > Cc: > > Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no > > hardware rendering > > Date: Wed, 28 Aug 2013 05:56:45 +0200 > > > > This is a very puzzling problem that really irks me. > > > > I had perfectly working R600 DRI on very similar hardware (HD4870) > > as well as a laptop with similar video (HD4200), but some Xorg > > update at least a year ago killed it. Why the regression without > > any apparent attempt to fix? The last it worked properly was the > > point in time when setting WITHOUT_NOVEAU allowed r600_dri.so to be > > compiled. All worked perfect and the newer Xorg brings no new > > features from a user point of view, only new problems. > > Our old xorg is blocking other ports from updating, so while it might > not directly bring new features from your point of view, it is > blocking new features in other areas. > What I meant was no user noticeable features in Xorg stack itself. I understand some other software running on Xorg might like a newer version, but from a user perspective the older versions of that software with working hardware rendering are more usable and useful than newer versions stuck on software rendering. Any new features are nothing more than theoretical if there is no practical way of running them. > What versions of relevant software are you using? Do you have a > xorg.log file to show us, so that we can see what's going on. > Unfortunately, not at the moment. Relevant versions of Xorg/Mesa stuff is too tangled a mess to possibly remember off the top of my head. I can't provide an Xorg.log until I replace some hardware. The desktop 890FX/PhenomII/HD4870 is having instability problems due to VRM cooling issues on the motherboard. While diagnosing the problem, I pulled all the hard drives except one which has Windows7, primarily to prevent creeping data corruption on the FreeBSD drives. When I get the motherboard replaced, then I can follow up on this properly. The TurionII/HD4200 laptop is running Windows7 as I gave up on using FreeBSD on it months ago. When it had working R600 DRI then it was quite usable under FreeBSD with the only caveat being the lack of GPU power control meant battery life was a little short. Without functional hardware rendering, not only was it frustratingly slow, but the increased CPU load impacted battery life to the point it was unacceptably short lived away from a power outlet. > > > I could almost understand if there was some actual problem with the > > R600 DRI, but there isn't. Starting X results in the software > > rasterizer, which makes KDE painfully slow . However, running > > certain apps I get hardware rendering. i.e. OpenArena loads > > r600_dri.so instead of swrast and the framerate in timedemo clearly > > slows hardware rendering is in fact working. Why can a game get > > hardware rendering but the rest of X can't? > > Once again, what version of libGL and libdri and drm ports are you > using? Are your ports tree up to date? Are you using WITH_NEW_XORG > or not? > See above about version numbers. Port tree was up to date on the desktop. I've been running 9-STABLE with ports updated monthly. I was not using the WITH_NEW_XORG recently as my understanding was that should only be turned on (at that point in time) for Intel KMS testers (not sure if can really call any of them users given the current state). > > > Considering how far off KMS support is, I would hope this issue > > would have been addressed by now. From my viewpoint, it looks like > > some stupid and likely trivial bug that causes Xorg to load swrast > > instead of r600_dri, but I haven't the time nor patience to dig > > through the mess that is Xorg to attempt to figure it out. > > Considering KMS for Ati/Radeon cards already hit the tree, I think it > is safe to say we have been busy elsewhere. > I recognize it is in the tree. In fact, its landing in the tree is what provoked me to respond to this PR at the this time. However, I just saw a statement somewhere on wiki or ML that it would not be ready for real use for another 1-2 years. From the announcement of it coming into -CURRENT, I get the impression it is really not usable beyond testing. Lacking a working console after Xorg loads is a total show stopper in my opinion (and why I can't call the Intel KMS stuff anything more than testing a year after it went in tree). Sure the serial console works, but that is only practical for testing, not daily use as a desktop. Forget use on a laptop as I haven't seen a serial port on one of those in a LONG time, not to mention the impractically of carrying some other device to be the console for my laptop, already a device that is massively inferior to a desktop in every way other than portability. I do not intend to come across as unappreciative of the KMS work, but I'm being realistic. I understand the motives for choosing the ordering for KMS development. First came Intel due to the large number of laptops with integrated Intel graphics that didn't even have UMS support. Next comes ATI/AMD that needs to migrate from UMS to KMS for support of newer hardware. Last shall be Nvidia since there is a vendor supported binary driver that is sufficiently usable for most with that hardware. Anything else but the current "Big 3" will be left to rot since Xorg/Mesa are dropping/have dropped UMS support entirely without regard to the vast amount of hardware that is still in use and working perfectly well on older versions of the stack. The overall approach makes logical sense, but the problem is this gap in which UMS support is rapidly decaying before KMS support has graduated from it's testing status. Prior to the KMS mess, Radeon r100-r700 was the best supported GPU hardware under FreeBSD using open drivers and I'm surely not alone in having used that to guide hardware buying decisions over the last several years. The UMS support needs to be maintained in a better state until KMS is truly ready to supercede it, meaning not only have OpenGL actually work beyond trivial demos, but more importantly a console that works at all times. Even once we have newcons running atop DRM drivers, I still see immense value in having a method to switch back to text mode with the traditional console. Being able to reliably see a panic and get into the debugger without relying on serial ports pretty much requires a text mode fallback. That combined with how far in the distance newcons is means it should be a priority to devise a solution to get back to text mode now. > > > Considering the recent suggestion of flipping the WITH_NEW_XORG > > switch, which itself is very ambiguous, I must re-iterate a previous > > suggestion: Instead of having a single set of ports for Xorg, > > PLEASE make some versioned ports for the older versions. This would > > allow the "legacy" hardware (as in what I think most of us are > > actually using) to continue to function in a useful fashion. > > Considering the precedent of version-named ports (e.g. postgresql, > > mysql, bdb, etc), I cannot fathom why this is not done for > > Xorg/DRI/Mesa. > > What is the problem with the name of the switch? It is fairly clear > what it does in my opinion. > The problem with the switch is that it is relative. Someone who may have had to flip it on at one point in time will later have to turn it off to retain the same working Xorg version. If they update ports without flipping the switch at the right time, getting back to working can be a nightmare. Further, the single switch only supports two version sets existing at any point in time. In the past, when there was both WITH_NEW_XORG and WITHOUT_NOVEUA switches, there were three possible version combinations controlled by two switches. That is in fact the last time anything worked for me (both set ON). In theory, after WITHOUT_NOVEUA went away, I should have been able to flip WITH_NEW_XORG to OFF and retained the same working configuration, but in reality that was not the case. It did not matter if the switch was ON or OFF, neither version would load the r600_dri.so when starting Xorg. I reported the problem on IRC and was told that was strange and shouldn't happen, but now we have a PR (the one I'm responding to) that says it is essentially expected behavior for the UMS driver that won't be addressed. > The problem with versioned ports, apart from the fact that it probably > would increase our workload even more, is that it is very hard to get > a port to depend on different versions, with different shared > libraries, functions, etc. etc. You also have to remember that xorg > and mesa is a package, and mixing up versions in general won't work. > I know they are a package that need to have versions kept in sync. That is exactly why I advocate versioned ports. Having versioned ports would make it easier to keep those in sync as the ports could depend on the correct version and updating one would trigger others to the updated. Currently, when the switch is flipped, all the right ports need to be rebuilt in just the right order and it doesn't always work. Sometimes it in necessary to unistall them all and then rebuild everything to get Xorg to even start. I have seen numerous others on IRC and the ML facing the same problem. I tried freezing portions of my ports tree and selectively going back in time, and while that worked briefly, it became an unmaintainable mess over time and I gave up on it, resulting in spending progressively more time in Windows on my desktop (even before the hardware problems) just to get anything done. FreeBSD still runs all my server hardware with text consoles quite nicely. > And lastly, even if we would have versioned ports, binary packages > still would have to depend on the default version (same for perl, > databases and so on), so it wouldn't gain you very much anyway, since > you would need to compile stuff from soruce to get a nondefault > version. Then you might as well just select version > in /etc/make.conf and then compile xorg to begin with. > In that case, at least there would be binary packages of each version rather than only for the default version. Binary packages are meaningless to me. I have to build everything from source to get working OPTIONS combination anyway. At least with versions I could be sure I'm building what I think I am/what I know I need. Using versioned ports would not only allow me to retain the known working versions, but would make it more clear what other software has to be frozen at a particular version to continue using it. Without that, it is rather unclear what are the exact repercussions of staying on older Xorg stacks. I see things like the databases and Python/Perl as great examples of what benefits versioned ports bring. People relying on older versions of those ports can do so with confidence while newer versions become available to those that need them. At the same time, those relying on older versions can move forward to new versions in testing environments, rework their software as needed, and eventually migrate to a newer version with confidence. Without versioned ports, updating the ports tree is a game of Russian roulette. When it comes to the Xorg stack, it feels like there is only one chamber without a bullet. It is my opinion that the primary factor holding back the "Linux desktop" (and by extension use of FreeBSD as a desktop OS) is the complexity and mess of Xfree86/Xorg. For more than a decade now, I've periodically tried both for desktop use and always found that the disaster that is X keeps me from being able to use it as such for more than a brief stint here and there. For a long time I used OS X as my desktop and regarded FreeBSD as a server OS, but with what Apple has done in the past few years OS X is as bad if not worse than Windows. As a former OS/2 user that sees Windows 2000 as the peak of Windows usability, and OS X 10.5 as the peak of Mac OS usability, I find myself so desperate for a usable desktop OS that I almost bought an Amiga X1000. Fortunately, MorphOS released 3.2 with PowerMac G5 support just in time to allow me to give that a spin on my old Mac without dropping significant coin on new hardware. Still, I'd like to see the non-Mac "UNIX desktop" eventually reach a state where it can be practically used as an everyday desktop OS. With it being so difficult for a highly technical (programmer) user to do so, it is obviously impossible for any "normal" user to do so. No surprise I see people frustrated with Windows installing one of the "easy" Linux distros, and then after a couple months at most, giving up and either going back to Windows or buying a Mac. I can only hope that Wayland is magically better, but the realist/pessimist portion of me fears that it will be too Linux centric, a nightmare to port, and still have no stable ABI. Lack of stable ABI in Linux is the secondary factor that prevents any real success outside the server space where admins can dedicate their lives to chasing updates and/or backporting bug fixes and required features. At least FreeBSD has a sensible way of versioning the ABI that allows it to be much more sane and really excel in that exact same space since it requires less effort to maintain production systems and can even be a better Linux than Linux in terms of running older Linux binaries on current OS versions. > Regards! Best Regards, Matthew "the desktop OS homeless" (OS/2 desktop user since Warp 3, until IBM abandoned it and the new owner renamed it, prompting a change of desktop OS to NT5 aka Win2k, until SP4 sabotaged the network stack prompting a downgrade to XP which was quickly followed by a migration to Mac OS X, satisfied until Apple killed compatibility and stability with 10.6 and then turned it into "desktop iOS" with 10.7, prompting complete abandonment of yet another platform and finding myself homeless when FreeBSD only fulfilled the role for a few months before the Xorg stack fell apart) From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 17:49:36 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99A1ED6B for ; Wed, 28 Aug 2013 17:49:36 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BAF72B12 for ; Wed, 28 Aug 2013 17:49:36 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VEjs5-000HA1-Qg; Wed, 28 Aug 2013 19:49:34 +0200 Message-ID: <521E3828.9000605@FreeBSD.org> Date: Wed, 28 Aug 2013 19:49:28 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130816 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ke Sun Subject: Re: unsupported synaptics touchpad References: <20130822155651.GA32146@probe.unige.ch> <52171DE6.7030909@FreeBSD.org> <20130823091753.GA21594@probe.unige.ch> <52175C5E.2080007@FreeBSD.org> <20130823150007.GA31164@probe.unige.ch> In-Reply-To: <20130823150007.GA31164@probe.unige.ch> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2UUBXTMOACVWLEJEGWCMB" Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:49:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UUBXTMOACVWLEJEGWCMB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 23.08.2013 17:00, Ke Sun wrote: > please see attached for the dmesgs with debug.psm.loglevel=3D2 in > /boot/loader.conf. I cannot tell much difference. Can you try with debug.psm.loglevel=3D5, then? > # sysctl hw.psm.synaptics_support > sysctl: unknown oid 'hw.psm.synaptics_support': No such file or directo= ry Yes, this one is only available as a tunable, not a sysctl. --=20 Jean-S=E9bastien P=E9dron ------enig2UUBXTMOACVWLEJEGWCMB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIeOC0ACgkQa+xGJsFYOlNZ+wCfS8E7y+AHw3SH0DOCeqUqzuVy iREAnjSpXWL+VGdPBbwp8wYlaXNnMRWN =gjL8 -----END PGP SIGNATURE----- ------enig2UUBXTMOACVWLEJEGWCMB-- From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 17:52:21 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6DF6E02 for ; Wed, 28 Aug 2013 17:52:21 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 996452B62 for ; Wed, 28 Aug 2013 17:52:21 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VEjul-000HDl-Ec; Wed, 28 Aug 2013 19:52:20 +0200 Message-ID: <521E38D3.4090902@FreeBSD.org> Date: Wed, 28 Aug 2013 19:52:19 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130816 Thunderbird/17.0.8 MIME-Version: 1.0 To: Artyom Mirgorodskiy Subject: Re: unsupported synaptics touchpad References: <20130822155651.GA32146@probe.unige.ch> <20130823091753.GA21594@probe.unige.ch> <52175C5E.2080007@FreeBSD.org> <1799072.RViviU3Mu9@notebook.alkar.net> In-Reply-To: <1799072.RViviU3Mu9@notebook.alkar.net> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2OJSAQCSBFFUXLSVBEQJX" Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:52:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OJSAQCSBFFUXLSVBEQJX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 23.08.2013 16:27, Artyom Mirgorodskiy wrote: > I'm sorry, friends, but the current implementation of=20 > SynapticsTouchPad is not compliant with SynapticsTouchPad > InterfacingGuide > http://ccdw.org/~cjj/l/docs/ACF126.pdf Do you have specific examples of such incompatibilities? I know that our in-kernel driver has not been updated for a long time, but I don't have an Synaptics touchpad anymore unfortunately. --=20 Jean-S=E9bastien P=E9dron ------enig2OJSAQCSBFFUXLSVBEQJX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIeONMACgkQa+xGJsFYOlN+9QCgh0P+IZ/OsZC8iukhv9VLVsWR Qg4An38qkGuIDGM/awC0NMpah0w6W80e =/xmL -----END PGP SIGNATURE----- ------enig2OJSAQCSBFFUXLSVBEQJX-- From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 18:17:51 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 690ED673; Wed, 28 Aug 2013 18:17:51 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9BE42CCE; Wed, 28 Aug 2013 18:17:50 +0000 (UTC) Received: by mail-ea0-f172.google.com with SMTP id r16so3146847ead.31 for ; Wed, 28 Aug 2013 11:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=cQ7UPE7yPdJHmcQ4ACvW8wh3DgniM04Tb2XEpJYchaA=; b=shmconD1VBNo7nCPbeHvQSyxDT6iyyeZh1MOiSa8ceu1QtWz8yOZDfNsfwQXkEuVFq yN3nGQ/Ikx1lITkRzK8hov/MpMHQ8QyqDabLzA+mQDq0NwTspQqXPq94YLCKfPOrC4HX KVduQkG2FUFCsQ4ENSo868FgZRr55SbrI3xDq4i0u9ddKxoqlqt15FCs2z19H9deBkQv PuZ1Re//wvLQ03tiOTX/vL5dqxan8kRUzyT5Y+TI9AOZ0APv+g+N4WzJ4CIG9N8FIOnL kjmKMtqvIoEoVRr9naFEVib6DuAyuzckww2JyG61P0IyPkXottd0aFx7kcKrkJtK2+Vu 5OIA== X-Received: by 10.14.53.11 with SMTP id f11mr79301eec.152.1377713868208; Wed, 28 Aug 2013 11:17:48 -0700 (PDT) Received: from notebook.alkar.net ([91.243.193.58]) by mx.google.com with ESMTPSA id f49sm39487996eec.7.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 11:17:47 -0700 (PDT) From: Artyom Mirgorodskiy To: =?ISO-8859-1?Q?Jean=2DS=E9bastien_P=E9dron?= Subject: Re: unsupported synaptics touchpad Date: Wed, 28 Aug 2013 21:17:53 +0300 Message-ID: <9437888.l2O97oTlfp@notebook.alkar.net> User-Agent: KMail/4.11 (FreeBSD/10.0-CURRENT; KDE/4.11.0; amd64; ; ) In-Reply-To: <521E38D3.4090902@FreeBSD.org> References: <20130822155651.GA32146@probe.unige.ch> <1799072.RViviU3Mu9@notebook.alkar.net> <521E38D3.4090902@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:17:51 -0000 Please see block /* XXX Documentation? */ and higher. For example I have is not working properly scrolling and pressing the r= ight button works the same way and scroll, making it impossible to open= the context menu. It's not bug of my touch pad. I read manual and dump= data from my touch pad - everything work according documentation, howe= ver I do not have enough time to make correct code. May be a good idea = to create patch and collect feedback... On Wednesday 28 August 2013 19:52:19 Jean-S=E9bastien P=E9dron wrote: > On 23.08.2013 16:27, Artyom Mirgorodskiy wrote: > > I'm sorry, friends, but the current implementation of=20 > > SynapticsTouchPad is not compliant with SynapticsTouchPad > > InterfacingGuide > > http://ccdw.org/~cjj/l/docs/ACF126.pdf >=20 > Do you have specific examples of such incompatibilities? I know that = our > in-kernel driver has not been updated for a long time, but I don't ha= ve > an Synaptics touchpad anymore unfortunately. >=20 >=20 --=20 Artyom Mirgorodskiy From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 20:26:08 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0FCB4AC for ; Wed, 28 Aug 2013 20:26:07 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 480C6257B for ; Wed, 28 Aug 2013 20:26:07 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7F45140003 for ; Wed, 28 Aug 2013 22:26:03 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 7506940004; Wed, 28 Aug 2013 22:26:03 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 2F09740003; Wed, 28 Aug 2013 22:26:01 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQJNp5l9bz8hVm; Wed, 28 Aug 2013 22:25:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id wxusbw56KltP; Wed, 28 Aug 2013 22:25:25 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQJNj1RVxz8hVt; Wed, 28 Aug 2013 22:25:25 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cQJNj0vCPz9Ctq; Wed, 28 Aug 2013 22:25:25 +0200 (CEST) Message-ID: <521E5CA0.6080206@freebsd.org> Date: Wed, 28 Aug 2013 22:25:04 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Matthew Rezny Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown> In-Reply-To: <20130828171520.00004b3e@unknown> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2EPSWDGHSUMXNHEICCFBM" X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:26:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EPSWDGHSUMXNHEICCFBM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/28/13 17:15, Matthew Rezny wrote: > On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising > wrote: >> On 08/28/13 06:20, Matthew Rezny wrote: >> Our old xorg is blocking other ports from updating, so while it >> might not directly bring new features from your point of view, it >> is blocking new features in other areas. >>=20 > What I meant was no user noticeable features in Xorg stack itself. I=20 > understand some other software running on Xorg might like a newer=20 > version, but from a user perspective the older versions of that=20 > software with working hardware rendering are more usable and useful=20 > than newer versions stuck on software rendering. Any new features > are nothing more than theoretical if there is no practical way of > running them. You are missing the point. Some software needs updated xorg stack, because of lacking features or bugs in our current xorg. If we can't update those packages, we are missing out on features there, and that might in turn stop other updates. Besides that, our current xorg is lacking support upstream, meaning security isses might go undetected, or we need to backport patches, which takes time and effort. >=20 >> What versions of relevant software are you using? Do you have a=20 >> xorg.log file to show us, so that we can see what's going on. >>=20 > Unfortunately, not at the moment. Relevant versions of Xorg/Mesa > stuff is too tangled a mess to possibly remember off the top of my > head. I can't provide an Xorg.log until I replace some hardware. The > desktop 890FX/PhenomII/HD4870 is having instability problems due to > VRM cooling issues on the motherboard. While diagnosing the problem, > I pulled all the hard drives except one which has Windows7, primarily > to prevent creeping data corruption on the FreeBSD drives. When I get > the motherboard replaced, then I can follow up on this properly. The=20 > TurionII/HD4200 laptop is running Windows7 as I gave up on using=20 > FreeBSD on it months ago. When it had working R600 DRI then it was=20 > quite usable under FreeBSD with the only caveat being the lack of > GPU power control meant battery life was a little short. Without > functional hardware rendering, not only was it frustratingly slow, > but the increased CPU load impacted battery life to the point it was=20 > unacceptably short lived away from a power outlet. Without a list of software, logs and other relevant information it is impossible to help you and debug this issue. It is not very hard to get a list of installed ports and packages, a dmesg output and a log from xor= g. As a side note, cooling issues can probably cause all sorts of issues that doesn't seem related at first, so that might be a place to start. >>=20 >>> I could almost understand if there was some actual problem with >>> the R600 DRI, but there isn't. Starting X results in the >>> software rasterizer, which makes KDE painfully slow . However, >>> running certain apps I get hardware rendering. i.e. OpenArena >>> loads r600_dri.so instead of swrast and the framerate in timedemo >>> clearly slows hardware rendering is in fact working. Why can a >>> game get hardware rendering but the rest of X can't? >>=20 >> Once again, what version of libGL and libdri and drm ports are you=20 >> using? Are your ports tree up to date? Are you using >> WITH_NEW_XORG or not? >>=20 > See above about version numbers. Port tree was up to date on the=20 > desktop. I've been running 9-STABLE with ports updated monthly. I > was not using the WITH_NEW_XORG recently as my understanding was that > should only be turned on (at that point in time) for Intel KMS > testers (not sure if can really call any of them users given the > current state). WITH_NEW_XORG=3D is usable for other hardware configurations as well, and= with the addition of the radeon KMS driver, it should work fine even with radeon hardware. It might need some polish in the ports department to get optimal performance, but we are working to get that into the tree in time for 10.0. >>=20 >>> Considering how far off KMS support is, I would hope this issue=20 >>> would have been addressed by now. From my viewpoint, it looks >>> like some stupid and likely trivial bug that causes Xorg to load >>> swrast instead of r600_dri, but I haven't the time nor patience >>> to dig through the mess that is Xorg to attempt to figure it >>> out. >>=20 >> Considering KMS for Ati/Radeon cards already hit the tree, I think >> it is safe to say we have been busy elsewhere. >>=20 > I recognize it is in the tree. In fact, its landing in the tree is > what provoked me to respond to this PR at the this time. However, I > just saw a statement somewhere on wiki or ML that it would not be > ready for real use for another 1-2 years. From the announcement of it > coming into -CURRENT, I get the impression it is really not usable > beyond testing. Lacking a working console after Xorg loads is a total > show stopper in my opinion (and why I can't call the Intel KMS stuff > anything more than testing a year after it went in tree). Sure the > serial console works, but that is only practical for testing, not > daily use as a desktop. Forget use on a laptop as I haven't seen a > serial port on one of those in a LONG time, not to mention the > impractically of carrying some other device to be the console for my > laptop, already a device that is massively inferior to a desktop in > every way other than portability. I doubt it is 1-2 years away, where did you see that mail? Of course there will be some bugs, as always, but it has been in the works for some time, and it has been tested and deemed ready for a release (10.0, which is due in a couple of months). With regards to VT switching, I can understand that it is an issue, but it is something that's actively being worked on, and the plan is to have it resolved before 10.0 as well, so FreeBSD is really making progress in the graphics and desktop department. >=20 > I do not intend to come across as unappreciative of the KMS work, > but I'm being realistic. I understand the motives for choosing the > ordering for KMS development. First came Intel due to the large > number of laptops with integrated Intel graphics that didn't even > have UMS support. Next comes ATI/AMD that needs to migrate from UMS > to KMS for support of newer hardware. Last shall be Nvidia since > there is a vendor supported binary driver that is sufficiently usable > for most with that hardware. Anything else but the current "Big 3" > will be left to rot since Xorg/Mesa are dropping/have dropped UMS > support entirely without regard to the vast amount of hardware that > is still in use and working perfectly well on older versions of the > stack. The overall approach makes logical sense, but the problem is > this gap in which UMS support is rapidly decaying before KMS support > has graduated from it's testing status. Prior to the KMS mess, Radeon > r100-r700 was the best supported GPU hardware under FreeBSD using > open drivers and I'm surely not alone in having used that to guide > hardware buying decisions over the last several years. The UMS > support needs to be maintained in a better state until KMS is truly > ready to supercede it, meaning not only have OpenGL actually work > beyond trivial demos, but more importantly a console that works at > all times. Even once we have newcons running atop DRM drivers, I > still see immense value in having a method to switch back to text=20 > mode with the traditional console. Being able to reliably see a > panic and get into the debugger without relying on serial ports > pretty much requires a text mode fallback. That combined with how far > in the distance newcons is means it should be a priority to devise a > solution to get back to text mode now. The problem is that we are in the hands of upstream development. Linux has had KMS for quite some time, so it is natural that xorg is starting to chop of support for UMS. And we need to get on that train, or get left in the dust. The FreeBSD x11@ team is stretched for resources as is, so we need to focus on what is important. And newcons isn't far in the distance, it is happening. With regards to nVidia, why should we not use the official binary blobs? They work (last time I heard) and are supported upstream. I doubt we'll ever see any KMS driver for nVidia graphics cards as long as we have this support. We are not Linus, giving the finger to all vendors who want to support our operating system, just because they might use a different license than the core OS uses. How far along is the linux KMS work for nVidia hardware? Lastly, last time I checked most drivers compiled fine with the new xorg distribution, and even with xserver 1.14 which is in experimental testing. Unfortunately we (the x11@ team) can't test every conceivable combination of hardware, so there might be some issues. On the other hand, there have been few complains about video hardware and drivers not working, so either noone is using those drivers, or they work ok. >>=20 >>> Considering the recent suggestion of flipping the WITH_NEW_XORG=20 >>> switch, which itself is very ambiguous, I must re-iterate a >>> previous suggestion: Instead of having a single set of ports for >>> Xorg, PLEASE make some versioned ports for the older versions. >>> This would allow the "legacy" hardware (as in what I think most >>> of us are actually using) to continue to function in a useful >>> fashion. Considering the precedent of version-named ports (e.g. >>> postgresql, mysql, bdb, etc), I cannot fathom why this is not >>> done for Xorg/DRI/Mesa. >>=20 >> What is the problem with the name of the switch? It is fairly >> clear what it does in my opinion. >>=20 > The problem with the switch is that it is relative. Someone who may=20 > have had to flip it on at one point in time will later have to turn > it off to retain the same working Xorg version. If they update ports=20 > without flipping the switch at the right time, getting back to > working can be a nightmare. Further, the single switch only supports > two version sets existing at any point in time. In the past, when > there was both WITH_NEW_XORG and WITHOUT_NOVEUA switches, there were > three possible version combinations controlled by two switches. That > is in fact the last time anything worked for me (both set ON). In > theory, after WITHOUT_NOVEUA went away, I should have been able to > flip WITH_NEW_XORG to OFF and retained the same working > configuration, but in reality that was not the case. It did not > matter if the switch was ON or OFF, neither version would load the > r600_dri.so when starting Xorg. I reported the problem on IRC and was > told that was strange and shouldn't happen, but now we have a PR (the > one I'm responding to) that says it is essentially expected behavior > for the UMS driver that won't be addressed. This is why we're slowly working towards getting one unified version of xorg again, but it takes time, both because we need to port software, and because the FreeBSD kernel and core system needs to "catch up" in terms of new hardware support. Currently there are two distributions, the old one, which is xserver 1.7.7, libGL 7.6.1 (if I'm not mistaken) and old versions of the intel driver that doesn't support any modern intel GPUs, and so on. And then there is the new distributions, which needs a modern FreeBSD with support for intel KMS if you have a intel GPU, xserver 1.12, mesa 8.0 and so on. I understand that it can be troublesome moving between versions. We are doing our best to make it work, but sometimes issues occur, especially when moving backwards, since that means ports versions going backwards. The WITHOUT_NOUVEAU option was removed some time ago, since NOUVEAU never really worked well on FreeBSD, as I've come to understand it. >=20 >> The problem with versioned ports, apart from the fact that it >> probably would increase our workload even more, is that it is very >> hard to get a port to depend on different versions, with different >> shared libraries, functions, etc. etc. You also have to remember >> that xorg and mesa is a package, and mixing up versions in general >> won't work. >>=20 > I know they are a package that need to have versions kept in sync. > That is exactly why I advocate versioned ports. Having versioned > ports would make it easier to keep those in sync as the ports could > depend on the correct version and updating one would trigger others > to the updated. Currently, when the switch is flipped, all the right > ports need to be rebuilt in just the right order and it doesn't > always work. Sometimes it in necessary to unistall them all and then > rebuild everything to get Xorg to even start. I have seen numerous > others on IRC and the ML facing the same problem. I tried freezing > portions of my ports tree and selectively going back in time, and > while that worked briefly, it became an unmaintainable mess over time > and I gave up on it, resulting in spending progressively more time in > Windows on my desktop (even before the hardware problems) just to get > anything done. FreeBSD still runs all my server hardware with text > consoles quite nicely. Well then, how do you solve it if you have an application foo, that wants libGL and xorg-server? Which version should it depend on, libGL A.B or libGL X.Y? How do you solve that, especially for a binary package? You can't, not with our current package manager at least. If you install the package foo, you'll get the default versions of libGL and xorg-server, otherwise you'll have to compile yourself anyway. It is exactly the same now. >=20 >> And lastly, even if we would have versioned ports, binary packages=20 >> still would have to depend on the default version (same for perl,=20 >> databases and so on), so it wouldn't gain you very much anyway, >> since you would need to compile stuff from soruce to get a >> nondefault version. Then you might as well just select version in >> /etc/make.conf and then compile xorg to begin with. >>=20 > In that case, at least there would be binary packages of each > version rather than only for the default version. Binary packages > are meaningless to me. I have to build everything from source to get=20 > working OPTIONS combination anyway. At least with versions I could > be sure I'm building what I think I am/what I know I need. Using > versioned ports would not only allow me to retain the known working > versions, but would make it more clear what other software has to be > frozen at a particular version to continue using it. Without that, it > is rather unclear what are the exact repercussions of staying on > older Xorg stacks. I see things like the databases and Python/Perl as > great examples of what benefits versioned ports bring. People relying > on older versions of those ports can do so with confidence while > newer versions become available to those that need them. At the same > time, those relying on older versions can move forward to new > versions in testing environments, rework their software as needed, > and eventually migrate to a newer version with confidence. Without > versioned ports, updating the ports tree is a game of Russian > roulette. When it comes to the Xorg stack, it feels like there is > only one chamber without a bullet. Binary packages are of no interest for you, maybe, but you are forgetting the bigger picture. It has to work as well, and all this has to work for everyone, with different versions of FreeBSD, different hardware, and different requirements. Can you maybe see now why it is actually a quite time-consuming effort to maintain this. Versioned ports would only give us even more to support, with little gain. If you set WITH_NEW_XORG, you get the new xorg distribution, comprising a set of N ports, with specific versions. If you don't set it, you get another set of M ports with specific versions, those sets might overlap, but not everywhere. You can't, however, pick different versions of different ports, they have to work together. And you can't install them side-by-side. While it might be possible to version the ports, I doubt it. This discussion has happened before, and I have still not seen any progress. You still can choose which distribution you want, by setting *one* option= =2E Besides, if we on top of different versions here, start adding different versions of other ports, you can soon follow that the dependency related issues will explode. >=20 > It is my opinion that the primary factor holding back the "Linux=20 > desktop" (and by extension use of FreeBSD as a desktop OS) is the=20 > complexity and mess of Xfree86/Xorg. For more than a decade now, > I've periodically tried both for desktop use and always found that > the disaster that is X keeps me from being able to use it as such for > more than a brief stint here and there. For a long time I used OS X > as my desktop and regarded FreeBSD as a server OS, but with what > Apple has done in the past few years OS X is as bad if not worse than > Windows. As a former OS/2 user that sees Windows 2000 as the peak of > Windows usability, and OS X 10.5 as the peak of Mac OS usability, I > find myself so desperate for a usable desktop OS that I almost bought > an Amiga X1000. Fortunately, MorphOS released 3.2 with PowerMac G5 > support just in time to allow me to give that a spin on my old Mac > without dropping significant coin on new hardware. Still, I'd like to > see the non-Mac "UNIX desktop" eventually reach a state where it can > be practically used as an everyday desktop OS. With it being so > difficult for a highly technical (programmer) user to do so, it is > obviously impossible for any "normal" user to do so. No surprise I > see people frustrated with Windows installing one of the "easy" Linux > distros, and then after a couple months at most, giving up and either > going back to Windows or buying a Mac. I can only hope that Wayland > is magically better, but the realist/pessimist portion of me fears > that it will be too Linux centric, a nightmare to port, and still > have no stable ABI. Lack of stable ABI in Linux is the secondary > factor that prevents any real success outside the server space where > admins can dedicate their lives to chasing updates and/or backporting > bug fixes and required features. At least FreeBSD has a sensible way > of versioning the ABI that allows it to be much more sane and really > excel in that exact same space since it requires less effort to > maintain production systems and can even be a better Linux than Linux > in terms of running older Linux binaries on current OS versions. xfree86/xorg is a complicated beast, that's why we're working on porting it and making it as easy to use as possible. I've been using FreeBSD on my both my laptop and desktop for quite some time, without any major hassles. I even run our testing versions, to start ironing out issues and bugs before the rest of the community sees our requests for further testing. As stated before, we do our best to test this, but the sheer variety of hardware out there makes it impossible to cover all corners. I have friends that use some free operating system or another without any hassle with X, and I sysadmin several Linux boxes with desktop environments in the computer club at the university I attend. Not to mention that the university also uses linux, so saying that the "UNIX desktop" is a no-go is clearly wrong. Remember also that FreeBSD, and the ports collection, including all relevant software for this discussion (except the nVidia drivers) are open source. Feel free to help out, experiment and send patches, that's how we in the x11@ team ended up here. And while it doesn't seem like much, some of us spend in excess of 40hrs/week some weeks, to make all this work. Regards! --=20 Niclas Zeising FreeBSD ports and doc commiter Member of the FreeBSD x11@ team Happy FreeBSD user ------enig2EPSWDGHSUMXNHEICCFBM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBCgAGBQJSHly0AAoJELuNS1e7i1VR6mAP/1SwKlv8Oa4gfaTY1prJkI3R qjGWtN0evJFnpoYsVelOrFKz2cY8gMOnlpcGgCaNzw8CIzi2Nd/X2WJ7CT1Vq6Az eQAyS5hzRdvRK1jBhXXJkU9R86vD4gVxdd66ZTqPfIqnCk3KIHudnyw9sUm0O4Uo QkAS2XcE5vZPa6aOFIw68g2B4qaRRU7KjAjHqxxARnaNllrFTIqPRZl6Pkoo+K0E C9zwiVTClqyWOEHlazRi4N0D0ZB3rGIfEex5m7UVP6PpGloPKl13fnieK6D6xIiq sn4kUe/GDouXsf2e2tMMVllmrgnAKdzSgLvhccqgahZgVVxxk9xDJ4hg4aCwvHtU PzOBUekP3RFXBP0TghdCx6AVdEl9b05074OmzXRSC1K38Q6SPJz/LxrwWNE8C2sY MuyezYbRb4kK7FMDRckgniWULZ8fEkhJZaLi68Mt5Xzi0Owjo75jMGS4HU9boRtr GH28eo65yqZGucya2ZxSnD4v7KcCA4Ec7At03HuVQd2ik7xJqmKLgxgaTHBwfX1V 12L5dPNqnjRZljYa3z5ikQQjjyeb3Y6uVIGkYab302XyLoHcuLnBHHdpfuQro5QB hxWkhFFD/2U7Mw4r9h1Ep14XKsGT6IA9EcdE1x1/ilOzcFPE0MnL3j7sQ/eaiIxq ToP7gu8yrESBq1VCDHa3 =ihxB -----END PGP SIGNATURE----- ------enig2EPSWDGHSUMXNHEICCFBM-- From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 20:26:24 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 083254E3 for ; Wed, 28 Aug 2013 20:26:24 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm11-vm10.access.bullet.mail.bf1.yahoo.com (nm11-vm10.access.bullet.mail.bf1.yahoo.com [216.109.114.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9BEB257F for ; Wed, 28 Aug 2013 20:26:23 +0000 (UTC) Received: from [66.196.81.165] by nm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 20:21:00 -0000 Received: from [98.139.221.51] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 20:21:00 -0000 Received: from [127.0.0.1] by smtp104.sbc.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 20:21:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1377721260; bh=FhTioVOnuDdZaButTJZipcXyHZe4eWl7pQlycxu60qE=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject; b=YI44ouIZd/MwKgNyh79yhqJ9b0wZSxE6utPH3hHjE/X0CSjBCBnvcOMctAqDKYe1228OtYKF0nIjpI+oA/LrhZZH+m4pXBUwJtdja90hKevy0AKp/jS0vEdCU3IvSbKnygBBApxSq0Vblxj0/kzN3A7TO4xXtGJ+ddJ+l2gxVRY= X-Yahoo-Newman-Id: 682705.3346.bm@smtp104.sbc.mail.bf1.yahoo.com Message-ID: <682705.3346.bm@smtp104.sbc.mail.bf1.yahoo.com> Date: Wed, 28 Aug 2013 13:21:00 -0700 (PDT) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: H2w_j4kVM1mDWuLYLqpLZoo1k_79IdRsrkVtY5IRzomNOIs q48H8HFyCNCemgvRrkqQRvg3F.HSWxYJCictjp0C8lnMbwkkJDY_C_p_1tJt CW6euVBLIBy7u_dmhA3r6XgI30A0oVOTQFWaj_2G1qAhUaZxjsFUu2MrtrJe K6aQ42haYMABYWcOhbqU4rzx_Vd_QkMWua6hj1H8Hk5pAXIq7vJigzCe9uq2 BhfqiJ1QVUTwfpQeQF2UVDY2Iz1.Pj4a_U4wiIuO31KuavTVBV2OeAc0sEY4 qFXQm7Oww9VzKfDFfDJmALV4JtDvS10qXGm8RNKJ8yMY3sJSPfGdOtkVivvb ySNmKAMTlI533L95ekyxNJIckP9Y0HMc8W0K.voSw2L1pFfZblzhRQyqWOlY jgUk1iLvT_acuWel2Tj8Aue1_xfd3PAtHbbrXoL3FwWRcc12FriaP6af5k9Q OhMLSHX4jbdn5vczszRDzGQQ8CmME62QBmFdRuQ9UBT8v8sh_tYZNdLJnMKg XRPs.rlWE75i.c_FLY.2bhQqpaBbxXM7wJIKHuMvJa3t7PG.Zs73WzODhTfk U67H8c4tF X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@74.130.200.176 with plain) by smtp104.sbc.mail.bf1.yahoo.com with SMTP; 28 Aug 2013 13:21:00 -0700 PDT From: "Thomas Mueller" To: freebsd-x11@freebsd.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Cc: Matthew Rezny , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:26:24 -0000 > I recognize it is in the tree. In fact, its landing in the tree is what > provoked me to respond to this PR at the this time. However, I just saw > a statement somewhere on wiki or ML that it would not be ready for real > use for another 1-2 years. From the announcement of it coming into > -CURRENT, I get the impression it is really not usable beyond testing. > Lacking a working console after Xorg loads is a total show stopper in > my opinion (and why I can't call the Intel KMS stuff anything more than > testing a year after it went in tree). Sure the serial console works, > but that is only practical for testing, not daily use as a desktop. > Forget use on a laptop as I haven't seen a serial port on one of those > in a LONG time, not to mention the impractically of carrying some > other device to be the console for my laptop, already a device that is > massively inferior to a desktop in every way other than portability. I had this type of problem with NetBSD 5.1_STABLE and 5.99.x even with native X that is part of the base system, as opposed to pkgsrc X. I could return to a text console in the dark and type "shutdown -r now" or even type the command to go back into X, successfully. Can that be done with FreeBSD, new Xorg and KMS, or is the system just crashed? With serial ports becoming obsolete, what can one use for or in place of a serial console? Would it work to have two xorg.conf files, one with Intel driver and the other with vesa? Then could you go back to a working console when using the vesa driver? I've wondered (call it X acrobatics) how to switch between root and nonroot, and between window managers, without going back to text console. I used OS/2 from 1.3 to Warp 4, until the single-digit days of April 2001 when it crashed, then chkdsk ran amok on reboot and trashed the hard-drive data. I was never able to boot OS/2 again, even from floppies. I repartitioned/reformatted the hard disk but was left with Linux and DR-DOS 7.03. Now it seems Linux and FreeBSD, even NetBSD, have far overtaken OS/2, now eComStation, for hardware support and usability. Tom From owner-freebsd-x11@FreeBSD.ORG Wed Aug 28 20:45:10 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D39F78BC for ; Wed, 28 Aug 2013 20:45:10 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71769268C for ; Wed, 28 Aug 2013 20:45:10 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0612D4000B for ; Wed, 28 Aug 2013 22:45:09 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id F01F640004; Wed, 28 Aug 2013 22:45:08 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 50B4040003; Wed, 28 Aug 2013 22:45:08 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQJqR48hTz8hVn; Wed, 28 Aug 2013 22:45:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id cvINrrUXm6_N; Wed, 28 Aug 2013 22:45:03 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQJqM5qJ0z8hVm; Wed, 28 Aug 2013 22:45:03 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cQJqM51wLz9Ctj; Wed, 28 Aug 2013 22:45:03 +0200 (CEST) Message-ID: <521E613C.9090506@freebsd.org> Date: Wed, 28 Aug 2013 22:44:44 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Thomas Mueller Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: <682705.3346.bm@smtp104.sbc.mail.bf1.yahoo.com> In-Reply-To: <682705.3346.bm@smtp104.sbc.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2FIOBXJIBOOJWOVIIBOPH" X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-x11@freebsd.org, Matthew Rezny X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:45:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FIOBXJIBOOJWOVIIBOPH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/28/13 22:21, Thomas Mueller wrote: > I had this type of problem with NetBSD 5.1_STABLE and 5.99.x even with = native X that is part of the base system, as opposed to pkgsrc X. I can't comment on how NetBSD does things, since I haven't used it. >=20 > I could return to a text console in the dark and type "shutdown -r now"= or even type the command to go back into X, successfully. In general, this can work. It did last time I tested, but that was some time ago so things might have changed. >=20 > Can that be done with FreeBSD, new Xorg and KMS, or is the system just = crashed? The system is definitely not crashed once you go out of X, the only thing that isn't working is the text console. >=20 > With serial ports becoming obsolete, what can one use for or in place o= f a serial console? FireWire. I haven't tested myself, but have a look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern= eldebug-dcons.html for instructions on how to use FireWire as a console. >=20 > Would it work to have two xorg.conf files, one with Intel driver and th= e other with vesa? Then could you go back to a working console when usin= g the vesa driver? Once you've loaded the KMS awawre kernel module, there is no way to get the console back short of a reboot of the system. >=20 > I've wondered (call it X acrobatics) how to switch between root and non= root, and between window managers, without going back to text console. You could try some sort of desktop manager, such as gdm or kdm. I've not used them on FreeBSD, but on linux they make it possible to have several users logged into X at once, and switching window manager, and so on. As for root, it is generally considered a bad idea to run X as root. If it's just a root terminal you need, you can always open an xterm (or your favorite terminal emulator) and use su or sudo. Regards! --=20 Niclas Zeising ------enig2FIOBXJIBOOJWOVIIBOPH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBCgAGBQJSHmFPAAoJELuNS1e7i1VRnfIP/3vb546NDxRP5TbgnBPDvRuN R8JFlohR1pWJMosZ9pq05QYcf1fnNHe+NDVVTNuKZlVe9+keJYZ3yA9NZQwgSymy 7Q/v7tGV08Q0YBn2n2N99+yH/5+dASRRCG9zrBcjFxNqwFE0tRrHsG3csh/qNpzf yIKOAgKJdSdwBZ1jTnwhryswqMSNdEBP03p7UtT5yT6OLHGE+uNr57tPzGvOipO3 0Unpj3cPcZ1IQ+1X2bhB/kG4+JdscW6kRRG8BzAcNmNsbzF+3q2/NYPxnIMihair edpc6Xot5fVw3O6OpUUG9Jh1GJSPHEZ5hCB9s+qqPiZLlTNEA5JHUjF54/rsB8S4 J/jxV+6I6KNx9B++/qStrq7LCmxDg6wi/ff9RTuRadkmBVW40YtLSRnnsLGENrlg gvG9+lqfE80oPIvnPnvgMSspF2o332zVeG3E1ciT1Qele4DJS3HP9Xh3vY9gJFC+ GhaoYHxj/3Hcakw/6hu0vRHwGAmOUgo7UAq1dnKjWWvJ840nQkeP5pYzG1LZSyKF eTfIWYfn7XPZSCq4slS+Q+lPUdhiDFuns5LON8rjxLfRHAgrJdyIkt3rK2SEG0ZR 5dY6H/S+TOb/WnkRKk7b/AeO/Kf+xXCvKCj/Y8UcsZDndHYevStFrWAMHtLClOwQ oZwvMMhftpyMfP4i+5r9 =0gz7 -----END PGP SIGNATURE----- ------enig2FIOBXJIBOOJWOVIIBOPH-- From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 00:26:52 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 469DA694; Thu, 29 Aug 2013 00:26:52 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id E957823AB; Thu, 29 Aug 2013 00:26:51 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=DqnUCRD+ c=1 sm=0 a=68NkTaeYMVLl2m++3813FQ==:17 a=i4YerQ4AwY4A:10 a=2nbQus8neRsA:10 a=DvSzqBOGy98A:10 a=pedpZTtsAAAA:8 a=ayC55rCoAAAA:8 a=KGjhK52YXX0A:10 a=alFmtWT1AaIA:10 a=6I5d2MoRAAAA:8 a=9eE5tM5AgMFw13IAlokA:9 a=c6gvhQW5lNsA:10 a=68NkTaeYMVLl2m++3813FQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 74.130.200.176 Received: from [74.130.200.176] ([74.130.200.176:58101] helo=localhost) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id D5/8E-14028-4459E125; Thu, 29 Aug 2013 00:26:45 +0000 Date: Thu, 29 Aug 2013 00:26:44 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-x11@freebsd.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Cc: Matthew Rezny , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 00:26:52 -0000 >From my previous post and Niclas Zeising's response: > > I had this type of problem with NetBSD 5.1_STABLE and 5.99.x even with native X that is part of the base system, as opposed to pkgsrc X. > I can't comment on how NetBSD does things, since I haven't used it. You aren't missing anything, judging from my experience. FreeBSD is decidedly more advanced. > > I could return to a text console in the dark and type "shutdown -r now" or even type the command to go back into X, successfully. > In general, this can work. It did last time I tested, but that was some > time ago so things might have changed. When I tried with new Xorg and KMS in 9-STABLE, my system froze immediately, not just the console. I finally managed to downgrade to the old Xorg after considerable difficulty. I'd like to try again on a new computer, with FreeBSD-current/HEAD (10.0 is in the not-so-distant future?). With 3 TB hard drive and GPT, I have plenty of space and partitions to experiment, and probably less hazardous than the stablest versions of NetBSD. > > With serial ports becoming obsolete, what can one use for or in place of a serial console? > FireWire. I haven't tested myself, but have a look at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html > for instructions on how to use FireWire as a console. This still leaves the question of how to set it up in terms of hardware. I don't think there are any FireWire consoles. Would I plug anything into the motherboard's FireWire port? I just thought of FireWire-to-HDMI cable but haven't looked to see if these exist. > > Would it work to have two xorg.conf files, one with Intel driver and the other with vesa? Then could you go back to a working console when using the vesa driver? > Once you've loaded the KMS awawre kernel module, there is no way to get > the console back short of a reboot of the system. But would starting X with vesa driver load the KMS awawre kernel module? What about "xorg -configure" which I might want to do the first time? > > I've wondered (call it X acrobatics) how to switch between root and nonroot, and between window managers, without going back to text console. > You could try some sort of desktop manager, such as gdm or kdm. I've > not used them on FreeBSD, but on linux they make it possible to have > several users logged into X at once, and switching window manager, and > so on. As for root, it is generally considered a bad idea to run X as > root. If it's just a root terminal you need, you can always open an > xterm (or your favorite terminal emulator) and use su or sudo. > Regards! > -- > Niclas Zeising On Linux (Slackware) I was only able to have one user at a time using xdm. But I remember one menu item in KDE was konsole as root user (konsole is KDE's X terminal). On NetBSD, xdm completely failed to run. But I got some ideas from Gentoo Linux emailing list, haven't tried yet. Tom From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 03:50:51 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 658D1E87; Thu, 29 Aug 2013 03:50:51 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36C332F29; Thu, 29 Aug 2013 03:50:51 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id g10so7130229pdj.40 for ; Wed, 28 Aug 2013 20:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lc/1GXecYk+CZLc/EB2HMU7ZQYEeB/zVLfAgiF1504k=; b=Eh8svbgYh4mWkUln8a5wv2HrRoHpsZb7jmE53jnU+CqHu46+apvUE/N07US7c1QC2d ZvJY2RKB+lAvm78zpezGXSG51nNo61Jr1wrU9dIEjIGT/GYPUPahle5IKq5zoi9fH8KE oX7X/3NdoUWU11gL7lMypRv+VqlSus9RVN7NjL+XMTXk2xGJ/weWdRBi1usvUQvxYW2h HU2vvzU4P0JEIIrXEW4Vr5fHNaYddaaRc0NUaADmNCjJIoEOGJmMpjoE63ggsn+k4o3A 3cwFMZ6oVk7VcnoZmJhe52R5EMCRUkWURLVqdpDAUjdV+lwaCWCETn3GYfvI3uJqmgxN gTNg== MIME-Version: 1.0 X-Received: by 10.66.121.68 with SMTP id li4mr2050530pab.33.1377748250865; Wed, 28 Aug 2013 20:50:50 -0700 (PDT) Received: by 10.68.44.102 with HTTP; Wed, 28 Aug 2013 20:50:50 -0700 (PDT) In-Reply-To: <9437888.l2O97oTlfp@notebook.alkar.net> References: <20130822155651.GA32146@probe.unige.ch> <1799072.RViviU3Mu9@notebook.alkar.net> <521E38D3.4090902@FreeBSD.org> <9437888.l2O97oTlfp@notebook.alkar.net> Date: Wed, 28 Aug 2013 22:50:50 -0500 Message-ID: Subject: Re: unsupported synaptics touchpad From: Brandon Gooch To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-x11@freebsd.org, =?ISO-8859-1?Q?Jean=2DS=E9bastien_P=E9dron?= X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 03:50:51 -0000 On Wed, Aug 28, 2013 at 1:17 PM, Artyom Mirgorodskiy < artyom.mirgorodsky@gmail.com> wrote: > Please see block /* XXX Documentation? */ and higher. > > For example I have is not working properly scrolling and pressing the > right button works the same way and scroll, making it impossible to open > the context menu. It's not bug of my touch pad. I read manual and dump da= ta > from my touch pad - everything work according documentation, however I do > not have enough time to make correct code. May be a good idea to create > patch and collect feedback... > Try this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D170834 Works for me... -Brandon > > On Wednesday 28 August 2013 19:52:19 Jean-S=E9bastien P=E9dron wrote: > > On 23.08.2013 16:27, Artyom Mirgorodskiy wrote: > > > I'm sorry, friends, but the current implementation of > > > SynapticsTouchPad is not compliant with SynapticsTouchPad > > > InterfacingGuide > > > http://ccdw.org/~cjj/l/docs/ACF126.pdf > > > > Do you have specific examples of such incompatibilities? I know that ou= r > > in-kernel driver has not been updated for a long time, but I don't have > > an Synaptics touchpad anymore unfortunately. > > > > > -- > Artyom Mirgorodskiy > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 05:12:07 2013 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5574F3F for ; Thu, 29 Aug 2013 05:12:07 +0000 (UTC) (envelope-from dcarmich@dcarmichael.net) Received: from pfa3.x.rootbsd.net (mail.dcarmichael.net [199.102.76.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DB2322D8 for ; Thu, 29 Aug 2013 05:12:06 +0000 (UTC) Received: from dc-macpro-eth.carmichael.lan (c-71-57-55-191.hsd1.il.comcast.net [71.57.55.191]) (authenticated bits=0) by pfa3.x.rootbsd.net (8.14.7/8.14.5) with ESMTP id r7T4ldWR038810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Aug 2013 00:47:41 -0400 (EDT) (envelope-from dcarmich@dcarmichael.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at pfa3.x.rootbsd.net X-Authentication-Warning: pfa3.x.rootbsd.net: Host c-71-57-55-191.hsd1.il.comcast.net [71.57.55.191] claimed to be dc-macpro-eth.carmichael.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: I have updated xf86-drivers/xf86-video-vmware with a fix for a cursor glitch From: Douglas Carmichael In-Reply-To: <5211F609.9090500@passap.ru> Date: Wed, 28 Aug 2013 23:47:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5211F609.9090500@passap.ru> To: Boris Samorodov X-Mailer: Apple Mail (2.1508) X-Spam-Status: No, score=2.4 required=5.0 tests=HELO_LH_HOME,RDNS_DYNAMIC autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pfa3.x.rootbsd.net Cc: x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 05:12:07 -0000 Boris: It is OK, but I have noticed no action on the PR since 8/19. Since it involves a fix for a serious issue (xdm causing graphical = glitches), could it be committed into the tree as quickly as possible? --Douglas On Aug 19, 2013, at 5:40 AM, Boris Samorodov wrote: > 19.08.2013 02:51, Douglas Carmichael =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> To whom it may concern: >>=20 >> I have recently updated xf86-drivers/xf86-video-vmware with a fix for = a cursor glitch that was from a VMware developer I'm working on the = issue with. >>=20 >> While the PR was properly filed (PR ports/181385), the header seems = to have been truncated. >>=20 >> What would be the best way to make sure this PR is committed = promptly? >=20 > I've changed the Synopsis. Is it OK now? >=20 > --=20 > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 05:31:59 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EA456FC; Thu, 29 Aug 2013 05:31:59 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBC9D238A; Thu, 29 Aug 2013 05:31:59 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id ma3so7133937pbc.7 for ; Wed, 28 Aug 2013 22:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NTHDtV4+W3qvr77qScrH4nBGQCJGr36y733507W42Bo=; b=j7ztBkUi5uyVOOFzZOK28NZGJKQdapmQ6wqtXVimzajvFY7Cep83Ss+OASoI/DutVZ B3w/rF4bMcCC+SaSJN5SZrnew3r+dnJjkm2EAmquFeIhzhi4TG9czaXZ+te+l7Hd8si/ E1qu+b5kzUQwhrxak+1teNboip1BHOPPVyMx1a66jeie+faOdjnywnPcRgZrlvpzsGTo uq26804aNjdtzhTnfpFWxf7lTDxP0SZdL109MZ2tivQDAMQtZroQiT/Jjj1YBJwy9Tp0 i3ImbzEyr1PoqBr5JO6T4hxbQCxNEsZUBK5+Uz2iBrmwagUJ9cHpki/D2yeztFs754rq Hz1A== MIME-Version: 1.0 X-Received: by 10.68.224.161 with SMTP id rd1mr1604950pbc.121.1377754302728; Wed, 28 Aug 2013 22:31:42 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.219.74 with HTTP; Wed, 28 Aug 2013 22:31:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Aug 2013 22:31:42 -0700 X-Google-Sender-Auth: 2XNhazlLrZmXfEKGnH5zhaIFX70 Message-ID: Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering From: Kevin Oberman To: Thomas Mueller Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-x11@freebsd.org" , Matthew Rezny , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 05:32:00 -0000 On Wed, Aug 28, 2013 at 5:26 PM, Thomas Mueller wrote: > > From my previous post and Niclas Zeising's response: > > > > I had this type of problem with NetBSD 5.1_STABLE and 5.99.x even with > native X that is part of the base system, as opposed to pkgsrc X. > > I can't comment on how NetBSD does things, since I haven't used it. > > You aren't missing anything, judging from my experience. FreeBSD is > decidedly more advanced. > > > > I could return to a text console in the dark and type "shutdown -r > now" or even type the command to go back into X, successfully. > > In general, this can work. It did last time I tested, but that was some > > time ago so things might have changed. > > When I tried with new Xorg and KMS in 9-STABLE, my system froze > immediately, not just the console. I finally managed to downgrade to the > old Xorg after considerable difficulty. > > I'd like to try again on a new computer, with FreeBSD-current/HEAD (10.0 > is in the not-so-distant future?). > > With 3 TB hard drive and GPT, I have plenty of space and partitions to > experiment, and probably less hazardous than the stablest versions of > NetBSD. > > > > With serial ports becoming obsolete, what can one use for or in place > of a serial console? > > > FireWire. I haven't tested myself, but have a look at > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html > > for instructions on how to use FireWire as a console. > > This still leaves the question of how to set it up in terms of hardware. > I don't think there are any FireWire consoles. > > Would I plug anything into the motherboard's FireWire port? I just > thought of FireWire-to-HDMI cable but haven't looked to see if these exist. > > > > Would it work to have two xorg.conf files, one with Intel driver and > the other with vesa? Then could you go back to a working console when > using the vesa driver? > > Once you've loaded the KMS awawre kernel module, there is no way to get > > the console back short of a reboot of the system. > > But would starting X with vesa driver load the KMS awawre kernel module? > > What about "xorg -configure" which I might want to do the first time? > > > > I've wondered (call it X acrobatics) how to switch between root and > nonroot, and between window managers, without going back to text console. > > You could try some sort of desktop manager, such as gdm or kdm. I've > > not used them on FreeBSD, but on linux they make it possible to have > > several users logged into X at once, and switching window manager, and > > so on. As for root, it is generally considered a bad idea to run X as > > root. If it's just a root terminal you need, you can always open an > > xterm (or your favorite terminal emulator) and use su or sudo. > > Regards! > > -- > > Niclas Zeising > > On Linux (Slackware) I was only able to have one user at a time using xdm. > > But I remember one menu item in KDE was konsole as root user (konsole is > KDE's X terminal). > > On NetBSD, xdm completely failed to run. > > But I got some ideas from Gentoo Linux emailing list, haven't tried yet. > > One very common mistake people make when attempting to use Intel KMS is to either add the KMS driver to loader.conf or to load it manually after booting. The result will be an immediate system lockup. Actually, I suspect the system is not frozen, but the display is frozen and nothing will accept keyboard or mouse input, so it looks frozen. Starting X will load the driver at the proper time so that X can takeover the display, keyboard, and mouse properly. I might also note that Intel KMS requires: WITH_NEW_XORG, WITH_KMS, and the build of graphics/libdrm with the KMS config option enabled. If I sent this to you in the past, sorry. I have posted this information a few times and it may or may not make a difference for you. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 11:27:14 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6102A9B2 for ; Thu, 29 Aug 2013 11:27:14 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAFD82DDE for ; Thu, 29 Aug 2013 11:27:13 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id EC66F4000C for ; Thu, 29 Aug 2013 13:27:10 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E234E4000E; Thu, 29 Aug 2013 13:27:10 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id BE69F4000C; Thu, 29 Aug 2013 13:27:09 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQhP92P5wz8hVt; Thu, 29 Aug 2013 13:27:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id GjTsbNPS_k4d; Thu, 29 Aug 2013 13:27:06 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQhP65MDjz8hVm; Thu, 29 Aug 2013 13:27:06 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cQhP63YrCz9Ctq; Thu, 29 Aug 2013 13:27:06 +0200 (CEST) Message-ID: <521F3002.4040104@freebsd.org> Date: Thu, 29 Aug 2013 13:26:58 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Thomas Mueller Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130829-0, 2013-08-29), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-x11@freebsd.org, Matthew Rezny X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 11:27:14 -0000 On 2013-08-29 02:26, Thomas Mueller wrote: > From my previous post and Niclas Zeising's response: >>> I could return to a text console in the dark and type "shutdown -r now" or even type the command to go back into X, successfully. >> In general, this can work. It did last time I tested, but that was some >> time ago so things might have changed. > > When I tried with new Xorg and KMS in 9-STABLE, my system froze immediately, not just the console. I finally managed to downgrade to the old Xorg after considerable difficulty. What hardware do you have? Are you sure that the system froze, and not only that the console went black? Did you check any logs (dmesg, xorg log, etc.) How do you load the kernel modules for the intel kms driver? In general, you shouldn't need to load anything at all, X loads the correct kernel module at the correct time during startup. > > I'd like to try again on a new computer, with FreeBSD-current/HEAD (10.0 is in the not-so-distant future?). 10.0 is slated to arrive in a few months. Be aware when trying new hardware, however, that FreeBSD might be lagging somewhat in support, especially when it comes to graphics hardware. > > With 3 TB hard drive and GPT, I have plenty of space and partitions to experiment, and probably less hazardous than the stablest versions of NetBSD. > >>> With serial ports becoming obsolete, what can one use for or in place of a serial console? > >> FireWire. I haven't tested myself, but have a look at >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html >> for instructions on how to use FireWire as a console. > > This still leaves the question of how to set it up in terms of hardware. I don't think there are any FireWire consoles. > > Would I plug anything into the motherboard's FireWire port? I just thought of FireWire-to-HDMI cable but haven't looked to see if these exist. Check the guide. In general you plug the firewire cable from one computer into another computer, and use the first one to debug the second. > >>> Would it work to have two xorg.conf files, one with Intel driver and the other with vesa? Then could you go back to a working console when using the vesa driver? >> Once you've loaded the KMS awawre kernel module, there is no way to get >> the console back short of a reboot of the system. > > But would starting X with vesa driver load the KMS awawre kernel module? No, using vesa driver won't load the KMS module, but once you've loaded the KMS module, you can't get the console back short of a reboot. > > What about "xorg -configure" which I might want to do the first time? In general you don't need very much in terms of a config file any more... It was some time since I set up my own X, so I can't remember how xorg -configure works, you have to try yourself. Regards! -- Niclas From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 14:10:14 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 89443ED8; Thu, 29 Aug 2013 14:10:14 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E906B2A85; Thu, 29 Aug 2013 14:10:13 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id h10so273621eaj.39 for ; Thu, 29 Aug 2013 07:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=9kBwi1CTrxUaf7r5Dn07aZn2zttlscp1i72O5loqig8=; b=f9g3BkGhMQeCmAjA/sDGBLP3rg6dQmbs5Ck53JcsRf5YxfQlZVpNNJVLViDnFHR7vO WL7cG2AHoe57SO0HCbNp4p6Kq5/drQH1pGfsbbb5iX797ycyIB1fTWSHsEDnMeATmLiu zWggUXC4ixmLX+HxVgSy1fBbNFCEAt6qmu9JXrbFW3U7kGQRkSHWIS9McRJKruoO5HQo xAGwZDEI5YhBD9OkGTFWubCDi5MAiJLKSjwPdsuxdxXeeS/fOJeoyMH/h0Brxl/y/VS9 3BWpp8K63ZgZAQQQCXhOZqiydO2n0PNqnXtXcQZor9odSnofdwU+38TZxhsZY0jKQiXv yV8Q== X-Received: by 10.15.101.195 with SMTP id bp43mr3582450eeb.70.1377785411974; Thu, 29 Aug 2013 07:10:11 -0700 (PDT) Received: from notebook.alkar.net ([91.243.193.58]) by mx.google.com with ESMTPSA id n48sm46500793eeg.17.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 07:10:11 -0700 (PDT) From: Artyom Mirgorodskiy To: Brandon Gooch Subject: Re: unsupported synaptics touchpad Date: Thu, 29 Aug 2013 17:10:18 +0300 Message-ID: <1596081.5RRtn7UfRG@notebook.alkar.net> User-Agent: KMail/4.11 (FreeBSD/10.0-CURRENT; KDE/4.11.0; amd64; ; ) In-Reply-To: References: <20130822155651.GA32146@probe.unige.ch> <9437888.l2O97oTlfp@notebook.alkar.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-x11@freebsd.org, =?ISO-8859-1?Q?Jean=2DS=E9bastien_P=E9dron?= X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 14:10:14 -0000 This patch works for me too. Thank you. On Wednesday 28 August 2013 22:50:50 Brandon Gooch wrote: > On Wed, Aug 28, 2013 at 1:17 PM, Artyom Mirgorodskiy < > artyom.mirgorodsky@gmail.com> wrote: >=20 > > Please see block /* XXX Documentation? */ and higher. > > > > For example I have is not working properly scrolling and pressing t= he > > right button works the same way and scroll, making it impossible to= open > > the context menu. It's not bug of my touch pad. I read manual and d= ump data > > from my touch pad - everything work according documentation, howeve= r I do > > not have enough time to make correct code. May be a good idea to cr= eate > > patch and collect feedback... > > >=20 > Try this patch: >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D170834 >=20 > Works for me... >=20 > -Brandon >=20 >=20 > > > > On Wednesday 28 August 2013 19:52:19 Jean-S=E9bastien P=E9dron wrot= e: > > > On 23.08.2013 16:27, Artyom Mirgorodskiy wrote: > > > > I'm sorry, friends, but the current implementation of > > > > SynapticsTouchPad is not compliant with SynapticsTouchPad > > > > InterfacingGuide > > > > http://ccdw.org/~cjj/l/docs/ACF126.pdf > > > > > > Do you have specific examples of such incompatibilities? I know t= hat our > > > in-kernel driver has not been updated for a long time, but I don'= t have > > > an Synaptics touchpad anymore unfortunately. > > > > > > > > -- > > Artyom Mirgorodskiy > > _______________________________________________ > > freebsd-x11@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.o= rg" > > --=20 Artyom Mirgorodskiy From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 14:31:28 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2867CA1C; Thu, 29 Aug 2013 14:31:28 +0000 (UTC) (envelope-from sunk.cs@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7AE2C14; Thu, 29 Aug 2013 14:31:27 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id h10so290692eaj.11 for ; Thu, 29 Aug 2013 07:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FYdq2rv3Afd/z6vqpk0KZnv60tUKoTG95vot0D2Vb5U=; b=gmLm8mgucZt2fDysiX/V8ejShEfOqJXUk4mqhZDb427GXVdRC4e5CDfm27d/teDgDU aYPTKxxxkcYoVk5276t8Dv2poElTeRQOKFE3jkOrRlaXEAIRo8z1KZbN5JejBw5i8Us1 CAgeNlSo4XUjuJOTXCgmydFOnaFaaOoXqorBGFYcjg4eKxQvmBCSnufx/wofmpzsdg2B PmqCRSKMnTyTBRISr50fI5CEIdxONGBk2b6qqHwKn9nE+Q8pWJ4mZcrm8UQq2qxJCyzr Lncf1jhYXifpv6JDKnc0fyhCIFQrK4rxnbS9OpfGGDAmCnmdpTQKWUbrBoRUD86PihHs 1NaA== X-Received: by 10.15.33.132 with SMTP id c4mr4896107eev.2.1377786685576; Thu, 29 Aug 2013 07:31:25 -0700 (PDT) Received: from localhost ([2001:620:600:4400:a6ba:dbff:fef0:3a99]) by mx.google.com with ESMTPSA id a1sm46589034eem.1.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 07:31:24 -0700 (PDT) Date: Thu, 29 Aug 2013 16:31:22 +0200 From: Ke Sun To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: unsupported synaptics touchpad Message-ID: <20130829143122.GA757@probe.unige.ch> References: <20130822155651.GA32146@probe.unige.ch> <52171DE6.7030909@FreeBSD.org> <20130823091753.GA21594@probe.unige.ch> <52175C5E.2080007@FreeBSD.org> <20130823150007.GA31164@probe.unige.ch> <521E3828.9000605@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <521E3828.9000605@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 14:31:28 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Jean, > Can you try with debug.psm.loglevel=5, then? please see the attached files for the kernel msgs, one with the tunable hw.psm.synaptics_support=0, and the other with hw.psm.synaptics_support=1 Best Ke Sun --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="with_synaptics_support.txt" Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #5 r254404: Fri Aug 16 15:17:58 CEST 2013 me@stone:/usr/obj/usr/src/sys/STONE amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz (2394.61-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0xbfebfbff Features2=0x7fbae3bf AMD Features=0x28100800 AMD Features2=0x1 Standard Extended Features=0x281 TSC: P-state invariant, performance statistics real memory = 6442450944 (6144 MB) avail memory = 6078537728 (5796 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard Cuse4BSD v0.1.29 @ /dev/cuse random: initialized ctl: CAM Target Layer loaded acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff irq 16 at device 0.0 on pci1 vgapci1: port 0xf000-0xf03f mem 0xf7400000-0xf77fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci1 agp0: aperture size is 256M, detected 65532k stolen memory pci0: at device 4.0 (no driver attached) xhci0: mem 0xf7a00000-0xf7a0ffff irq 16 at device 20.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xf7a20000-0xf7a203ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 hdac0: mem 0xf7a18000-0xf7a1bfff irq 22 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 ath0: mem 0xf7900000-0xf797ffff irq 17 at device 0.0 on pci3 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 2196.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 pci4: at device 0.0 (no driver attached) re0: port 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 19 at device 0.2 on pci4 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x48800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 50:46:5d:e2:e8:cc ehci1: mem 0xf7a1f000-0xf7a1f3ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7a1e000-0xf7a1e7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahciem0: on ahci0 pci0: at device 31.3 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x321 offMax=0x5df hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20 and 25 on hdaa0 pcm1: at nid 33 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 6 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub0: on usbus2 ugen1.1: at usbus1 uhub1: on usbus1 ugen0.1: <0x8086> at usbus0 uhub2: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-9 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada1: Command Queueing enabled ada1: 22902MB (46905264 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device SMP: AP CPU #1 Launched! cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1197304730 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. uhub2: 8 ports with 8 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus1 ugen2.2: at usbus2 uhub3: on usbus2 ugen1.2: at usbus1 uhub4: on usbus1 Root mount waiting for: usbus2 usbus1 uhub3: 6 ports with 6 removable, self powered uhub4: 6 ports with 6 removable, self powered ugen1.3: at usbus1 Root mount waiting for: usbus1 ugen1.4: at usbus1 Trying to mount root from zfs:stone []... ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called wlan0: Ethernet address: dc:85:de:3e:a5:69 drmn1: on vgapci1 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. drmn1: taking over the fictitious range 0xd0000000-0xe0000000 info: [drm] Initialized i915 1.6.0 20080730 psm0: disable tap and drag gestures psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_SAMPLING_RATE (20) 00fa psm: ENABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 00 14 psm: DISABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 00 14 psm0: disable tap and drag gestures psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_SAMPLING_RATE (20) 00fa psm: ENABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 00 14 psm: cmd 0xff psmintr: fa psmintr: aa psmintr: 00 psm: cmd 0xe6 psmintr: fa psm: cmd 0xf3 psmintr: fa psm: cmd 0x64 psmintr: fa psm: cmd 0xe8 psmintr: fa psm: cmd 0x3 psmintr: fa psm: cmd 0xf4 psmintr: fa psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psmintr: 08 psmintr: 03 psmintr: 02 psmintr: 08 psmintr: 03 psmintr: 02 psmintr: 08 psmintr: 04 psmintr: 02 psmintr: 08 psmintr: 04 psmintr: 02 psmintr: 08 psmintr: 08 psmintr: 02 psmintr: 08 psmintr: 0e psmintr: 01 psmintr: 08 psmintr: 0f psmintr: 01 psmintr: 08 psmintr: 11 psmintr: 00 psmintr: 08 psmintr: 0f psmintr: 00 psmintr: 08 psmintr: 10 psmintr: 00 psmintr: 28 psmintr: 10 psmintr: fe psmintr: 28 psmintr: 0f psmintr: fe psmintr: 28 psmintr: 0e psmintr: fc psmintr: 28 psmintr: 0c psmintr: fb psmintr: 28 psmintr: 0b psmintr: fb psmintr: 28 psmintr: 0a psmintr: fc psmintr: 28 psmintr: 08 psmintr: fb psmintr: 28 psmintr: 06 psmintr: fb psmintr: 28 psmintr: 03 psmintr: fc psmintr: 28 psmintr: 02 psmintr: fc psmintr: 28 psmintr: 01 psmintr: fc psmintr: 28 psmintr: 00 psmintr: fc psmintr: 38 psmintr: ff psmintr: fc psmintr: 38 psmintr: ff psmintr: fd psmintr: 38 psmintr: fe psmintr: fe psmintr: 38 psmintr: fe psmintr: ff psmintr: 38 psmintr: fc psmintr: ff psmintr: 18 psmintr: fc psmintr: 00 psmintr: 18 psmintr: fb psmintr: 01 psmintr: 18 psmintr: fc psmintr: 02 psmintr: 18 psmintr: fc psmintr: 02 psmintr: 18 psmintr: fc psmintr: 02 psmintr: 18 psmintr: fa psmintr: 04 psmintr: 18 psmintr: fa psmintr: 05 psmintr: 18 psmintr: fa psmintr: 07 psmintr: 18 psmintr: f8 psmintr: 09 psmintr: 18 psmintr: f9 psmintr: 09 psmintr: 18 psmintr: fa psmintr: 07 psmintr: 18 psmintr: fc psmintr: 07 psmintr: 18 psmintr: fb psmintr: 07 psmintr: 18 psmintr: fb psmintr: 07 psmintr: 18 psmintr: fc psmintr: 08 psmintr: 18 psmintr: fc psmintr: 08 psmintr: 18 psmintr: fc psmintr: 09 psmintr: 18 psmintr: fc psmintr: 08 psmintr: 18 psmintr: fc psmintr: 08 psmintr: 18 psmintr: fd psmintr: 09 psmintr: 18 psmintr: fd psmintr: 09 psmintr: 18 psmintr: fd psmintr: 09 psmintr: 18 psmintr: fd psmintr: 07 psmintr: 18 psmintr: fe psmintr: 06 psmintr: 18 psmintr: fe psmintr: 05 psmintr: 18 psmintr: fd psmintr: 05 psmintr: 18 psmintr: ff psmintr: 04 psmintr: 18 psmintr: ff psmintr: 04 psmintr: 18 psmintr: ff psmintr: 05 psmintr: 18 psmintr: ff psmintr: 03 psmintr: 18 psmintr: ff psmintr: 03 psmintr: 08 psmintr: 00 psmintr: 03 psmintr: 18 psmintr: ff psmintr: 03 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 18 psmintr: ff psmintr: 02 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 00 psmintr: 01 psmintr: 08 psmintr: 03 psmintr: 02 psmintr: 08 psmintr: 04 psmintr: 04 psmintr: 08 psmintr: 03 psmintr: 03 psmintr: 08 psmintr: 02 psmintr: 04 psmintr: 08 psmintr: 03 psmintr: 03 psmintr: 08 psmintr: 03 psmintr: 03 psmintr: 08 psmintr: 01 psmintr: 02 psmintr: 08 psmintr: 01 psmintr: 01 psmintr: 08 psmintr: 01 psmintr: 01 psmintr: 18 psmintr: ff psmintr: 00 psmintr: 18 psmintr: fe psmintr: 00 psmintr: 18 psmintr: f9 psmintr: 00 psmintr: 18 psmintr: f1 psmintr: 01 psmintr: 18 psmintr: ef psmintr: 01 psmintr: 18 psmintr: ed psmintr: 03 psmintr: 18 psmintr: ed psmintr: 04 psmintr: 18 psmintr: ec psmintr: 04 psmintr: 18 psmintr: ee psmintr: 06 psmintr: 18 psmintr: ee psmintr: 06 psmintr: 18 psmintr: f1 psmintr: 05 psmintr: 18 psmintr: f3 psmintr: 06 psmintr: 18 psmintr: f5 psmintr: 05 psmintr: 18 psmintr: f7 psmintr: 04 psmintr: 18 psmintr: fb psmintr: 05 psmintr: 18 psmintr: fe psmintr: 05 psmintr: 08 psmintr: 00 psmintr: 04 psmintr: 38 psmintr: fe psmintr: ff psmintr: 38 psmintr: fe psmintr: ff psmintr: 38 psmintr: fc psmintr: fe psmintr: 38 psmintr: f8 psmintr: fd psmintr: 38 psmintr: f2 psmintr: fc psmintr: 38 psmintr: ed psmintr: fd psmintr: 38 psmintr: e9 psmintr: fe psmintr: 38 psmintr: e6 psmintr: ff psmintr: 38 psmintr: e6 psmintr: fe psmintr: 18 psmintr: e6 psmintr: 00 psmintr: 18 psmintr: e8 psmintr: 00 psmintr: 18 psmintr: ea psmintr: 00 psmintr: 18 psmintr: ed psmintr: 01 psmintr: 18 psmintr: f1 psmintr: 00 psmintr: 18 psmintr: f4 psmintr: 03 psmintr: 18 psmintr: f7 psmintr: 02 psmintr: 18 psmintr: ff psmintr: 01 psmintr: 38 psmintr: ff psmintr: fe psmintr: 38 psmintr: ff psmintr: ff psmintr: 28 psmintr: 00 psmintr: ff psmintr: 38 psmintr: ff psmintr: ff psmintr: 08 psmintr: 02 psmintr: 01 psmintr: 08 psmintr: 01 psmintr: 02 psmintr: 08 psmintr: 01 psmintr: 01 psmintr: 08 psmintr: 02 psmintr: 02 psmintr: 08 psmintr: 01 psmintr: 02 psmintr: 08 psmintr: 03 psmintr: 02 psmintr: 08 psmintr: 02 psmintr: 01 psmintr: 08 psmintr: 03 psmintr: 01 psmintr: 08 psmintr: 02 psmintr: 01 psmintr: 08 psmintr: 01 psmintr: 01 psmintr: 08 psmintr: 01 psmintr: 00 psmintr: 08 psmintr: 01 psmintr: 01 psmintr: 08 psmintr: 02 psmintr: 00 psmintr: 08 psmintr: 01 psmintr: 00 psmintr: 28 psmintr: 00 psmintr: ff psmintr: 28 psmintr: 00 psmintr: ff psmintr: 28 psmintr: 01 psmintr: fe psmintr: 28 psmintr: 00 psmintr: fe psmintr: 28 psmintr: 01 psmintr: fd psmintr: 28 psmintr: 02 psmintr: fc psmintr: 28 psmintr: 02 psmintr: fb psmintr: 28 psmintr: 03 psmintr: f9 psmintr: 28 psmintr: 02 psmintr: f9 psmintr: 28 psmintr: 05 psmintr: f8 psmintr: 28 psmintr: 04 psmintr: f9 psmintr: 28 psmintr: 05 psmintr: f8 psmintr: 28 psmintr: 05 psmintr: f8 psmintr: 28 psmintr: 04 psmintr: f9 psmintr: 28 psmintr: 04 psmintr: f8 psmintr: 28 psmintr: 03 psmintr: fb psmintr: 28 psmintr: 02 psmintr: fd psmintr: 28 psmintr: 02 psmintr: fc psmintr: 28 psmintr: 01 psmintr: fe psmintr: 28 psmintr: 00 psmintr: ff psmintr: 18 psmintr: fe psmintr: 02 psmintr: 18 psmintr: fc psmintr: 06 psmintr: 28 psmintr: 01 psmintr: fd psmintr: 28 psmintr: 03 psmintr: fe psmintr: 28 psmintr: 06 psmintr: fd psmintr: 28 psmintr: 0c psmintr: f8 psmintr: 28 psmintr: 0e psmintr: f6 psmintr: 28 psmintr: 12 psmintr: f4 psmintr: 28 psmintr: 13 psmintr: f2 psmintr: 28 psmintr: 13 psmintr: f2 psmintr: 28 psmintr: 11 psmintr: f2 psmintr: 28 psmintr: 10 psmintr: f3 psmintr: 28 psmintr: 0d psmintr: f5 psmintr: 28 psmintr: 0a psmintr: f6 psmintr: 28 psmintr: 09 psmintr: f7 psmintr: 28 psmintr: 06 psmintr: f8 psmintr: 28 psmintr: 05 psmintr: fa psmintr: 28 psmintr: 02 psmintr: fc psmintr: 18 psmintr: ff psmintr: 03 psmintr: 28 psmintr: 02 psmintr: fe psmintr: 28 psmintr: 05 psmintr: fc psmintr: 28 psmintr: 0a psmintr: f7 psmintr: 28 psmintr: 0c psmintr: f5 psmintr: 28 psmintr: 0e psmintr: f4 psmintr: 28 psmintr: 0e psmintr: f5 psmintr: 28 psmintr: 0e psmintr: f3 psmintr: 28 psmintr: 0c psmintr: f6 psmintr: 28 psmintr: 0b psmintr: f7 psmintr: 28 psmintr: 08 psmintr: f8 psmintr: 28 psmintr: 07 psmintr: fb psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psmintr: 28 psmintr: 00 psmintr: fd psmintr: 28 psmintr: 00 psmintr: fe psmintr: 28 psmintr: 02 psmintr: fe psmintr: 08 psmintr: 01 psmintr: 00 psmintr: 28 psmintr: 01 psmintr: ff psmintr: 28 psmintr: 01 psmintr: fe psmintr: 28 psmintr: 01 psmintr: ff psmintr: 28 psmintr: 01 psmintr: ff psmintr: 08 psmintr: 01 psmintr: 00 psmintr: 08 psmintr: 02 psmintr: 00 psmintr: 08 psmintr: 02 psmintr: 00 psmintr: 08 psmintr: 15 psmintr: 04 psm0: lost interrupt? --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="without_synaptics_support.txt" Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #5 r254404: Fri Aug 16 15:17:58 CEST 2013 me@stone:/usr/obj/usr/src/sys/STONE amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz (2394.61-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0xbfebfbff Features2=0x7fbae3bf AMD Features=0x28100800 AMD Features2=0x1 Standard Extended Features=0x281 TSC: P-state invariant, performance statistics real memory = 6442450944 (6144 MB) avail memory = 6078537728 (5796 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard Cuse4BSD v0.1.29 @ /dev/cuse random: initialized ctl: CAM Target Layer loaded acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff irq 16 at device 0.0 on pci1 vgapci1: port 0xf000-0xf03f mem 0xf7400000-0xf77fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci1 agp0: aperture size is 256M, detected 65532k stolen memory pci0: at device 4.0 (no driver attached) xhci0: mem 0xf7a00000-0xf7a0ffff irq 16 at device 20.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xf7a20000-0xf7a203ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 hdac0: mem 0xf7a18000-0xf7a1bfff irq 22 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 ath0: mem 0xf7900000-0xf797ffff irq 17 at device 0.0 on pci3 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 2196.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 pci4: at device 0.0 (no driver attached) re0: port 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 19 at device 0.2 on pci4 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x48800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 50:46:5d:e2:e8:cc ehci1: mem 0xf7a1f000-0xf7a1f3ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7a1e000-0xf7a1e7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahciem0: on ahci0 pci0: at device 31.3 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x317 offMax=0x524 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20 and 25 on hdaa0 pcm1: at nid 33 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 6 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-9 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada1: Command Queueing enabled ada1: 22902MB (46905264 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device SMP: AP CPU #1 Launched! cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1197306600 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus2 usbus1 uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus1 ugen2.2: at usbus2 uhub3: on usbus2 ugen1.2: at usbus1 uhub4: on usbus1 Root mount waiting for: usbus2 usbus1 uhub3: 6 ports with 6 removable, self powered uhub4: 6 ports with 6 removable, self powered ugen1.3: at usbus1 Root mount waiting for: usbus1 ugen1.4: at usbus1 Trying to mount root from zfs:stone []... ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called wlan0: Ethernet address: dc:85:de:3e:a5:69 drmn1: on vgapci1 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. drmn1: taking over the fictitious range 0xd0000000-0xe0000000 info: [drm] Initialized i915 1.6.0 20080730 psm0: disable tap and drag gestures psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_SAMPLING_RATE (20) 00fa psm: ENABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 00 14 psm: DISABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 00 14 psm0: disable tap and drag gestures psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_SAMPLING_RATE (20) 00fa psm: ENABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 20 00 14 psm: cmd 0xff psmintr: fa psmintr: aa psmintr: 00 psm: cmd 0xe6 psmintr: fa psm: cmd 0xf3 psmintr: fa psm: cmd 0x64 psmintr: fa psm: cmd 0xe8 psmintr: fa psm: cmd 0x3 psmintr: fa psm: cmd 0xf4 psmintr: fa psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psmintr: 09 psmintr: 00 psmintr: 00 psmintr: 08 psmintr: 00 psmintr: 00 psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psmintr: 08 psmintr: 00 psmintr: 02 psmintr: 28 psmintr: 00 psmintr: ff psmintr: 09 psmintr: 00 psmintr: 00 psmintr: 08 psmintr: 00 psmintr: 00 psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psmintr: 09 psmintr: 00 psmintr: 00 psmintr: 29 psmintr: 00 psmintr: ff psmintr: 29 psmintr: 00 psmintr: ff psmintr: 29 psmintr: 00 psmintr: ff psmintr: 09 psmintr: 00 psmintr: 01 psmintr: 19 psmintr: ff psmintr: 00 psmintr: 19 psmintr: e9 psmintr: 09 psmintr: 08 psmintr: 00 psmintr: 00 psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? psm0: lost interrupt? --PNTmBPCT7hxwcZjr-- From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 16:17:04 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 718677D1; Thu, 29 Aug 2013 16:17:04 +0000 (UTC) (envelope-from mrezny@hexaneinc.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id B30B92528; Thu, 29 Aug 2013 16:17:03 +0000 (UTC) Received: from mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.140]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 873E541C07A; Thu, 29 Aug 2013 18:16:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter2-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter2-d.gandi.net (mfilter2-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 2n9J1+wv+vFA; Thu, 29 Aug 2013 18:16:42 +0200 (CEST) X-Originating-IP: 89.24.3.53 Received: from unknown (53-3.gprs.tmcz.cz [89.24.3.53]) (Authenticated sender: mrezny@hexaneinc.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id A08D341C074; Thu, 29 Aug 2013 18:16:41 +0200 (CEST) Date: Thu, 29 Aug 2013 18:16:49 +0200 From: Matthew Rezny To: Niclas Zeising Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130829181649.0000788c@unknown> In-Reply-To: <521E5CA0.6080206@freebsd.org> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown> <521E5CA0.6080206@freebsd.org> X-Mailer: Claws Mail 3.9.0cvs98 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 16:17:04 -0000 On Wed, 28 Aug 2013 22:25:04 +0200 Niclas Zeising wrote: > On 08/28/13 17:15, Matthew Rezny wrote: > > On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising > > wrote: > >> On 08/28/13 06:20, Matthew Rezny wrote: >=20 > >> Our old xorg is blocking other ports from updating, so while it > >> might not directly bring new features from your point of view, it > >> is blocking new features in other areas. > >>=20 > > What I meant was no user noticeable features in Xorg stack itself. > > I understand some other software running on Xorg might like a newer=20 > > version, but from a user perspective the older versions of that=20 > > software with working hardware rendering are more usable and useful=20 > > than newer versions stuck on software rendering. Any new features > > are nothing more than theoretical if there is no practical way of > > running them. >=20 > You are missing the point. Some software needs updated xorg stack, > because of lacking features or bugs in our current xorg. If we can't > update those packages, we are missing out on features there, and that > might in turn stop other updates. > Besides that, our current xorg is lacking support upstream, meaning > security isses might go undetected, or we need to backport patches, > which takes time and effort. >=20 Sorry, but it is actually you who misses the point. It matters not what new features are in the updated software or what new features are in the Xorg stack. If there is not a working driver then the Xorg stack is useless and thus all the software that depends on it is also useless. It can have a million new whizbang features but all that means nothing if I can't run the Xorg stack due to missing/non-functional drivers. Miss out on new features, or miss out on all of it, which is worse? Answer should be obvious. Also, "upstream" does not support our platform so we must support ts ourselves regardless what version it is. We had a version that worked thanks to the effort of you and others. It's great to know that a newer version is in the works, but until it's fully baked, don't take away what we already had working. To throw it away away prematurely is not only frustrating for those who were using it, but it also makes waste of the past efforts. >=20 > >> What versions of relevant software are you using? Do you have a=20 > >> xorg.log file to show us, so that we can see what's going on. > >>=20 > > Unfortunately, not at the moment. Relevant versions of Xorg/Mesa > > stuff is too tangled a mess to possibly remember off the top of my > > head. I can't provide an Xorg.log until I replace some hardware. The > > desktop 890FX/PhenomII/HD4870 is having instability problems due to > > VRM cooling issues on the motherboard. While diagnosing the problem, > > I pulled all the hard drives except one which has Windows7, > > primarily to prevent creeping data corruption on the FreeBSD > > drives. When I get the motherboard replaced, then I can follow up > > on this properly. The TurionII/HD4200 laptop is running Windows7 as > > I gave up on using FreeBSD on it months ago. When it had working > > R600 DRI then it was quite usable under FreeBSD with the only > > caveat being the lack of GPU power control meant battery life was a > > little short. Without functional hardware rendering, not only was > > it frustratingly slow, but the increased CPU load impacted battery > > life to the point it was unacceptably short lived away from a power > > outlet. >=20 > Without a list of software, logs and other relevant information it is > impossible to help you and debug this issue. It is not very hard to > get a list of installed ports and packages, a dmesg output and a log > from xorg. >=20 I never said it was hard to do. I said I couldn't do it right this moment and gave the reason why. > As a side note, cooling issues can probably cause all sorts of issues > that doesn't seem related at first, so that might be a place to start. >=20 I am well aware that cooling issues can cause anomalous behavior. That is why I pulled all the harddrives except one. The drives I pulled contain my important data and the FreeBSD zpool. The drive that remains is the Windows OS and app drive, which is the easiest to recreate. It is also what I needed for hardware diagnostics to determine the root cause of the problem and is what I will need to validate the new board. If it gets hosed, I can re-install it fast. When I'm sure the hardware is back in good order, then I'll put the rest of the drives in and get all that you ask. >>=20 > >>> I could almost understand if there was some actual problem with > >>> the R600 DRI, but there isn't. Starting X results in the > >>> software rasterizer, which makes KDE painfully slow . However, > >>> running certain apps I get hardware rendering. i.e. OpenArena > >>> loads r600_dri.so instead of swrast and the framerate in timedemo > >>> clearly slows hardware rendering is in fact working. Why can a > >>> game get hardware rendering but the rest of X can't? > >>=20 > >> Once again, what version of libGL and libdri and drm ports are you=20 > >> using? Are your ports tree up to date? Are you using > >> WITH_NEW_XORG or not? > >>=20 > > See above about version numbers. Port tree was up to date on the=20 > > desktop. I've been running 9-STABLE with ports updated monthly. I > > was not using the WITH_NEW_XORG recently as my understanding was > > that should only be turned on (at that point in time) for Intel KMS > > testers (not sure if can really call any of them users given the > > current state). >=20 > WITH_NEW_XORG=3D is usable for other hardware configurations as well, > and with the addition of the radeon KMS driver, it should work fine > even with radeon hardware. It might need some polish in the ports > department to get optimal performance, but we are working to get that > into the tree in time for 10.0. >=20 At this moment in time I'm not even sure what WITH_NEW_XORG means in terms of versions so I can't really guess at what it does and doesn't work with. What I know is that radeon DRI does not work with or without it when I last tested flipping the switch. The wisdom I remember reading in the past in regards to the switch was that leaving it off should be the version where DRI works, setting it on would get new Xorg which breaks DRI for sure, unless WITH_KMS is also on, in which case DRI works but only for Intel KMS. >>=20 > >>> Considering how far off KMS support is, I would hope this issue=20 > >>> would have been addressed by now. From my viewpoint, it looks > >>> like some stupid and likely trivial bug that causes Xorg to load > >>> swrast instead of r600_dri, but I haven't the time nor patience > >>> to dig through the mess that is Xorg to attempt to figure it > >>> out. > >>=20 > >> Considering KMS for Ati/Radeon cards already hit the tree, I think > >> it is safe to say we have been busy elsewhere. > >>=20 > > I recognize it is in the tree. In fact, its landing in the tree is > > what provoked me to respond to this PR at the this time. However, I > > just saw a statement somewhere on wiki or ML that it would not be > > ready for real use for another 1-2 years. From the announcement of > > it coming into -CURRENT, I get the impression it is really not > > usable beyond testing. Lacking a working console after Xorg loads > > is a total show stopper in my opinion (and why I can't call the > > Intel KMS stuff anything more than testing a year after it went in > > tree). Sure the serial console works, but that is only practical > > for testing, not daily use as a desktop. Forget use on a laptop as > > I haven't seen a serial port on one of those in a LONG time, not to > > mention the impractically of carrying some other device to be the > > console for my laptop, already a device that is massively inferior > > to a desktop in every way other than portability. >=20 > I doubt it is 1-2 years away, where did you see that mail? Of course > there will be some bugs, as always, but it has been in the works for > some time, and it has been tested and deemed ready for a release > (10.0, which is due in a couple of months). With regards to VT > switching, I can understand that it is an issue, but it is something > that's actively being worked on, and the plan is to have it resolved > before 10.0 as well, so FreeBSD is really making progress in the > graphics and desktop department. >=20 I am going by what you said last month: Niclas Zeising on Tue Jul 9 18:50:47 UTC 2013 "The reason we haven't updated to xserver 1.14.1 is partly that it is untested, and also that some drivers, most notably the UMS version of the ati driver, no longer works with this version. We are currently at version 6.14.6 of the ATI driver, which is the last to not need KMS. This will be updated some time after the ATI KMS work in the kernel is completed, and possibly merged back. This means that this work is probably a year or two (at least) away." Maybe I misinterpreted that somehow so correct me if I read it wrong. It is good to hear the VT switching issue is being worked on with intent to have it resolved by 10.0. That is much more reassuring than the last message I saw on the ML on the topic. Raphael Kubo da Costa on Fri Jun 21 12:34:54 UTC 2013 "Niclas Zeising writes: > while the VT switching issues are being worked on. Side question: is someone currently working on this? I assumed nobody had picked up that part of the work and kib wasn't interested in it." >=20 > > I do not intend to come across as unappreciative of the KMS work, > > but I'm being realistic. I understand the motives for choosing the > > ordering for KMS development. First came Intel due to the large > > number of laptops with integrated Intel graphics that didn't even > > have UMS support. Next comes ATI/AMD that needs to migrate from UMS > > to KMS for support of newer hardware. Last shall be Nvidia since > > there is a vendor supported binary driver that is sufficiently > > usable for most with that hardware. Anything else but the current > > "Big 3" will be left to rot since Xorg/Mesa are dropping/have > > dropped UMS support entirely without regard to the vast amount of > > hardware that is still in use and working perfectly well on older > > versions of the stack. The overall approach makes logical sense, > > but the problem is this gap in which UMS support is rapidly > > decaying before KMS support has graduated from it's testing status. > > Prior to the KMS mess, Radeon r100-r700 was the best supported GPU > > hardware under FreeBSD using open drivers and I'm surely not alone > > in having used that to guide hardware buying decisions over the > > last several years. The UMS support needs to be maintained in a > > better state until KMS is truly ready to supercede it, meaning not > > only have OpenGL actually work beyond trivial demos, but more > > importantly a console that works at all times. Even once we have > > newcons running atop DRM drivers, I still see immense value in > > having a method to switch back to text mode with the traditional > > console. Being able to reliably see a panic and get into the > > debugger without relying on serial ports pretty much requires a > > text mode fallback. That combined with how far in the distance > > newcons is means it should be a priority to devise a solution to > > get back to text mode now. >=20 > The problem is that we are in the hands of upstream development. > Linux has had KMS for quite some time, so it is natural that xorg is > starting to chop of support for UMS. And we need to get on that > train, or get left in the dust. The FreeBSD x11@ team is stretched > for resources as is, so we need to focus on what is important. And > newcons isn't far in the distance, it is happening. We have always been at the mercy of upstream to some extent. Yes, they have been doing KMS for a while. Yes, we need to do KMS too. That does not mean we need to throw UMS support out the window. We need to keep around the UMS support for the foreseeable future. When the day comes that all hardware supported by UMS is supported by KMS, then and only then can we safely throw away UMS support. As it is now, some hardware is vesa only on Linux but still properly supported on FreeBSD using the older Xorg. That is a good thing for us. > With regards to nVidia, why should we not use the official binary > blobs? They work (last time I heard) and are supported upstream. I > doubt we'll ever see any KMS driver for nVidia graphics cards as long > as we have this support. We are not Linus, giving the finger to all > vendors who want to support our operating system, just because they > might use a different license than the core OS uses. How far along > is the linux KMS work for nVidia hardware? The reason to not use the official binary blobs is they don't support everything. Last time I looked, the nvidia hardware support was divided across no less than three, maybe even four driver versions. Only the newest hardware is supported by the current driver which works with current Xorg stack. All the previous driver versions for the "legacy" hardware are considered "legacy" drivers and not maintained. They don't work with current Xorg stack on either FreeBSD or Linux. I cannot speak to the quality of the open drivers on Linux as I have not been using them. The nvidia hardware I have is sitting in boxes that only need text mode because there was no viable driver for any other use of it. =46rom reading the status of the nouveau project, they have a driver that is at least better than vesa (2D accel and some 3D support) which supports all nvidia hardware with the GeForce name (and maybe even some TNT stuff but not the early Riva). That goes back further than any of the nvidia legacy drivers iirc. Relying on vendor drivers leaves us at their mercy, and when it's a closed driver there is no way for us to fork it when "upstream" (vendor) drops support. Additionally, even when it is still vendor supported, we can't fix bugs ourselves. Those factors are part of why we are using an open source operating system in the first place. > Lastly, last time I checked most drivers compiled fine with the new > xorg distribution, and even with xserver 1.14 which is in experimental > testing. Unfortunately we (the x11@ team) can't test every > conceivable combination of hardware, so there might be some issues. > On the other hand, there have been few complains about video hardware > and drivers not working, so either noone is using those drivers, or > they work ok. >=20 Working drivers are one thing. Working DRI is another. Yes, the ATI driver still works for 2D and that is better than running the vesa driver. The DRI doesn't work for Xorg so that means no 3D/OpenGL in general. That is a regression since it used to work. Since a few programs can load the DRI driver directly, it's clear that the DRI driver works and the problem is Xorg forgot how to talk to it. That should be fixable. >>=20 > >>> Considering the recent suggestion of flipping the WITH_NEW_XORG=20 > >>> switch, which itself is very ambiguous, I must re-iterate a > >>> previous suggestion: Instead of having a single set of ports for > >>> Xorg, PLEASE make some versioned ports for the older versions. > >>> This would allow the "legacy" hardware (as in what I think most > >>> of us are actually using) to continue to function in a useful > >>> fashion. Considering the precedent of version-named ports (e.g. > >>> postgresql, mysql, bdb, etc), I cannot fathom why this is not > >>> done for Xorg/DRI/Mesa. > >>=20 > >> What is the problem with the name of the switch? It is fairly > >> clear what it does in my opinion. > >>=20 > > The problem with the switch is that it is relative. Someone who may=20 > > have had to flip it on at one point in time will later have to turn > > it off to retain the same working Xorg version. If they update > > ports without flipping the switch at the right time, getting back to > > working can be a nightmare. Further, the single switch only supports > > two version sets existing at any point in time. In the past, when > > there was both WITH_NEW_XORG and WITHOUT_NOVEUA switches, there were > > three possible version combinations controlled by two switches. That > > is in fact the last time anything worked for me (both set ON). In > > theory, after WITHOUT_NOVEUA went away, I should have been able to > > flip WITH_NEW_XORG to OFF and retained the same working > > configuration, but in reality that was not the case. It did not > > matter if the switch was ON or OFF, neither version would load the > > r600_dri.so when starting Xorg. I reported the problem on IRC and > > was told that was strange and shouldn't happen, but now we have a > > PR (the one I'm responding to) that says it is essentially expected > > behavior for the UMS driver that won't be addressed. >=20 > This is why we're slowly working towards getting one unified version > of xorg again, but it takes time, both because we need to port > software, and because the FreeBSD kernel and core system needs to > "catch up" in terms of new hardware support. Why unify? We should have one Xorg stack version that is frozen at the point where UMS reached it's peak. That version can be patched up with bug fixes as need be. The new KMS version is effectively a fork which should have separate ports to allow it to move forward without breaking the old UMS stack. > Currently there are two distributions, the old one, which is xserver > 1.7.7, libGL 7.6.1 (if I'm not mistaken) and old versions of the intel > driver that doesn't support any modern intel GPUs, and so on. > And then there is the new distributions, which needs a modern FreeBSD > with support for intel KMS if you have a intel GPU, xserver 1.12, mesa > 8.0 and so on. So I'm not the only one who can't remember what versions correspond to the possible switch options... > I understand that it can be troublesome moving between versions. We > are doing our best to make it work, but sometimes issues occur, > especially when moving backwards, since that means ports versions > going backwards. The WITHOUT_NOUVEAU option was removed some time > ago, since NOUVEAU never really worked well on FreeBSD, as I've come > to understand it. >=20 That is exactly why versioned ports would be a benefit. It is troublesome to go backward in versions, so it should be avoided. With the ambiguous switch, one can too easily go forward by accident and then it's difficult to go back. With a versioned port, it would be easy to stay on the version that works. The reason that nouveau has not worked well on FreeBSD is that it requires both KMS and gallium. The very early versions that worked with UMS were only the start. With KMS arriving sooner on Linux, the nouveau project decided early on to go KMS only. That makes sense for them. When we have KMS and gallium support ironed out with Intel and ATI, then it should be less difficult to bring in a current nouveau driver for those that want to not use the official nvidia binary blob, either on principle or because they have older hardware that is only supported by legacy drivers which only work with a legacy Xorg stack. >=20 > >> The problem with versioned ports, apart from the fact that it > >> probably would increase our workload even more, is that it is very > >> hard to get a port to depend on different versions, with different > >> shared libraries, functions, etc. etc. You also have to remember > >> that xorg and mesa is a package, and mixing up versions in general > >> won't work. > >>=20 > > I know they are a package that need to have versions kept in sync. > > That is exactly why I advocate versioned ports. Having versioned > > ports would make it easier to keep those in sync as the ports could > > depend on the correct version and updating one would trigger others > > to the updated. Currently, when the switch is flipped, all the right > > ports need to be rebuilt in just the right order and it doesn't > > always work. Sometimes it in necessary to unistall them all and then > > rebuild everything to get Xorg to even start. I have seen numerous > > others on IRC and the ML facing the same problem. I tried freezing > > portions of my ports tree and selectively going back in time, and > > while that worked briefly, it became an unmaintainable mess over > > time and I gave up on it, resulting in spending progressively more > > time in Windows on my desktop (even before the hardware problems) > > just to get anything done. FreeBSD still runs all my server > > hardware with text consoles quite nicely. >=20 > Well then, how do you solve it if you have an application foo, that > wants libGL and xorg-server? Which version should it depend on, libGL > A.B or libGL X.Y? How do you solve that, especially for a binary > package? You can't, not with our current package manager at least. > If you install the package foo, you'll get the default versions of > libGL and xorg-server, otherwise you'll have to compile yourself > anyway. It is exactly the same now. >=20 For ports, look at the gcc situation. Some have gcc=3Dany, some have gcc=3D4.2, some have gcc=3D4.4+, some have gcc=3D4.6+, etc. It's clearly possible to say it doesn't matter, only an old version, or only version at least as new as X.Y. It should be possible to do so for the Xorg stack as well. The ports that make up the stack can be kept in sync by having the old UMS stack ports pinned to the old version and new KMS stack held together by new_version+. For X apps and libraries, anything that needs old or new can specify it. Anything that does not say can be assumed to be Xorg=3Dany. This would not be exactly how it is now. This would be manageable. As for the binary packages, I think it's solvable by depending on the proper library version, but don't quote me on that. >=20 > >> And lastly, even if we would have versioned ports, binary packages=20 > >> still would have to depend on the default version (same for perl,=20 > >> databases and so on), so it wouldn't gain you very much anyway, > >> since you would need to compile stuff from soruce to get a > >> nondefault version. Then you might as well just select version in > >> /etc/make.conf and then compile xorg to begin with. > >>=20 > > In that case, at least there would be binary packages of each > > version rather than only for the default version. Binary packages > > are meaningless to me. I have to build everything from source to > > get working OPTIONS combination anyway. At least with versions I > > could be sure I'm building what I think I am/what I know I need. > > Using versioned ports would not only allow me to retain the known > > working versions, but would make it more clear what other software > > has to be frozen at a particular version to continue using it. > > Without that, it is rather unclear what are the exact repercussions > > of staying on older Xorg stacks. I see things like the databases > > and Python/Perl as great examples of what benefits versioned ports > > bring. People relying on older versions of those ports can do so > > with confidence while newer versions become available to those that > > need them. At the same time, those relying on older versions can > > move forward to new versions in testing environments, rework their > > software as needed, and eventually migrate to a newer version with > > confidence. Without versioned ports, updating the ports tree is a > > game of Russian roulette. When it comes to the Xorg stack, it feels > > like there is only one chamber without a bullet. >=20 > Binary packages are of no interest for you, maybe, but you are > forgetting the bigger picture. It has to work as well, and all this > has to work for everyone, with different versions of FreeBSD, > different hardware, and different requirements. Can you maybe see > now why it is actually a quite time-consuming effort to maintain this. > Versioned ports would only give us even more to support, with little > gain. If you set WITH_NEW_XORG, you get the new xorg distribution, > comprising a set of N ports, with specific versions. If you don't set > it, you get another set of M ports with specific versions, those sets > might overlap, but not everywhere. You can't, however, pick different > versions of different ports, they have to work together. And you > can't install them side-by-side. While it might be possible to > version the ports, I doubt it. This discussion has happened before, > and I have still not seen any progress. > You still can choose which distribution you want, by setting *one* > option. >=20 Perhaps I should have said the provided binary packages mean nothing for me. The provided binary packages are always default options, which are rarely if ever suitable. For some people they are fine. They might even be handy for quick testing to see if it's worth compiling a port with custom options. Now that we have pkgng and poudiere, personalized binary packages become a reasonable form of testing and past version preservation. Sometime after I have my desktop back up and running, I intend to make use of those to see if I can improve this situation. My plan is to setup a build jail with an old version of the ports tree (real old, a year or more in the past). I will initially build everything from that old version. Then, I will slowly roll the tree forward, rebuilding all ports that change each step of the way. When the ports tree is up to current I should have a personal binary package repository with a nice history of the Xorg stack amongst other things from which I can cherry pick. I can quickly switch around versions by just uninstalling one package and installing another, much faster than building the ports again and again with different options and much more manageable than trying to take portions of the ports tree back in time as I had previously done. The only tricky one is the Xorg stack for which I need ports built with the WITH_NEW_XORG switch both on and off. The best solution that comes to mind at the moment is to construct slave ports that set the switch and build those slave ports so I get Xorg_foo_OLD and Xorg_foo_NEW packages. The statement that the ports might be versionable but you doubt it makes no sense. The ports that have the switch already have two versions smashed into one port. To separate them is a matter of making two ports, one that follows the flow with the switch off and the other that follows the flow with the switch on. Someone with good script-fu could probably automate this process. For personal reasons I can't commit to doing this on any timeline, but I will share my work if and when I get around to doing this. It is, after all, the backup plan should the aforementioned slave port idea not work out as hoped. > Besides, if we on top of different versions here, start adding > different versions of other ports, you can soon follow that the > dependency related issues will explode. > >=20 > > It is my opinion that the primary factor holding back the "Linux=20 > > desktop" (and by extension use of FreeBSD as a desktop OS) is the=20 > > complexity and mess of Xfree86/Xorg. For more than a decade now, > > I've periodically tried both for desktop use and always found that > > the disaster that is X keeps me from being able to use it as such > > for more than a brief stint here and there. For a long time I used > > OS X as my desktop and regarded FreeBSD as a server OS, but with > > what Apple has done in the past few years OS X is as bad if not > > worse than Windows. As a former OS/2 user that sees Windows 2000 as > > the peak of Windows usability, and OS X 10.5 as the peak of Mac OS > > usability, I find myself so desperate for a usable desktop OS that > > I almost bought an Amiga X1000. Fortunately, MorphOS released 3.2 > > with PowerMac G5 support just in time to allow me to give that a > > spin on my old Mac without dropping significant coin on new > > hardware. Still, I'd like to see the non-Mac "UNIX desktop" > > eventually reach a state where it can be practically used as an > > everyday desktop OS. With it being so difficult for a highly > > technical (programmer) user to do so, it is obviously impossible > > for any "normal" user to do so. No surprise I see people frustrated > > with Windows installing one of the "easy" Linux distros, and then > > after a couple months at most, giving up and either going back to > > Windows or buying a Mac. I can only hope that Wayland is magically > > better, but the realist/pessimist portion of me fears that it will > > be too Linux centric, a nightmare to port, and still have no stable > > ABI. Lack of stable ABI in Linux is the secondary factor that > > prevents any real success outside the server space where admins can > > dedicate their lives to chasing updates and/or backporting bug > > fixes and required features. At least FreeBSD has a sensible way of > > versioning the ABI that allows it to be much more sane and really > > excel in that exact same space since it requires less effort to > > maintain production systems and can even be a better Linux than > > Linux in terms of running older Linux binaries on current OS > > versions. >=20 >=20 >=20 > xfree86/xorg is a complicated beast, that's why we're working on > porting it and making it as easy to use as possible. I've been using > FreeBSD on my both my laptop and desktop for quite some time, without > any major hassles. I even run our testing versions, to start ironing > out issues and bugs before the rest of the community sees our > requests for further testing. > As stated before, we do our best to test this, but the sheer variety > of hardware out there makes it impossible to cover all corners. > I have friends that use some free operating system or another without > any hassle with X, and I sysadmin several Linux boxes with desktop > environments in the computer club at the university I attend. Not to > mention that the university also uses linux, so saying that the "UNIX > desktop" is a no-go is clearly wrong. >=20 The lack of testing capacity is one more reason to carefully preserve the UMS Xorg stack in a usable and easily obtainable state before we go too much deeper into KMS territory. Of course a University, with it's IT staff dedicated to the task, can manage to maintain a group of UNIX desktops/workstations with Linux and *BSD just as they had done with the proprietary UNIX workstations of the past. The little rant I put after the meat of my post was more about home and small business users without the support staff dedicated to such efforts. If it's hard for me to maintain my own personal systems, it's nearly impossible for the non-technical users. How many years has one of the major industry magazines run a "Is this the year of the Linux desktop?" cover story? I've been seeing at least one a year for no less than a decade. Each time there's a reason why THIS year will be THE year as opposed to all the others. They always miss the mark. Some businesses and governments have done Linux desktop projects and some have worked, but also some have not and they've gone back to Windows. For all those that went back, chances of them even giving Linux or another "UNIX desktop" (OS X aside) a try in the feature are slim to none. Once burned, twice shy. > Remember also that FreeBSD, and the ports collection, including all > relevant software for this discussion (except the nVidia drivers) are > open source. Feel free to help out, experiment and send patches, > that's how we in the x11@ team ended up here. And while it doesn't > seem like much, some of us spend in excess of 40hrs/week some weeks, > to make all this work. >=20 I think that we all understand this point. That is after all how we ended up here. Frustrated by vendors dropping support for the platforms we loved, or sabotaging the versions we enjoyed in an attempt to force us onto their vision of the future, is the reason we end up using open source software. If the original author drops it, so what? If it has value, the users who care can choose to continue on with it to the best of their abilities. Unfortunately for Xorg, the value is the apps that run on it more-so than the Xorg stack itself. That combined with the complexity limits the number of people willing to bury themselves in maintaining it at any version. It is not my ideal, but I would happily put 40+hours/week into it if doing so could keep food on my table, a roof over my head, and the lights on (ok, I can forgo lights, I just need the computers to stay on). A myriad of personal problems has meant that I haven't been able to do so much for Xorg/Mesa as I'm struggling enough to find sufficient paid work. If anyone wants to help change that, I'll commit to doing more for the community. Right now I must pick my battles carefully, meaning I can only put much time into advancing those aspects of my computing life that I depend on to do any paid work I can find, and that itself takes a back seat to simply finding suitable work to do. > Regards! From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 16:33:25 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20F69F02; Thu, 29 Aug 2013 16:33:25 +0000 (UTC) (envelope-from mrezny@hexaneinc.com) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by mx1.freebsd.org (Postfix) with ESMTP id B8301266B; Thu, 29 Aug 2013 16:33:24 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 433B647A0F1; Thu, 29 Aug 2013 18:33:18 +0200 (CEST) Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 760EE1720A5; Thu, 29 Aug 2013 18:33:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ut0oe+hciwwd; Thu, 29 Aug 2013 18:32:29 +0200 (CEST) X-Originating-IP: 89.24.3.53 Received: from unknown (53-3.gprs.tmcz.cz [89.24.3.53]) (Authenticated sender: mrezny@hexaneinc.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5DE98172055; Thu, 29 Aug 2013 18:32:29 +0200 (CEST) Date: Thu, 29 Aug 2013 18:32:32 +0200 From: Matthew Rezny To: Niclas Zeising Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130829183232.0000443f@unknown> In-Reply-To: <521F3002.4040104@freebsd.org> References: <521F3002.4040104@freebsd.org> X-Mailer: Claws Mail 3.9.0cvs98 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Thomas Mueller , freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 16:33:25 -0000 On Thu, 29 Aug 2013 13:26:58 +0200 Niclas Zeising wrote: > On 2013-08-29 02:26, Thomas Mueller wrote: > > From my previous post and Niclas Zeising's response: > >>> I could return to a text console in the dark and type "shutdown > >>> -r now" or even type the command to go back into X, successfully. > >> In general, this can work. It did last time I tested, but that > >> was some time ago so things might have changed. > > > > When I tried with new Xorg and KMS in 9-STABLE, my system froze > > immediately, not just the console. I finally managed to downgrade > > to the old Xorg after considerable difficulty. > > What hardware do you have? Are you sure that the system froze, and > not only that the console went black? Did you check any logs (dmesg, > xorg log, etc.) How do you load the kernel modules for the intel kms > driver? In general, you shouldn't need to load anything at all, X > loads the correct kernel module at the correct time during startup. > > > > I'd like to try again on a new computer, with FreeBSD-current/HEAD > > (10.0 is in the not-so-distant future?). > > 10.0 is slated to arrive in a few months. Be aware when trying new > hardware, however, that FreeBSD might be lagging somewhat in support, > especially when it comes to graphics hardware. > > > > With 3 TB hard drive and GPT, I have plenty of space and partitions > > to experiment, and probably less hazardous than the stablest > > versions of NetBSD. > > > >>> With serial ports becoming obsolete, what can one use for or in > >>> place of a serial console? > > > >> FireWire. I haven't tested myself, but have a look at > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html > >> for instructions on how to use FireWire as a console. > > > > This still leaves the question of how to set it up in terms of > > hardware. I don't think there are any FireWire consoles. > > > > Would I plug anything into the motherboard's FireWire port? I just > > thought of FireWire-to-HDMI cable but haven't looked to see if > > these exist. > > Check the guide. In general you plug the firewire cable from one > computer into another computer, and use the first one to debug the > second. > Firewire is a nice option in terms of speed, but it has some caveats. One is that both sides need to be FreeBSD AFAIK. Serial console works with any OS on the second device, or the second device could even be a dumb terminal if you have one of those still laying around. Another downside is lack of Firewire ports. Every PC motherboard I have at least has one serial port, at least as a header if not directly on the back. Not all have Firewire ports, maybe only half of them do. My laptop without serial has no Firewire either. There are some laptops that do have Firewire but no serial, so that can be a solution for debugging, though it's only possible if you have another system to tether it to so it's not a terribly practical way to get a console for regular use. The only box I have that lacks serial but has Firewire is a Mac. I tried to use the Firewire dcons when I was trying to get Xorg working on FreeBSD/ppc64. It didn't work out too well, but I inadvertently figured out that I could get the console to stay alive through OpenFirmware even when the FreeBSD managed console went dead. That helped immensely in testing. After trying two AGP cards and two old PCI cards, all with no luck, I gave up on Xorg and decided FreeBSD/ppc64 was a reasonable way to use the G5 as a server box should I need to, but it wasn't a solution to keep that machine as a viable desktop. Since then there has been a patch to fix PCI access on that platform so maybe Xorg would work, but I haven't had a chance to go back and test that again. > > >>> Would it work to have two xorg.conf files, one with Intel driver > >>> and the other with vesa? Then could you go back to a working > >>> console when using the vesa driver? > >> Once you've loaded the KMS awawre kernel module, there is no way > >> to get the console back short of a reboot of the system. > > > > But would starting X with vesa driver load the KMS awawre kernel > > module? > > No, using vesa driver won't load the KMS module, but once you've > loaded the KMS module, you can't get the console back short of a > reboot. > > > > What about "xorg -configure" which I might want to do the first > > time? > In general you don't need very much in terms of a config file any > more... It was some time since I set up my own X, so I can't > remember how xorg -configure works, you have to try yourself. > > Regards! From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 16:39:41 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B255B25F; Thu, 29 Aug 2013 16:39:41 +0000 (UTC) (envelope-from mrezny@hexaneinc.com) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 520A426CD; Thu, 29 Aug 2013 16:39:41 +0000 (UTC) Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 744C6A80BC; Thu, 29 Aug 2013 18:39:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Rc+PX3-VKcUg; Thu, 29 Aug 2013 18:39:21 +0200 (CEST) X-Originating-IP: 89.24.3.53 Received: from unknown (53-3.gprs.tmcz.cz [89.24.3.53]) (Authenticated sender: mrezny@hexaneinc.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3E9F7A80B1; Thu, 29 Aug 2013 18:39:20 +0200 (CEST) Date: Thu, 29 Aug 2013 18:39:29 +0200 From: Matthew Rezny To: Kevin Oberman Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130829183929.00005478@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.9.0cvs98 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Thomas Mueller , "freebsd-x11@freebsd.org" , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 16:39:41 -0000 On Wed, 28 Aug 2013 22:31:42 -0700 Kevin Oberman wrote: > On Wed, Aug 28, 2013 at 5:26 PM, Thomas Mueller > wrote: > > > > > From my previous post and Niclas Zeising's response: > > > > > > I had this type of problem with NetBSD 5.1_STABLE and 5.99.x > > > > even with > > native X that is part of the base system, as opposed to pkgsrc X. > > > I can't comment on how NetBSD does things, since I haven't used > > > it. > > > > You aren't missing anything, judging from my experience. FreeBSD is > > decidedly more advanced. > > > > > > I could return to a text console in the dark and type "shutdown > > > > -r > > now" or even type the command to go back into X, successfully. > > > In general, this can work. It did last time I tested, but that > > > was some time ago so things might have changed. > > > > When I tried with new Xorg and KMS in 9-STABLE, my system froze > > immediately, not just the console. I finally managed to downgrade > > to the old Xorg after considerable difficulty. > > > > I'd like to try again on a new computer, with FreeBSD-current/HEAD > > (10.0 is in the not-so-distant future?). > > > > With 3 TB hard drive and GPT, I have plenty of space and partitions > > to experiment, and probably less hazardous than the stablest > > versions of NetBSD. > > > > > > With serial ports becoming obsolete, what can one use for or in > > > > place > > of a serial console? > > > > > FireWire. I haven't tested myself, but have a look at > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html > > > for instructions on how to use FireWire as a console. > > > > This still leaves the question of how to set it up in terms of > > hardware. I don't think there are any FireWire consoles. > > > > Would I plug anything into the motherboard's FireWire port? I just > > thought of FireWire-to-HDMI cable but haven't looked to see if > > these exist. > > > > > > Would it work to have two xorg.conf files, one with Intel > > > > driver and > > the other with vesa? Then could you go back to a working console > > when using the vesa driver? > > > Once you've loaded the KMS awawre kernel module, there is no way > > > to get the console back short of a reboot of the system. > > > > But would starting X with vesa driver load the KMS awawre kernel > > module? > > > > What about "xorg -configure" which I might want to do the first > > time? > > > > > > I've wondered (call it X acrobatics) how to switch between root > > > > and > > nonroot, and between window managers, without going back to text > > console. > > > You could try some sort of desktop manager, such as gdm or kdm. > > > I've not used them on FreeBSD, but on linux they make it possible > > > to have several users logged into X at once, and switching window > > > manager, and so on. As for root, it is generally considered a > > > bad idea to run X as root. If it's just a root terminal you > > > need, you can always open an xterm (or your favorite terminal > > > emulator) and use su or sudo. Regards! > > > -- > > > Niclas Zeising > > > > On Linux (Slackware) I was only able to have one user at a time > > using xdm. > > > > But I remember one menu item in KDE was konsole as root user > > (konsole is KDE's X terminal). > > > > On NetBSD, xdm completely failed to run. > > > > But I got some ideas from Gentoo Linux emailing list, haven't tried > > yet. > > > > One very common mistake people make when attempting to use Intel > > KMS is to > either add the KMS driver to loader.conf or to load it manually after > booting. The result will be an immediate system lockup. Actually, I > suspect the system is not frozen, but the display is frozen and > nothing will accept keyboard or mouse input, so it looks frozen. > > Starting X will load the driver at the proper time so that X can > takeover the display, keyboard, and mouse properly. > > I might also note that Intel KMS requires: WITH_NEW_XORG, WITH_KMS, > and the build of graphics/libdrm with the KMS config option enabled. > > If I sent this to you in the past, sorry. I have posted this > information a few times and it may or may not make a difference for > you. I have not tried the Intel KMS as I have no applicable hardware, but I have read plenty of reports from people testing. I had assumed that when the KMS driver loads, it owns the video card and the kernel never gets to take it back. Does it also take over keyboard and mouse in some way? If so, that makes the problem worse and explains why some seem to have trouble getting a clean reboot/shutdown. I can't fathom why a video driver would take ownership of input devices. The VT switching issue doesn't seem like it should be a big one to solve. The kernel knows how to reinitialize the video card in text mode as it already relies on that to switch to a text console while UMS Xorg is running. I first thought the issue with KMS was simply that there was not a provision for the kernel to tell the KMS driver to give up the card. However, unloading the module still doesn't give the video card back so there is something more than meets the eye. From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 18:28:32 2013 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AAAE9867; Thu, 29 Aug 2013 18:28:32 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6604C2EDA; Thu, 29 Aug 2013 18:28:32 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 82B551E007B3; Thu, 29 Aug 2013 20:28:31 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.5/8.14.4) with ESMTP id r7TIRU0M011181; Thu, 29 Aug 2013 20:27:30 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.5/8.14.3/Submit) id r7TIRU7K011180; Thu, 29 Aug 2013 20:27:30 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 29 Aug 2013 20:27:30 +0200 To: Florent Peterschmitt Subject: Re: Fwd: Re: CFT: vlc 2.0.8 (with two PRs applied) Message-ID: <20130829182730.GA11033@triton8.kn-bremen.de> References: <521E6602.6010104@peterschmitt.fr> <521F7259.2040805@peterschmitt.fr> <20130829174653.GA6823@triton8.kn-bremen.de> <521F8BBF.70708@peterschmitt.fr> <20130829180827.GA9347@triton8.kn-bremen.de> <521F8FA0.2080605@peterschmitt.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <521F8FA0.2080605@peterschmitt.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: x11@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 18:28:32 -0000 On Thu, Aug 29, 2013 at 08:14:56PM +0200, Florent Peterschmitt wrote: > Le 29/08/2013 20:08, Juergen Lock a crit : > >>> Is this using intel kms? radeon kms? Seems at least radeon kms doesn't > >>> do xv with all cards yet, and vdpau even less so: > >>> > >>> https://wiki.freebsd.org/AMD_GPU > >> > >> I don't use any of them, but It's an ATI card. > >> > > Hmm maybe you are and don't know it? > > Nope, at all :) It?s impossible since my kernel conf is custom (GENERIC > without drivers I don't use in fact) and don't include radeonkms drivers > nor drm2. Then, these modules aren't loaded. > > The X.org drivers are those from the port tree and are not development > ones that use KMS ;) > Hm that would mean vanilla radeon drivers are now broken for xv as well, not good. :( Which card is this btw? I've Cc'd x11@ - maybe someone there has an idea... Best, Juergen From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 18:32:16 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F374C9B3 for ; Thu, 29 Aug 2013 18:32:15 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 793462F30 for ; Thu, 29 Aug 2013 18:32:15 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E77B740010 for ; Thu, 29 Aug 2013 20:32:12 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id DBF3D4000D; Thu, 29 Aug 2013 20:32:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 552D44000C; Thu, 29 Aug 2013 20:32:12 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQsqb70lsz8hVn; Thu, 29 Aug 2013 20:32:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id u98cuwYOeJ8A; Thu, 29 Aug 2013 20:32:08 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQsqX4QS5z8hVm; Thu, 29 Aug 2013 20:32:08 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cQsqX3jHjz9Ctj; Thu, 29 Aug 2013 20:32:08 +0200 (CEST) Message-ID: <521F93A6.5040405@freebsd.org> Date: Thu, 29 Aug 2013 20:32:06 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Matthew Rezny Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: <20130829183929.00005478@unknown> In-Reply-To: <20130829183929.00005478@unknown> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130829-0, 2013-08-29), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: Kevin Oberman , "freebsd-x11@freebsd.org" , Thomas Mueller X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 18:32:16 -0000 On 2013-08-29 18:39, Matthew Rezny wrote: > On Wed, 28 Aug 2013 22:31:42 -0700 > Kevin Oberman wrote: >> On Wed, Aug 28, 2013 at 5:26 PM, Thomas Mueller >> wrote: >> Starting X will load the driver at the proper time so that X can >> takeover the display, keyboard, and mouse properly. >> >> I might also note that Intel KMS requires: WITH_NEW_XORG, WITH_KMS, >> and the build of graphics/libdrm with the KMS config option enabled. >> >> If I sent this to you in the past, sorry. I have posted this >> information a few times and it may or may not make a difference for >> you. > > I have not tried the Intel KMS as I have no applicable hardware, but I > have read plenty of reports from people testing. I had assumed that > when the KMS driver loads, it owns the video card and the kernel never > gets to take it back. Does it also take over keyboard and mouse in some > way? If so, that makes the problem worse and explains why some seem to > have trouble getting a clean reboot/shutdown. I can't fathom why a > video driver would take ownership of input devices. > > The VT switching issue doesn't seem like it should be a big one to > solve. The kernel knows how to reinitialize the video card in text mode > as it already relies on that to switch to a text console while UMS Xorg > is running. I first thought the issue with KMS was simply that there > was not a provision for the kernel to tell the KMS driver to give up > the card. However, unloading the module still doesn't give the video > card back so there is something more than meets the eye. VT switching is being worked on, and hopefully will make it in time for FreeBSD 10.0. I doubt that the driver takes ownership of input devices, but maybe X does, and then fails to return them, in some configurations. I just tested on my laptop, which uses KMS, and I had no trouble exiting X, got a black screen, then blindly type "startx" and have it come back up again. Neither was there any trouble powering off the computer cleanly using the power button, so in the general case, the computer is clearly still alive and working, even after exiting X. The only thing not working is the console. Regards! -- Niclas From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 18:52:53 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 895677C5; Thu, 29 Aug 2013 18:52:53 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 4D34820BE; Thu, 29 Aug 2013 18:52:53 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 8CFAE6E85; Thu, 29 Aug 2013 20:52:52 +0200 (CEST) Message-ID: <521F9883.2080604@peterschmitt.fr> Date: Thu, 29 Aug 2013 20:52:51 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Fwd: Re: CFT: vlc 2.0.8 (with two PRs applied) References: <521E6602.6010104@peterschmitt.fr> <521F7259.2040805@peterschmitt.fr> <20130829174653.GA6823@triton8.kn-bremen.de> <521F8BBF.70708@peterschmitt.fr> <20130829180827.GA9347@triton8.kn-bremen.de> <521F8FA0.2080605@peterschmitt.fr> <20130829182730.GA11033@triton8.kn-bremen.de> In-Reply-To: <20130829182730.GA11033@triton8.kn-bremen.de> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WRtGg43ehuO27PgVQ46A9leEsEbTHor4C" Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 18:52:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WRtGg43ehuO27PgVQ46A9leEsEbTHor4C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 29/08/2013 20:27, Juergen Lock a =E9crit : > Hm that would mean vanilla radeon drivers are now broken for xv as > well, not good. :( Which card is this btw? >=20 > I've Cc'd x11@ - maybe someone there has an idea... It's the same with the vesa driver in a VirtualBox VM. --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) --WRtGg43ehuO27PgVQ46A9leEsEbTHor4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSH5iDAAoJEFr01BkajbiBXB0QAJab/nc+eKatIGFFg6VQ61Hg xxMcVHJiSzixDiQBezBU50DKBTfS0LT41t1oXWwgxCmR/9kIUqeRDQoccXu51rNL OjUz7y8whHecC5F8sbq4GdheCHsW2V1NtZwsN04p+YowSi+E3L7gga93PBhd+6RE Xx8eV5JPZ0cygjfZU3z7UgZIaXZ+hAwWxewAZsYwuYQ5dWiseHfVnsYxvR4Jcan5 VQwUeK/7wJQMrvKDegQGO93MzaZ/caZ69DW+wGwgAD8nIx/L9PqsaoPKz7whpta7 bNJURrt28UDz9zX9zkuXfHhn7ohDnXXg+npTKGKD06raYnWOJUiHW3cgj55Fl+io ZfiJSiBfNgLkIZES9Tw1hT76qpcsBJHMrGWATO6gWb0GUkefykPkBgz8W6Ma3XQr aVKYqkDc7wWroH1A9zT/YExi+ixZEPe2t3HLCEL3bIj5ovPFUqmr7uzxk81GYLz/ K3yuY3iYLQK+QsgCvVKf0mUiqzGk/s9sXfcciRwm6JJZakxc+ZnvxYzh9BJUedlY C2jBCpwX70sI++GxexKDoK2zb4uIypq7THv5ETtUs3tMif5h87VR5JeMKVG9FhW2 MkpJVciRmulrV7UMntRfjKz9cv/J6GRRycdScf76H0ZqsMA9AliLjvemndjiki/k HSdzwNKD6przejivRIBb =vv+Y -----END PGP SIGNATURE----- --WRtGg43ehuO27PgVQ46A9leEsEbTHor4C-- From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 19:17:25 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C8BBC1BA; Thu, 29 Aug 2013 19:17:25 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 840E62265; Thu, 29 Aug 2013 19:17:25 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 75A281E007A8; Thu, 29 Aug 2013 21:17:24 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.5/8.14.4) with ESMTP id r7TJGsbD014639; Thu, 29 Aug 2013 21:16:54 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.5/8.14.3/Submit) id r7TJGsEs014638; Thu, 29 Aug 2013 21:16:54 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 29 Aug 2013 21:16:53 +0200 To: Florent Peterschmitt Subject: Re: Fwd: Re: CFT: vlc 2.0.8 (with two PRs applied) Message-ID: <20130829191653.GA14395@triton8.kn-bremen.de> References: <521E6602.6010104@peterschmitt.fr> <521F7259.2040805@peterschmitt.fr> <20130829174653.GA6823@triton8.kn-bremen.de> <521F8BBF.70708@peterschmitt.fr> <20130829180827.GA9347@triton8.kn-bremen.de> <521F8FA0.2080605@peterschmitt.fr> <20130829182730.GA11033@triton8.kn-bremen.de> <521F9883.2080604@peterschmitt.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <521F9883.2080604@peterschmitt.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-x11@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 19:17:25 -0000 On Thu, Aug 29, 2013 at 08:52:51PM +0200, Florent Peterschmitt wrote: > Le 29/08/2013 20:27, Juergen Lock a crit : > > Hm that would mean vanilla radeon drivers are now broken for xv as > > well, not good. :( Which card is this btw? > > > > I've Cc'd x11@ - maybe someone there has an idea... > > It's the same with the vesa driver in a VirtualBox VM. > Hm is vesa even supposed to support xv? Also have you tried xv with another player like mplayer -vo xv ? Best, Juergen From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 19:40:44 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F43B83F for ; Thu, 29 Aug 2013 19:40:44 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6B9E23EC for ; Thu, 29 Aug 2013 19:40:43 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 32E3D40013 for ; Thu, 29 Aug 2013 21:40:41 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 283DF40011; Thu, 29 Aug 2013 21:40:41 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id A773C4000C; Thu, 29 Aug 2013 21:40:39 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQvLb1FzZz8hVt; Thu, 29 Aug 2013 21:40:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id 7MT-Vts7pagc; Thu, 29 Aug 2013 21:40:33 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cQvLT1cNxz8hVm; Thu, 29 Aug 2013 21:40:33 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cQvLT0ZWNz9Ctj; Thu, 29 Aug 2013 21:40:32 +0200 (CEST) Message-ID: <521FA3AE.1010900@freebsd.org> Date: Thu, 29 Aug 2013 21:40:30 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Matthew Rezny Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown> <521E5CA0.6080206@freebsd.org> <20130829181649.0000788c@unknown> In-Reply-To: <20130829181649.0000788c@unknown> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130829-0, 2013-08-29), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 19:40:44 -0000 On 2013-08-29 18:16, Matthew Rezny wrote: > On Wed, 28 Aug 2013 22:25:04 +0200 > Niclas Zeising wrote: > >> On 08/28/13 17:15, Matthew Rezny wrote: >>> On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising >>> wrote: >>>> On 08/28/13 06:20, Matthew Rezny wrote: >> >>>> Our old xorg is blocking other ports from updating, so while it >>>> might not directly bring new features from your point of view, it >>>> is blocking new features in other areas. >>>> >>> What I meant was no user noticeable features in Xorg stack itself. >>> I understand some other software running on Xorg might like a newer >>> version, but from a user perspective the older versions of that >>> software with working hardware rendering are more usable and useful >>> than newer versions stuck on software rendering. Any new features >>> are nothing more than theoretical if there is no practical way of >>> running them. >> >> You are missing the point. Some software needs updated xorg stack, >> because of lacking features or bugs in our current xorg. If we can't >> update those packages, we are missing out on features there, and that >> might in turn stop other updates. >> Besides that, our current xorg is lacking support upstream, meaning >> security isses might go undetected, or we need to backport patches, >> which takes time and effort. >> > Sorry, but it is actually you who misses the point. It matters not what > new features are in the updated software or what new features are in the > Xorg stack. If there is not a working driver then the Xorg stack is > useless and thus all the software that depends on it is also useless. > It can have a million new whizbang features but all that means nothing > if I can't run the Xorg stack due to missing/non-functional drivers. > Miss out on new features, or miss out on all of it, which is worse? > Answer should be obvious. It does work! It works for me, on two different hardware configurations, it works for the rest of the x11@ team, or it wouldn't have made it into the regular ports tree. It seem to work for mostly everyone else, since there's been very little traffic on the list lately regarding any issues with our X. I'm not denying that it doesn't work for you, but since you haven't provided any information I need, I can't help you currently. In the meantime, the rest of us moves along to newer versions, with new features and probably bugs. Some visible, some not visible, and a lot of features needed. > > Also, "upstream" does not support our platform so we must support ts > ourselves regardless what version it is. We had a version that worked > thanks to the effort of you and others. It's great to know that a newer > version is in the works, but until it's fully baked, don't take away > what we already had working. To throw it away away prematurely is not > only frustrating for those who were using it, but it also makes waste > of the past efforts. Upstream does support us. They generally accept our patches, if we send them along, and at least I have mostly been helped and advised when I've asked for it. They might not be able to test every corner case, and naturally they will move ahead to new APIs and ways of doing things, regardless of what we do. We do, however, have to show that we still use the software, or we will come to a time when it is impossible to get X to work on FreeBSD. >> WITH_NEW_XORG= is usable for other hardware configurations as well, >> and with the addition of the radeon KMS driver, it should work fine >> even with radeon hardware. It might need some polish in the ports >> department to get optimal performance, but we are working to get that >> into the tree in time for 10.0. >> > At this moment in time I'm not even sure what WITH_NEW_XORG means in > terms of versions so I can't really guess at what it does and doesn't > work with. What I know is that radeon DRI does not work with or without > it when I last tested flipping the switch. The wisdom I remember > reading in the past in regards to the switch was that leaving it off > should be the version where DRI works, setting it on would get new Xorg > which breaks DRI for sure, unless WITH_KMS is also on, in which case > DRI works but only for Intel KMS. WITH_NEW_XORG gives the new FreeBSD xorg stack, as opposed to the legacy FreeBSD xorg stack, it is as simple as that. It works with intel KMS, it works with Radeon KMS (it still needs some small fixes in ports to get that to play really well, but we are working on that), and it works with the nVidia blob driver, and it works, at least for me, with Radeon without KMS. I assume it works with other hardware as well, since no one has complained. >> > I am going by what you said last month: > Niclas Zeising on Tue Jul 9 18:50:47 UTC 2013 > > "The reason we haven't updated to xserver 1.14.1 is partly that it is > untested, and also that some drivers, most notably the UMS version of > the ati driver, no longer works with this version. We are currently at > version 6.14.6 of the ATI driver, which is the last to not need KMS. > This will be updated some time after the ATI KMS work in the kernel is > completed, and possibly merged back. This means that this work is > probably a year or two (at least) away." This is referring to xserver 1.14.1, which does not work with the ATI UMS driver, meaning we can't import xserver 1.14.1 untill *all* supported versions of FreeBSD has the Radeon KMS kernel module, which is at least a couple of years away. It has nothing to do with the state of the Radeon KMS driver in FreeBSD 10.0. > > Maybe I misinterpreted that somehow so correct me if I read it wrong. > It is good to hear the VT switching issue is being worked on with > intent to have it resolved by 10.0. That is much more reassuring than > the last message I saw on the ML on the topic. > Raphael Kubo da Costa on Fri Jun 21 12:34:54 UTC 2013 > > "Niclas Zeising writes: >> while the VT switching issues are being worked on. > > Side question: is someone currently working on this? I assumed nobody > had picked up that part of the work and kib wasn't interested in it." Kib wasn't interested in this, and when this was mailed, more than two months ago, I was unsure if it was ok to discuss in public who was working on this, since no formal announcement had been made yet. Today, there is a git branch, somewhere. Have a look at https://wiki.freebsd.org/Newcons, allthough that page haven't been updated in quite some time, there is a link to the SVN repo were this work is being done. >> The problem is that we are in the hands of upstream development. >> Linux has had KMS for quite some time, so it is natural that xorg is >> starting to chop of support for UMS. And we need to get on that >> train, or get left in the dust. The FreeBSD x11@ team is stretched >> for resources as is, so we need to focus on what is important. And >> newcons isn't far in the distance, it is happening. > > We have always been at the mercy of upstream to some extent. Yes, they > have been doing KMS for a while. Yes, we need to do KMS too. That does > not mean we need to throw UMS support out the window. We need to keep > around the UMS support for the foreseeable future. When the day comes > that all hardware supported by UMS is supported by KMS, then and only > then can we safely throw away UMS support. As it is now, some hardware > is vesa only on Linux but still properly supported on FreeBSD using the > older Xorg. That is a good thing for us. This will never happen. Some legacy hardware will loose support. However, we need to move on, to support new hardware, and to support other software. There are parts of the ports tree where we can't update because of bugs in our legacy xorg, and these ports include new features we must have, in order to in turn be able to update other ports. We can't hold off these updates forever, just because some rarely used xorg driver needs the legacy xorg stack. And, as I said, last time I checked, almost all drivers compile with xorg 1.14, and the same goes for the drivers in the ports tree. I hardly think Linux and the freedesktop foundation throws out support for legacy hardware just because they can. It is more likely because no one is using said hardware, and is there to support it. X needs to move on, to get support for modern hardware, as well as support for new graphics features, and better graphics performance. As a comparison, do you think I can plug in my old 3dfx voodoo2 card and have windows 7 support it? Or even windows XP? How about my nVidia 440MX? Some legacy hardware will loose support, it is regrettable, but sometimes unavoidable. > >> With regards to nVidia, why should we not use the official binary >> blobs? They work (last time I heard) and are supported upstream. I >> doubt we'll ever see any KMS driver for nVidia graphics cards as long >> as we have this support. We are not Linus, giving the finger to all >> vendors who want to support our operating system, just because they >> might use a different license than the core OS uses. How far along >> is the linux KMS work for nVidia hardware? > > The reason to not use the official binary blobs is they don't support > everything. Last time I looked, the nvidia hardware support was divided > across no less than three, maybe even four driver versions. Only the > newest hardware is supported by the current driver which works with > current Xorg stack. All the previous driver versions for the "legacy" > hardware are considered "legacy" drivers and not maintained. They don't > work with current Xorg stack on either FreeBSD or Linux. I cannot speak > to the quality of the open drivers on Linux as I have not been using > them. The nvidia hardware I have is sitting in boxes that only need > text mode because there was no viable driver for any other use of it. > From reading the status of the nouveau project, they have a driver that > is at least better than vesa (2D accel and some 3D support) which > supports all nvidia hardware with the GeForce name (and maybe even some > TNT stuff but not the early Riva). That goes back further than any of > the nvidia legacy drivers iirc. Relying on vendor drivers leaves us at > their mercy, and when it's a closed driver there is no way for us to > fork it when "upstream" (vendor) drops support. Additionally, even when > it is still vendor supported, we can't fix bugs ourselves. Those > factors are part of why we are using an open source operating system in > the first place. I don't know exactly which nVidia driver supports which hardware, and which version of xorg, I don't maintain those drivers. Yes, we are at the mercy of upstream, as always, but in the case of nVidia at least, this collaboration has worked fine as far as I know. I don't know about the status of nouveau in Linux, but I know that on the ubuntu machines I maintain at uni we use the binary driverers. The same goes for all the department's CentOS installations, which makes me believe that this works better, or at least is less of a maintenance and administration burden, compared to using the nouveau driver. It is possible to port the nouveau kernel bits to FreeBSD, but so far no one has volunteered to do it, and in my opinion, there are other things that are more important to fix, such as updating the intel KMS driver to support new intel graphics hardware. For nouveau there is a working alternative, for intel and radeon graphics, there isn't. >> This is why we're slowly working towards getting one unified version >> of xorg again, but it takes time, both because we need to port >> software, and because the FreeBSD kernel and core system needs to >> "catch up" in terms of new hardware support. > > Why unify? We should have one Xorg stack version that is frozen at the > point where UMS reached it's peak. That version can be patched up with > bug fixes as need be. The new KMS version is effectively a fork which > should have separate ports to allow it to move forward without breaking > the old UMS stack. Feel free to step in and maintain this mess, the rest of us probably lack the time and energy to do so. It is not as easy as it sounds to backport security and stability fixes, and the UMS stack lacks support for a lot of modern graphics hardware. You also still haven't solved the dependency issues. > >> Currently there are two distributions, the old one, which is xserver >> 1.7.7, libGL 7.6.1 (if I'm not mistaken) and old versions of the intel >> driver that doesn't support any modern intel GPUs, and so on. >> And then there is the new distributions, which needs a modern FreeBSD >> with support for intel KMS if you have a intel GPU, xserver 1.12, mesa >> 8.0 and so on. > > So I'm not the only one who can't remember what versions correspond to > the possible switch options... I gave you a list of the most important version differences. I can go on, the intel driver in the old xorg implementation is at 2.7.1, while in the new stack it is at 2.21.9, and in our development repo it is at 2.21.15. libGL and dri is at 7.6.1 and 8.0.4 respectively. And in the development repo it's at 9.1. libdrm is at 2.4.17 in the old stack, and 2.4.46 for the new one. > The reason that nouveau has not worked well on FreeBSD is that it > requires both KMS and gallium. The very early versions that worked with > UMS were only the start. With KMS arriving sooner on Linux, the nouveau > project decided early on to go KMS only. That makes sense for them. > When we have KMS and gallium support ironed out with Intel and ATI, > then it should be less difficult to bring in a current nouveau driver > for those that want to not use the official nvidia binary blob, either > on principle or because they have older hardware that is only supported > by legacy drivers which only work with a legacy Xorg stack. Yes, as stated before, it is possible to do this work, however, FreeBSD is mostly a volunteer effort, and so far no one has stepped up to do the work. > For ports, look at the gcc situation. Some have gcc=any, some have > gcc=4.2, some have gcc=4.4+, some have gcc=4.6+, etc. It's clearly > possible to say it doesn't matter, only an old version, or only > version at least as new as X.Y. It should be possible to do so for the > Xorg stack as well. The ports that make up the stack can be kept in sync > by having the old UMS stack ports pinned to the old version and new KMS > stack held together by new_version+. For X apps and libraries, anything > that needs old or new can specify it. Anything that does not say can be > assumed to be Xorg=any. This would not be exactly how it is now. This > would be manageable. As for the binary packages, I think it's solvable > by depending on the proper library version, but don't quote me on that. Patches welcome! > Perhaps I should have said the provided binary packages mean nothing > for me. You are forgetting all other users, however. >> > The lack of testing capacity is one more reason to carefully preserve > the UMS Xorg stack in a usable and easily obtainable state before we > go too much deeper into KMS territory. Except that we lack important hardware support with the UMS stack, so we can't stay there forever. Not to mention that this prevents us from updates in other areas. > > Of course a University, with it's IT staff dedicated to the task, can > manage to maintain a group of UNIX desktops/workstations with Linux and > *BSD just as they had done with the proprietary UNIX workstations of > the past. The little rant I put after the meat of my post was more about > home and small business users without the support staff dedicated to > such efforts. If it's hard for me to maintain my own personal systems, > it's nearly impossible for the non-technical users. How many years has > one of the major industry magazines run a "Is this the year of the > Linux desktop?" cover story? I've been seeing at least one a year for > no less than a decade. Each time there's a reason why THIS year will be > THE year as opposed to all the others. They always miss the mark. Some > businesses and governments have done Linux desktop projects and some > have worked, but also some have not and they've gone back to Windows. > For all those that went back, chances of them even giving Linux or > another "UNIX desktop" (OS X aside) a try in the feature are slim to > none. Once burned, twice shy. I manage my computers, no problem. Have you tried PC-BSD? They've used the KMS enabled X by default for some time, and I think it works there as well. I haven't tested myself though. > >> Remember also that FreeBSD, and the ports collection, including all >> relevant software for this discussion (except the nVidia drivers) are >> open source. Feel free to help out, experiment and send patches, >> that's how we in the x11@ team ended up here. And while it doesn't >> seem like much, some of us spend in excess of 40hrs/week some weeks, >> to make all this work. >> > I think that we all understand this point. That is after all how we > ended up here. Frustrated by vendors dropping support for the platforms > we loved, or sabotaging the versions we enjoyed in an attempt to force > us onto their vision of the future, is the reason we end up using open > source software. If the original author drops it, so what? If it has > value, the users who care can choose to continue on with it to the > best of their abilities. Unfortunately for Xorg, the value is the apps > that run on it more-so than the Xorg stack itself. That combined with > the complexity limits the number of people willing to bury themselves in > maintaining it at any version. It is not my ideal, but I would happily > put 40+hours/week into it if doing so could keep food on my table, a > roof over my head, and the lights on (ok, I can forgo lights, I just > need the computers to stay on). A myriad of personal problems has meant > that I haven't been able to do so much for Xorg/Mesa as I'm struggling > enough to find sufficient paid work. If anyone wants to help change > that, I'll commit to doing more for the community. Right now I must > pick my battles carefully, meaning I can only put much time into > advancing those aspects of my computing life that I depend on to do any > paid work I can find, and that itself takes a back seat to simply > finding suitable work to do. > Most of us have a day job besides the 40 hrs/week we put into FreeBSD. I know people are getting payed to work on FreeBSD, but most of the work is still done by volunteers. I understand that not everyone can do this, but keep in mind that everone working on FreeBSD, regardless of which part, is doing their absolute best to make FreeBSD as good as humanly possible. Regard! -- Niclas From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 19:58:56 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D94EEED5; Thu, 29 Aug 2013 19:58:56 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9CAD42504; Thu, 29 Aug 2013 19:58:56 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 640776F7F; Thu, 29 Aug 2013 21:58:55 +0200 (CEST) Message-ID: <521FA7FE.8070708@peterschmitt.fr> Date: Thu, 29 Aug 2013 21:58:54 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 Subject: Re: Fwd: Re: CFT: vlc 2.0.8 (with two PRs applied) References: <521E6602.6010104@peterschmitt.fr> <521F7259.2040805@peterschmitt.fr> <20130829174653.GA6823@triton8.kn-bremen.de> <521F8BBF.70708@peterschmitt.fr> <20130829180827.GA9347@triton8.kn-bremen.de> <521F8FA0.2080605@peterschmitt.fr> <20130829182730.GA11033@triton8.kn-bremen.de> <521F9883.2080604@peterschmitt.fr> <20130829191653.GA14395@triton8.kn-bremen.de> In-Reply-To: <20130829191653.GA14395@triton8.kn-bremen.de> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hKqwb3BNFkEbBLfOC3v0TUnTfX8RXK6FH" Cc: freebsd-x11@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 19:58:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hKqwb3BNFkEbBLfOC3v0TUnTfX8RXK6FH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Le 29/08/2013 21:16, Juergen Lock a =E9crit : > Hm is vesa even supposed to support xv? I really don't know :D > Also have you tried xv with another player like mplayer -vo xv ? Here is the output (from the ATI machine): % mplayer -vo xv 46\ Le\ Code\ de\ chevalerie.mkv [=85] [VO_XV] It seems there is no Xvideo support for your video card available= =2E [VO_XV] Run 'xvinfo' to verify its Xv support and read [VO_XV] DOCS/HTML/en/video.html#xv! [VO_XV] See 'mplayer -vo help' for other (non-xv) video out drivers. [VO_XV] Try -vo x11. Error opening/initializing the selected video_out (-vo) device. It runs well with -vo x11 --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) --hKqwb3BNFkEbBLfOC3v0TUnTfX8RXK6FH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSH6f+AAoJEFr01BkajbiBCf0P/iGOn6hnyHPzvv6/LveO8nEF 57enL5TDFQxkYPj0kQQDI4ODmk4HtaEzL+iG5fCEiUA/vWFcV2u2Y58WHtptP/lz yuO3ldMXCt+5tcj6mSPXTc5r2JdI8AiAe4+E9kIZvK6ntf+gWhcOejBCszYbxmH0 S4A/RDAdcX3mMt2oE2V+aPKbXAinomrTWCUoBZTSwnE69pJPvPhX/kTAZ6OIJPbH UtCtb2fqGZgsKH34VMkFv7lK0fnm2NT/m8Ss5zw+pvMMuSmICVEmaL2yigG4lX0J Wsiixzq7AICdvvHYOyTo4QM15TIO3mvaFU+nRI+ehVHKyhlhko8td6eroMuJn4MO PhnhfifF8Aqktvw32SmjJsVFXhOh9HF73VCZBtaJGOzdvbTOVXTERbl8uZjoCKmQ l6hQfqIwbPUHDkN5nI5qIOEJQuhqrzSGyjrEnOpBjEz3pgdpMARYNBPZmUvPfrqv JfI9wYFQQWzRTGz9Ef0TU5dHgXQSNWARL2wDvEeRzN7rBF9cwnjH0JM90H6fbqeZ JKt6vwTCT9b9G9vOqRGGToJKH2KJuZFMjO4wTaSdfJf8NC6Zxyl+lAqRpDPQUZWB e8woaGNhWwms0/yuetuOi9d/g2HtQhv4q09IBTMvqGqWl2j5V5+0w4KEgNs4EVMT NKW1JbVtfAoUG03F26HX =fNzV -----END PGP SIGNATURE----- --hKqwb3BNFkEbBLfOC3v0TUnTfX8RXK6FH-- From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 20:17:31 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1FA7530D; Thu, 29 Aug 2013 20:17:31 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 671D6262B; Thu, 29 Aug 2013 20:17:30 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 558501E007A8; Thu, 29 Aug 2013 22:17:28 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.5/8.14.4) with ESMTP id r7TKGWZc018291; Thu, 29 Aug 2013 22:16:32 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.5/8.14.3/Submit) id r7TKGWdg018290; Thu, 29 Aug 2013 22:16:32 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 29 Aug 2013 22:16:32 +0200 To: Florent Peterschmitt Subject: Re: Fwd: Re: CFT: vlc 2.0.8 (with two PRs applied) Message-ID: <20130829201632.GA18280@triton8.kn-bremen.de> References: <521E6602.6010104@peterschmitt.fr> <521F7259.2040805@peterschmitt.fr> <20130829174653.GA6823@triton8.kn-bremen.de> <521F8BBF.70708@peterschmitt.fr> <20130829180827.GA9347@triton8.kn-bremen.de> <521F8FA0.2080605@peterschmitt.fr> <20130829182730.GA11033@triton8.kn-bremen.de> <521F9883.2080604@peterschmitt.fr> <20130829191653.GA14395@triton8.kn-bremen.de> <521FA7FE.8070708@peterschmitt.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <521FA7FE.8070708@peterschmitt.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-x11@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 20:17:31 -0000 On Thu, Aug 29, 2013 at 09:58:54PM +0200, Florent Peterschmitt wrote: > Le 29/08/2013 21:16, Juergen Lock a écrit : > > Hm is vesa even supposed to support xv? > > I really don't know :D > > > Also have you tried xv with another player like mplayer -vo xv ? > > Here is the output (from the ATI machine): > > % mplayer -vo xv 46\ Le\ Code\ de\ chevalerie.mkv > […] > [VO_XV] It seems there is no Xvideo support for your video card available. > [VO_XV] Run 'xvinfo' to verify its Xv support and read > [VO_XV] DOCS/HTML/en/video.html#xv! > [VO_XV] See 'mplayer -vo help' for other (non-xv) video out drivers. > [VO_XV] Try -vo x11. > Error opening/initializing the selected video_out (-vo) device. > > > It runs well with -vo x11 > Oh ok so the problem is vlc tries to use xv even when it's not available. Hm. Best, Juergen From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 20:20:09 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F1B1943E; Thu, 29 Aug 2013 20:20:08 +0000 (UTC) (envelope-from edwin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C75A52657; Thu, 29 Aug 2013 20:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7TKK8BQ009192; Thu, 29 Aug 2013 20:20:08 GMT (envelope-from edwin@freefall.freebsd.org) Received: (from edwin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7TKK8tf009191; Thu, 29 Aug 2013 20:20:08 GMT (envelope-from edwin) Date: Thu, 29 Aug 2013 20:20:08 GMT Message-Id: <201308292020.r7TKK8tf009191@freefall.freebsd.org> To: edwin@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org, freebsd-x11@FreeBSD.org From: edwin@FreeBSD.org Subject: Re: ports/181660: [patch][xorg-dev] x11-servers/xorg-server: fix typos and new xorg support in config/devd X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Aug 2013 20:20:09 -0000 Synopsis: [patch][xorg-dev] x11-servers/xorg-server: fix typos and new xorg support in config/devd Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: edwin Responsible-Changed-When: Thu Aug 29 20:20:08 UTC 2013 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=181660 From owner-freebsd-x11@FreeBSD.ORG Thu Aug 29 20:30:01 2013 Return-Path: Delivered-To: freebsd-x11@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A0034681 for ; Thu, 29 Aug 2013 20:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72BBC26F3 for ; Thu, 29 Aug 2013 20:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7TKU1r3011224 for ; Thu, 29 Aug 2013 20:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7TKU1S3011223; Thu, 29 Aug 2013 20:30:01 GMT (envelope-from gnats) Date: Thu, 29 Aug 2013 20:30:01 GMT Message-Id: <201308292030.r7TKU1S3011223@freefall.freebsd.org> To: freebsd-x11@FreeBSD.org Cc: From: Niclas Zeising Subject: Re: ports/181660: [patch][xorg-dev] x11-servers/xorg-server: fix typos and new xorg support in config/devd X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Niclas Zeising List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 20:30:01 -0000 The following reply was made to PR ports/181660; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, jbeich@tormail.org Cc: Subject: Re: ports/181660: [patch][xorg-dev] x11-servers/xorg-server: fix typos and new xorg support in config/devd Date: Thu, 29 Aug 2013 22:28:35 +0200 I take it you have ported this patch from xserver 1.12 to 1.14? Or is it the same patch? I'll see if I can get to this tomorrow. -- Niclas Zeising From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 06:22:31 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A50445B; Fri, 30 Aug 2013 06:22:31 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id D303A2875; Fri, 30 Aug 2013 06:22:30 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=ddwCLAre c=1 sm=0 a=68NkTaeYMVLl2m++3813FQ==:17 a=i4YerQ4AwY4A:10 a=2nbQus8neRsA:10 a=DvSzqBOGy98A:10 a=pedpZTtsAAAA:8 a=ayC55rCoAAAA:8 a=KGjhK52YXX0A:10 a=alFmtWT1AaIA:10 a=6I5d2MoRAAAA:8 a=EhV1unwLwbzM96U6VukA:9 a=c6gvhQW5lNsA:10 a=68NkTaeYMVLl2m++3813FQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 74.130.200.176 Received: from [74.130.200.176] ([74.130.200.176:61179] helo=localhost) by hrndva-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 26/37-28548-F1A30225; Fri, 30 Aug 2013 06:22:24 +0000 Date: Fri, 30 Aug 2013 06:22:23 +0000 Message-ID: <26.37.28548.F1A30225@hrndva-omtalb.mail.rr.com> From: "Thomas Mueller" To: freebsd-x11@freebsd.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Cc: Matthew Rezny , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 06:22:31 -0000 >From my previous post and Niclas Zeising's response: > > When I tried with new Xorg and KMS in 9-STABLE, my system froze immediately, not just the console. I finally managed to downgrade to the old Xorg after > considerable difficulty. > What hardware do you have? Are you sure that the system froze, and not > only that the console went black? Did you check any logs (dmesg, xorg > log, etc.) How do you load the kernel modules for the intel kms driver? > In general, you shouldn't need to load anything at all, X loads the > correct kernel module at the correct time during startup. I don't remember about the logs, and now is far too late. But I remember doing everything I did when I had this problem with NetBSD on old computer, native xorg server, not pkgsrc, and no KMS. Nothing I did with keyboard had any effect. I tried to Ctrl-Alt-F1 and "shutdown -r now", nothing. I also tried the Caps Lock key to see if there was any life, did not light up. By the way, another problem I had with NetBSD was the text console screen blanking after 30 seconds inactivity and not coming back until I could find my way in the dark to a root command prompt and type screenblank -u >>>> With serial ports becoming obsolete, what can one use for or in place of a serial console? >>> FireWire. I haven't tested myself, but have a look at >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html >>> for instructions on how to use FireWire as a console. >> This still leaves the question of how to set it up in terms of hardware. I don't think there are any FireWire consoles. >> Would I plug anything into the motherboard's FireWire port? I just thought of FireWire-to-HDMI cable but haven't looked to see if these exist. > Check the guide. In general you plug the firewire cable from one > computer into another computer, and use the first one to debug the second. Does it have to be Firewire as opposed to something else like USB or Ethernet? I have to check Newegg, Tiger Direct, etc for what is available. No Firewire to HDMI. Regarding xorg.conf, I could run, as root (already did), "Xorg -configure" from present installation, and make one version with driver vesa. I see I have a /root/xorg.conf.new with Driver "fbdev". Change that to "intel" for one version and "vesa" for the other? Any problem switching (between boots) keyboards? I have both PS/2 and USB. PS/2 combo mouse/keyboard port allows connecting a mouse or keyboard but not both at the same time. But the idea of having a fallback vesa driver was in case the intel driver fails, and when I have work to do where I need to switch back to a text console. Tom From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 09:22:51 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1C070A46 for ; Fri, 30 Aug 2013 09:22:51 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9418C24DB for ; Fri, 30 Aug 2013 09:22:50 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F25FD40006 for ; Fri, 30 Aug 2013 11:22:47 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E880240009; Fri, 30 Aug 2013 11:22:47 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 4CC4A40006; Fri, 30 Aug 2013 11:22:45 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRFb86B8Mz8hVn; Fri, 30 Aug 2013 11:22:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id tWzOhcYnrWOc; Fri, 30 Aug 2013 11:22:42 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRFb60Ld5z8hVm; Fri, 30 Aug 2013 11:22:42 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cRFb553BLz9Ctj; Fri, 30 Aug 2013 11:22:41 +0200 (CEST) Message-ID: <52206460.5020902@freebsd.org> Date: Fri, 30 Aug 2013 11:22:40 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Thomas Mueller Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering References: <26.37.28548.F1A30225@hrndva-omtalb.mail.rr.com> In-Reply-To: <26.37.28548.F1A30225@hrndva-omtalb.mail.rr.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130829-1, 2013-08-29), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-x11@freebsd.org, Matthew Rezny X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 09:22:51 -0000 On 2013-08-30 08:22, Thomas Mueller wrote: > From my previous post and Niclas Zeising's response: > >>> When I tried with new Xorg and KMS in 9-STABLE, my system froze immediately, not just the console. I finally managed to downgrade to the old Xorg after >> considerable difficulty. > >> What hardware do you have? Are you sure that the system froze, and not >> only that the console went black? Did you check any logs (dmesg, xorg >> log, etc.) How do you load the kernel modules for the intel kms driver? >> In general, you shouldn't need to load anything at all, X loads the >> correct kernel module at the correct time during startup. > > I don't remember about the logs, and now is far too late. > > But I remember doing everything I did when I had this problem with NetBSD on old computer, native xorg server, not pkgsrc, and no KMS. > > Nothing I did with keyboard had any effect. I tried to Ctrl-Alt-F1 and "shutdown -r now", nothing. > > I also tried the Caps Lock key to see if there was any life, did not light up. > > By the way, another problem I had with NetBSD was the text console screen blanking after 30 seconds inactivity and not coming back until I could find my way in the dark to a root command prompt and type > > screenblank -u This could be a NetBSD specific issue maybe? As I said before, I had no trouble on my laptop running 'startx' from the black console, so I assume shutdown -r now works as long as I have a root shell. I also could shut down cleanly with the power button, using acpi. All this on FreeBSD. > >>>>> With serial ports becoming obsolete, what can one use for or in place of a serial console? > >>>> FireWire. I haven't tested myself, but have a look at >>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html >>>> for instructions on how to use FireWire as a console. > >>> This still leaves the question of how to set it up in terms of hardware. I don't think there are any FireWire consoles. > >>> Would I plug anything into the motherboard's FireWire port? I just thought of FireWire-to-HDMI cable but haven't looked to see if these exist. > >> Check the guide. In general you plug the firewire cable from one >> computer into another computer, and use the first one to debug the second. > > Does it have to be Firewire as opposed to something else like USB or Ethernet? It has to be FireWire... With FireWire it is possible to do DMA, or access system memory directly, or somesuch, which makes it work (and also is a security issue, apparently). I have heard people suggest making a debug network stack to be able to debug remotely using ethernet, but this is not possible today. > Regarding xorg.conf, I could run, as root (already did), "Xorg -configure" from present installation, and make one version with driver vesa. > > I see I have a /root/xorg.conf.new with Driver "fbdev". Change that to "intel" for one version and "vesa" for the other? Something like that, then you have to point X to the right config at startup. Regards! -- Niclas From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 10:12:32 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF12EE07; Fri, 30 Aug 2013 10:12:32 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward9l.mail.yandex.net (forward9l.mail.yandex.net [IPv6:2a02:6b8:0:1819::9]) by mx1.freebsd.org (Postfix) with ESMTP id 7E79F2829; Fri, 30 Aug 2013 10:12:32 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward9l.mail.yandex.net (Yandex) with ESMTP id CDB89E60F69; Fri, 30 Aug 2013 14:12:30 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 595401B60015; Fri, 30 Aug 2013 14:12:30 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jmThQmW7gg-CUTeZSWM; Fri, 30 Aug 2013 14:12:30 +0400 Message-ID: <5220700D.1050301@passap.ru> Date: Fri, 30 Aug 2013 14:12:29 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 MIME-Version: 1.0 To: Artyom Mirgorodskiy Subject: Re: unsupported synaptics touchpad References: <20130822155651.GA32146@probe.unige.ch> <9437888.l2O97oTlfp@notebook.alkar.net> <1596081.5RRtn7UfRG@notebook.alkar.net> In-Reply-To: <1596081.5RRtn7UfRG@notebook.alkar.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-x11@freebsd.org, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 10:12:32 -0000 29.08.2013 18:10, Artyom Mirgorodskiy пишет: > This patch works for me too. Thank you. Please, submit a follow-up to the PR with some info about hardware, software, problem and the result. Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 10:37:35 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3A888179; Fri, 30 Aug 2013 10:37:35 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 022252962; Fri, 30 Aug 2013 10:37:34 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id E54AB6588; Fri, 30 Aug 2013 12:37:33 +0200 (CEST) Message-ID: <522075EB.2080306@peterschmitt.fr> Date: Fri, 30 Aug 2013 12:37:31 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org, freebsd-x11@freebsd.org Subject: VirtualBox vboxmouse X.org configuration X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EFkfStpbrfWNQ3uFhkMuiabiFXGOUf3l6" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 10:37:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EFkfStpbrfWNQ3uFhkMuiabiFXGOUf3l6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I'm using FreeBSD 9.2-RC3 and VBox 4.2.16 on host & guest. I had to configure X.org this way to get mouse integration: --- Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" RightOf "Screen0" InputDevice "Mouse0" "CorePointer" InputDevice "Mouse1" InputDevice "Keyboard0" "CoreKeyboard" Option "AutoAddDevices" "False" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" EndSection Section "InputDevice" Identifier "Mouse1" Driver "vboxmouse" Option "SendCoreEvents" "True" EndSection --- Does anybody can confirm this is the right way? Using directly the vboxmouse on CorePointer doesn't work at all and disabling integration from VBox host makes the pointer not moving anymore. --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) --EFkfStpbrfWNQ3uFhkMuiabiFXGOUf3l6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIHXsAAoJEFr01BkajbiB3loP/3be3ejxXL1aiHxUvwkCN4Ra r7haChlUAwvtWDskBN6d++B33ss9EfR/wd/kqn1UkOXuFiY3RHlBt/+iWiuoqV8e KU6KhT1Uv2WEgknf13XQhSVEN2Rhz7+DpTScwHJ7jD8ZNLJK0GiJfT5x1D7Fz1uR oS34ETjfvlbiUzeeOQXRVhp4eBd3CQfRmM0EGPZd5JhLga90wOinQ7+JQTJRZ8Lt kAT2CzG8im8DUsCnX9aV7CSDt4MFKEOyGtCrZDzTscyO9iWSEXnL6eCxYDncez4c 26mGxCVzG03xZtwOEoayNXgwcfP28asNCqMZcQPRSR3LT2imTlxZRmakaR+SGoVI oM+t9vdgiZ2yn6IYeMbA0Ui6rQNgJiRLA+XU5f5sIwJTKXMDVsse/WyZ2H6/eAnG BS/UH7bTBf/Qmi8usyRU3TkR5ole2cbt/qPg+QruJCcgpkRsOkEtaspNk5n1zSsZ 3qnqQoNP9BnbKun0G3CGFjSbVx33SvmPwmBZ3Lv9zuLEqWhzwqNAs5BCdmBrbAKv nUO5WkGOIVdXP9ZOemnl3/BmypLUz9rfRCsEFynJMNyndkJivBYcVw9d5Vvc69WF ZmiLzDBoLSPo4mkSZwpBlAsUMR/YeFG14ggcacWRXcpgPOsJr9OUgfEkL4nUoDUu DdzA6T+AihDOpggadbFC =5e+c -----END PGP SIGNATURE----- --EFkfStpbrfWNQ3uFhkMuiabiFXGOUf3l6-- From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 14:16:58 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EA0DD937 for ; Fri, 30 Aug 2013 14:16:58 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACB9D286F for ; Fri, 30 Aug 2013 14:16:58 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VFPVQ-000Ocr-FH; Fri, 30 Aug 2013 16:16:56 +0200 Message-ID: <5220A94F.6030800@FreeBSD.org> Date: Fri, 30 Aug 2013 16:16:47 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130813 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ke Sun Subject: Re: unsupported synaptics touchpad References: <20130822155651.GA32146@probe.unige.ch> <52171DE6.7030909@FreeBSD.org> <20130823091753.GA21594@probe.unige.ch> <52175C5E.2080007@FreeBSD.org> <20130823150007.GA31164@probe.unige.ch> <521E3828.9000605@FreeBSD.org> <20130829143122.GA757@probe.unige.ch> In-Reply-To: <20130829143122.GA757@probe.unige.ch> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2SJWHTTQTSKJPTSEMVIFR" Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 14:16:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SJWHTTQTSKJPTSEMVIFR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, I understand the problem with the "hw.psm.tap_enabled" sysctl: it only works for Synaptics touchpad when not using "hw.psm.synaptics_support=3D1". For any other touchpads using the "Generic PS/2 mouse" code in psm(4), the sysctl is not used at all. I'll try to prepare a patch for that, but maybe not before a few days. --=20 Jean-S=E9bastien P=E9dron ------enig2SJWHTTQTSKJPTSEMVIFR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIgqVgACgkQa+xGJsFYOlNZoQCgxZGdRb3iUiKJcCM0wXsUWgKf n+IAoLq1ee7l8dc4nhDxzuBRijqwgrFy =YjiO -----END PGP SIGNATURE----- ------enig2SJWHTTQTSKJPTSEMVIFR-- From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 16:53:20 2013 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39E45E1C; Fri, 30 Aug 2013 16:53:20 +0000 (UTC) (envelope-from mrezny@hexaneinc.com) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id 85D322206; Fri, 30 Aug 2013 16:53:19 +0000 (UTC) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1ED9C1720A1; Fri, 30 Aug 2013 18:53:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 4s50t7O2YT9u; Fri, 30 Aug 2013 18:52:59 +0200 (CEST) X-Originating-IP: 89.24.3.53 Received: from unknown (53-3.gprs.tmcz.cz [89.24.3.53]) (Authenticated sender: mrezny@hexaneinc.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 254BF172070; Fri, 30 Aug 2013 18:52:59 +0200 (CEST) Date: Fri, 30 Aug 2013 18:53:08 +0200 From: Matthew Rezny To: Niclas Zeising Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Message-ID: <20130830185308.00003809@unknown> In-Reply-To: <521FA3AE.1010900@freebsd.org> References: <201308280420.r7S4K1OM083764@freefall.freebsd.org> <521DE1F6.1030305@freebsd.org> <20130828171520.00004b3e@unknown> <521E5CA0.6080206@freebsd.org> <20130829181649.0000788c@unknown> <521FA3AE.1010900@freebsd.org> X-Mailer: Claws Mail 3.9.0cvs98 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:53:20 -0000 On Thu, 29 Aug 2013 21:40:30 +0200 Niclas Zeising wrote: > On 2013-08-29 18:16, Matthew Rezny wrote: > > On Wed, 28 Aug 2013 22:25:04 +0200 > > Niclas Zeising wrote: > > > >> On 08/28/13 17:15, Matthew Rezny wrote: > >>> On Wed, 28 Aug 2013 13:41:42 +0200 Niclas Zeising > >>> wrote: > >>>> On 08/28/13 06:20, Matthew Rezny wrote: > >> > >>>> Our old xorg is blocking other ports from updating, so while it > >>>> might not directly bring new features from your point of view, it > >>>> is blocking new features in other areas. > >>>> > >>> What I meant was no user noticeable features in Xorg stack itself. > >>> I understand some other software running on Xorg might like a > >>> newer version, but from a user perspective the older versions of > >>> that software with working hardware rendering are more usable and > >>> useful than newer versions stuck on software rendering. Any new > >>> features are nothing more than theoretical if there is no > >>> practical way of running them. > >> > >> You are missing the point. Some software needs updated xorg stack, > >> because of lacking features or bugs in our current xorg. If we > >> can't update those packages, we are missing out on features there, > >> and that might in turn stop other updates. > >> Besides that, our current xorg is lacking support upstream, meaning > >> security isses might go undetected, or we need to backport patches, > >> which takes time and effort. > >> > > Sorry, but it is actually you who misses the point. It matters not > > what new features are in the updated software or what new features > > are in the Xorg stack. If there is not a working driver then the > > Xorg stack is useless and thus all the software that depends on it > > is also useless. It can have a million new whizbang features but > > all that means nothing if I can't run the Xorg stack due to > > missing/non-functional drivers. Miss out on new features, or miss > > out on all of it, which is worse? Answer should be obvious. > > It does work! It works for me, on two different hardware > configurations, it works for the rest of the x11@ team, or it wouldn't > have made it into the regular ports tree. It seem to work for mostly > everyone else, since there's been very little traffic on the list > lately regarding any issues with our X. I'm not denying that it > doesn't work for you, but since you haven't provided any information > I need, I can't help you currently. In the meantime, the rest of us > moves along to newer versions, with new features and probably bugs. > Some visible, some not visible, and a lot of features needed. > If it works, then why did you suspend this PR with the statement "This is a known issue and will not be fixed until the ATI KMS work is integrated into FreeBSD."? If it is not an issue, then why is it that I have seen numerous ML posts in the past couple years asking how to make DRI work on R600 class hardware? I have seen 2-3 people report it works but at least a dozen state that it doesn't work for them. If you know some magic trick to enable DRI in Xorg (not just in a couple games, but for KWin and apps) then please share it. > > > Also, "upstream" does not support our platform so we must support ts > > ourselves regardless what version it is. We had a version that > > worked thanks to the effort of you and others. It's great to know > > that a newer version is in the works, but until it's fully baked, > > don't take away what we already had working. To throw it away away > > prematurely is not only frustrating for those who were using it, > > but it also makes waste of the past efforts. > > Upstream does support us. They generally accept our patches, if we > send them along, and at least I have mostly been helped and advised > when I've asked for it. They might not be able to test every corner > case, and naturally they will move ahead to new APIs and ways of > doing things, regardless of what we do. > We do, however, have to show that we still use the software, or we > will come to a time when it is impossible to get X to work on FreeBSD. > Accepting patches is not the same as supporting us. Upstream is essentially Linux. Even if Xorg and Mesa are not directly part of Linux, they now rely on the DRM drivers in Linux and design decisions are very Linux centric. i.e. dropping HAL and using udev for handling input devices, where HAL was a portable standalone but udev is a non-portable part of Linux. The BSDs and OpenSolaris are essentially left out in the cold to use what they can of the resulting code. We will always be behind on versions as we must port what we can and either ignore or replace the pieces that are too Linux specific. > >> WITH_NEW_XORG= is usable for other hardware configurations as well, > >> and with the addition of the radeon KMS driver, it should work fine > >> even with radeon hardware. It might need some polish in the ports > >> department to get optimal performance, but we are working to get > >> that into the tree in time for 10.0. > >> > > At this moment in time I'm not even sure what WITH_NEW_XORG means in > > terms of versions so I can't really guess at what it does and > > doesn't work with. What I know is that radeon DRI does not work > > with or without it when I last tested flipping the switch. The > > wisdom I remember reading in the past in regards to the switch was > > that leaving it off should be the version where DRI works, setting > > it on would get new Xorg which breaks DRI for sure, unless WITH_KMS > > is also on, in which case DRI works but only for Intel KMS. > > WITH_NEW_XORG gives the new FreeBSD xorg stack, as opposed to the > legacy FreeBSD xorg stack, it is as simple as that. It works with > intel KMS, it works with Radeon KMS (it still needs some small fixes > in ports to get that to play really well, but we are working on > that), and it works with the nVidia blob driver, and it works, at > least for me, with Radeon without KMS. I assume it works with other > hardware as well, since no one has complained. > The switch, as named, implies it is more for testing than use. "Give me something newer than default" is what that name says. It's exact meaning, in terms of versions and what features it enables/breaks, has changed over time. It would be more logical to change the name as the meaning changes. At least then it would be more obvious when there is a change in the effect. For example, it could currently be called WITH_XORG_KMS_SUPPORT, which of course requires WITH_KMS. >> > > I am going by what you said last month: > > Niclas Zeising on Tue Jul 9 18:50:47 UTC 2013 > > > > "The reason we haven't updated to xserver 1.14.1 is partly that it > > is untested, and also that some drivers, most notably the UMS > > version of the ati driver, no longer works with this version. We > > are currently at version 6.14.6 of the ATI driver, which is the > > last to not need KMS. This will be updated some time after the ATI > > KMS work in the kernel is completed, and possibly merged back. > > This means that this work is probably a year or two (at least) > > away." > > This is referring to xserver 1.14.1, which does not work with the ATI > UMS driver, meaning we can't import xserver 1.14.1 untill *all* > supported versions of FreeBSD has the Radeon KMS kernel module, which > is at least a couple of years away. It has nothing to do with the > state of the Radeon KMS driver in FreeBSD 10.0. > OK, so that timeline was not for Radeon KMS support becoming usable, but for that support to exist in all branches that are supported by ports, which basically means 10-RELEASE, backport to 9, and wait for 8 to expire. Do you have any insight into when we might reasonable expect the Radeon KMS support to graduate from testing to general use? In time for 10.0? > > > Maybe I misinterpreted that somehow so correct me if I read it > > wrong. It is good to hear the VT switching issue is being worked on > > with intent to have it resolved by 10.0. That is much more > > reassuring than the last message I saw on the ML on the topic. > > Raphael Kubo da Costa on Fri Jun 21 12:34:54 UTC 2013 > > > > "Niclas Zeising writes: > >> while the VT switching issues are being worked on. > > > > Side question: is someone currently working on this? I assumed > > nobody had picked up that part of the work and kib wasn't > > interested in it." > > Kib wasn't interested in this, and when this was mailed, more than two > months ago, I was unsure if it was ok to discuss in public who was > working on this, since no formal announcement had been made yet. > Today, there is a git branch, somewhere. Have a look at > https://wiki.freebsd.org/Newcons, allthough that page haven't been > updated in quite some time, there is a link to the SVN repo were this > work is being done. > I realize it's been some months since that statement, but I had not seen any statement on the status since that time. I am aware of multiple projects intended to replace SC. Newscons is one which had appeared to be stalled for some time but I had heard some mumblings about it recently enough to figure it was coming back to life slowly. There was also the KGI based console that looked usable around the same time Newcons started, but it too seemed to stall without going into the tree. I understand that sometimes there are private projects, but my feeling is that it is best to make as much public as possible. Publicly sharing information about upcoming and ongoing projects not only alleviates the need for some questions, but allows better planning and can enable people who want to same thing to possibly work together rather than needlessly duplicate efforts in private. > >> The problem is that we are in the hands of upstream development. > >> Linux has had KMS for quite some time, so it is natural that xorg > >> is starting to chop of support for UMS. And we need to get on that > >> train, or get left in the dust. The FreeBSD x11@ team is stretched > >> for resources as is, so we need to focus on what is important. And > >> newcons isn't far in the distance, it is happening. > > > > We have always been at the mercy of upstream to some extent. Yes, > > they have been doing KMS for a while. Yes, we need to do KMS too. > > That does not mean we need to throw UMS support out the window. We > > need to keep around the UMS support for the foreseeable future. > > When the day comes that all hardware supported by UMS is supported > > by KMS, then and only then can we safely throw away UMS support. As > > it is now, some hardware is vesa only on Linux but still properly > > supported on FreeBSD using the older Xorg. That is a good thing for > > us. > > This will never happen. Some legacy hardware will loose support. > However, we need to move on, to support new hardware, and to support > other software. There are parts of the ports tree where we can't > update because of bugs in our legacy xorg, and these ports include > new features we must have, in order to in turn be able to update > other ports. We can't hold off these updates forever, just because > some rarely used xorg driver needs the legacy xorg stack. > And, as I said, last time I checked, almost all drivers compile with > xorg 1.14, and the same goes for the drivers in the ports tree. > I hardly think Linux and the freedesktop foundation throws out support > for legacy hardware just because they can. It is more likely because > no one is using said hardware, and is there to support it. X needs > to move on, to get support for modern hardware, as well as support > for new graphics features, and better graphics performance. > As a comparison, do you think I can plug in my old 3dfx voodoo2 card > and have windows 7 support it? Or even windows XP? How about my > nVidia 440MX? Some legacy hardware will loose support, it is > regrettable, but sometimes unavoidable. > I know that this, support of all hardware with KMS, will never happen. I intended that to be interpreted as a need to maintain a UMS supporting Xorg stack indefinitely. Surely not every library and app can be used in their most recent form on the older stack, but at least the things that have been working with it can be kept for use by those who are satisfied with them. I have not tried my Voodoo2 in Windows 7 as that OS brings no benefit for the box which hosts that card, but it certainly works in Windows XP. I do not know about the 440MX as that's a cut down card, but my 4600Ti works at least up through XP. Windows 7 botched the audio path so badly that Windows XP remains the best OS for Win32 games that don't require DX11 (DX10 is possible on XP with a little hacking). Vendors dropping support don't mean the hardware isn't still used. Creative ate Aureal before the W2K drivers were even fully finished, but my Vortex2 works in XP, and thanks to community driver efforts it even supports A3D and hardware accelerated DS3D. Supporting hardware that is no longer vendor supported is one area where open source operating systems have previously and should continue to surpass closed operating systems. A good number of my SCSI cards don't have support for NT6+ and some (adaptec) don't even have any support for 64bit XP, but they all work great in FreeBSD and Linux. Sometimes old hardware is in use because it's not possible to upgrade (AGP video cards) and sometimes it's in use because it simply still works well enough there is no compelling reason to replace it. e.g. my file server has the PCIe slots full of network and SAS cards, so to avoid using the onboard intel video, I put my trusty MilleniumII in an otherwise useless PCI slot. Silly as that may sound to some, the integrated video consumes 3% of system memory bandwidth for a text mode console in idle state (surely much more for graphical modes) so using a graphics cards with dedicated hardware and memory reduces contention for system resources and improves performance on the tasks the box is intended for. > > >> With regards to nVidia, why should we not use the official binary > >> blobs? They work (last time I heard) and are supported upstream. I > >> doubt we'll ever see any KMS driver for nVidia graphics cards as > >> long as we have this support. We are not Linus, giving the finger > >> to all vendors who want to support our operating system, just > >> because they might use a different license than the core OS uses. > >> How far along is the linux KMS work for nVidia hardware? > > > > The reason to not use the official binary blobs is they don't > > support everything. Last time I looked, the nvidia hardware support > > was divided across no less than three, maybe even four driver > > versions. Only the newest hardware is supported by the current > > driver which works with current Xorg stack. All the previous driver > > versions for the "legacy" hardware are considered "legacy" drivers > > and not maintained. They don't work with current Xorg stack on > > either FreeBSD or Linux. I cannot speak to the quality of the open > > drivers on Linux as I have not been using them. The nvidia hardware > > I have is sitting in boxes that only need text mode because there > > was no viable driver for any other use of it. From reading the > > status of the nouveau project, they have a driver that is at least > > better than vesa (2D accel and some 3D support) which supports all > > nvidia hardware with the GeForce name (and maybe even some TNT > > stuff but not the early Riva). That goes back further than any of > > the nvidia legacy drivers iirc. Relying on vendor drivers leaves us > > at their mercy, and when it's a closed driver there is no way for > > us to fork it when "upstream" (vendor) drops support. Additionally, > > even when it is still vendor supported, we can't fix bugs > > ourselves. Those factors are part of why we are using an open > > source operating system in the first place. > > I don't know exactly which nVidia driver supports which hardware, and > which version of xorg, I don't maintain those drivers. Yes, we are at > the mercy of upstream, as always, but in the case of nVidia at least, > this collaboration has worked fine as far as I know. I don't know > about the status of nouveau in Linux, but I know that on the ubuntu > machines I maintain at uni we use the binary driverers. The same > goes for all the department's CentOS installations, which makes me > believe that this works better, or at least is less of a maintenance > and administration burden, compared to using the nouveau driver. > It is possible to port the nouveau kernel bits to FreeBSD, but so far > no one has volunteered to do it, and in my opinion, there are other > things that are more important to fix, such as updating the intel KMS > driver to support new intel graphics hardware. For nouveau there is > a working alternative, for intel and radeon graphics, there isn't. > That is the current state. The vendor's drivers are currently better performing for modern hardware and still a better experience for some older hardware. The much older hardware is stuck with either vesa or nouveau for a modern Xorg stack, but that is not the hardware you have. The importance of nouveau on FreeBSD is minimal now for the reasons we both covered, but that will change in time as more of the current cards go to legacy driver support by the vendor and the legacy drivers fall further behind in Xorg support while nouveau continues to improve. > >> This is why we're slowly working towards getting one unified > >> version of xorg again, but it takes time, both because we need to > >> port software, and because the FreeBSD kernel and core system > >> needs to "catch up" in terms of new hardware support. > > > > Why unify? We should have one Xorg stack version that is frozen at > > the point where UMS reached it's peak. That version can be patched > > up with bug fixes as need be. The new KMS version is effectively a > > fork which should have separate ports to allow it to move forward > > without breaking the old UMS stack. > > Feel free to step in and maintain this mess, the rest of us probably > lack the time and energy to do so. It is not as easy as it sounds to > backport security and stability fixes, and the UMS stack lacks support > for a lot of modern graphics hardware. > You also still haven't solved the dependency issues. > First step is to separate the UMS and KMS stacks more cleanly, which I have said I would like to do when I am able to do so. Resolving dependencies will get easier with that done. Maintenance after that point is mainly keeping it buildable and collecting the bugfixes from our community. Upstream won't have much to backport in my opinion. > > > >> Currently there are two distributions, the old one, which is > >> xserver 1.7.7, libGL 7.6.1 (if I'm not mistaken) and old versions > >> of the intel driver that doesn't support any modern intel GPUs, > >> and so on. And then there is the new distributions, which needs a > >> modern FreeBSD with support for intel KMS if you have a intel GPU, > >> xserver 1.12, mesa 8.0 and so on. > > > > So I'm not the only one who can't remember what versions correspond > > to the possible switch options... > > I gave you a list of the most important version differences. I can go > on, the intel driver in the old xorg implementation is at 2.7.1, while > in the new stack it is at 2.21.9, and in our development repo it is at > 2.21.15. libGL and dri is at 7.6.1 and 8.0.4 respectively. And in > the development repo it's at 9.1. libdrm is at 2.4.17 in the old > stack, and 2.4.46 for the new one. > > > The reason that nouveau has not worked well on FreeBSD is that it > > requires both KMS and gallium. The very early versions that worked > > with UMS were only the start. With KMS arriving sooner on Linux, > > the nouveau project decided early on to go KMS only. That makes > > sense for them. When we have KMS and gallium support ironed out > > with Intel and ATI, then it should be less difficult to bring in a > > current nouveau driver for those that want to not use the official > > nvidia binary blob, either on principle or because they have older > > hardware that is only supported by legacy drivers which only work > > with a legacy Xorg stack. > > Yes, as stated before, it is possible to do this work, however, > FreeBSD is mostly a volunteer effort, and so far no one has stepped > up to do the work. > > > For ports, look at the gcc situation. Some have gcc=any, some have > > gcc=4.2, some have gcc=4.4+, some have gcc=4.6+, etc. It's clearly > > possible to say it doesn't matter, only an old version, or only > > version at least as new as X.Y. It should be possible to do so for > > the Xorg stack as well. The ports that make up the stack can be > > kept in sync by having the old UMS stack ports pinned to the old > > version and new KMS stack held together by new_version+. For X apps > > and libraries, anything that needs old or new can specify it. > > Anything that does not say can be assumed to be Xorg=any. This > > would not be exactly how it is now. This would be manageable. As > > for the binary packages, I think it's solvable by depending on the > > proper library version, but don't quote me on that. > > Patches welcome! > In due time. This would be part of phase 2 (improving dependency handling). There might even be a better way, but this is what seems practical and logical at the moment. > > Perhaps I should have said the provided binary packages mean nothing > > for me. > > You are forgetting all other users, however. > It would be interesting to know what portion of the user base actually uses the provided binary packages. I know a few reasons to do so. One is for speeds of installation. Another is to be able to point to the project as the vendor when documenting compliance in certain industries. That aside, the real point is I don't mind compiling from ports to get the options I want and the version I want. Right now, anyone wanting KMS needs to do that. If the default changes, then anyone not wanting KMS has to do that. If the Xorg stack ports split, binary packages for both could be available. That would be an improvement from the current state for users of binary packages. The issue would then only be the binary packages for apps that depend on Xorg stack, which is not unsolvable but something I personally am not motivated to do anything about. > >> > > The lack of testing capacity is one more reason to carefully > > preserve the UMS Xorg stack in a usable and easily obtainable state > > before we go too much deeper into KMS territory. > > Except that we lack important hardware support with the UMS stack, so > we can't stay there forever. Not to mention that this prevents us > from updates in other areas. > Difference of perspective. If new hardware isn't supported, I hold off on buying it. If the hardware I have looses support, then something that was working becomes "broken" and that is a regression in functionality. > > > Of course a University, with it's IT staff dedicated to the task, > > can manage to maintain a group of UNIX desktops/workstations with > > Linux and *BSD just as they had done with the proprietary UNIX > > workstations of the past. The little rant I put after the meat of > > my post was more about home and small business users without the > > support staff dedicated to such efforts. If it's hard for me to > > maintain my own personal systems, it's nearly impossible for the > > non-technical users. How many years has one of the major industry > > magazines run a "Is this the year of the Linux desktop?" cover > > story? I've been seeing at least one a year for no less than a > > decade. Each time there's a reason why THIS year will be THE year > > as opposed to all the others. They always miss the mark. Some > > businesses and governments have done Linux desktop projects and > > some have worked, but also some have not and they've gone back to > > Windows. For all those that went back, chances of them even giving > > Linux or another "UNIX desktop" (OS X aside) a try in the feature > > are slim to none. Once burned, twice shy. > > I manage my computers, no problem. Have you tried PC-BSD? They've > used the KMS enabled X by default for some time, and I think it works > there as well. I haven't tested myself though. > I tried PC-BSD on several occasions. I am not a fan of PBI, but they have made using ports with it easier than it used to be. The last time I tried PC-BSD, it was the version handed out at EuroBSDcon last year and it initially came up in vesa mode on my laptop. The ati/radeon driver (which was autodetected as the best option) would not work at all as it was apparently too new and I just got errors about not being able to invoke KMS mode. The radeonhd driver was also given as an option but did not have working DRI. I managed to get DRI working by patching and recompiling the driver. I found a bugfix for the particular chipset in my laptop sitting to rot in some repo at suse IIRC. The fix was committed to their repo, but the last official release of the radeonhd driver was prior to the commit, and without an official release that fix never got carried over from Linux. I dropped a link on IRC at the time but I did not check to see if anyone committed the patch to the radeonhd driver on FreeBSD. I also had problems with getting acceptable sound support since PC-BSD has everything going through PulseAudio, which is another whole bucket of worms. I played with it for a few weeks before deciding PC-BSD is still not for me. > > >> Remember also that FreeBSD, and the ports collection, including all > >> relevant software for this discussion (except the nVidia drivers) > >> are open source. Feel free to help out, experiment and send > >> patches, that's how we in the x11@ team ended up here. And while > >> it doesn't seem like much, some of us spend in excess of > >> 40hrs/week some weeks, to make all this work. > >> > > I think that we all understand this point. That is after all how we > > ended up here. Frustrated by vendors dropping support for the > > platforms we loved, or sabotaging the versions we enjoyed in an > > attempt to force us onto their vision of the future, is the reason > > we end up using open source software. If the original author drops > > it, so what? If it has value, the users who care can choose to > > continue on with it to the best of their abilities. Unfortunately > > for Xorg, the value is the apps that run on it more-so than the > > Xorg stack itself. That combined with the complexity limits the > > number of people willing to bury themselves in maintaining it at > > any version. It is not my ideal, but I would happily put > > 40+hours/week into it if doing so could keep food on my table, a > > roof over my head, and the lights on (ok, I can forgo lights, I > > just need the computers to stay on). A myriad of personal problems > > has meant that I haven't been able to do so much for Xorg/Mesa as > > I'm struggling enough to find sufficient paid work. If anyone wants > > to help change that, I'll commit to doing more for the community. > > Right now I must pick my battles carefully, meaning I can only put > > much time into advancing those aspects of my computing life that I > > depend on to do any paid work I can find, and that itself takes a > > back seat to simply finding suitable work to do. > > > > Most of us have a day job besides the 40 hrs/week we put into FreeBSD. > I know people are getting payed to work on FreeBSD, but most of the > work is still done by volunteers. I understand that not everyone can > do this, but keep in mind that everone working on FreeBSD, regardless > of which part, is doing their absolute best to make FreeBSD as good as > humanly possible. > I thank those who manage to work their day job and still donate their time to the project. I envy those whose day job is to work for the this or any similar open project. Most of the jobs I've had are unrelated, so all my efforts are on my own time as is the case for most everyone else. Recently, it's been hard to find jobs that can even pay the bills, forget directly supporting an open project or even leaving time on the side to do so. I was half joking/half serious in my comments, in that I don't expect it to come true, but if anyone wanted to throw money at this problem I'd happily tackle it on a faster timeline than what I foresee myself being able to do while living in the current state. > Regard! From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 16:38:57 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0EEECB63 for ; Fri, 30 Aug 2013 16:38:57 +0000 (UTC) (envelope-from gosha-necr@yandex.ru) Received: from forward18.mail.yandex.net (forward18.mail.yandex.net [IPv6:2a02:6b8:0:1402::3]) by mx1.freebsd.org (Postfix) with ESMTP id C09DB2133 for ; Fri, 30 Aug 2013 16:38:55 +0000 (UTC) Received: from web23g.yandex.ru (web23g.yandex.ru [95.108.253.232]) by forward18.mail.yandex.net (Yandex) with ESMTP id 0A3751780057 for ; Fri, 30 Aug 2013 20:38:52 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web23g.yandex.ru (Yandex) with ESMTP id 77D2C3990060; Fri, 30 Aug 2013 20:38:52 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1377880732; bh=y04FxKOgB5XPSeeRoX+5fOGWtr/9SYGasrXrbqTPOnE=; h=From:To:In-Reply-To:References:Subject:Date; b=Z5rDJMR+/JGJMARu3hnD2owdubQ2zTNWh5GDkM4KsZPYbc3aaKB4SJXtE5+9P3VIq FA8mo9Qc5CSst56KNiTjYdV1oYfMMmQJJE2y3awh2WYi0jHjChqPREQnYPQ+L4mMne JnqH4xyTm1ThsRbdgvg1jDZ63yMkNUYwgZCSCmoE= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web23g.yandex.ru with HTTP; Fri, 30 Aug 2013 20:38:51 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: "freebsd-x11@freebsd.org" In-Reply-To: <521C9D2A.4070001@FreeBSD.org> References: <521C9D2A.4070001@FreeBSD.org> Subject: [REPORT] AMD Radeon KMS on Asus X501U Message-Id: <423811377880731@web23g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 30 Aug 2013 22:38:51 +0600 X-Mailman-Approved-At: Fri, 30 Aug 2013 16:56:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:38:57 -0000 Hi! I'm tryin to test your work and thats my actions: 1. Installed 9.1-RELEASE 2. get -CURRENT sources with svnlite 3. edit kernel config (attached) 4. make buildworld && make kernel && reboot && mergemaster ..... 5. My resulted uname: FreeBSD TEST 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri Aug 30 05:39:14 CET 2013 root@TEST:/usr/obj/usr/src/sys/BSDSERV amd64 6. I'm go throught steps in WIKI 7. On last step (cd /home/my/graphics/dri && make install clean I get error (in the end) My comments: I have GCC (WITHOUT_CLANG=yes) My info ============== dmesg ====================== Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Fri Aug 30 05:39:14 CET 2013 root@TEST:/usr/obj/usr/src/sys/BSDSERV amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1647.04-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 1634295808 (1558 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130823/tbfadt-633) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xb0000000-0xbfffffff,0xfeb00000-0xfeb3ffff irq 18 at device 1.0 on pci0 hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 xhci0: mem 0xfeb48000-0xfeb49fff irq 18 at device 16.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 ahci0: port 0xf190-0xf197,0xf180-0xf183,0xf170-0xf177,0xf160-0xf163,0xf150-0xf15f mem 0xfeb4f000-0xfeb4f7ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ohci0: mem 0xfeb4e000-0xfeb4efff irq 18 at device 18.0 on pci0 usbus1 on ohci0 ehci0: mem 0xfeb4d000-0xfeb4d0ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 ohci1: mem 0xfeb4c000-0xfeb4cfff irq 18 at device 19.0 on pci0 usbus3 on ohci1 ehci1: mem 0xfeb4b000-0xfeb4b0ff irq 17 at device 19.2 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf100-0xf10f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 hdac1: mem 0xfeb40000-0xfeb43fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 sdhci_pci0: mem 0xfeb4a000-0xfeb4a0ff irq 16 at device 20.7 on pci0 sdhci_pci0: 1 slot(s) allocated pcib3: at device 21.0 on pci0 pci3: on pcib3 pcib4: at device 21.1 on pci0 pci6: on pcib4 re0: port 0xd000-0xd0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 17 at device 0.0 on pci6 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: ASPM disabled re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 30:85:a9:7a:08:93 pcib5: at device 21.3 on pci0 pci7: on pcib5 ath0: mem 0xfe900000-0xfe97ffff irq 19 at device 0.0 on pci7 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 150.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_throttle0: on cpu0 hwpstate0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 25 on hdaa1 pcm2: at nid 26 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: <0x1022> at usbus0 uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen4.1: at usbus4 uhub2: on usbus4 ugen3.1: at usbus3 uhub3: on usbus3 ugen2.1: at usbus2 uhub4: on usbus2 uhub0: 5 ports with 5 removable, self powered uhub3: 5 ports with 5 removable, self powered uhub1: 4 ports with 4 removable, self powered uhub4: 5 ports with 5 removable, self powered uhub2: 5 ports with 5 removable, self powered ugen4.2: at usbus4 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1647039318 Hz quality 800 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ada0a [rw]... ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called ============== pciconf -lvbce ================= hostb0@pci0:0:0:0: class=0x060000 card=0x15101022 chip=0x15101022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 14h Processor Root Complex' class = bridge subclass = HOST-PCI vgapci0@pci0:0:1:0: class=0x030000 card=0x14b71043 chip=0x98061002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'Wrestler [Radeon HD 6320]' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0xb0000000, size 268435456, enabled bar [14] = type I/O Port, range 32, base 0xf000, size 256, enabled bar [18] = type Memory, range 32, base 0xfeb00000, size 262144, enabled cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[58] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 05[a0] = MSI supports 1 message, 64 bit ecap 000b[100] = Vendor 1 ID 1 PCI-e errors = Non-Fatal Error Detected Unsupported Request Detected hdac0@pci0:0:1:1: class=0x040300 card=0x13141002 chip=0x13141002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'Wrestler HDMI Audio [Radeon HD 6250/6310]' class = multimedia subclass = HDA bar [10] = type Memory, range 32, base 0xfeb44000, size 16384, enabled cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[58] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 05[a0] = MSI supports 1 message, 64 bit enabled with 1 message ecap 000b[100] = Vendor 1 ID 1 PCI-e errors = Non-Fatal Error Detected Unsupported Request Detected pcib1@pci0:0:4:0: class=0x060400 card=0x12341022 chip=0x15121022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 14h Processor Root Port' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port slot max data 128(128) link x16(x2) speed undef(2.5) ASPM disabled(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x12341022 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ecap 000b[100] = Vendor 1 ID 1 xhci0@pci0:0:16:0: class=0x0c0330 card=0x14b71043 chip=0x78121022 rev=0x03 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson USB XHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0xfeb48000, size 8192, enabled cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[70] = MSI supports 8 messages, 64 bit enabled with 1 message cap 11[90] = MSI-X supports 8 messages Table in map 0x10[0x1000], PBA in map 0x10[0x1080] cap 10[a0] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) ecap 0018[100] = LTR 1 ahci0@pci0:0:17:0: class=0x010601 card=0x14b71043 chip=0x78011022 rev=0x40 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson SATA Controller [AHCI mode]' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xf190, size 8, enabled bar [14] = type I/O Port, range 32, base 0xf180, size 4, enabled bar [18] = type I/O Port, range 32, base 0xf170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xf160, size 4, enabled bar [20] = type I/O Port, range 32, base 0xf150, size 16, enabled bar [24] = type Memory, range 32, base 0xfeb4f000, size 2048, enabled cap 05[50] = MSI supports 4 messages, 64 bit enabled with 1 message cap 12[70] = SATA Index-Data Pair ohci0@pci0:0:18:0: class=0x0c0310 card=0x14b71043 chip=0x78071022 rev=0x11 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson USB OHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb4e000, size 4096, enabled ehci0@pci0:0:18:2: class=0x0c0320 card=0x14b71043 chip=0x78081022 rev=0x11 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson USB EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb4d000, size 256, enabled cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 ohci1@pci0:0:19:0: class=0x0c0310 card=0x14b71043 chip=0x78071022 rev=0x11 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson USB OHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb4c000, size 4096, enabled ehci1@pci0:0:19:2: class=0x0c0320 card=0x14b71043 chip=0x78081022 rev=0x11 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson USB EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb4b000, size 256, enabled cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 none0@pci0:0:20:0: class=0x0c0500 card=0x14b71043 chip=0x780b1022 rev=0x14 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson SMBus Controller' class = serial bus subclass = SMBus atapci0@pci0:0:20:1: class=0x01018a card=0x14b71043 chip=0x780c1022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0xf100, size 16, enabled hdac1@pci0:0:20:2: class=0x040300 card=0x14b71043 chip=0x780d1022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson Azalia Controller' class = multimedia subclass = HDA bar [10] = type Memory, range 64, base 0xfeb40000, size 16384, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 isab0@pci0:0:20:3: class=0x060100 card=0x14b71043 chip=0x780e1022 rev=0x11 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson LPC Bridge' class = bridge subclass = PCI-ISA pcib2@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x780f1022 rev=0x40 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson PCI Bridge' class = bridge subclass = PCI-PCI sdhci_pci0@pci0:0:20:7: class=0x080501 card=0x14b71043 chip=0x78061022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson SD Flash Controller' class = base peripheral subclass = SD host controller bar [10] = type Memory, range 64, base 0xfeb4a000, size 256, enabled pcib3@pci0:0:21:0: class=0x060400 card=0x00001022 chip=0x43a01022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson PCI to PCI bridge (PCIE port 0)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[58] = PCI-Express 2 root port slot max data 128(128) link x16(x1) speed undef(5.0) ASPM disabled(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x00001022 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ecap 000b[100] = Vendor 1 ID 1 pcib4@pci0:0:21:1: class=0x060400 card=0x00001022 chip=0x43a11022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson PCI to PCI bridge (PCIE port 1)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) speed 2.5(5.0) ASPM L0s/L1(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x00001022 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ecap 000b[100] = Vendor 1 ID 1 pcib5@pci0:0:21:3: class=0x060400 card=0x00001022 chip=0x43a31022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson PCI to PCI bridge (PCIE port 3)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) speed 2.5(5.0) ASPM L0s/L1(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x00001022 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ecap 000b[100] = Vendor 1 ID 1 hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x17001022 rev=0x43 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 0' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x17011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 1' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x17021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 2' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x17031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 3' class = bridge subclass = HOST-PCI cap 0f[f0] = unknown hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x17041022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 4' class = bridge subclass = HOST-PCI hostb6@pci0:0:24:5: class=0x060000 card=0x00000000 chip=0x17181022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 6' class = bridge subclass = HOST-PCI hostb7@pci0:0:24:6: class=0x060000 card=0x00000000 chip=0x17161022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 5' class = bridge subclass = HOST-PCI hostb8@pci0:0:24:7: class=0x060000 card=0x00000000 chip=0x17191022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 7' class = bridge subclass = HOST-PCI re0@pci0:6:0:0: class=0x020000 card=0x14b71043 chip=0x816810ec rev=0x07 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xd000, size 256, enabled bar [18] = type Prefetchable Memory, range 64, base 0xd0004000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xd0000000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 01000000684ce000 ath0@pci0:7:0:0: class=0x028000 card=0x2c971a3b chip=0x0032168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9485 Wireless Network Adapter' class = network bar [10] = type Memory, range 64, base 0xfe900000, size 524288, enabled cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 4 messages, 64 bit, vector masks cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ASPM L0s/L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0000000000000000 PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error ============== devinfo -vr ================= nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9e7ff 0x100000-0x6556bfff 0x65cd9000-0x65cd9fff 0x65ce1000-0x660f1fff 0x663f3000-0x663fffff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x63 0x65 0x67-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x240-0x259 0x40b 0x4d0-0x4d1 0x4d6 0x800-0x89f 0x900-0x90f 0x910-0x91f 0xc00-0xc01 0xc14 0xc50-0xc51 0xc52 0xc6c 0xc6f 0xcd0-0xcd1 0xcd2-0xcd3 0xcd4-0xcd5 0xcd6-0xcd7 0xcd8-0xcdf 0xfe00-0xfefe I/O memory addresses: 0x67000000-0x7effffff 0xe0000000-0xefffffff 0xfec00000-0xfec00fff 0xfec10000-0xfec10fff 0xfed00000-0xfed00fff 0xfed61000-0xfed70fff 0xfed80000-0xfed8ffff 0xfee00000-0xfee00fff 0xff000000-0xffffffff acpi_ec0 pnpinfo _HID=PNP0C09 _UID=0 at handle=\_SB_.PCI0.SBRG.EC0_ I/O ports: 0x62 0x66 cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000 I/O ports: 0x1771 acpi_throttle0 ACPI I/O ports: 0x810-0x813 acpi_perf0 hwpstate0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.P001 acpi_throttle1 acpi_perf1 hwpstate1 pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x1022 device=0x1510 subvendor=0x1022 subdevice=0x1510 class=0x060000 at slot=0 function=0 handle=\_SB_.PCI0.GNBD vgapci0 pnpinfo vendor=0x1002 device=0x9806 subvendor=0x1043 subdevice=0x14b7 class=0x030000 at slot=1 function=0 handle=\_SB_.PCI0.VGA_ I/O ports: 0xf000-0xf0ff I/O memory addresses: 0xb0000000-0xbfffffff 0xfeb00000-0xfeb3ffff drm0 drmn0 hdac0 pnpinfo vendor=0x1002 device=0x1314 subvendor=0x1002 subdevice=0x1314 class=0x040300 at slot=1 function=1 Interrupt request lines: 256 I/O memory addresses: 0xfeb44000-0xfeb47fff hdacc0 pnpinfo vendor=0x1002 device=0xaa01 revision=0x02 stepping=0x00 at cad=0 hdaa0 pnpinfo type=0x01 subsystem=0x00aa0100 at nid=1 pcm0 at nid=3 pcib1 pnpinfo vendor=0x1022 device=0x1512 subvendor=0x1022 subdevice=0x1234 class=0x060400 at slot=4 function=0 handle=\_SB_.PCI0.BR14 pci1 xhci0 pnpinfo vendor=0x1022 device=0x7812 subvendor=0x1043 subdevice=0x14b7 class=0x0c0330 at slot=16 function=0 handle=\_SB_.PCI0.XHC0 Interrupt request lines: 257 I/O memory addresses: 0xfeb48000-0xfeb49fff usbus0 uhub1 ahci0 pnpinfo vendor=0x1022 device=0x7801 subvendor=0x1043 subdevice=0x14b7 class=0x010601 at slot=17 function=0 handle=\_SB_.PCI0.SATA Interrupt request lines: 258 I/O ports: 0xf150-0xf15f 0xf160-0xf163 0xf170-0xf177 0xf180-0xf183 0xf190-0xf197 I/O memory addresses: 0xfeb4f000-0xfeb4f7ff ahcich0 at channel=0 I/O memory addresses: 0xfeb4f100-0xfeb4f17f ohci0 pnpinfo vendor=0x1022 device=0x7807 subvendor=0x1043 subdevice=0x14b7 class=0x0c0310 at slot=18 function=0 handle=\_SB_.PCI0.OHC1 Interrupt request lines: 18 I/O memory addresses: 0xfeb4e000-0xfeb4efff usbus1 uhub0 ehci0 pnpinfo vendor=0x1022 device=0x7808 subvendor=0x1043 subdevice=0x14b7 class=0x0c0320 at slot=18 function=2 handle=\_SB_.PCI0.EHC1 Interrupt request lines: 17 I/O memory addresses: 0xfeb4d000-0xfeb4d0ff usbus2 uhub4 ohci1 pnpinfo vendor=0x1022 device=0x7807 subvendor=0x1043 subdevice=0x14b7 class=0x0c0310 at slot=19 function=0 handle=\_SB_.PCI0.OHC2 Interrupt request lines: 18 I/O memory addresses: 0xfeb4c000-0xfeb4cfff usbus3 uhub3 ehci1 pnpinfo vendor=0x1022 device=0x7808 subvendor=0x1043 subdevice=0x14b7 class=0x0c0320 at slot=19 function=2 handle=\_SB_.PCI0.EHC2 Interrupt request lines: 17 I/O memory addresses: 0xfeb4b000-0xfeb4b0ff usbus4 uhub2 unknown pnpinfo vendor=0x1022 device=0x780b subvendor=0x1043 subdevice=0x14b7 class=0x0c0500 at slot=20 function=0 atapci0 pnpinfo vendor=0x1022 device=0x780c subvendor=0x1043 subdevice=0x14b7 class=0x01018a at slot=20 function=1 handle=\_SB_.PCI0.IDEC I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xf100-0xf10f ata0 at channel=0 Interrupt request lines: 14 ata1 at channel=1 Interrupt request lines: 15 hdac1 pnpinfo vendor=0x1022 device=0x780d subvendor=0x1043 subdevice=0x14b7 class=0x040300 at slot=20 function=2 handle=\_SB_.PCI0.SBAZ Interrupt request lines: 16 I/O memory addresses: 0xfeb40000-0xfeb43fff hdacc1 pnpinfo vendor=0x10ec device=0x0270 revision=0x01 stepping=0x00 at cad=0 hdaa1 pnpinfo type=0x01 subsystem=0x104314b7 at nid=1 pcm1 at nid=20,25 pcm2 at nid=26 isab0 pnpinfo vendor=0x1022 device=0x780e subvendor=0x1043 subdevice=0x14b7 class=0x060100 at slot=20 function=3 handle=\_SB_.PCI0.SBRG isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff fdc0 ppc0 uart0 uart1 wbwd0 pcib2 pnpinfo vendor=0x1022 device=0x780f subvendor=0x0000 subdevice=0x0000 class=0x060401 at slot=20 function=4 pci2 sdhci_pci0 pnpinfo vendor=0x1022 device=0x7806 subvendor=0x1043 subdevice=0x14b7 class=0x080501 at slot=20 function=7 Interrupt request lines: 16 I/O memory addresses: 0xfeb4a000-0xfeb4a0ff pcib3 pnpinfo vendor=0x1022 device=0x43a0 subvendor=0x1022 subdevice=0x0000 class=0x060400 at slot=21 function=0 handle=\_SB_.PCI0.PE20 I/O ports: 0xe000-0xefff I/O memory addresses: 0xc0000000-0xcfffffff 0xfea00000-0xfeafffff pci3 pcib4 pnpinfo vendor=0x1022 device=0x43a1 subvendor=0x1022 subdevice=0x0000 class=0x060400 at slot=21 function=1 handle=\_SB_.PCI0.PE21 I/O ports: 0xd000-0xdfff I/O memory addresses: 0xd0000000-0xd00fffff pci6 re0 pnpinfo vendor=0x10ec device=0x8168 subvendor=0x1043 subdevice=0x14b7 class=0x020000 at slot=0 function=0 handle=\_SB_.PCI0.PE21.GLAN Interrupt request lines: 259 pcib4 I/O port window: 0xd000-0xd0ff pcib4 prefetch window: 0xd0000000-0xd0003fff 0xd0004000-0xd0004fff miibus0 rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x5 at phyno=1 pcib5 pnpinfo vendor=0x1022 device=0x43a3 subvendor=0x1022 subdevice=0x0000 class=0x060400 at slot=21 function=3 handle=\_SB_.PCI0.PE23 I/O memory addresses: 0xfe900000-0xfe9fffff pci7 ath0 pnpinfo vendor=0x168c device=0x0032 subvendor=0x1a3b subdevice=0x2c97 class=0x028000 at slot=0 function=0 Interrupt request lines: 19 pcib5 memory window: 0xfe900000-0xfe97ffff hostb1 pnpinfo vendor=0x1022 device=0x1700 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=0 hostb2 pnpinfo vendor=0x1022 device=0x1701 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=1 hostb3 pnpinfo vendor=0x1022 device=0x1702 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=2 hostb4 pnpinfo vendor=0x1022 device=0x1703 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=3 hostb5 pnpinfo vendor=0x1022 device=0x1704 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=4 hostb6 pnpinfo vendor=0x1022 device=0x1718 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=5 hostb7 pnpinfo vendor=0x1022 device=0x1716 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=6 hostb8 pnpinfo vendor=0x1022 device=0x1719 subvendor=0x0000 subdevice=0x0000 class=0x060000 at slot=24 function=7 acpi_sysresource0 pnpinfo _HID=PNP0C01 _UID=200 at handle=\_SB_.PCI0.AMDN acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=1792 at handle=\_SB_.PCI0.SBRG.S900 unknown pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.SBRG.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.SBRG.DMAD DMA request lines: 4 I/O ports: 0x0-0xf 0x81-0x83 0x87 0x89-0x8b 0x8f 0xc0-0xdf attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.SBRG.TMR_ Interrupt request lines: 0 I/O ports: 0x40-0x43 atrtc0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.SBRG.RTC0 Interrupt request lines: 8 I/O ports: 0x70-0x71 unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.SBRG.SPKR I/O ports: 0x61 acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=16 at handle=\_SB_.PCI0.SBRG.RMSC fpupnp0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.SBRG.COPR I/O ports: 0xf0-0xff acpi_sysresource3 pnpinfo _HID=PNP0C02 _UID=153 at handle=\_SB_.PCI0.SBRG.NBRM acpi_sysresource4 pnpinfo _HID=PNP0C02 _UID=19 at handle=\_SB_.PCI0.SBRG.ADBG psmcpnp0 pnpinfo _HID=ETD0108 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2M atkbdc0 pnpinfo _HID=ATK3001 _UID=0 at handle=\_SB_.PCI0.SBRG.PS2K Interrupt request lines: 1 I/O ports: 0x60 0x64 atkbd0 psm0 Interrupt request lines: 12 unknown pnpinfo _HID=PNP0C09 _UID=0 at handle=\_SB_.PCI0.SBRG.EC0_ acpi_sysresource5 pnpinfo _HID=PNP0C02 _UID=20 at handle=\_SB_.PCI0.GNBD.BROD unknown pnpinfo _HID=AFD0001 _UID=0 at handle=\_SB_.PCI0.AFD_ acpi_acad0 pnpinfo _HID=ACPI0003 _UID=0 at handle=\_SB_.PCI0.AC0_ battery0 pnpinfo _HID=PNP0C0A _UID=0 at handle=\_SB_.PCI0.BAT0 acpi_button0 pnpinfo _HID=PNP0C0C _UID=170 at handle=\_SB_.PWRB pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKH acpi_sysresource6 pnpinfo _HID=PNP0C01 _UID=1 at handle=\_SB_.RMEM unknown pnpinfo _HID=PNP0C14 _UID=0 at handle=\_SB_.ATKD unknown pnpinfo _HID=ATK4001 _UID=0 at handle=\_SB_.ASHS acpi_lid0 pnpinfo _HID=PNP0C0D _UID=0 at handle=\_SB_.LID_ acpi_button1 pnpinfo _HID=PNP0C0E _UID=0 at handle=\_SB_.SLPB acpi_tz0 pnpinfo _HID=none _UID=0 at handle=\_TZ_.THRM hpet0 pnpinfo _HID=PNP0103 _UID=0 at handle=\HPET ACPI I/O memory addresses: 0xfed00000-0xfed003ff acpi_sysresource7 pnpinfo _HID=PNP0C02 _UID=3601 at handle=\OMSC acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x808-0x80b ============== pkg info ================= autoconf-2.69 Automatically configure source code on many Un*x platforms autoconf-wrapper-20130530 Wrapper script for GNU autoconf automake-1.14 GNU Standards-compliant Makefile generator automake-wrapper-20130530 Wrapper script for GNU automake bigreqsproto-1.1.2 BigReqs extension headers bison-2.7.1,1 A parser generator from FSF, (mostly) compatible with Yacc cairo-1.10.2_5,2 Vector graphics library with cross-device output support cmake-2.8.11.2 Cross-platform Makefile generator cmake-modules-2.8.11.2 Modules and Templates for CMake compositeproto-0.4.2 Composite extension headers consolekit-0.4.3 Framework for defining and tracking users damageproto-1.2.1 Damage extension headers db42-4.2.52_5 The Berkeley DB package, revision 4.2 dbus-1.6.12 A message bus system for inter-application communication dbus-glib-0.100.2 GLib bindings for the D-BUS messaging system dialog4ports-0.1.5_1 Console Interface to configure ports dmidecode-2.11 A tool for dumping DMI (SMBIOS) contents in human-readable format docbook-4.1_4 V4.1 of the DocBook DTD, designed for technical documentation docbook-xsl-1.76.1_1 XSL DocBook stylesheets dri2proto-2.8 DRI2 prototype headers evieext-1.1.1 XEVIE extension headers expat-2.1.0 XML 1.0 parser written in C fixesproto-5.0 Fixes extension headers fontconfig-2.10.93,1 An XML-based font configuration API for X Windows fontsproto-2.1.2 Fonts extension headers freetype2-2.4.12_1 A free and portable TrueType font rendering engine gettext-0.18.3 GNU gettext package glib-2.36.3 Some useful routines of C programming (current stable version) glproto-1.4.16 GLX extension headers gmake-3.82_1 GNU version of 'make' utility gnome_subr-1.0 Common startup and shutdown subroutines used by GNOME scripts gnomehier-3.0 A utility port that creates the GNOME directory tree gobject-introspection-1.36.0_2 Generate interface introspection data for GObject libraries hal-0.5.14_20 Hardware Abstraction Layer for simplifying device access help2man-1.43.3 Automatically generating simple manual pages from program output inputproto-2.3 Input extension headers intltool-0.50.2 Tools to internationalize various kinds of data files iso8879-1986_3 Character entity sets from ISO 8879:1986 (SGML) kbproto-1.0.6 KB extension headers libGL-9.1.6 OpenGL library that renders using GLX or DRI libICE-1.0.8,1 Inter Client Exchange library for X11 libSM-1.2.1,1 Session Management library for X11 libX11-1.6.1,1 X11 library libXau-1.0.8 Authentication Protocol library for X11 libXaw-1.0.11,2 X Athena Widgets library libXdamage-1.1.4 X Damage extension library libXdmcp-1.1.1 X Display Manager Control Protocol library libXext-1.3.2,1 X11 Extension library libXfixes-5.0.1 X Fixes extension library libXfont-1.4.6,1 X font library libXi-1.7.2,1 X Input extension library libXinerama-1.1.3,1 X11 Xinerama library libXmu-1.1.1,1 X Miscellaneous Utilities libraries libXp-1.0.2,1 X print library libXpm-3.5.10 X Pixmap library libXrender-0.9.8 X Render extension library libXt-1.1.4,1 X Toolkit library libXxf86misc-1.0.3 X XF86-Misc Extension libXxf86vm-1.1.3 X Vidmode Extension libcheck-0.9.10 Unit test framework for C libdrm-2.4.46 Userspace interface to kernel Direct Rendering Module services libexecinfo-1.1_3 A library for inspecting program's backtrace libffi-3.0.13 Foreign Function Interface libfontenc-1.1.2 The fontenc Library libgcrypt-1.5.3 General purpose crypto library based on code used in GnuPG libgpg-error-1.12 Common error values for all GnuPG components libiconv-1.14_1 A character set conversion library libpciaccess-0.13.2 Generic PCI access library libpthread-stubs-0.3_3 This library provides weak aliases for pthread functions libtool-2.4.2 Generic shared library support script libvolume_id-0.81.1 Library to provide file system type information libxcb-1.9.1 The X protocol C-language Binding (XCB) library libxkbfile-1.0.8 XKB file library libxkbui-1.0.2_1 The xkbui library libxml2-2.8.0_2 XML parser library for GNOME libxslt-1.1.28_1 The XSLT C library for GNOME llvm-3.3_3 Low Level Virtual Machine m4-1.4.16_1,1 GNU m4 makedepend-1.0.5,1 Dependency generator for makefiles nload-0.7.4 Console application which monitors network traffic in real time p5-Locale-gettext-1.05_3 Message handling functions p5-XML-Parser-2.41_1 Perl extension interface to James Clark's XML parser, expat pciids-20130823 Database of all known IDs used in PCI devices pcre-8.33 Perl Compatible Regular Expressions library perl-5.14.4 Practical Extraction and Report Language pixman-0.30.0 Low-level pixel manipulation library pkg-1.1.4_1 New generation package manager pkgconf-0.9.3 Utility to help to configure compiler and linker flags png-1.5.17 Library for manipulating PNG images policykit-0.9_6 Framework for controlling access to system-wide components polkit-0.105_1 Framework for controlling access to system-wide components printproto-1.0.5 Print extension headers py27-Babel-1.3 Collection of tools for internationalizing Python applications py27-Jinja2-2.7.1 Fast and easy to use stand-alone template engine py27-MarkupSafe-0.18 Implements a XML/HTML/XHTML Markup safe string for Python py27-distribute-0.6.35 Python packages installer and Setuptools replacement py27-docutils-0.11 Python Documentation Utilities py27-libxml2-2.8.0 Python interface for XML parser library for GNOME py27-pygments-1.6 Syntax highlighter written in Python py27-sphinx-1.1.3_1 Python documentation generator python-2.7_1,2 The "meta-port" for the default version of Python interpreter python2-2 The "meta-port" for version 2 of the Python interpreter python27-2.7.5_2 Interpreted object-oriented programming language randrproto-1.4.0 Randr extension headers recordproto-1.14.2 RECORD extension headers renderproto-0.11.1 RenderProto protocol headers resourceproto-1.2.0 Resource extension headers screen-4.0.3_14 A multi-screen window manager scrnsaverproto-1.2.2 ScrnSaver extension headers sqlite3-3.7.17_1 SQL database engine in a C library svnup-1.0 Lightweight program to pull source from an Apache Subversion server trapproto-3.4.3 DEC-XTRAP extension headers unzip-6.0_1 List, test, and extract compressed files in a ZIP archive v4l_compat-1.0.20120501_1 Video4Linux IOCTL header files videoproto-2.3.2 Video extension headers xcb-proto-1.8 The X protocol C-language Binding (XCB) protocol xcb-util-0.3.9_1,1 A module with libxcb/libX11 extension/replacement libraries xcb-util-renderutil-0.3.8 Convenience functions for the Render extension xcmiscproto-1.2.2 XCMisc extension headers xextproto-7.2.1 XExt extension headers xf86-video-ati-7.2.0 X.Org ati display driver xf86bigfontproto-1.2.0 XFree86-Bigfont extension headers xf86dgaproto-2.1 XFree86-DGA extension headers xf86driproto-2.1.1 XFree86-DRI extension headers xf86miscproto-0.9.3 XFree86-Misc extension headers xf86vidmodeproto-2.3.1 XFree86-VidModeExtension extension headers xineramaproto-1.2.1 Xinerama extension headers xkbcomp-1.2.4 Compile XKB keyboard description xkeyboard-config-2.9 X Keyboard Configuration Database xmlcatmgr-2.2 SGML and XML catalog manager xorg-macros-1.17 X.Org development aclocal macros xorg-server-1.12.4_1,1 X.Org X server and related programs xproto-7.0.24 X11 protocol headers xtrans-1.2.7 Abstract network code for X ============== ERROR on graphics/dri building ==================== CC brw_clip_unfilled.lo CC brw_clip_util.lo CC brw_context.lo CXX brw_cubemap_normalize.lo CC brw_curbe.lo CC brw_disasm.lo CC brw_draw.lo CC brw_draw_upload.lo CC brw_eu.lo CC brw_eu_compact.lo brw_eu_compact.c:44:4: error: invalid suffix "b00000000000000000" on integer constant brw_eu_compact.c:45:4: error: invalid suffix "b01000000000000000" on integer constant brw_eu_compact.c:46:4: error: invalid suffix "b00110000000000000" on integer constant brw_eu_compact.c:47:4: error: invalid suffix "b00000000100000000" on integer constant brw_eu_compact.c:48:4: error: invalid suffix "b00010000000000000" on integer constant brw_eu_compact.c:49:4: error: invalid suffix "b00001000100000000" on integer constant brw_eu_compact.c:50:4: error: invalid suffix "b00000000100000010" on integer constant brw_eu_compact.c:51:4: error: invalid suffix "b00000000000000010" on integer constant brw_eu_compact.c:52:4: error: invalid suffix "b01000000100000000" on integer constant brw_eu_compact.c:53:4: error: invalid suffix "b01010000000000000" on integer constant brw_eu_compact.c:54:4: error: invalid suffix "b10110000000000000" on integer constant brw_eu_compact.c:55:4: error: invalid suffix "b00100000000000000" on integer constant brw_eu_compact.c:56:4: error: invalid suffix "b11010000000000000" on integer constant brw_eu_compact.c:57:4: error: invalid suffix "b11000000000000000" on integer constant brw_eu_compact.c:58:4: error: invalid suffix "b01001000100000000" on integer constant brw_eu_compact.c:59:4: error: invalid suffix "b01000000000001000" on integer constant brw_eu_compact.c:60:4: error: invalid suffix "b01000000000000100" on integer constant brw_eu_compact.c:61:4: error: invalid suffix "b00000000000001000" on integer constant brw_eu_compact.c:62:4: error: invalid suffix "b00000000000000100" on integer constant brw_eu_compact.c:63:4: error: invalid suffix "b00111000100000000" on integer constant brw_eu_compact.c:64:4: error: invalid suffix "b00001000100000010" on integer constant brw_eu_compact.c:65:4: error: invalid suffix "b00110000100000000" on integer constant brw_eu_compact.c:66:4: error: invalid suffix "b00110000000000001" on integer constant brw_eu_compact.c:67:4: error: invalid suffix "b00100000000000001" on integer constant brw_eu_compact.c:68:4: error: invalid suffix "b00110000000000010" on integer constant brw_eu_compact.c:69:4: error: invalid suffix "b00110000000000101" on integer constant brw_eu_compact.c:70:4: error: invalid suffix "b00110000000001001" on integer constant brw_eu_compact.c:71:4: error: invalid suffix "b00110000000010000" on integer constant brw_eu_compact.c:72:4: error: invalid suffix "b00110000000000011" on integer constant brw_eu_compact.c:73:4: error: invalid suffix "b00110000000000100" on integer constant brw_eu_compact.c:74:4: error: invalid suffix "b00110000100001000" on integer constant brw_eu_compact.c:75:4: error: invalid suffix "b00100000000001001" on integer constant brw_eu_compact.c:79:4: error: invalid suffix "b001001110000000000" on integer constant brw_eu_compact.c:80:4: error: invalid suffix "b001000110000100000" on integer constant brw_eu_compact.c:81:4: error: invalid suffix "b001001110000000001" on integer constant brw_eu_compact.c:82:4: error: invalid suffix "b001000000001100000" on integer constant brw_eu_compact.c:83:4: error: invalid suffix "b001010110100101001" on integer constant brw_eu_compact.c:84:4: error: invalid suffix "b001000000110101101" on integer constant brw_eu_compact.c:85:4: error: invalid suffix "b001100011000101100" on integer constant brw_eu_compact.c:86:4: error: invalid suffix "b001011110110101101" on integer constant brw_eu_compact.c:87:4: error: invalid suffix "b001000000111101100" on integer constant brw_eu_compact.c:88:4: error: invalid suffix "b001000000001100001" on integer constant brw_eu_compact.c:89:4: error: invalid suffix "b001000110010100101" on integer constant brw_eu_compact.c:90:4: error: invalid suffix "b001000000001000001" on integer constant brw_eu_compact.c:91:4: error: invalid suffix "b001000001000110001" on integer constant brw_eu_compact.c:92:4: error: invalid suffix "b001000001000101001" on integer constant brw_eu_compact.c:93:4: error: invalid suffix "b001000000000100000" on integer constant brw_eu_compact.c:94:4: error: invalid suffix "b001000001000110010" on integer constant brw_eu_compact.c:95:4: error: invalid suffix "b001010010100101001" on integer constant brw_eu_compact.c:96:4: error: invalid suffix "b001011010010100101" on integer constant brw_eu_compact.c:97:4: error: invalid suffix "b001000000110100101" on integer constant brw_eu_compact.c:98:4: error: invalid suffix "b001100011000101001" on integer constant brw_eu_compact.c:99:4: error: invalid suffix "b001011011000101100" on integer constant brw_eu_compact.c:100:4: error: invalid suffix "b001011010110100101" on integer constant brw_eu_compact.c:101:4: error: invalid suffix "b001011110110100101" on integer constant brw_eu_compact.c:102:4: error: invalid suffix "b001111011110111101" on integer constant brw_eu_compact.c:103:4: error: invalid suffix "b001111011110111100" on integer constant brw_eu_compact.c:104:4: error: invalid suffix "b001111011110111101" on integer constant brw_eu_compact.c:105:4: error: invalid suffix "b001111011110011101" on integer constant brw_eu_compact.c:106:4: error: invalid suffix "b001111011110111110" on integer constant brw_eu_compact.c:107:4: error: invalid suffix "b001000000000100001" on integer constant brw_eu_compact.c:108:4: error: invalid suffix "b001000000000100010" on integer constant brw_eu_compact.c:109:4: error: invalid suffix "b001001111111011101" on integer constant brw_eu_compact.c:110:4: error: invalid suffix "b001000001110111110" on integer constant brw_eu_compact.c:114:4: error: invalid suffix "b000000000000000" on integer constant brw_eu_compact.c:115:4: error: invalid suffix "b000000000000100" on integer constant brw_eu_compact.c:116:4: error: invalid suffix "b000000110000000" on integer constant brw_eu_compact.c:117:4: error: invalid suffix "b111000000000000" on integer constant brw_eu_compact.c:118:4: error: invalid suffix "b011110000001000" on integer constant brw_eu_compact.c:119:4: error: invalid suffix "b000010000000000" on integer constant brw_eu_compact.c:120:4: error: invalid suffix "b000000000010000" on integer constant brw_eu_compact.c:121:4: error: invalid suffix "b000110000001100" on integer constant brw_eu_compact.c:122:4: error: invalid suffix "b001000000000000" on integer constant brw_eu_compact.c:123:4: error: invalid suffix "b000001000000000" on integer constant brw_eu_compact.c:124:4: error: invalid suffix "b000001010010100" on integer constant brw_eu_compact.c:125:4: error: invalid suffix "b000000001010110" on integer constant brw_eu_compact.c:126:4: error: invalid suffix "b010000000000000" on integer constant brw_eu_compact.c:127:4: error: invalid suffix "b110000000000000" on integer constant brw_eu_compact.c:128:4: error: invalid suffix "b000100000000000" on integer constant brw_eu_compact.c:129:4: error: invalid suffix "b000000010000000" on integer constant brw_eu_compact.c:130:4: error: invalid suffix "b000000000001000" on integer constant brw_eu_compact.c:131:4: error: invalid suffix "b100000000000000" on integer constant brw_eu_compact.c:132:4: error: invalid suffix "b000001010000000" on integer constant brw_eu_compact.c:133:4: error: invalid suffix "b001010000000000" on integer constant brw_eu_compact.c:134:4: error: invalid suffix "b001100000000000" on integer constant brw_eu_compact.c:135:4: error: invalid suffix "b000000001010100" on integer constant brw_eu_compact.c:136:4: error: invalid suffix "b101101010010100" on integer constant brw_eu_compact.c:137:4: error: invalid suffix "b010100000000000" on integer constant brw_eu_compact.c:138:4: error: invalid suffix "b000000010001111" on integer constant brw_eu_compact.c:139:4: error: invalid suffix "b011000000000000" on integer constant brw_eu_compact.c:140:4: error: invalid suffix "b111110000000000" on integer constant brw_eu_compact.c:141:4: error: invalid suffix "b101000000000000" on integer constant brw_eu_compact.c:142:4: error: invalid suffix "b000000000001111" on integer constant brw_eu_compact.c:143:4: error: invalid suffix "b000100010001111" on integer constant brw_eu_compact.c:144:4: error: invalid suffix "b001000010001111" on integer constant brw_eu_compact.c:145:4: error: invalid suffix "b000110000000000" on integer constant brw_eu_compact.c:149:4: error: invalid suffix "b000000000000" on integer constant brw_eu_compact.c:150:4: error: invalid suffix "b010110001000" on integer constant brw_eu_compact.c:151:4: error: invalid suffix "b010001101000" on integer constant brw_eu_compact.c:152:4: error: invalid suffix "b001000101000" on integer constant brw_eu_compact.c:153:4: error: invalid suffix "b011010010000" on integer constant brw_eu_compact.c:154:4: error: invalid suffix "b000100100000" on integer constant brw_eu_compact.c:155:4: error: invalid suffix "b010001101100" on integer constant brw_eu_compact.c:156:4: error: invalid suffix "b010101110000" on integer constant brw_eu_compact.c:157:4: error: invalid suffix "b011001111000" on integer constant brw_eu_compact.c:158:4: error: invalid suffix "b001100101000" on integer constant brw_eu_compact.c:159:4: error: invalid suffix "b010110001100" on integer constant brw_eu_compact.c:160:4: error: invalid suffix "b001000100000" on integer constant brw_eu_compact.c:161:4: error: invalid suffix "b010110001010" on integer constant brw_eu_compact.c:162:4: error: invalid suffix "b000000000010" on integer constant brw_eu_compact.c:163:4: error: invalid suffix "b010101010000" on integer constant brw_eu_compact.c:164:4: error: invalid suffix "b010101101000" on integer constant brw_eu_compact.c:165:4: error: invalid suffix "b111101001100" on integer constant brw_eu_compact.c:166:4: error: invalid suffix "b111100101100" on integer constant brw_eu_compact.c:167:4: error: invalid suffix "b011001110000" on integer constant brw_eu_compact.c:168:4: error: invalid suffix "b010110001001" on integer constant brw_eu_compact.c:169:4: error: invalid suffix "b010101011000" on integer constant brw_eu_compact.c:170:4: error: invalid suffix "b001101001000" on integer constant brw_eu_compact.c:171:4: error: invalid suffix "b010000101100" on integer constant brw_eu_compact.c:172:4: error: invalid suffix "b010000000000" on integer constant brw_eu_compact.c:173:4: error: invalid suffix "b001101110000" on integer constant brw_eu_compact.c:174:4: error: invalid suffix "b001100010000" on integer constant brw_eu_compact.c:175:4: error: invalid suffix "b001100000000" on integer constant brw_eu_compact.c:176:4: error: invalid suffix "b010001101010" on integer constant brw_eu_compact.c:177:4: error: invalid suffix "b001101111000" on integer constant brw_eu_compact.c:178:4: error: invalid suffix "b000001110000" on integer constant brw_eu_compact.c:179:4: error: invalid suffix "b001100100000" on integer constant brw_eu_compact.c:180:4: error: invalid suffix "b001101010000" on integer constant brw_eu_compact.c:184:4: error: invalid suffix "b0000000000000000010" on integer constant brw_eu_compact.c:185:4: error: invalid suffix "b0000100000000000000" on integer constant brw_eu_compact.c:186:4: error: invalid suffix "b0000100000000000001" on integer constant brw_eu_compact.c:187:4: error: invalid suffix "b0000100000000000010" on integer constant brw_eu_compact.c:188:4: error: invalid suffix "b0000100000000000011" on integer constant brw_eu_compact.c:189:4: error: invalid suffix "b0000100000000000100" on integer constant brw_eu_compact.c:190:4: error: invalid suffix "b0000100000000000101" on integer constant brw_eu_compact.c:191:4: error: invalid suffix "b0000100000000000111" on integer constant brw_eu_compact.c:192:4: error: invalid suffix "b0000100000000001000" on integer constant brw_eu_compact.c:193:4: error: invalid suffix "b0000100000000001001" on integer constant brw_eu_compact.c:194:4: error: invalid suffix "b0000100000000001101" on integer constant brw_eu_compact.c:195:4: error: invalid suffix "b0000110000000000000" on integer constant brw_eu_compact.c:196:4: error: invalid suffix "b0000110000000000001" on integer constant brw_eu_compact.c:197:4: error: invalid suffix "b0000110000000000010" on integer constant brw_eu_compact.c:198:4: error: invalid suffix "b0000110000000000011" on integer constant brw_eu_compact.c:199:4: error: invalid suffix "b0000110000000000100" on integer constant brw_eu_compact.c:200:4: error: invalid suffix "b0000110000000000101" on integer constant brw_eu_compact.c:201:4: error: invalid suffix "b0000110000000000111" on integer constant brw_eu_compact.c:202:4: error: invalid suffix "b0000110000000001001" on integer constant brw_eu_compact.c:203:4: error: invalid suffix "b0000110000000001101" on integer constant brw_eu_compact.c:204:4: error: invalid suffix "b0000110000000010000" on integer constant brw_eu_compact.c:205:4: error: invalid suffix "b0000110000100000000" on integer constant brw_eu_compact.c:206:4: error: invalid suffix "b0001000000000000000" on integer constant brw_eu_compact.c:207:4: error: invalid suffix "b0001000000000000010" on integer constant brw_eu_compact.c:208:4: error: invalid suffix "b0001000000000000100" on integer constant brw_eu_compact.c:209:4: error: invalid suffix "b0001000000100000000" on integer constant brw_eu_compact.c:210:4: error: invalid suffix "b0010110000000000000" on integer constant brw_eu_compact.c:211:4: error: invalid suffix "b0010110000000010000" on integer constant brw_eu_compact.c:212:4: error: invalid suffix "b0011000000000000000" on integer constant brw_eu_compact.c:213:4: error: invalid suffix "b0011000000100000000" on integer constant brw_eu_compact.c:214:4: error: invalid suffix "b0101000000000000000" on integer constant brw_eu_compact.c:215:4: error: invalid suffix "b0101000000100000000" on integer constant brw_eu_compact.c:219:4: error: invalid suffix "b001000000000000001" on integer constant brw_eu_compact.c:220:4: error: invalid suffix "b001000000000100000" on integer constant brw_eu_compact.c:221:4: error: invalid suffix "b001000000000100001" on integer constant brw_eu_compact.c:222:4: error: invalid suffix "b001000000001100001" on integer constant brw_eu_compact.c:223:4: error: invalid suffix "b001000000010111101" on integer constant brw_eu_compact.c:224:4: error: invalid suffix "b001000001011111101" on integer constant brw_eu_compact.c:225:4: error: invalid suffix "b001000001110100001" on integer constant brw_eu_compact.c:226:4: error: invalid suffix "b001000001110100101" on integer constant brw_eu_compact.c:227:4: error: invalid suffix "b001000001110111101" on integer constant brw_eu_compact.c:228:4: error: invalid suffix "b001000010000100001" on integer constant brw_eu_compact.c:229:4: error: invalid suffix "b001000110000100000" on integer constant brw_eu_compact.c:230:4: error: invalid suffix "b001000110000100001" on integer constant brw_eu_compact.c:231:4: error: invalid suffix "b001001010010100101" on integer constant brw_eu_compact.c:232:4: error: invalid suffix "b001001110010100100" on integer constant brw_eu_compact.c:233:4: error: invalid suffix "b001001110010100101" on integer constant brw_eu_compact.c:234:4: error: invalid suffix "b001111001110111101" on integer constant brw_eu_compact.c:235:4: error: invalid suffix "b001111011110011101" on integer constant brw_eu_compact.c:236:4: error: invalid suffix "b001111011110111100" on integer constant brw_eu_compact.c:237:4: error: invalid suffix "b001111011110111101" on integer constant brw_eu_compact.c:238:4: error: invalid suffix "b001111111110111100" on integer constant brw_eu_compact.c:239:4: error: invalid suffix "b000000001000001100" on integer constant brw_eu_compact.c:240:4: error: invalid suffix "b001000000000111101" on integer constant brw_eu_compact.c:241:4: error: invalid suffix "b001000000010100101" on integer constant brw_eu_compact.c:242:4: error: invalid suffix "b001000010000100000" on integer constant brw_eu_compact.c:243:4: error: invalid suffix "b001001010010100100" on integer constant brw_eu_compact.c:244:4: error: invalid suffix "b001001110010000100" on integer constant brw_eu_compact.c:245:4: error: invalid suffix "b001010010100001001" on integer constant brw_eu_compact.c:246:4: error: invalid suffix "b001101111110111101" on integer constant brw_eu_compact.c:247:4: error: invalid suffix "b001111111110111101" on integer constant brw_eu_compact.c:248:4: error: invalid suffix "b001011110110101100" on integer constant brw_eu_compact.c:249:4: error: invalid suffix "b001010010100101000" on integer constant brw_eu_compact.c:250:4: error: invalid suffix "b001010110100101000" on integer constant brw_eu_compact.c:254:4: error: invalid suffix "b000000000000000" on integer constant brw_eu_compact.c:255:4: error: invalid suffix "b000000000000001" on integer constant brw_eu_compact.c:256:4: error: invalid suffix "b000000000001000" on integer constant brw_eu_compact.c:257:4: error: invalid suffix "b000000000001111" on integer constant brw_eu_compact.c:258:4: error: invalid suffix "b000000000010000" on integer constant brw_eu_compact.c:259:4: error: invalid suffix "b000000010000000" on integer constant brw_eu_compact.c:260:4: error: invalid suffix "b000000100000000" on integer constant brw_eu_compact.c:261:4: error: invalid suffix "b000000110000000" on integer constant brw_eu_compact.c:262:4: error: invalid suffix "b000001000000000" on integer constant brw_eu_compact.c:263:4: error: invalid suffix "b000001000010000" on integer constant brw_eu_compact.c:264:4: error: invalid suffix "b000010100000000" on integer constant brw_eu_compact.c:265:4: error: invalid suffix "b001000000000000" on integer constant brw_eu_compact.c:266:4: error: invalid suffix "b001000000000001" on integer constant brw_eu_compact.c:267:4: error: invalid suffix "b001000010000001" on integer constant brw_eu_compact.c:268:4: error: invalid suffix "b001000010000010" on integer constant brw_eu_compact.c:269:4: error: invalid suffix "b001000010000011" on integer constant brw_eu_compact.c:270:4: error: invalid suffix "b001000010000100" on integer constant brw_eu_compact.c:271:4: error: invalid suffix "b001000010000111" on integer constant brw_eu_compact.c:272:4: error: invalid suffix "b001000010001000" on integer constant brw_eu_compact.c:273:4: error: invalid suffix "b001000010001110" on integer constant brw_eu_compact.c:274:4: error: invalid suffix "b001000010001111" on integer constant brw_eu_compact.c:275:4: error: invalid suffix "b001000110000000" on integer constant brw_eu_compact.c:276:4: error: invalid suffix "b001000111101000" on integer constant brw_eu_compact.c:277:4: error: invalid suffix "b010000000000000" on integer constant brw_eu_compact.c:278:4: error: invalid suffix "b010000110000000" on integer constant brw_eu_compact.c:279:4: error: invalid suffix "b011000000000000" on integer constant brw_eu_compact.c:280:4: error: invalid suffix "b011110010000111" on integer constant brw_eu_compact.c:281:4: error: invalid suffix "b100000000000000" on integer constant brw_eu_compact.c:282:4: error: invalid suffix "b101000000000000" on integer constant brw_eu_compact.c:283:4: error: invalid suffix "b110000000000000" on integer constant brw_eu_compact.c:284:4: error: invalid suffix "b111000000000000" on integer constant brw_eu_compact.c:285:4: error: invalid suffix "b111000000011100" on integer constant brw_eu_compact.c:289:4: error: invalid suffix "b000000000000" on integer constant brw_eu_compact.c:290:4: error: invalid suffix "b000000000010" on integer constant brw_eu_compact.c:291:4: error: invalid suffix "b000000010000" on integer constant brw_eu_compact.c:292:4: error: invalid suffix "b000000010010" on integer constant brw_eu_compact.c:293:4: error: invalid suffix "b000000011000" on integer constant brw_eu_compact.c:294:4: error: invalid suffix "b000000100000" on integer constant brw_eu_compact.c:295:4: error: invalid suffix "b000000101000" on integer constant brw_eu_compact.c:296:4: error: invalid suffix "b000001001000" on integer constant brw_eu_compact.c:297:4: error: invalid suffix "b000001010000" on integer constant brw_eu_compact.c:298:4: error: invalid suffix "b000001110000" on integer constant brw_eu_compact.c:299:4: error: invalid suffix "b000001111000" on integer constant brw_eu_compact.c:300:4: error: invalid suffix "b001100000000" on integer constant brw_eu_compact.c:301:4: error: invalid suffix "b001100000010" on integer constant brw_eu_compact.c:302:4: error: invalid suffix "b001100001000" on integer constant brw_eu_compact.c:303:4: error: invalid suffix "b001100010000" on integer constant brw_eu_compact.c:304:4: error: invalid suffix "b001100010010" on integer constant brw_eu_compact.c:305:4: error: invalid suffix "b001100100000" on integer constant brw_eu_compact.c:306:4: error: invalid suffix "b001100101000" on integer constant brw_eu_compact.c:307:4: error: invalid suffix "b001100111000" on integer constant brw_eu_compact.c:308:4: error: invalid suffix "b001101000000" on integer constant brw_eu_compact.c:309:4: error: invalid suffix "b001101000010" on integer constant brw_eu_compact.c:310:4: error: invalid suffix "b001101001000" on integer constant brw_eu_compact.c:311:4: error: invalid suffix "b001101010000" on integer constant brw_eu_compact.c:312:4: error: invalid suffix "b001101100000" on integer constant brw_eu_compact.c:313:4: error: invalid suffix "b001101101000" on integer constant brw_eu_compact.c:314:4: error: invalid suffix "b001101110000" on integer constant brw_eu_compact.c:315:4: error: invalid suffix "b001101110001" on integer constant brw_eu_compact.c:316:4: error: invalid suffix "b001101111000" on integer constant brw_eu_compact.c:317:4: error: invalid suffix "b010001101000" on integer constant brw_eu_compact.c:318:4: error: invalid suffix "b010001101001" on integer constant brw_eu_compact.c:319:4: error: invalid suffix "b010001101010" on integer constant brw_eu_compact.c:320:4: error: invalid suffix "b010110001000" on integer constant gmake[7]: *** [brw_eu_compact.lo] 1 gmake[7]: `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa/drivers/dri/ i965' gmake[6]: *** [all-recursive] 1 gmake[6]: `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa/drivers/dri' gmake[5]: *** [all-recursive] 1 gmake[5]: `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa/drivers' gmake[4]: *** [all-recursive] 1 gmake[4]: `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa' gmake[3]: *** [all] 2 gmake[3]: `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa' gmake[2]: *** [all-recursive] 1 gmake[2]: `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src' gmake[1]: *** [all-recursive] 1 gmake[1]: `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6' *** Error code 1 Stop. make: stopped in /usr/home/goshanecr/graphics/dri From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 17:54:30 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F0A4A35 for ; Fri, 30 Aug 2013 17:54:30 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 055E8253E for ; Fri, 30 Aug 2013 17:54:28 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A208D40011 for ; Fri, 30 Aug 2013 19:54:25 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 9783640012; Fri, 30 Aug 2013 19:54:25 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 3117240011; Fri, 30 Aug 2013 19:54:23 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRSxV6Mhlz8hVn; Fri, 30 Aug 2013 19:54:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id ZRB1qUH9CIAX; Fri, 30 Aug 2013 19:54:19 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRSxR642hz8hVm; Fri, 30 Aug 2013 19:54:19 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cRSxR4CRZz9Ctj; Fri, 30 Aug 2013 19:54:19 +0200 (CEST) Message-ID: <5220DC43.2060300@daemonic.se> Date: Fri, 30 Aug 2013 19:54:11 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: =?UTF-8?B?0JPRg9C70Y/QtdCyINCT0L7RiNCw?= Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> In-Reply-To: <423811377880731@web23g.yandex.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "freebsd-x11@freebsd.org" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 17:54:30 -0000 On 08/30/13 18:38, Гуляев Гоша wrote: > Hi! > > I'm tryin to test your work and thats my actions: [SNIP] > integer constant > brw_eu_compact.c:316:4: error: invalid suffix "b001101111000" on > integer constant > brw_eu_compact.c:317:4: error: invalid suffix "b010001101000" on > integer constant > brw_eu_compact.c:318:4: error: invalid suffix "b010001101001" on > integer constant > brw_eu_compact.c:319:4: error: invalid suffix "b010001101010" on > integer constant > brw_eu_compact.c:320:4: error: invalid suffix "b010110001000" on > integer constant > gmake[7]: *** [brw_eu_compact.lo] Ошибка 1 > gmake[7]: Выход из каталога > `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa/drivers/dri/ > i965' > gmake[6]: *** [all-recursive] Ошибка 1 > gmake[6]: Выход из каталога > `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa/drivers/dri' > gmake[5]: *** [all-recursive] Ошибка 1 > gmake[5]: Выход из каталога > `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa/drivers' > gmake[4]: *** [all-recursive] Ошибка 1 > gmake[4]: Выход из каталога > `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa' > gmake[3]: *** [all] Ошибка 2 > gmake[3]: Выход из каталога > `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src/mesa' > gmake[2]: *** [all-recursive] Ошибка 1 > gmake[2]: Выход из каталога > `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6/src' > gmake[1]: *** [all-recursive] Ошибка 1 > gmake[1]: Выход из каталога > `/usr/home/goshanecr/graphics/dri/work/Mesa-9.1.6' > *** Error code 1 > Stop. > make: stopped in /usr/home/goshanecr/graphics/dri Currently you need to use clang to compile libGL and dri from the xorg development repo. This is because our gcc is so old it lacks certain functions needed to compile these ports. A fix is in the works, but will probably take a couple of days (at least) before it is out. Regards! -- Niclas From owner-freebsd-x11@FreeBSD.ORG Fri Aug 30 21:06:07 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 817AE154 for ; Fri, 30 Aug 2013 21:06:07 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm18-vm10.access.bullet.mail.bf1.yahoo.com (nm18-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 225832F68 for ; Fri, 30 Aug 2013 21:06:06 +0000 (UTC) Received: from [66.196.81.155] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2013 20:59:50 -0000 Received: from [98.139.221.53] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2013 20:59:50 -0000 Received: from [127.0.0.1] by smtp106.sbc.mail.bf1.yahoo.com with NNFMP; 30 Aug 2013 20:59:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1377896390; bh=MRLt6AyEJ+78d2azHzzV3LCs9Boefzcn1hc6kiRRotk=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject; b=gw3MBi0EiYT4HGWFZOAYc/OYJ/9OAmAoYcCpHQ9Daj51B0hVvSp3nn7LtQUGV4uHUvdp+mlngfZN0tyjq6xME4poJKznzOFI4kBHK8rr2f3nIiVJadj/6J4uR98hHBSbnxCrkbTwJixchRgoRBAZXQRyxdpSsiPXSJeWm30vVWk= X-Yahoo-Newman-Id: 83574.30239.bm@smtp106.sbc.mail.bf1.yahoo.com Message-ID: <83574.30239.bm@smtp106.sbc.mail.bf1.yahoo.com> Date: Fri, 30 Aug 2013 13:59:50 -0700 (PDT) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JK4lbN8VM1kiKYfMYLlfhl_DrPjfcSNytFuBOshtzxCYGMF SxJp.4JGFpkjIk.cFOUctv.pkh3tjx8u6yZma8EKhveaylJVUymN5OFIhRnJ c5nZh_5J09YV8G2FRNHI4Nn5sltKJnGjEU5kFwiyvhHbnhLKYoKa5uptsdKo 5OPbFsv.t3doDG7kW8iwtZJo8YZNC1sBPEvhIXDmuiysp9jcaJBXavBZftxC wsWIoJ.ROXhF_.npUlpw2VHAbGEBe0VH9GjRhOqktuYhwdvrdXWFUpXRaBoC EmqwAqWjlW7PlWbu3n.kZ34EhsrYidfaOrB.9.0kRJq.fQ.BvFEt7Gt0VeHc upRp1b64jaGjNSJqR8k4wQE2PDV5qt3khvC0w7_g9Z7RjCuZWowp8e_Y3jaj FgAK9rUxbbs2BSAIjEaJjLrWLFWBas1wJqSc0fJKOYxYWwT90YP0MGeKhvQm 2t9ZqigGk9ssLflgMzrcF9dNpvKHzAlB5JOaTEJ4NI99.k7DU4ho1O6KFSJp Zi_gb2w-- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@74.130.200.176 with plain) by smtp106.sbc.mail.bf1.yahoo.com with SMTP; 30 Aug 2013 13:59:50 -0700 PDT From: "Thomas Mueller" To: freebsd-x11@freebsd.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Cc: Matthew Rezny , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 21:06:07 -0000 >From my previous post and Niclas Zeising's response: > > By the way, another problem I had with NetBSD was the text console screen blanking after 30 seconds inactivity and not coming back until I could find my > >way in the dark to a root command prompt and type > > screenblank -u > This could be a NetBSD specific issue maybe? As I said before, I had no > trouble on my laptop running 'startx' from the black console, so I > assume shutdown -r now works as long as I have a root shell. I also > could shut down cleanly with the power button, using acpi. All this on > FreeBSD. The screen blanking after 30 seconds was NetBSD-specific, didn't happen under FreeBSD (through 8.2) or Linux (through Slackware 13.0) on the same hardware. Graphics card was ATI Rage 128 (r128). With recent builds of NetBSD releng-6, text console does not blank on its own, but comes back very dim after returning from X. With NetBSD 5.1_STABLE, I could type "shutdown -r now" in the dark or startx /path/to/appropriate-xinitrc-file, that worked. So I guess I would try that in FreeBSD WITH_NEW_XORG too, based on what I did with NetBSD on old computer. In FreeBSD WITH_NEW_XORG, I never explicitly kldloaded i919kms.ko , forgot to mention that on last post. I don't really know the logistics of how I'd connect two computers by Firewire, might not be able to find long-enough cable. Would the other computer have to be running FreeBSD? I remember OS/2 long ago offered a kernel debugger, maybe it was part of OS/2 Developer Connection, that worked through a serial connection to abother computer, which did not have to be running OS/2; DOS would have been good enough. I never tried that. To start X with specified conf file, something like startx /usr/local/lib/X11/xinit/xinitrc.icewm -- -config xorg.conf.vesa Just for comparison, upgrading pkgsrc X on NetBSD releng-6 resulted in mouse pointer moving right-to-left and back but not up and down. That was this year, about June 20, which is where that installation rests now. modular-xorg-server version was/is 1.12.4 As has been pointed out, upstream Xorg development is Linux-centric. I guess everything else is Tier 2 or lower priority. Tom From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 00:33:45 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61C6F125; Sat, 31 Aug 2013 00:33:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34ECB2A3C; Sat, 31 Aug 2013 00:33:45 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz10so2948904pad.16 for ; Fri, 30 Aug 2013 17:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OFrOLFxQsRXQfIx7UFokqCMdtxgUThBVKwLCOtWGPB0=; b=UN7DCvnOG3949yp4JxksSgaRiVghphS7W7bfZTUoOJLd3d6o0kMWJuHtMvBcOPlYNf csPCCLAYrlFzKW3FzKuahzh0IWas780y1rXrw5gQOS8MYBYKvitRyxgxdPNb4+VHl9CC wE57cRoQHOtpJzsFbfHaObQ+wHbvQqkI2OYjDmBM2dpZ+mIQYan+Ozu6EJ9NPYDkIH0+ vWWPN7rsZNYx+9o55Q8W2OO+i4mdVvk1GMmnRJiMeXwfaq63K4b6epCWncUNNmiYK6Hh HSsdS/CGBv2cCTVfOEu2vqdgF16sVs2aZIbCtesgAGdmeDzU5TSA5P2m3UN++J2PrnQO Uzuw== MIME-Version: 1.0 X-Received: by 10.66.194.13 with SMTP id hs13mr13534370pac.163.1377909224846; Fri, 30 Aug 2013 17:33:44 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.219.74 with HTTP; Fri, 30 Aug 2013 17:33:44 -0700 (PDT) In-Reply-To: <52206460.5020902@freebsd.org> References: <26.37.28548.F1A30225@hrndva-omtalb.mail.rr.com> <52206460.5020902@freebsd.org> Date: Fri, 30 Aug 2013 17:33:44 -0700 X-Google-Sender-Auth: SIXohlHYHJD4uT8DiVDlKrwT8uk Message-ID: Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering From: Kevin Oberman To: Niclas Zeising Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Thomas Mueller , "freebsd-x11@freebsd.org" , Matthew Rezny X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 00:33:45 -0000 On Fri, Aug 30, 2013 at 2:22 AM, Niclas Zeising wrote: > On 2013-08-30 08:22, Thomas Mueller wrote: > > From my previous post and Niclas Zeising's response: > > > >>> When I tried with new Xorg and KMS in 9-STABLE, my system froze > immediately, not just the console. I finally managed to downgrade to the > old Xorg after > >> considerable difficulty. > > > >> What hardware do you have? Are you sure that the system froze, and not > >> only that the console went black? Did you check any logs (dmesg, xorg > >> log, etc.) How do you load the kernel modules for the intel kms driver? > >> In general, you shouldn't need to load anything at all, X loads the > >> correct kernel module at the correct time during startup. > > > > I don't remember about the logs, and now is far too late. > > > > But I remember doing everything I did when I had this problem with > NetBSD on old computer, native xorg server, not pkgsrc, and no KMS. > > > > Nothing I did with keyboard had any effect. I tried to Ctrl-Alt-F1 and > "shutdown -r now", nothing. > > > > I also tried the Caps Lock key to see if there was any life, did not > light up. > > > > By the way, another problem I had with NetBSD was the text console > screen blanking after 30 seconds inactivity and not coming back until I > could find my way in the dark to a root command prompt and type > > > > screenblank -u > > This could be a NetBSD specific issue maybe? As I said before, I had no > trouble on my laptop running 'startx' from the black console, so I > assume shutdown -r now works as long as I have a root shell. I also > could shut down cleanly with the power button, using acpi. All this on > FreeBSD. > I really suggest adding yourself to the operator account. That will allow you to shutdown without a root login. Entering Fn+F1 and "shutdown -r now" has no chance of working as X is still running on vty0, so you have no shell to receive the command. You can try entering a CTRL-C to kill X or logout of the X session instead of Fn+F1? Maybe Fn+F2 and log in or log into that vty before starting X. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 00:51:45 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 154AF86C; Sat, 31 Aug 2013 00:51:45 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D82F52B55; Sat, 31 Aug 2013 00:51:44 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id r10so2497026pdi.41 for ; Fri, 30 Aug 2013 17:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=njYLuHIjxE/57yTz7D83OYWQaINBhV/xidSCUGrzLjY=; b=iGslSxnVV6JSejWSqdxWcmb+CDiNdmCK2lTGisTNv+FvpI3kk0bmeycCxvZMyIp2pG CF9eFO+5eUGDqLZKuo+GL1d2Z4sUVALvFYK0awbdwRHSe+P2WFOcsvqecOr0LIJzNimF X77ukCo3QLTakj3qzlGSMkdJqlHv6+YSxbmJ/XW9EmBoUoKx0J6WS+tL8QgGMfobCfJR cNBL1HWwUieZG/MUrFRLzvPvHwhfjcnvmwmEu5xqYgfHR/HoB5jjArWEbV5l5x81Rjl0 +FPiICjd16dIXJsIWjrK3OkmmkUlmAgfABJe0eHzzuon5GlPPwQp0YFC+zJ+ZXg1XtVa QTBQ== MIME-Version: 1.0 X-Received: by 10.68.197.195 with SMTP id iw3mr13051188pbc.5.1377910304555; Fri, 30 Aug 2013 17:51:44 -0700 (PDT) Received: by 10.68.44.102 with HTTP; Fri, 30 Aug 2013 17:51:44 -0700 (PDT) In-Reply-To: <5220700D.1050301@passap.ru> References: <20130822155651.GA32146@probe.unige.ch> <9437888.l2O97oTlfp@notebook.alkar.net> <1596081.5RRtn7UfRG@notebook.alkar.net> <5220700D.1050301@passap.ru> Date: Fri, 30 Aug 2013 19:51:44 -0500 Message-ID: Subject: Re: unsupported synaptics touchpad From: Brandon Gooch To: Boris Samorodov Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-x11@freebsd.org, =?ISO-8859-1?Q?Jean=2DS=E9bastien_P=E9dron?= X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 00:51:45 -0000 On Fri, Aug 30, 2013 at 5:12 AM, Boris Samorodov wrote: > 29.08.2013 18:10, Artyom Mirgorodskiy =D0=C9=DB=C5=D4: > >> This patch works for me too. Thank you. > > Please, submit a follow-up to the PR with some info about > hardware, software, problem and the result. Thanks! > > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve I was told by jkim@ that there is a problem with the patch due to the change in the synapticshw struct in sys/sys/mouse.h -- ABI compatibility problem. I don't know how to correctly fix the patch to get it into an acceptable state (#ifdef maybe?), so I was hoping someone with a bit more expertise could user the changes in with more correctness. -Brandon From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 03:52:01 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81643C3E for ; Sat, 31 Aug 2013 03:52:01 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm1-vm7.access.bullet.mail.gq1.yahoo.com (nm1-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3612624BF for ; Sat, 31 Aug 2013 03:52:00 +0000 (UTC) Received: from [216.39.60.170] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Aug 2013 03:45:30 -0000 Received: from [98.138.104.99] by tm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Aug 2013 03:45:30 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 31 Aug 2013 03:45:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1377920730; bh=XYRu48IZYY8AxDKsQPhcQ/M5os4orBgVrcteWllYDZ8=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject; b=Zlu2zCTXW+X/GNdWH2qgHwC64fs4XWjQVCprwH2y7+hXIMtYDR64qgpISr/wp9sg/PxfZJRua+2outs0X4cnQT+kND2CiaRMzje4Tt8/CxpKUF7N8gMadmYy8hW8ISaxxrwnt8zQeOCaDs9SieH7KwJAKbs64si8H6KPcHUS6tg= X-Yahoo-Newman-Id: 80399.44329.bm@smtp119.sbc.mail.ne1.yahoo.com Message-ID: <80399.44329.bm@smtp119.sbc.mail.ne1.yahoo.com> Date: Sat, 31 Aug 2013 03:45:30 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QXjiZUUVM1nafi.pG.Oxpq8bvwoTKiLcdauGGBz1po6BCtb AQL6ctobMFrt9mCT9JZXu3MYh0i9fM53XONdYQh7hT1sj7xcCwlV_XAJEakM KnHU9Kqtm9I1MatMnQS4AXvuWgLV2vmpOEsVJ4WHE53Hty3KYSIGPV4uOwcD jdQBhqsV2e53RmI5753AwDkWYLtCz3QUtuUCNL5gnQY3oyqKxCsO.wRjZHWZ ig50gCoZ2wEOGncj7Rw08T0Z0V0_s7pm1vZ_qnasVwOMuMp9YFNk4qtTVXwa skuJ68QQJVjxHkVY2h4hcnc8nwsPc356uD8vqWSRimd_am1j4.nlgAaXPoX. GOe.ZbPZV8Wmc7V2EXTJvwRgpbFyKq2kQ7GpcdaQp8IIsVUXZW5PLXZKYUxV F.hPPGgedGZmrrtAmgsRiqu34rMV8PDdjgBRlfcYbLs3yeJISH7tIN_ro_5q qgKjAUqxYwhix5STuJ1Cc.RrqA3MkkCnKB9IXH3YLJzGMSzuesflvnLhlhwN nV4TgKR5_irHJU89HG.ix5.95_qGGAfbBXUqrJ3tR X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@74.130.200.176 with plain) by smtp119.sbc.mail.ne1.yahoo.com with SMTP; 31 Aug 2013 03:45:29 +0000 UTC From: "Thomas Mueller" To: freebsd-x11@freebsd.org Subject: Re: ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering Cc: Matthew Rezny , Niclas Zeising X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 03:52:01 -0000 > I really suggest adding yourself to the operator account. That will allow > you to shutdown without a root login. > Entering Fn+F1 and "shutdown -r now" has no chance of working as X is still > running on vty0, so you have no shell to receive the command. You can try > entering a CTRL-C to kill X or logout of the X session instead of Fn+F1? > Maybe Fn+F2 and log in or log into that vty before starting X. -- > R. Kevin Oberman, Network Engineer With NetBSD 5.x screenblanking the text console, and not able to come back to a text console from X, I worked almost exclusively as root. I didn't take NetBSD seriously for multiuser. Before going into X, I remembered to have an extra console logged in as root, just so I could Crtl-Alt-Fn to that console and type shutdown -r now. NetBSD by default gives four vty consoles, in contrast to 8 in FreeBSD and 6 in Slackware Linux. Tom From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 03:55:58 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7CEF5C95 for ; Sat, 31 Aug 2013 03:55:58 +0000 (UTC) (envelope-from gosha-necr@yandex.ru) Received: from forward6.mail.yandex.net (forward6.mail.yandex.net [IPv6:2a02:6b8:0:202::7]) by mx1.freebsd.org (Postfix) with ESMTP id 603F624DA for ; Sat, 31 Aug 2013 03:55:57 +0000 (UTC) Received: from web10m.yandex.ru (web10m.yandex.ru [37.140.138.101]) by forward6.mail.yandex.net (Yandex) with ESMTP id E4CEC11226C6; Sat, 31 Aug 2013 07:55:55 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web10m.yandex.ru (Yandex) with ESMTP id 849FC24A06A1; Sat, 31 Aug 2013 07:55:55 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1377921355; bh=IauutvV80n/odt3HhE6na/xgzpmtoquvmyc3l27SmTc=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=rdM8r1nXTxZfpyQKVfXyTRPveDPRQy1hSb+zhDxqa/wbNQhrGy1/tgc1nZWL9/GTx nNl2UrraEsDtAB9/SqyCpYFMpyFSI0f0y2a+o+zvqiYqM5437lJpPowGP269Onf7ly W93Irn5+f8l5m/H6iGsEdWbRedK9tYDjJPoz0MYw= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web10m.yandex.ru with HTTP; Sat, 31 Aug 2013 07:55:54 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: Niclas Zeising In-Reply-To: <5220DC43.2060300@daemonic.se> References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> <5220DC43.2060300@daemonic.se> Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U Message-Id: <42821377921354@web10m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 31 Aug 2013 09:55:54 +0600 X-Mailman-Approved-At: Sat, 31 Aug 2013 04:30:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-x11@freebsd.org" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 03:55:58 -0000 30.08.2013, 23:54, "Niclas Zeising" : On 08/30/13 18:38, wrote: Hi! I'm tryin to test your work and thats my actions: Currently you need to use clang to compile libGL and dri from the xorg development repo. This is because our gcc is so old it lacks certain functions needed to compile these ports. A fix is in the works, but will probably take a couple of days (at least) before it is out. Regards! -- Niclas Yes, it helps! I'm rebuild system with clang and after that graphics/dri installs. Other info about system (pciconf -lvbce, devinfo, dmesg , etc.. in my first letter But Xorg not starts, below that Xorg.0.log ================= kldstat ========================== 1 21 0xffffffff80200000 b9cf08 kernel 2 1 0xffffffff80e12000 10308e radeonkms.ko 3 1 0xffffffff80f16000 3e503 drm2.ko 4 4 0xffffffff80f55000 140a iicbus.ko 5 1 0xffffffff80f57000 ce0 iic.ko 6 1 0xffffffff80f58000 12d9 iicbb.ko ================= Xorg.0.log ======================== [ 49.877] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [ 49.877] _XSERVTransOpen: transport open failed for inet6/TEST:0 [ 49.877] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 49.911] X.Org X Server 1.12.4 Release Date: 2012-08-27 [ 49.911] X Protocol Version 11, Revision 0 [ 49.911] Build Operating System: FreeBSD 10.0-CURRENT amd64 [ 49.911] Current Operating System: FreeBSD TEST 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Aug 31 08:03:00 CET 2013 goshanecr@TEST:/usr/obj/usr/src/sys/BSDSERV amd64 [ 49.912] Build Date: 30 August 2013 02:54:25PM [ 49.912] [ 49.912] Current version of pixman: 0.30.0 [ 49.912] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 49.912] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 49.913] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 31 12:28:49 2013 [ 50.014] (==) Using config file: "/etc/X11/xorg.conf" [ 50.042] (==) ServerLayout "X.org Configured" [ 50.042] (**) |-->Screen "Screen0" (0) [ 50.042] (**) | |-->Monitor "Monitor0" [ 50.044] (**) | |-->Device "Card0" [ 50.044] (**) |-->Input Device "Keyboard" [ 50.044] (**) |-->Input Device "Mouse" [ 50.044] (**) Option "AIGLX" "true" [ 50.045] (**) Option "AutoAddDevices" "true" [ 50.045] (**) Option "DRI2" "true" [ 50.045] (**) Automatically adding devices [ 50.045] (==) Automatically enabling devices [ 50.085] (WW) The directory "/usr/local/lib/X11/fonts/cyrillic/" does not exist. [ 50.085] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/misc/" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/100dpi/" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/75dpi/" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/msttf/" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (WW) The directory "/usr/local/lib/X11/fonts/terminus-font/" does not exist. [ 50.086] Entry deleted from font path. [ 50.086] (**) FontPath set to: ${prefix}/share/fonts/X11/misc/, ${prefix}/share/fonts/X11/TTF/, ${prefix}/share/fonts/X11/OTF/, ${prefix}/share/fonts/X11/Type1/, ${prefix}/share/fonts/X11/100dpi/, ${prefix}/share/fonts/X11/75dpi/ [ 50.086] (**) ModulePath set to "/usr/local/lib/xorg/modules" [ 50.086] (**) Extension "Composite" is enabled [ 50.086] (WW) Ignoring unrecognized extension "XDamage" [ 50.087] (**) Extension "RENDER" is enabled [ 50.087] (**) Extension "DAMAGE" is enabled [ 50.087] (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AutoAddDevices. [ 50.087] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 50.087] (WW) Disabling Keyboard [ 50.087] (WW) Disabling Mouse [ 50.087] (II) Loader magic: 0x7bfec0 [ 50.087] (II) Module ABI versions: [ 50.087] X.Org ANSI C Emulation: 0.4 [ 50.087] X.Org Video Driver: 12.1 [ 50.087] X.Org XInput driver : 16.0 [ 50.087] X.Org Server Extension : 6.0 [ 50.089] (--) PCI:*(0:0:1:0) 1002:9806:1043:14b7 rev 0, Mem @ 0xb0000000/268435456, 0xfeb00000/262144, I/O @ 0x0000f000/256, BIOS @ 0x????????/65536 [ 50.089] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. [ 50.089] (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. [ 50.089] (II) "glx" will be loaded. This was enabled by default and also specified in the config file. [ 50.089] (II) "record" will be loaded. This was enabled by default and also specified in the config file. [ 50.089] (II) "dri" will be loaded. This was enabled by default and also specified in the config file. [ 50.089] (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. [ 50.089] (II) LoadModule: "extmod" [ 50.090] (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so [ 50.107] (II) Module extmod: vendor="X.Org Foundation" [ 50.107] compiled for 1.12.4, module version = 1.0.0 [ 50.107] Module class: X.Org Server Extension [ 50.107] ABI class: X.Org Server Extension, version 6.0 [ 50.108] (II) Loading extension MIT-SCREEN-SAVER [ 50.108] (II) Loading extension XFree86-VidModeExtension [ 50.108] (II) Loading extension XFree86-DGA [ 50.108] (II) Loading extension DPMS [ 50.108] (II) Loading extension XVideo [ 50.108] (II) Loading extension XVideo-MotionCompensation [ 50.108] (II) Loading extension X-Resource [ 50.108] (II) LoadModule: "record" [ 50.109] (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so [ 50.110] (II) Module record: vendor="X.Org Foundation" [ 50.110] compiled for 1.12.4, module version = 1.13.0 [ 50.110] Module class: X.Org Server Extension [ 50.111] ABI class: X.Org Server Extension, version 6.0 [ 50.111] (II) Loading extension RECORD [ 50.111] (II) LoadModule: "dbe" [ 50.111] (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so [ 50.113] (II) Module dbe: vendor="X.Org Foundation" [ 50.113] compiled for 1.12.4, module version = 1.0.0 [ 50.113] Module class: X.Org Server Extension [ 50.113] ABI class: X.Org Server Extension, version 6.0 [ 50.113] (II) Loading extension DOUBLE-BUFFER [ 50.113] (II) LoadModule: "glx" [ 50.114] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 50.126] (II) Module glx: vendor="X.Org Foundation" [ 50.126] compiled for 1.12.4, module version = 1.0.0 [ 50.126] ABI class: X.Org Server Extension, version 6.0 [ 50.128] (**) AIGLX enabled [ 50.129] (II) Loading extension GLX [ 50.129] (II) LoadModule: "dri" [ 50.129] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so [ 50.145] (II) Module dri: vendor="X.Org Foundation" [ 50.145] compiled for 1.12.4, module version = 1.0.0 [ 50.145] ABI class: X.Org Server Extension, version 6.0 [ 50.146] (II) Loading extension XFree86-DRI [ 50.146] (II) LoadModule: "dri2" [ 50.146] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so [ 50.148] (II) Module dri2: vendor="X.Org Foundation" [ 50.148] compiled for 1.12.4, module version = 1.2.0 [ 50.148] ABI class: X.Org Server Extension, version 6.0 [ 50.148] (II) Loading extension DRI2 [ 50.148] (II) LoadModule: "vbe" [ 50.169] (II) Loading /usr/local/lib/xorg/modules/libvbe.so [ 50.175] (II) Module vbe: vendor="X.Org Foundation" [ 50.175] compiled for 1.12.4, module version = 1.1.0 [ 50.175] ABI class: X.Org Video Driver, version 12.1 [ 50.175] (II) LoadModule: "ddc" [ 50.176] (II) Module "ddc" already built-in [ 50.176] (II) LoadModule: "radeon" [ 50.205] (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so [ 50.261] (II) Module radeon: vendor="X.Org Foundation" [ 50.261] compiled for 1.12.4, module version = 7.2.0 [ 50.261] Module class: X.Org Video Driver [ 50.261] ABI class: X.Org Video Driver, version 12.1 [ 50.262] (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI FireMV 2400 3155 (PCI), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI FireMV 2400 PCI, ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Mobility Radeon X1700, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon 4800 Series, ATI Radeon HD 4850 x2, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI Mobility RADEON HD 4870, ATI Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Mobility Radeon HD 4650, ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670, ATI FirePro M5750, ATI Mobility Radeon HD 4670, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830, ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740, ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770, ATI FirePro M5750, ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI RV670, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series, ATI FirePro RG220, ATI Mobility Radeon 4330, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, SUMO, SUMO, SUMO2, SUMO2, SUMO2, SUMO2, SUMO, SUMO, SUMO, SUMO, SUMO, SUMO, SUMO, SUMO, ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200, ATI Mobility Radeon 4100, ATI Radeon HD 4290, ATI Radeon HD 4250, AMD Radeon HD 6310 Graphics, AMD Radeon HD 6310 Graphics, AMD Radeon HD 6250 Graphics, AMD Radeon HD 6250 Graphics, AMD Radeon HD 6300 Series Graphics, AMD Radeon HD 6200 Series Graphics, PALM, PALM, PALM, CYPRESS, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, AMD Firestream 9370, AMD Firestream 9350, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5800 Series, ATI Radeon HD 5900 Series, ATI Radeon HD 5900 Series, ATI Mobility Radeon HD 5800 Series, ATI Mobility Radeon HD 5800 Series, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI Mobility Radeon HD 5800 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 6700 Series, ATI Radeon HD 5700 Series, ATI Radeon HD 6700 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5570, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI Radeon HD 5670, ATI Radeon HD 5570, ATI Radeon HD 5500 Series, REDWOOD, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon Graphics, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro (FireGL) Graphics Adapter, ATI FirePro 2270, CEDAR, ATI Radeon HD 5450, CEDAR, CEDAR, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, CAYMAN, AMD Radeon HD 6900 Series, AMD Radeon HD 6900 Series, CAYMAN, CAYMAN, CAYMAN, AMD Radeon HD 6900M Series, Mobility Radeon HD 6000 Series, BARTS, BARTS, Mobility Radeon HD 6000 Series, Mobility Radeon HD 6000 Series, BARTS, BARTS, BARTS, BARTS, AMD Radeon HD 6800 Series, AMD Radeon HD 6800 Series, AMD Radeon HD 6700 Series, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, TURKS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, CAICOS, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, ARUBA, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, TAHITI, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, PITCAIRN, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, VERDE, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, OLAND, HAINAN, HAINAN, HAINAN, HAINAN, HAINAN, HAINAN, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, BONAIRE, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI, KABINI [ 50.285] (--) Using syscons driver with X support (version 2.0) [ 50.285] (--) using VT number 9 [ 50.297] (II) [KMS] Kernel modesetting enabled. [ 50.297] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 50.297] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 50.298] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 50.298] (==) RADEON(0): Default visual is TrueColor [ 50.298] (==) RADEON(0): RGB weight 888 [ 50.298] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 50.298] (--) RADEON(0): Chipset: "AMD Radeon HD 6300 Series Graphics" (ChipID = 0x9806) [ 50.298] drmOpenDevice: node name is /dev/dri/card0 [ 50.299] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 50.299] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 50.299] drmOpenDevice: open result is -1, (No such file or directory) [ 50.299] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 50.299] drmOpenDevice: open result is -1, (No such file or directory) [ 50.299] drmOpenDevice: Open failed [ 52.358] drmOpenByBusid: Searching for BusID pci:0000:00:01.0 [ 52.358] drmOpenDevice: node name is /dev/dri/card0 [ 52.358] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.358] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 52.358] drmOpenDevice: open result is -1, (No such file or directory) [ 52.358] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 52.358] drmOpenDevice: open result is -1, (No such file or directory) [ 52.358] drmOpenDevice: Open failed [ 52.358] drmOpenByBusid: drmOpenMinor returns -2 [ 52.359] drmOpenDevice: node name is /dev/dri/card1 [ 52.359] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.359] Failed to change owner or group for file /dev/dri/card1! 2: No such file or directory [ 52.359] drmOpenDevice: open result is -1, (No such file or directory) [ 52.359] Failed to change owner or group for file /dev/dri/card1! 2: No such file or directory [ 52.359] drmOpenDevice: open result is -1, (No such file or directory) [ 52.359] drmOpenDevice: Open failed [ 52.359] drmOpenByBusid: drmOpenMinor returns -2 [ 52.359] drmOpenDevice: node name is /dev/dri/card2 [ 52.359] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.359] Failed to change owner or group for file /dev/dri/card2! 2: No such file or directory [ 52.359] drmOpenDevice: open result is -1, (No such file or directory) [ 52.359] Failed to change owner or group for file /dev/dri/card2! 2: No such file or directory [ 52.359] drmOpenDevice: open result is -1, (No such file or directory) [ 52.359] drmOpenDevice: Open failed [ 52.359] drmOpenByBusid: drmOpenMinor returns -2 [ 52.359] drmOpenDevice: node name is /dev/dri/card3 [ 52.359] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.359] Failed to change owner or group for file /dev/dri/card3! 2: No such file or directory [ 52.359] drmOpenDevice: open result is -1, (No such file or directory) [ 52.359] Failed to change owner or group for file /dev/dri/card3! 2: No such file or directory [ 52.359] drmOpenDevice: open result is -1, (No such file or directory) [ 52.359] drmOpenDevice: Open failed [ 52.359] drmOpenByBusid: drmOpenMinor returns -2 [ 52.359] drmOpenDevice: node name is /dev/dri/card4 [ 52.359] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.360] Failed to change owner or group for file /dev/dri/card4! 2: No such file or directory [ 52.360] drmOpenDevice: open result is -1, (No such file or directory) [ 52.360] Failed to change owner or group for file /dev/dri/card4! 2: No such file or directory [ 52.360] drmOpenDevice: open result is -1, (No such file or directory) [ 52.360] drmOpenDevice: Open failed [ 52.360] drmOpenByBusid: drmOpenMinor returns -2 [ 52.360] drmOpenDevice: node name is /dev/dri/card5 [ 52.360] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.360] Failed to change owner or group for file /dev/dri/card5! 2: No such file or directory [ 52.360] drmOpenDevice: open result is -1, (No such file or directory) [ 52.360] Failed to change owner or group for file /dev/dri/card5! 2: No such file or directory [ 52.360] drmOpenDevice: open result is -1, (No such file or directory) [ 52.360] drmOpenDevice: Open failed [ 52.360] drmOpenByBusid: drmOpenMinor returns -2 [ 52.360] drmOpenDevice: node name is /dev/dri/card6 [ 52.360] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.360] Failed to change owner or group for file /dev/dri/card6! 2: No such file or directory [ 52.360] drmOpenDevice: open result is -1, (No such file or directory) [ 52.360] Failed to change owner or group for file /dev/dri/card6! 2: No such file or directory [ 52.360] drmOpenDevice: open result is -1, (No such file or directory) [ 52.360] drmOpenDevice: Open failed [ 52.360] drmOpenByBusid: drmOpenMinor returns -2 [ 52.360] drmOpenDevice: node name is /dev/dri/card7 [ 52.360] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.360] Failed to change owner or group for file /dev/dri/card7! 2: No such file or directory [ 52.361] drmOpenDevice: open result is -1, (No such file or directory) [ 52.361] Failed to change owner or group for file /dev/dri/card7! 2: No such file or directory [ 52.361] drmOpenDevice: open result is -1, (No such file or directory) [ 52.361] drmOpenDevice: Open failed [ 52.361] drmOpenByBusid: drmOpenMinor returns -2 [ 52.361] drmOpenDevice: node name is /dev/dri/card8 [ 52.361] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.361] Failed to change owner or group for file /dev/dri/card8! 2: No such file or directory [ 52.361] drmOpenDevice: open result is -1, (No such file or directory) [ 52.361] Failed to change owner or group for file /dev/dri/card8! 2: No such file or directory [ 52.361] drmOpenDevice: open result is -1, (No such file or directory) [ 52.361] drmOpenDevice: Open failed [ 52.361] drmOpenByBusid: drmOpenMinor returns -2 [ 52.361] drmOpenDevice: node name is /dev/dri/card9 [ 52.361] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.361] Failed to change owner or group for file /dev/dri/card9! 2: No such file or directory [ 52.361] drmOpenDevice: open result is -1, (No such file or directory) [ 52.361] Failed to change owner or group for file /dev/dri/card9! 2: No such file or directory [ 52.361] drmOpenDevice: open result is -1, (No such file or directory) [ 52.361] drmOpenDevice: Open failed [ 52.361] drmOpenByBusid: drmOpenMinor returns -2 [ 52.361] drmOpenDevice: node name is /dev/dri/card10 [ 52.361] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.361] Failed to change owner or group for file /dev/dri/card10! 2: No such file or directory [ 52.361] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] Failed to change owner or group for file /dev/dri/card10! 2: No such file or directory [ 52.362] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] drmOpenDevice: Open failed [ 52.362] drmOpenByBusid: drmOpenMinor returns -2 [ 52.362] drmOpenDevice: node name is /dev/dri/card11 [ 52.362] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.362] Failed to change owner or group for file /dev/dri/card11! 2: No such file or directory [ 52.362] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] Failed to change owner or group for file /dev/dri/card11! 2: No such file or directory [ 52.362] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] drmOpenDevice: Open failed [ 52.362] drmOpenByBusid: drmOpenMinor returns -2 [ 52.362] drmOpenDevice: node name is /dev/dri/card12 [ 52.362] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.362] Failed to change owner or group for file /dev/dri/card12! 2: No such file or directory [ 52.362] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] Failed to change owner or group for file /dev/dri/card12! 2: No such file or directory [ 52.362] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] drmOpenDevice: Open failed [ 52.362] drmOpenByBusid: drmOpenMinor returns -2 [ 52.362] drmOpenDevice: node name is /dev/dri/card13 [ 52.362] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.362] Failed to change owner or group for file /dev/dri/card13! 2: No such file or directory [ 52.362] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] Failed to change owner or group for file /dev/dri/card13! 2: No such file or directory [ 52.362] drmOpenDevice: open result is -1, (No such file or directory) [ 52.362] drmOpenDevice: Open failed [ 52.363] drmOpenByBusid: drmOpenMinor returns -2 [ 52.363] drmOpenDevice: node name is /dev/dri/card14 [ 52.363] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.363] Failed to change owner or group for file /dev/dri/card14! 2: No such file or directory [ 52.363] drmOpenDevice: open result is -1, (No such file or directory) [ 52.363] Failed to change owner or group for file /dev/dri/card14! 2: No such file or directory [ 52.363] drmOpenDevice: open result is -1, (No such file or directory) [ 52.363] drmOpenDevice: Open failed [ 52.363] drmOpenByBusid: drmOpenMinor returns -2 [ 52.363] drmOpenDevice: node name is /dev/dri/card15 [ 52.363] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.363] Failed to change owner or group for file /dev/dri/card15! 2: No such file or directory [ 52.363] drmOpenDevice: open result is -1, (No such file or directory) [ 52.363] Failed to change owner or group for file /dev/dri/card15! 2: No such file or directory [ 52.363] drmOpenDevice: open result is -1, (No such file or directory) [ 52.363] drmOpenDevice: Open failed [ 52.363] drmOpenByBusid: drmOpenMinor returns -2 [ 52.363] drmOpenDevice: node name is /dev/dri/card0 [ 52.363] Failed to change owner or group for file /dev/dri! 2: No such file or directory [ 52.363] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 52.363] drmOpenDevice: open result is -1, (No such file or directory) [ 52.363] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory [ 52.363] drmOpenDevice: open result is -1, (No such file or directory) [ 52.363] drmOpenDevice: Open failed [ 52.364] [drm] failed to load kernel module "radeonkms" [ 52.364] (EE) RADEON(0): [drm] Failed to open DRM device for pci:0000:00:01.0: File exists [ 52.364] (EE) RADEON(0): Kernel modesetting setup failed [ 52.364] (II) UnloadModule: "radeon" [ 52.364] (EE) Screen(s) found, but none have a usable configuration. [ 52.364] Fatal server error: [ 52.364] no screens found [ 52.364] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 52.364] Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 52.364] [ 52.431] Server terminated with error (1). Closing log file. -------------------------------------------- , . From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 07:35:12 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 24D73DFF for ; Sat, 31 Aug 2013 07:35:12 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF7C220B8 for ; Sat, 31 Aug 2013 07:35:11 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=[192.168.1.176]) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VFfiA-000MoQ-2Q for freebsd-x11@freebsd.org; Sat, 31 Aug 2013 09:35:10 +0200 Message-ID: <52219CB1.607@FreeBSD.org> Date: Sat, 31 Aug 2013 09:35:13 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-x11@freebsd.org Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> <5220DC43.2060300@daemonic.se> <42821377921354@web10m.yandex.ru> In-Reply-To: <42821377921354@web10m.yandex.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 07:35:12 -0000 Le 31/08/2013 05:55, Гуляев Гоша a écrit : > But Xorg not starts, below that Xorg.0.log Could you please send the output of dmesg after trying to start X? -- Jean-Sébastien Pédron From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 10:19:37 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC920DDD for ; Sat, 31 Aug 2013 10:19:37 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F2A7279E for ; Sat, 31 Aug 2013 10:19:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7044340015 for ; Sat, 31 Aug 2013 12:19:34 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 6666140016; Sat, 31 Aug 2013 12:19:34 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D719D40015; Sat, 31 Aug 2013 12:19:32 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRtpC4p4Gz8hVn; Sat, 31 Aug 2013 12:19:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id VQZmSgw-4vrK; Sat, 31 Aug 2013 12:19:29 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRtp924SJz8hVm; Sat, 31 Aug 2013 12:19:29 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cRtp91106z9Ctj; Sat, 31 Aug 2013 12:19:29 +0200 (CEST) Message-ID: <5221C331.6050801@daemonic.se> Date: Sat, 31 Aug 2013 12:19:29 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: =?UTF-8?B?0JPRg9C70Y/QtdCyINCT0L7RiNCw?= Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> <5220DC43.2060300@daemonic.se> <42821377921354@web10m.yandex.ru> In-Reply-To: <42821377921354@web10m.yandex.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "freebsd-x11@freebsd.org" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 10:19:37 -0000 On 08/31/13 05:55, Гуляев Гоша wrote: > 30.08.2013, 23:54, "Niclas Zeising" : >> Currently you need to use clang to compile libGL and dri from the xorg >> development repo. This is because our gcc is so old it lacks certain >> functions needed to compile these ports. >> A fix is in the works, but will probably take a couple of days (at >> least) before it is out. >> > Yes, it helps! > I'm rebuild system with clang and after that graphics/dri installs. > Other info about system (pciconf -lvbce, devinfo, dmesg , etc.. in my first letter [SNIP xorg log] Hi! Do you have serial console to the machine? The trouble might be that the radeon KMS kernel module isn't loaded properly. Does the console come back once X exits? Can you post kldstat before and after starting X, as well as dmesg? Regards! -- Niclas From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 12:38:24 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C073CA; Sat, 31 Aug 2013 12:38:24 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B71052F0E; Sat, 31 Aug 2013 12:38:23 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2433540004; Sat, 31 Aug 2013 14:38:21 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 1A26C40015; Sat, 31 Aug 2013 14:38:21 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C333540004; Sat, 31 Aug 2013 14:38:19 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRxtM3PqYz8hVn; Sat, 31 Aug 2013 14:38:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id Xx79eSjm2CEI; Sat, 31 Aug 2013 14:38:17 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3cRxtK0mTvz8hVm; Sat, 31 Aug 2013 14:38:17 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3cRxtJ6z5bz9Ctj; Sat, 31 Aug 2013 14:38:16 +0200 (CEST) Message-ID: <5221E3B8.6060708@daemonic.se> Date: Sat, 31 Aug 2013 14:38:16 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: =?UTF-8?B?0JPRg9C70Y/QtdCyINCT0L7RiNCw?= Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> <5220DC43.2060300@daemonic.se> <42821377921354@web10m.yandex.ru> <5221C331.6050801@daemonic.se> <198331377951869@web2g.yandex.ru> In-Reply-To: <198331377951869@web2g.yandex.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "freebsd-x11@freebsd.org" , dumbbell@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 12:38:24 -0000 On 08/31/13 14:24, Гуляев Гоша wrote: > No, I have not serial console (if it means that on notebook needed COM-post, it > has not nor COM, not LPT ports) > After Xorg exits, physical console come back normaly > Also I send kernel config in the end of letter > ============= kldstat before Xorg ====================== > Id Refs Address Size Name > 1 1 0xffffffff80200000 b9cf08 kernel > > ============= kldstat after Xorg ====================== > Id Refs Address Size Name > 1 21 0xffffffff80200000 b9cf08 kernel > 2 1 0xffffffff80e12000 10308e radeonkms.ko > 3 1 0xffffffff80f16000 3e503 drm2.ko > 4 4 0xffffffff80f55000 140a iicbus.ko > 5 1 0xffffffff80f57000 ce0 iic.ko > 6 1 0xffffffff80f58000 12d9 iicbb.ko > ============ dmesg before Xorg ======================= So the kernel module is loaded when X starts, but see below. [SNIP] > info: [drm] Initialized drm 1.1.0 20060810 > drmn0: on vgapci0 > info: [drm] MSI enabled 1 message(s) > info: [drm] RADEON_IS_PCIE > info: [drm] initializing kernel modesetting (PALM 0x1002:0x9806 0x1043:0x14B7). > info: [drm] register mmio base: 0xFEB00000 > info: [drm] register mmio size: 262144 > info: [drm] radeon_atrm_get_bios: ===> Try ATRM... > info: [drm] radeon_atrm_get_bios: IGP card detected, skipping this method... > info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... > info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table > info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND > info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... > info: [drm] igp_read_bios_from_vram: VRAM base address: 0xb0000000 > info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800b0000000 (262144 bytes) > info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x2070 > info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... > info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... > info: [drm] igp_read_bios_from_vram: VRAM base address: 0xb0000000 > info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800b0000000 (262144 bytes) > info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x2070 > error: [drm:pid905:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM > drmn0: error: Fatal error during GPU init > info: [drm] radeon: finishing device. > [TTM] Memory type 2 has not been initialized > device_attach: drmn0 attach returned 22 Something goes wrong when loading the radeon KMS module and attaching to the hardware. This means that when X starts it has no way of talking to the graphics card, and exits. I hope dumbbell@ (CCd) knows more about this, since he imported the radeon KMS driver into FreeBSD. Sorry that I can't be of more help. Regards! -- Niclas From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 12:17:42 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C9EBE32; Sat, 31 Aug 2013 12:17:42 +0000 (UTC) (envelope-from gosha-necr@yandex.ru) Received: from forward17.mail.yandex.net (forward17.mail.yandex.net [IPv6:2a02:6b8:0:1402::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9B02E47; Sat, 31 Aug 2013 12:17:41 +0000 (UTC) Received: from web2g.yandex.ru (web2g.yandex.ru [95.108.252.102]) by forward17.mail.yandex.net (Yandex) with ESMTP id 54C061060526; Sat, 31 Aug 2013 16:17:39 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web2g.yandex.ru (Yandex) with ESMTP id D431F39F8044; Sat, 31 Aug 2013 16:17:38 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1377951459; bh=dr4FLyTS9tMYf98dFlaHgjvg4jZPzWe43j+DwPzirIw=; h=From:To:In-Reply-To:References:Subject:Date; b=Ah17pD8E5oftY/5SXxDuTkMtLljWw/uvyjTHl+DBMBlRlQMlykkjWr/0ZKS0dm5+o 5QmnKlB2Uz9Zllny/s2a3Xnos90AQESwhhjbilu+ZA2LK19vOVtemgkhMxSUshEh8D kAbTpfffixrQpz4Ekxw6A48uDlWaGquvl6cFDBx8= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web2g.yandex.ru with HTTP; Sat, 31 Aug 2013 16:17:38 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: =?utf-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , "freebsd-x11@freebsd.org" In-Reply-To: <52219CB1.607@FreeBSD.org> References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> <5220DC43.2060300@daemonic.se> <42821377921354@web10m.yandex.ru> <52219CB1.607@FreeBSD.org> Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U Message-Id: <195671377951458@web2g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 31 Aug 2013 18:17:38 +0600 X-Mailman-Approved-At: Sat, 31 Aug 2013 13:48:55 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 12:17:42 -0000 31.08.2013, 13:35, "Jean-Sébastien Pédron" : Le 31/08/2013 05:55, лев оа a écrit : But Xorg not starts, below that Xorg.0.log Could you please send the output of dmesg after trying to start X? Yes, that is: ============= dmesg after trying Xorg ==================== Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Sat Aug 31 08:03:00 CET 2013 goshanecr@TEST:/usr/obj/usr/src/sys/BSDSERV amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1647.04-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 1634627584 (1558 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130823/tbfadt-630) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xb0000000-0xbfffffff,0xfeb00000-0xfeb3ffff irq 18 at device 1.0 on pci0 hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 xhci0: mem 0xfeb48000-0xfeb49fff irq 18 at device 16.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 ahci0: port 0xf190-0xf197,0xf180-0xf183,0xf170-0xf177,0xf160-0xf163,0xf150-0xf15f mem 0xfeb4f000-0xfeb4f7ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ohci0: mem 0xfeb4e000-0xfeb4efff irq 18 at device 18.0 on pci0 usbus1 on ohci0 ehci0: mem 0xfeb4d000-0xfeb4d0ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 ohci1: mem 0xfeb4c000-0xfeb4cfff irq 18 at device 19.0 on pci0 usbus3 on ohci1 ehci1: mem 0xfeb4b000-0xfeb4b0ff irq 17 at device 19.2 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf100-0xf10f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 hdac1: mem 0xfeb40000-0xfeb43fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 sdhci_pci0: mem 0xfeb4a000-0xfeb4a0ff irq 16 at device 20.7 on pci0 sdhci_pci0: 1 slot(s) allocated pcib3: at device 21.0 on pci0 pci3: on pcib3 pcib4: at device 21.1 on pci0 pci6: on pcib4 re0: port 0xd000-0xd0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 17 at device 0.0 on pci6 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 30:85:a9:7a:08:93 pcib5: at device 21.3 on pci0 pci7: on pcib5 ath0: mem 0xfe900000-0xfe97ffff irq 19 at device 0.0 on pci7 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_throttle0: on cpu0 hwpstate0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 25 on hdaa1 pcm2: at nid 26 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: <0x1022> at usbus0 uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen4.1: at usbus4 uhub1: on usbus4 ugen3.1: at usbus3 uhub2: on usbus3 ugen2.1: at usbus2 uhub3: on usbus2 ugen1.1: at usbus1 uhub4: on usbus1 uhub2: 5 ports with 5 removable, self powered uhub4: 5 ports with 5 removable, self powered uhub0: 4 ports with 4 removable, self powered uhub1: 5 ports with 5 removable, self powered uhub3: 5 ports with 5 removable, self powered ugen4.2: at usbus4 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1647038739 Hz quality 800 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ada0a [rw]... ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (PALM 0x1002:0x9806 0x1043:0x14B7). info: [drm] register mmio base: 0xFEB00000 info: [drm] register mmio size: 262144 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: IGP card detected, skipping this method... info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xb0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800b0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x5407 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xb0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800b0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x5407 error: [drm:pid881:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM drmn0: error: Fatal error during GPU init info: [drm] radeon: finishing device. [TTM] Memory type 2 has not been initialized device_attach: drmn0 attach returned 22 re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN -- Jean-Sébastien Pédron _______________________________________________ [1]freebsd-x11@freebsd.org mailing list [2]http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to "[3]freebsd-x11-unsubscribe@freebsd.org" -------------------------------------------- С важением, лев оа. References 1. mailto:freebsd-x11@freebsd.org 2. http://lists.freebsd.org/mailman/listinfo/freebsd-x11 3. mailto:freebsd-x11-unsubscribe@freebsd.org From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 12:24:32 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D2111F89 for ; Sat, 31 Aug 2013 12:24:32 +0000 (UTC) (envelope-from gosha-necr@yandex.ru) Received: from forward20.mail.yandex.net (forward20.mail.yandex.net [IPv6:2a02:6b8:0:1402::5]) by mx1.freebsd.org (Postfix) with ESMTP id D3E072E98 for ; Sat, 31 Aug 2013 12:24:31 +0000 (UTC) Received: from web2g.yandex.ru (web2g.yandex.ru [95.108.252.102]) by forward20.mail.yandex.net (Yandex) with ESMTP id 3E9C11041D51; Sat, 31 Aug 2013 16:24:30 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web2g.yandex.ru (Yandex) with ESMTP id C4CC239F8045; Sat, 31 Aug 2013 16:24:29 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1377951870; bh=ZGJhc6u7kFV6u1aHEWAa0c9pxTdrRWZVjsmxWsGQ6r4=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=V+5YoGVMGbR+gQsnlHu4Y8EPhm0dAqWyXrskFW3G6DBPpwQIijhrycpiimu+dwlhE tDXJ/Zr+Hfy//BDgfr05GA4ct/KUVxpO558eVGdo6+B3dJlSPvKSMz+MbNfBY2hsGs PZI9xc1PnquECunkYT392Do/W0veIyi2HLbA1CfA= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web2g.yandex.ru with HTTP; Sat, 31 Aug 2013 16:24:29 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: Niclas Zeising In-Reply-To: <5221C331.6050801@daemonic.se> References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> <5220DC43.2060300@daemonic.se> <42821377921354@web10m.yandex.ru> <5221C331.6050801@daemonic.se> Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U Message-Id: <198331377951869@web2g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 31 Aug 2013 18:24:29 +0600 X-Mailman-Approved-At: Sat, 31 Aug 2013 15:02:50 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-x11@freebsd.org" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 12:24:32 -0000 31.08.2013, 16:19, "Niclas Zeising" : On 08/31/13 05:55, wrote: 30.08.2013, 23:54, "Niclas Zeising" <[1]zeising+freebsd@daemonic.se>: Currently you need to use clang to compile libGL and dri from the xorg development repo. This is because our gcc is so old it lacks certain functions needed to compile these ports. A fix is in the works, but will probably take a couple of days (at least) before it is out. Yes, it helps! I'm rebuild system with clang and after that graphics/dri installs. Other info about system (pciconf -lvbce, devinfo, dmesg , etc.. in my first letter [SNIP xorg log] Hi! Do you have serial console to the machine? The trouble might be that the radeon KMS kernel module isn't loaded properly. Does the console come back once X exits? Can you post kldstat before and after starting X, as well as dmesg? Regards! -- Niclas No, I have not serial console (if it means that on notebook needed COM-post, it has not nor COM, not LPT ports) After Xorg exits, physical console come back normaly Also I send kernel config in the end of letter ============= kldstat before Xorg ====================== Id Refs Address Size Name 1 1 0xffffffff80200000 b9cf08 kernel ============= kldstat after Xorg ====================== Id Refs Address Size Name 1 21 0xffffffff80200000 b9cf08 kernel 2 1 0xffffffff80e12000 10308e radeonkms.ko 3 1 0xffffffff80f16000 3e503 drm2.ko 4 4 0xffffffff80f55000 140a iicbus.ko 5 1 0xffffffff80f57000 ce0 iic.ko 6 1 0xffffffff80f58000 12d9 iicbb.ko ============ dmesg before Xorg ======================= Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Sat Aug 31 08:03:00 CET 2013 goshanecr@TEST:/usr/obj/usr/src/sys/BSDSERV amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1647.04-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 1634627584 (1558 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130823/tbfadt-630) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xb0000000-0xbfffffff,0xfeb00000-0xfeb3ffff irq 18 at device 1.0 on pci0 hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 xhci0: mem 0xfeb48000-0xfeb49fff irq 18 at device 16.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 ahci0: port 0xf190-0xf197,0xf180-0xf183,0xf170-0xf177,0xf160-0xf163,0xf150-0xf15f mem 0xfeb4f000-0xfeb4f7ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ohci0: mem 0xfeb4e000-0xfeb4efff irq 18 at device 18.0 on pci0 usbus1 on ohci0 ehci0: mem 0xfeb4d000-0xfeb4d0ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 ohci1: mem 0xfeb4c000-0xfeb4cfff irq 18 at device 19.0 on pci0 usbus3 on ohci1 ehci1: mem 0xfeb4b000-0xfeb4b0ff irq 17 at device 19.2 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf100-0xf10f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 hdac1: mem 0xfeb40000-0xfeb43fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 sdhci_pci0: mem 0xfeb4a000-0xfeb4a0ff irq 16 at device 20.7 on pci0 sdhci_pci0: 1 slot(s) allocated pcib3: at device 21.0 on pci0 pci3: on pcib3 pcib4: at device 21.1 on pci0 pci6: on pcib4 re0: port 0xd000-0xd0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 17 at device 0.0 on pci6 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 30:85:a9:7a:08:93 pcib5: at device 21.3 on pci0 pci7: on pcib5 ath0: mem 0xfe900000-0xfe97ffff irq 19 at device 0.0 on pci7 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_throttle0: on cpu0 hwpstate0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 25 on hdaa1 pcm2: at nid 26 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: <0x1022> at usbus0 uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen4.1: at usbus4 uhub2: on usbus4 ugen3.1: at usbus3 uhub3: on usbus3 ugen2.1: at usbus2 uhub4: on usbus2 uhub0: 5 ports with 5 removable, self powered uhub3: 5 ports with 5 removable, self powered uhub1: 4 ports with 4 removable, self powered uhub2: 5 ports with 5 removable, self powered uhub4: 5 ports with 5 removable, self powered ugen4.2: at usbus4 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1647041208 Hz quality 800 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ada0a [rw]... ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called ======== dmesg after Xorg ====================== Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Sat Aug 31 08:03:00 CET 2013 goshanecr@TEST:/usr/obj/usr/src/sys/BSDSERV amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1647.04-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 1634627584 (1558 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130823/tbfadt-630) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xb0000000-0xbfffffff,0xfeb00000-0xfeb3ffff irq 18 at device 1.0 on pci0 hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 xhci0: mem 0xfeb48000-0xfeb49fff irq 18 at device 16.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 ahci0: port 0xf190-0xf197,0xf180-0xf183,0xf170-0xf177,0xf160-0xf163,0xf150-0xf15f mem 0xfeb4f000-0xfeb4f7ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ohci0: mem 0xfeb4e000-0xfeb4efff irq 18 at device 18.0 on pci0 usbus1 on ohci0 ehci0: mem 0xfeb4d000-0xfeb4d0ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 ohci1: mem 0xfeb4c000-0xfeb4cfff irq 18 at device 19.0 on pci0 usbus3 on ohci1 ehci1: mem 0xfeb4b000-0xfeb4b0ff irq 17 at device 19.2 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf100-0xf10f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 hdac1: mem 0xfeb40000-0xfeb43fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 sdhci_pci0: mem 0xfeb4a000-0xfeb4a0ff irq 16 at device 20.7 on pci0 sdhci_pci0: 1 slot(s) allocated pcib3: at device 21.0 on pci0 pci3: on pcib3 pcib4: at device 21.1 on pci0 pci6: on pcib4 re0: port 0xd000-0xd0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 17 at device 0.0 on pci6 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 30:85:a9:7a:08:93 pcib5: at device 21.3 on pci0 pci7: on pcib5 ath0: mem 0xfe900000-0xfe97ffff irq 19 at device 0.0 on pci7 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9485 mac 576.1 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_throttle0: on cpu0 hwpstate0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 25 on hdaa1 pcm2: at nid 26 on hdaa1 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: <0x1022> at usbus0 uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen4.1: at usbus4 uhub2: on usbus4 ugen3.1: at usbus3 uhub3: on usbus3 ugen2.1: at usbus2 uhub4: on usbus2 uhub0: 5 ports with 5 removable, self powered uhub3: 5 ports with 5 removable, self powered uhub1: 4 ports with 4 removable, self powered uhub2: 5 ports with 5 removable, self powered uhub4: 5 ports with 5 removable, self powered ugen4.2: at usbus4 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1647041208 Hz quality 800 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ada0a [rw]... ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (PALM 0x1002:0x9806 0x1043:0x14B7). info: [drm] register mmio base: 0xFEB00000 info: [drm] register mmio size: 262144 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: IGP card detected, skipping this method... info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xb0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800b0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x2070 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xb0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800b0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x2070 error: [drm:pid905:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM drmn0: error: Fatal error during GPU init info: [drm] radeon: finishing device. [TTM] Memory type 2 has not been initialized device_attach: drmn0 attach returned 22 ============= KERNEL config ===================== cpu HAMMER ident BSDSERV #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload #options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device #options NFSCL # New Network Filesystem Client #options NFSD # New Network Filesystem Server #options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCL #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options MAC # TrustedBSD MAC Framework options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # Kernel ELF linker loads CTF data options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use this instead: options DDB # Support DDB. options GDB # Support remote GDB. #options DEADLKRES # Enable the deadlock resolver #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed #options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives #device fdc # ATA controllers device ahci # AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_STATIC_ID # Static device numbering #device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA #device siis # SiliconImage SiI3124/SiI3132/SiI3531 SATA # SCSI Controllers #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device esp # AMD Am53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series #device isp # Qlogic family ##device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device mps # LSI-Logic MPT-Fusion 2 ##device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device isci # Intel C600 SAS controller # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD device pass # Passthrough device (direct ATA/SCSI access) #device ses # Enclosure Services (SES and SAF-TE) #device ctl # CAM Target Layer # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #XXX it is not 64-bit clean, -scottl #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptnr # Highpoint DC7280, R750 #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device hpt27xx # Highpoint RocketRAID 27xx #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID #device tws # LSI 3ware 9750 SATA+SAS 6Gb/s RAID controller # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device aacraid # Adaptec by PMC RAID #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver options VESA # Add support for VESA BIOS Extensions (VBE) device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device uart # Generic UART driver # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device ppi # Parallel port interface device #device vpo # Requires scbus and da #device puc # Multi I/O cards and multi-channel UARTs # PCI Ethernet NICs. #device bxe # Broadcom BCM57710/BCM57711/BCM57711E 10Gb Ethernet #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 Gigabit Ethernet Family #device igb # Intel PRO/1000 PCIE Server Gigabit Family #device ixgbe # Intel PRO/10GbE PCIE Ethernet Family #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device ae # Attansic/Atheros L2 FastEthernet #device age # Attansic/Atheros L1 Gigabit Ethernet #device alc # Atheros AR8131/AR8132 Ethernet #device ale # Atheros AR8121/AR8113/AR8114 Ethernet #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device cas # Sun Cassini/Cassini+ and NS DP83065 Saturn #device dc # DEC/Intel 21143 and various workalikes #device et # Agere ET1310 10/100/Gigabit Ethernet #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device gem # Sun GEM/Sun ERI/Apple GMAC #device hme # Sun HME (Happy Meal Ethernet) #device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet ##device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sge # Silicon Integrated Systems SiS190/191 #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm #device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros NICs device ath_pci # Atheros pci/cardbus glue device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation options ATH_ENABLE_11N # Enable 802.11n support for AR5416 and later device ath_rate_sample # SampleRate tx rate control for ath #device bwi # Broadcom BCM430x/BCM431x wireless NICs. #device bwn # Broadcom BCM43xx wireless NICs. #device ipw # Intel 2100 wireless NICs. #device iwi # Intel 2200BG/2225BG/2915ABG wireless NICs. #device iwn # Intel 4965/1000/5000/6000 wireless NICs. #device malo # Marvell Libertas wireless NICs. #device mwl # Marvell 88W8363 802.11n wireless NICs. #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wpi # Intel 3945ABG wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device #options PADLOCK_RNG # VIA Padlock RNG #options RDRAND_RNG # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device xhci # XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da # Sound support device sound # Generic sound driver (required) device snd_cmi # CMedia CMI8338/CMI8738 device snd_csa # Crystal Semiconductor CS461x/428x device snd_emu10kx # Creative SoundBlaster Live! and Audigy device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_via8233 # VIA VT8233x Audio # MMC/SD device mmc # MMC/SD bus device mmcsd # MMC/SD memory card device sdhci # Generic PCI SD Host Controller # VirtIO support #device virtio # Generic VirtIO bus (required) #device virtio_pci # VirtIO PCI device #device vtnet # VirtIO Ethernet device #device virtio_blk # VirtIO Block device #device virtio_scsi # VirtIO SCSI device #device virtio_balloon # VirtIO Memory Balloon device -------------------------------------------- , . References 1. mailto:zeising+freebsd@daemonic.se From owner-freebsd-x11@FreeBSD.ORG Sat Aug 31 12:48:47 2013 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AFBB4229; Sat, 31 Aug 2013 12:48:47 +0000 (UTC) (envelope-from gosha-necr@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) by mx1.freebsd.org (Postfix) with ESMTP id 60D012F7E; Sat, 31 Aug 2013 12:48:47 +0000 (UTC) Received: from web24j.yandex.ru (web24j.yandex.ru [5.45.198.65]) by forward12.mail.yandex.net (Yandex) with ESMTP id E9968C2244E; Sat, 31 Aug 2013 16:48:45 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web24j.yandex.ru (Yandex) with ESMTP id 73A191E01039; Sat, 31 Aug 2013 16:48:45 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1377953325; bh=M1OJf/yh9IdsEWeRWukPtLiFvXPh0mHnR1LtUzW2pRQ=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=McQC0C0ybQlgt1sU156oWo6baeEgLZLyrMi3JIVKWiSj7didMQ8vwDCEshissiN+e dLJ3wSFLVwCXZYcAwhko6xeJKZhxUzsTrI6nVkmgUixUaKWg7HlrBktd+XPCAYxsGE h/PvHvtq901d4vrIYDJaJSEd8SeyUUvnbzHYqkM8= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web24j.yandex.ru with HTTP; Sat, 31 Aug 2013 16:48:44 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: Niclas Zeising In-Reply-To: <5221E3B8.6060708@daemonic.se> References: <521C9D2A.4070001@FreeBSD.org> <423811377880731@web23g.yandex.ru> <5220DC43.2060300@daemonic.se> <42821377921354@web10m.yandex.ru> <5221C331.6050801@daemonic.se> <198331377951869@web2g.yandex.ru> <5221E3B8.6060708@daemonic.se> Subject: Re: [REPORT] AMD Radeon KMS on Asus X501U Message-Id: <33591377953324@web24j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 31 Aug 2013 18:48:44 +0600 X-Mailman-Approved-At: Sat, 31 Aug 2013 15:12:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-x11@freebsd.org" , "dumbbell@freebsd.org" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 12:48:47 -0000 31.08.2013, 18:38, "Niclas Zeising" : On 08/31/13 14:24, wrote: No, I have not serial console (if it means that on notebook needed COM-post, it has not nor COM, not LPT ports) After Xorg exits, physical console come back normaly Also I send kernel config in the end of letter ============= kldstat before Xorg ====================== Id Refs Address Size Name 1 1 0xffffffff80200000 b9cf08 kernel ============= kldstat after Xorg ====================== Id Refs Address Size Name 1 21 0xffffffff80200000 b9cf08 kernel 2 1 0xffffffff80e12000 10308e radeonkms.ko 3 1 0xffffffff80f16000 3e503 drm2.ko 4 4 0xffffffff80f55000 140a iicbus.ko 5 1 0xffffffff80f57000 ce0 iic.ko 6 1 0xffffffff80f58000 12d9 iicbb.ko ============ dmesg before Xorg ======================= So the kernel module is loaded when X starts, but see below. [SNIP] Something goes wrong when loading the radeon KMS module and attaching to the hardware. This means that when X starts it has no way of talking to the graphics card, and exits. I hope dumbbell@ (CCd) knows more about this, since he imported the radeon KMS driver into FreeBSD. Sorry that I can't be of more help. Regards! -- Niclas Thank to you and Jean Sebastian for your work! I just want to help in that work with my tests. -------------------------------------------- , .