From owner-freebsd-acpi@FreeBSD.ORG Sun Oct 14 14:44:21 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4320D626 for ; Sun, 14 Oct 2012 14:44:21 +0000 (UTC) (envelope-from info@tfbalance-report.com) Received: from mailgw14.surf-town.net (mail16.surf-town.net [212.97.132.56]) by mx1.freebsd.org (Postfix) with ESMTP id C4DEF8FC0C for ; Sun, 14 Oct 2012 14:44:19 +0000 (UTC) Received: by mailgw14.surf-town.net (Postfix, from userid 65534) id E3CED3E69A; Sun, 14 Oct 2012 16:44:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailgw14.surf-town.net (Postfix) with ESMTP id D2C2F3E66C for ; Sun, 14 Oct 2012 16:44:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailgw14.surf-town.net X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=7 tests=[ALL_TRUSTED=-1.44, DCC_CHECK=1.37, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3] autolearn=unavailable Received: from mailgw14.surf-town.net ([127.0.0.1]) by localhost (mailgw14.surf-town.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2mGrU77PwTv3 for ; Sun, 14 Oct 2012 16:44:18 +0200 (CEST) Received: from [172.21.212.133] (unknown [178.86.30.201]) by mailgw14.surf-town.net (Postfix) with ESMTPA id 41C313E66E for ; Sun, 14 Oct 2012 16:44:15 +0200 (CEST) From: "QATAR - FINANCE" To: "freebsd-acpi" Subject: Loan offer at interest rate of 2 % per annun. Message-ID: <42c91e527ade36458df64dc3c56eb3fe@MAXILASE-PC> Date: Sun, 14 Oct 2012 14:44:54 +0000 MIME-Version: 1.0 X-Priority: 1 X-Mailer: Microsoft Office Outlook 13.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: qatar@infomaniak.ch List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 14:44:21 -0000 Loan offer at interest rate of 2 % per annun. =0D=0A=0D=0ADo = you need a loan to clear your debts/bills, or start up a business? = Then consider your financial problems over. In today's economic = climate, finding reliable funding sources can be frustrating = and full of disappointments, but with our sophisticated loan = repayment plan, everyone Smiles home.=0D=0AQatar Loan Finance = Foundation provides financing for alternative energy, commercial = real estate projects and personal financing; thus, arranging = a loan with us is simple and straightforward, convenient and = fast. We can give you an immediate 'in principle' decision and = we'll find you some of the most competitive personal loan rates = available.=0D=0AWe Offer guaranteed loan services of any amount = and to any part of the world for (individuals, companies, realtors = and corporate bodies) at our superb interest rate of 2%. Our = team of loan experts first listens to our client's requirements = and then provides them with best loan solutions.=0D=0A=0D=0A=0D=0AWe = Offer LOANS ranging from 100.000 euros Min. to 500 000 000 euros = Max. at 2 % interest rate per annun, Loans for developing your = business expansion. We are certified, trustworthy, reliable, = efficient, Fast and dynamic. and a co-operate financier for = real estate and any kinds of business financing, we give out = long term loan for five to ten years maximum.=0D=0A=0D=0APlease = if you are interested in our financial offer, do not hesitate = to contact us at qatar@infomaniak.ch for more informations =0D=0A =0D= =0AEmir SHEIK HAMAD BIN KHALIFA AL THANI =0D=0AQatar Loan Finance = Foundation From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 15 11:06:11 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CF0C500 for ; Mon, 15 Oct 2012 11:06:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4F08FC27 for ; Mon, 15 Oct 2012 11:06:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9FB6A1H011414 for ; Mon, 15 Oct 2012 11:06:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9FB6AR9011413 for freebsd-acpi@FreeBSD.org; Mon, 15 Oct 2012 11:06:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Oct 2012 11:06:10 GMT Message-Id: <201210151106.q9FB6AR9011413@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 11:06:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 15 15:17:28 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AECEC81E; Mon, 15 Oct 2012 15:17:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8328FC16; Mon, 15 Oct 2012 15:17:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D51ACB958; Mon, 15 Oct 2012 11:17:27 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Mon, 15 Oct 2012 11:12:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210151112.03393.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 15 Oct 2012 11:17:27 -0400 (EDT) Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:17:28 -0000 On Friday, October 12, 2012 7:57:43 pm Alberto Villa wrote: > On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin wrote: > > I think this is correct, but in we need to do more to properly handle that > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > device ID unless that bit is set (except for the special case of > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > spec. I think this larger patch will do that while also fixing your case: > > I tested your patch and the only effect is that my three reported > screens (I'm on a laptop) changed from "crt" to "out" (I understand > why, from the code): > > hw.acpi.video.out0.active: 1 > hw.acpi.video.out1.active: 1 > hw.acpi.video.out1.brightness: 100 > hw.acpi.video.out1.fullpower: 100 > hw.acpi.video.out1.economy: 50 > hw.acpi.video.out1.levels: 100 50 0 10 20 30 40 50 60 70 80 90 100 > hw.acpi.video.out2.active: 1 > > Is there something I can do to help you make them recognised > correctly, or is it fault of a buggy ACPI table? Interesting. Can you get an acpidump? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 15 15:17:28 2012 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AECEC81E; Mon, 15 Oct 2012 15:17:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8328FC16; Mon, 15 Oct 2012 15:17:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D51ACB958; Mon, 15 Oct 2012 11:17:27 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Mon, 15 Oct 2012 11:12:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210151112.03393.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 15 Oct 2012 11:17:27 -0400 (EDT) Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:17:28 -0000 On Friday, October 12, 2012 7:57:43 pm Alberto Villa wrote: > On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin wrote: > > I think this is correct, but in we need to do more to properly handle that > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > device ID unless that bit is set (except for the special case of > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > spec. I think this larger patch will do that while also fixing your case: > > I tested your patch and the only effect is that my three reported > screens (I'm on a laptop) changed from "crt" to "out" (I understand > why, from the code): > > hw.acpi.video.out0.active: 1 > hw.acpi.video.out1.active: 1 > hw.acpi.video.out1.brightness: 100 > hw.acpi.video.out1.fullpower: 100 > hw.acpi.video.out1.economy: 50 > hw.acpi.video.out1.levels: 100 50 0 10 20 30 40 50 60 70 80 90 100 > hw.acpi.video.out2.active: 1 > > Is there something I can do to help you make them recognised > correctly, or is it fault of a buggy ACPI table? Interesting. Can you get an acpidump? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 16 23:49:13 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FB92862; Tue, 16 Oct 2012 23:49:13 +0000 (UTC) (envelope-from nm.knife@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 89A438FC17; Tue, 16 Oct 2012 23:49:12 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id 16so5519016wgi.31 for ; Tue, 16 Oct 2012 16:49:11 -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=xZay5UsxrZYnKii3ZRSs7lxCin9E65oN4S5JpoalTKM=; b=FKYSYB3C8JHl8AwT8S0WS6GcfW2UU/AsyEYBY6CZXMT5K5oUOt96e16rXShXp0Ma+t NEEU2KBFFFajKrobinoTd+EPyejXIj9LhpOt4GwPkxDrbxnehTPq1Mtcx2MdJ7hsQAE0 FBi+4ycXcOJjk8slDGDzFBSbQV8pBkPosLgEay316JVzpTel+92XbzjgDcKIAsWtab3u hAb3GhxkqXHtWgtk5T5Plysddr0r9TdJr7eX2OthBp8GQYa06srNFsMm0m8ecnrUpJMZ Sop5HINCoXJnUgEWHm/1FDfGu4lXwXxB1sk/fZ5CBUsd65ed+zN6qY0iI4w+xVf+srI0 C5bQ== MIME-Version: 1.0 Received: by 10.216.136.230 with SMTP id w80mr10632502wei.199.1350431351371; Tue, 16 Oct 2012 16:49:11 -0700 (PDT) Received: by 10.227.38.145 with HTTP; Tue, 16 Oct 2012 16:49:11 -0700 (PDT) In-Reply-To: <50778671.9020703@gmail.com> References: <4E836C06.9070405@gmail.com> <4F7A8A99.4040603@gmail.com> <20120403210619.Q2060@sola.nimnet.asn.au> <4F7DAAB0.2010206@gmail.com> <4F7E2D5C.3020506@gmail.com> <4F7F9504.1030405@gmail.com> <20120814102409.7dc335b8@X220.ovitrap.com> <20121011094459.12ee1653@X220.ovitrap.com> <50778671.9020703@gmail.com> Date: Tue, 16 Oct 2012 16:49:11 -0700 Message-ID: Subject: Re: x220 notes From: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= To: matt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 23:49:13 -0000 > You've swapped the X220 cpu for something? Or a different machine? > > I find X does horrible things to battery usage on my X220. Getting into > the lowest C state, and disabling ALL of the USB devices helps somewhat, as > does setting a lower backlight level at boot (you can make an rc script, or > catch the backlight buttons while the bios is still loading). > > Matt > I set a lower light (5-6) during BIOS boot, and if needed I modify manually in X. I monitored my CPU usage and did notice that the CPU takes its sweet time to lower the frequency (Windows keeps the frequency the same 99.67, but changes the multiplier from 8 to 32). I don't know if FreeBSD does that or it only manipulates the frequency. The multiplier makes more sense. Also, CPU cores in X stay at 50C. In Windows at no activicy they drop to 44C and if no strenuous activity for a while, to 40C. It would be great if FreeBSD could downgrade the frequency faster upon no load. I use this: powerd_flags="-a hiadaptive -b adaptive -i 85 -r 60 -p 100" I am always looking for the "perfect" FreeBSD laptop, but I guess it just doesn't exist. And I do need my 7-8 hours of battery with wireless on. If you guys have any suggestions on further optimizing the power usage and automating the regulation, please let me know (like turning off and on USB devices, spinning down the HDD, etc), also if you know about controlling the multiplier instead of the frequency. -- Lyubomir Grigorov (bgalakazam) From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 17 01:04:31 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2323EAF; Wed, 17 Oct 2012 01:04:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A34198FC08; Wed, 17 Oct 2012 01:04:30 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so7036888pbb.13 for ; Tue, 16 Oct 2012 18:04:30 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ir5KO8ovGXuyLA3SXv2XjHYy2mZA5SZLYxTbB6iSn+c=; b=wJDqoKfpoJuFqvl9UzGM9bqiuY2pOnR7zb3nInpr1pKEdA009RhuWGxO95A83+EGc7 keoD+YBvPjbjNp7ppriPPlhyvTWU4ENlFoJ2gvoY2CDjxz+0lP4r+X4ht7+vZNm+uGap Peux+BPGs1Uv67HbnfjLjPqArcpJLhD2Pqz+fWCyDSjaJ8iqrh+6HT2XetrEFsTGeD/E NipRCiQMWvfdxFZVRYGoL/3IbExb312KhVFWnNEdjzomD5tJfaoPWKzEu5hVAGxa2wNe vuswTiIzK3TeHHbjD0CkhV9iJD80YKsTZjJrhckIBoq3S47S0NFuvVX9wvvusXaz6BES sa6g== MIME-Version: 1.0 Received: by 10.66.86.129 with SMTP id p1mr6513885paz.39.1350435870099; Tue, 16 Oct 2012 18:04:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Tue, 16 Oct 2012 18:04:30 -0700 (PDT) In-Reply-To: References: <4E836C06.9070405@gmail.com> <4F7A8A99.4040603@gmail.com> <20120403210619.Q2060@sola.nimnet.asn.au> <4F7DAAB0.2010206@gmail.com> <4F7E2D5C.3020506@gmail.com> <4F7F9504.1030405@gmail.com> <20120814102409.7dc335b8@X220.ovitrap.com> <20121011094459.12ee1653@X220.ovitrap.com> <50778671.9020703@gmail.com> Date: Tue, 16 Oct 2012 18:04:30 -0700 X-Google-Sender-Auth: 4IZ5gFAYlRQpTGB20ss9yt9YfNI Message-ID: Subject: Re: x220 notes From: Adrian Chadd To: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 01:04:31 -0000 Which wifi card does it use? Adrian From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 17 01:27:59 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78865581; Wed, 17 Oct 2012 01:27:59 +0000 (UTC) (envelope-from nm.knife@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 997258FC12; Wed, 17 Oct 2012 01:27:58 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so5140611wey.13 for ; Tue, 16 Oct 2012 18:27:57 -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=zdrAiOId7YWm+Yp+0rwUIWnggEeHqBtCmSoJW7K/WQU=; b=SYE7XaQ6oPipQ3oDu2341KEKfua/nUin9UIoXsei5LsqDNK0+AMRK6SV6vMo6M9WFl IQz1QX4XrDPcqr6Nltr+VR5Ybqj0Qw6EkXXgnzzrmOwptPS1NF6P909nT+iSsB2Ll2K7 xvcakN+M/GrsQtT7X2uboEFOr+XdI9gIj4pmeyQo2wTLjgkzQCwtUw8f1s4RcwQybQas 90a2/kJinSm2EMFQY3BeQF2/MwCKN4JxVA1ve0tHgCzCnR3a19H3PQjkyqd5VpAUMhc4 4+wCN3wYyuOn/gPu/nX9IKaUSb5p4rLL7u5R7Zk5vKMP3RaK9tgkrd/nh0y7DX7tAW6l tYVg== MIME-Version: 1.0 Received: by 10.216.136.230 with SMTP id w80mr10745461wei.199.1350437277530; Tue, 16 Oct 2012 18:27:57 -0700 (PDT) Received: by 10.227.38.145 with HTTP; Tue, 16 Oct 2012 18:27:57 -0700 (PDT) In-Reply-To: References: <4E836C06.9070405@gmail.com> <4F7A8A99.4040603@gmail.com> <20120403210619.Q2060@sola.nimnet.asn.au> <4F7DAAB0.2010206@gmail.com> <4F7E2D5C.3020506@gmail.com> <4F7F9504.1030405@gmail.com> <20120814102409.7dc335b8@X220.ovitrap.com> <20121011094459.12ee1653@X220.ovitrap.com> <50778671.9020703@gmail.com> Date: Tue, 16 Oct 2012 18:27:57 -0700 Message-ID: Subject: Re: x220 notes From: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 01:27:59 -0000 6300 N, 3x3 antennae, but that shouldn't be a problem since the other members reporting low battery time have other cards. 2012/10/16 Adrian Chadd > Which wifi card does it use? > > > > > Adrian > -- Lyubomir Grigorov (bgalakazam) From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 17 08:54:30 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A0C15AB for ; Wed, 17 Oct 2012 08:54:30 +0000 (UTC) (envelope-from nm.knife@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECE28FC08 for ; Wed, 17 Oct 2012 08:54:28 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hr7so292978wib.13 for ; Wed, 17 Oct 2012 01:54:22 -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=hH8+Iip6oQcPz9jXZlQE8JRcYpL180CWMNtndx6rjI4=; b=fhPda99y1YYT2zcsvPeVsi9P30tWRXZNtTjTli+gVIAyDqLd1DJaPRS3rdz5tQOQN5 2l2MyeWGTR+foVbZ9Vyo7vtez3siSO1wbzqz89SnGZ+qnURwT+ZT41tctbz9b7gec9aI 4dyFmkGpHhHjJ5ttTM8p0hOb3aXoQ2X1p+RKR3UxN02dGGN5mV7/KxOQOYpdIhelNuEJ sXOKNNQHHUaESg8FR+xw4cYC8XmTU5oYoGkEhY8w0zKVp6G4nxd4+ighxPFEfwMDLMoN G4+YhypyIRO8+UPUAJTK4f0xAuhDokgj1kOJ5xn3litu5BXNt3DGJl/VVS9EdoxRsiEz IE3Q== MIME-Version: 1.0 Received: by 10.216.195.133 with SMTP id p5mr11300780wen.1.1350464062222; Wed, 17 Oct 2012 01:54:22 -0700 (PDT) Received: by 10.227.38.145 with HTTP; Wed, 17 Oct 2012 01:54:22 -0700 (PDT) Date: Wed, 17 Oct 2012 01:54:22 -0700 Message-ID: Subject: X220 suspend/resume debugging on 10-CURRENT From: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 08:54:30 -0000 I decided to play around with suspend/resume on my X220 for a while and here are my findings. I hope this helps to bring a solution to a working suspend/resume in X220 (BTW it's reported as working correctly in X1). Below my tests are also the relevant outputs of "dmesg", "devinfo -rv" and "pciconf -clv". - testing was done in console mode $ uname -a FreeBSD LGX 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Tue Oct 9 11:37:31 PDT 2012 alakazam@LGX:/usr/obj/usr/src/sys/GENERIC amd64 - With acpi_ibm.ko unloaded, it suspends with "acpiconf -s 3" - Power led is blinking - Beeps on suspend, beeps on resume - Screen resumes off. - Keyboard works and I am able to "reboot" - "kldload acpi_ibm" "kldload vesa" "kldload i915kms" do nothing - With acpi_ibm.ko loaded, it suspends with "acpiconf -s 3" - Power led is blinking - Beeps on suspend, beeps on resume - Screen resumes off - Keyboard works and I am able to "reboot" - "kldload vesa" "kldload i915kms" do nothing - With acpi_ibm.ko loaded, "sysctl debug.acpi.suspend_bounce=1", it doesn't suspend with "acpiconf -s 3" - Doesn't suspend - Screen is on, but it's all black - Keyboard works and I am able to "reboot" - "kldload vesa" "kldload i915kms" do nothing - With acpi_ibm.ko and i915kms.ko loaded, it suspends with "acpiconf -s 3" - Screen turns off after loading module, solution is to startx, but I am not testing that. - Power led is blinking - Beeps on suspend, beeps on resume - Screen resumes off - "startx" turns on screen, but it's black with random line in top left. - "kldload vesa" "kldload i915kms" do nothing == Copyright (c) 1992-2012 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 #2: Tue Oct 9 11:37:31 PDT 2012 alakazam@LGX:/usr/obj/usr/src/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (2491.97-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbff Features2=0x1fbae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16408248320 (15648 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: 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 kbd1 at kbdmux0 hpt27xx: RocketRAID 27xx controller driver v1.0 (Oct 9 2012 11:36:43) ctl: CAM Target Layer loaded acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, df900000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: 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 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-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x5000-0x503f mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory pci0: at device 22.0 (no driver attached) em0: port 0x5080-0x509f mem 0xf2500000-0xf251ffff,0xf252b000-0xf252bfff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: f0:de:f1:dd:a2:6f ehci0: mem 0xf252a000-0xf252a3ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac0: mem 0xf2520000-0xf2523fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci3: on pcib2 iwn0: mem 0xf2400000-0xf2401fff irq 17 at device 0.0 on pci3 pcib3: irq 19 at device 28.3 on pci0 pci5: on pcib3 pcib4: irq 16 at device 28.4 on pci0 pci13: on pcib4 sdhci0: mem 0xf1400000-0xf14000ff irq 16 at device 0.0 on pci13 sdhci0: 1 slot(s) allocated ehci1: mem 0xf2529000-0xf25293ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x50a8-0x50af,0x50bc-0x50bf,0x50a0-0x50a7,0x50b8-0x50bb,0x5060-0x507f mem 0xf2528000-0xf25287ff 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 ahcich4: at channel 4 on ahci0 ahciem0: on ahci0 pci0: at device 31.3 (no driver attached) acpi_tz0: 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 battery0: on acpi0 acpi_acad0: on acpi0 orm0: at iomem 0xc0000-0xcffff 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 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec hpt27xx: no controller detected. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 31 and 27 on hdaa0 pcm1: at nid 25 and 35 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 pcm3: at nid 6 on hdaa1 pcm4: at nid 7 on hdaa1 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: 61057MB (125045424 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 9734256 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ada0s1a [rw]... WARNING: /: TRIM flag on fs but disk does not support TRIM KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type KLD vboxnetflt.ko: depends on vboxdrv - not available or version mismatch linker_load_file: Unsupported file type wlan0: Ethernet address: 00:24:d7:cf:90:70 lock order reversal: 1st 0xffffff83d8a83bb8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2652 2nd 0xfffffe000abfaa00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x875 _sx_xlock() at _sx_xlock+0x64 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x973 ufs_mkdir() at ufs_mkdir+0x4a2 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xb7 kern_mkdirat() at kern_mkdirat+0x290 amd64_syscall() at amd64_syscall+0x369 Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800920fca, rsp = 0x7fffffffd788, rbp = 0x801006050 --- == == nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9d7ff 0x100000-0x1fffffff 0x20200000-0x3fffffff 0x40200000-0xda99efff 0xdafff000-0xdaffffff 0x100000000-0x41e5fffff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x24-0x25 0x28-0x29 0x2c-0x2d 0x30-0x31 0x34-0x35 0x38-0x39 0x3c-0x3d 0x50-0x53 0x72-0x77 0x90-0x9f 0xa4-0xa5 0xa8-0xa9 0xac-0xad 0xb0-0xb5 0xb8-0xb9 0xbc-0xbd 0x400-0x47f 0x500-0x57f 0x800-0x80f 0x15e0-0x15ef 0x1600-0x167f I/O memory addresses: 0xc0000-0xc3fff 0xc4000-0xc7fff 0xc8000-0xcbfff 0xcc000-0xcffff 0xd0000-0xd3fff 0xd4000-0xd7fff 0xd8000-0xdbfff 0xdc000-0xdffff 0xe0000-0xe3fff 0xe4000-0xe7fff 0xe8000-0xebfff 0xec000-0xeffff 0xf0000-0xfffff 0xf8000000-0xfbffffff 0xfec00000-0xfed3ffff 0xfed45000-0xfed4bfff 0xfed4c000-0xffffffff acpi_ec0 pnpinfo _HID=PNP0C09 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__ I/O ports: 0x62 0x66 cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x414 0x416 acpi_perf0 acpi_throttle0 est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x414 0x416 acpi_perf1 acpi_throttle1 est1 p4tcc1 cpufreq1 cpu2 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 ACPI I/O ports: 0x414 0x416 acpi_perf2 acpi_throttle2 est2 p4tcc2 cpufreq2 cpu3 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU3 ACPI I/O ports: 0x414 0x416 acpi_perf3 acpi_throttle3 est3 p4tcc3 cpufreq3 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU4 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU5 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU6 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU7 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=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_sysresource0 pnpinfo _HID=PNP0C01 _UID=0 at handle=\_SB_.MEM_ acpi_lid0 pnpinfo _HID=PNP0C0D _UID=0 at handle=\_SB_.LID_ acpi_button0 pnpinfo _HID=PNP0C0E _UID=0 at handle=\_SB_.SLPB pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x0104 subvendor=0x17aa subdevice=0x21da class=0x060000 at slot=0 function=0 vgapci0 pnpinfo vendor=0x8086 device=0x0126 subvendor=0x17aa subdevice=0x21da class=0x030000 at slot=2 function=0 handle=\_SB_.PCI0.VID_ I/O ports: 0x5000-0x503f I/O memory addresses: 0xe0000000-0xefffffff 0xf0000000-0xf03fffff agp0 drm0 drmn0 unknown pnpinfo vendor=0x8086 device=0x1c3a subvendor=0x17aa subdevice=0x21da class=0x078000 at slot=22 function=0 I/O memory addresses: 0xf2525000-0xf252500f em0 pnpinfo vendor=0x8086 device=0x1502 subvendor=0x17aa subdevice=0x21ce class=0x020000 at slot=25 function=0 handle=\_SB_.PCI0.IGBE Interrupt request lines: 264 I/O ports: 0x5080-0x509f I/O memory addresses: 0xf2500000-0xf251ffff 0xf252b000-0xf252bfff ehci0 pnpinfo vendor=0x8086 device=0x1c2d subvendor=0x17aa subdevice=0x21da class=0x0c0320 at slot=26 function=0 handle=\_SB_.PCI0.EHC2 Interrupt request lines: 16 I/O memory addresses: 0xf252a000-0xf252a3ff usbus0 uhub0 uhub2 pnpinfo vendor=0x8087 product=0x0024 devclass=0x09 devsubclass=0x00 sernum="" release=0x0000 mode=host intclass=0x09 intsubclass=0x00 i at bus=1 hubaddr=1 port=0 devaddr=2 interface=0 hdac0 pnpinfo vendor=0x8086 device=0x1c20 subvendor=0x17aa subdevice=0x21da class=0x040300 at slot=27 function=0 handle=\_SB_.PCI0.HDEF Interrupt request lines: 265 I/O memory addresses: 0xf2520000-0xf2523fff hdacc0 pnpinfo vendor=0x14f1 device=0x506e revision=0x00 stepping=0x03 at cad=0 hdaa0 pnpinfo type=0x01 subsystem=0x17aa21da at nid=1 pcm0 at nid=31,27 pcm1 at nid=25,35 hdacc1 pnpinfo vendor=0x8086 device=0x2805 revision=0x00 stepping=0x00 at cad=3 hdaa1 pnpinfo type=0x01 subsystem=0x80860101 at nid=1 pcm2 at nid=5 pcm3 at nid=6 pcm4 at nid=7 pcib1 pnpinfo vendor=0x8086 device=0x1c10 subvendor=0x17aa subdevice=0x21da class=0x060400 at slot=28 function=0 handle=\_SB_.PCI0.EXP1 pci2 pcib2 pnpinfo vendor=0x8086 device=0x1c12 subvendor=0x17aa subdevice=0x21da class=0x060400 at slot=28 function=1 handle=\_SB_.PCI0.EXP2 I/O memory addresses: 0xf2400000-0xf24fffff pci3 iwn0 pnpinfo vendor=0x8086 device=0x4238 subvendor=0x8086 subdevice=0x1111 class=0x028000 at slot=0 function=0 Interrupt request lines: 266 pcib2 memory window: 0xf2400000-0xf2401fff pcib3 pnpinfo vendor=0x8086 device=0x1c16 subvendor=0x17aa subdevice=0x21da class=0x060400 at slot=28 function=3 handle=\_SB_.PCI0.EXP4 I/O ports: 0x4000-0x4fff I/O memory addresses: 0xf0400000-0xf0bfffff 0xf1c00000-0xf23fffff pci5 pcib4 pnpinfo vendor=0x8086 device=0x1c18 subvendor=0x17aa subdevice=0x21da class=0x060400 at slot=28 function=4 handle=\_SB_.PCI0.EXP5 I/O ports: 0x3000-0x3fff I/O memory addresses: 0xf0c00000-0xf13fffff 0xf1400000-0xf1bfffff pci13 sdhci0 pnpinfo vendor=0x1180 device=0xe822 subvendor=0x17aa subdevice=0x21da class=0x088001 at slot=0 function=0 handle=\_SB_.PCI0.EXP5.SLOT Interrupt request lines: 16 pcib4 memory window: 0xf1400000-0xf14000ff ehci1 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x17aa subdevice=0x21da class=0x0c0320 at slot=29 function=0 handle=\_SB_.PCI0.EHC1 Interrupt request lines: 23 I/O memory addresses: 0xf2529000-0xf25293ff usbus1 uhub1 uhub3 pnpinfo vendor=0x8087 product=0x0024 devclass=0x09 devsubclass=0x00 sernum="" release=0x0000 mode=host intclass=0x09 intsubclass=0x00 i at bus=1 hubaddr=1 port=1 devaddr=2 interface=0 isab0 pnpinfo vendor=0x8086 device=0x1c4f subvendor=0x17aa subdevice=0x21da class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.LPC_ isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 ACPI I/O memory addresses: 0xc0000-0xcffff fdc0 ppc0 uart0 uart1 ahci0 pnpinfo vendor=0x8086 device=0x1c03 subvendor=0x17aa subdevice=0x21da class=0x010601 at slot=31 function=2 handle=\_SB_.PCI0.SAT1 Interrupt request lines: 267 I/O ports: 0x5060-0x507f 0x50a0-0x50a7 0x50a8-0x50af 0x50b8-0x50bb 0x50bc-0x50bf I/O memory addresses: 0xf2528000-0xf25287ff ahcich0 at channel=0 I/O memory addresses: 0xf2528100-0xf252817f ahcich1 at channel=1 I/O memory addresses: 0xf2528180-0xf25281ff ahcich2 at channel=2 ahcich3 at channel=3 ahcich4 at channel=4 I/O memory addresses: 0xf2528300-0xf252837f ahcich5 at channel=5 ahciem0 I/O memory addresses: 0xf2528020-0xf2528023 0xf2528580-0xf2528587 unknown pnpinfo vendor=0x8086 device=0x1c22 subvendor=0x17aa subdevice=0x21da class=0x0c0500 at slot=31 function=3 handle=\_SB_.PCI0.SMBU I/O ports: 0xefa0-0xefbf I/O memory addresses: 0xf2524000-0xf25240ff acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.LPC_.SIO_ unknown pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.LPC_.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 0x4d0-0x4d1 attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.LPC_.TIMR Interrupt request lines: 0 I/O ports: 0x40-0x43 hpet0 pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.LPC_.HPET Interrupt request lines: 256 257 258 259 260 261 262 263 ACPI I/O memory addresses: 0xfed00000-0xfed003ff atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.LPC_.DMAC DMA request lines: 4 I/O ports: 0x0-0xf 0x80-0x8f 0xc0-0xdf unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.LPC_.SPKR I/O ports: 0x61 fpupnp0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.LPC_.FPU_ I/O ports: 0xf0 atrtc0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.LPC_.RTC_ Interrupt request lines: 8 I/O ports: 0x70-0x71 atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.LPC_.KBD_ Interrupt request lines: 1 I/O ports: 0x60 0x64 atkbd0 psm0 Interrupt request lines: 12 psmcpnp0 pnpinfo _HID=LEN0020 _UID=0 at handle=\_SB_.PCI0.LPC_.MOU_ unknown pnpinfo _HID=SMO1200 _UID=1 at handle=\_SB_.PCI0.LPC_.TPM_ I/O memory addresses: 0xfed40000-0xfed44fff unknown pnpinfo _HID=PNP0C09 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__ unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.PUBS battery0 pnpinfo _HID=PNP0C0A _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.BAT0 unknown pnpinfo _HID=PNP0C0A _UID=1 at handle=\_SB_.PCI0.LPC_.EC__.BAT1 acpi_acad0 pnpinfo _HID=ACPI0003 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.AC__ unknown pnpinfo _HID=LEN0068 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.HKEY unknown pnpinfo _HID=IBM0079 _UID=0 at handle=\_SB_.GDCK unknown pnpinfo _HID=PNP0C14 _UID=1 at handle=\_SB_.WMI1 unknown pnpinfo _HID=PNP0C14 _UID=2 at handle=\_SB_.WMI2 acpi_tz0 pnpinfo _HID=none _UID=0 at handle=\_TZ_.THM0 acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x408-0x40b == == hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family MEI Controller' class = simple comms cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[8c] = MSI supports 1 message, 64 bit em0@pci0:0:25:0: class=0x020000 card=0x21ce17aa chip=0x15028086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82579LM Gigabit Network Connection' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:0: class=0x0c0320 card=0x21da17aa chip=0x1c2d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP hdac0@pci0:0:27:0: class=0x040300 card=0x21da17aa chip=0x1c208086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family High Definition Audio Controller' class = multimedia subclass = HDA cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR link x0(x0) ecap 0002[100] = VC 1 max VC1 ecap 0005[130] = Root Complex Link Declaration 1 pcib1@pci0:0:28:0: class=0x060400 card=0x21da17aa chip=0x1c108086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib2@pci0:0:28:1: class=0x060400 card=0x21da17aa chip=0x1c128086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 2' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib3@pci0:0:28:3: class=0x060400 card=0x21da17aa chip=0x1c168086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 4' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib4@pci0:0:28:4: class=0x060400 card=0x21da17aa chip=0x1c188086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 5' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 ehci1@pci0:0:29:0: class=0x0c0320 card=0x21da17aa chip=0x1c268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP isab0@pci0:0:31:0: class=0x060100 card=0x21da17aa chip=0x1c4f8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'QM67 Express Chipset Family LPC Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: AMT, 4 PCI-e x1 slots ahci0@pci0:0:31:2: class=0x010601 card=0x21da17aa chip=0x1c038086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller' class = mass storage subclass = SATA cap 05[80] = MSI supports 1 message enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP none1@pci0:0:31:3: class=0x0c0500 card=0x21da17aa chip=0x1c228086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family SMBus Controller' class = serial bus subclass = SMBus iwn0@pci0:3:0:0: class=0x028000 card=0x11118086 chip=0x42388086 rev=0x35 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Ultimate-N 6300' class = network cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 0024d7ffffcf9070 sdhci0@pci0:13:0:0: class=0x088001 card=0x21da17aa chip=0xe8221180 rev=0x07 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'MMC/SD Host Controller' class = base peripheral cap 05[50] = MSI supports 1 message, 64 bit cap 01[78] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[80] = PCI-Express 1 endpoint max data 128(128) link x1(x1) ecap 0002[100] = VC 1 max VC0 ecap 0001[800] = AER 1 0 fatal 0 non-fatal 2 corrected == Cheers. -- Lyubomir Grigorov (bgalakazam) From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 17 09:11:10 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A658FC8C; Wed, 17 Oct 2012 09:11:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id EAA778FC14; Wed, 17 Oct 2012 09:11:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q9H9AR6c087933; Wed, 17 Oct 2012 20:10:27 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 17 Oct 2012 20:10:27 +1100 (EST) From: Ian Smith To: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= Subject: Re: x220 notes In-Reply-To: Message-ID: <20121017173848.U88114@sola.nimnet.asn.au> References: <4E836C06.9070405@gmail.com> <20120403210619.Q2060@sola.nimnet.asn.au> <4F7DAAB0.2010206@gmail.com> <4F7E2D5C.3020506@gmail.com> <4F7F9504.1030405@gmail.com> <20120814102409.7dc335b8@X220.ovitrap.com> <20121011094459.12ee1653@X220.ovitrap.com> <50778671.9020703@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 09:11:10 -0000 On Tue, 16 Oct 2012, ??????? ???????? wrote: > I set a lower light (5-6) during BIOS boot, and if needed I modify manually > in X. I monitored my CPU usage and did notice that the CPU takes its sweet > time to lower the frequency (Windows keeps the frequency the same 99.67, > but changes the multiplier from 8 to 32). I don't know if FreeBSD does that > or it only manipulates the frequency. The multiplier makes more sense. > Also, CPU cores in X stay at 50C. In Windows at no activicy they drop to > 44C and if no strenuous activity for a while, to 40C. > > It would be great if FreeBSD could downgrade the frequency faster upon no > load. I use this: > powerd_flags="-a hiadaptive -b adaptive -i 85 -r 60 -p 100" powerd(8) says: Adaptive mode attempts to strike a balance by degrading performance when the system appears idle and increasing it when the system is busy. It offers a good balance between a small performance loss for greatly increased power savings. Hiadaptive mode is like adaptive mode, but tuned for systems where performance and interactivity are more important than power consumption. It increases frequency faster, reduces the fre- quency less aggressively and will maintain full frequency for longer. So you want to use adaptive rather than hiadaptive, as power consumption is more important to you. Also, -i probably should be lower than -r, as when load is less than 85% it will decrease frequency, but if it's then still higher than 60% powerd might kick it up again. After experiments I wound up using "-a adp -b adp -i 50 -r 80 -p 200" which is nearer the defaults, but mine is only a two-speed P3 and not so indicative for you. Best way is likely to stop powerd (service powerd stop) then run 'powerd -v ..' in a root terminal - maybe using script(1) to record results - and watch it dance under various sorts of load, with different -i and -r parameters. You will clearly see the difference between adp and hadp. > I am always looking for the "perfect" FreeBSD laptop, but I guess it just > doesn't exist. And I do need my 7-8 hours of battery with wireless on. If > you guys have any suggestions on further optimizing the power usage and > automating the regulation, please let me know (like turning off and on USB > devices, spinning down the HDD, etc), also if you know about controlling > the multiplier instead of the frequency. Adrian, true to form, has pounced on your wireless :) I'm not a fan of spinning down HDs myself; if you do, you need to watch out for the dreaded Load Cycle Count issue (see ataidle(8)), and things like cron tasks that may spin it back up frequently. This and very much more information on power saving by Alexander Motin - who most recently updated powerd and added eventtimers(4) to 9.X - in his excellent guide: http://wiki.freebsd.org/TuningPowerConsumption As for the multiplier thing, it depends on which cpufreq(4) drivers your system is using. If it's a Core 2 Duo or i{5,7}, then both voltage and frequency are controlled, frequency by changing multiplier I assume; you should look at the code used by your processor. Also, don't miss advice there and elsewhere to disable throttling and just use est cpufreq(4) drivers, and for using C states to advantage. Before and after doing all that, compare differences for: % sysctl dev.cpu.0.freq_levels % sysctl dev.cpu |grep cx cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 18 01:08:56 2012 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C23F0DCF; Thu, 18 Oct 2012 01:08:56 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C3C4C8FC0C; Thu, 18 Oct 2012 01:08:55 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so3731067bkc.13 for ; Wed, 17 Oct 2012 18:08:54 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=P0wLrQSN6kiCl+2ezc/oCnpebpNLDPFmLsvvvVCbnM0=; b=ezPG7+ctR2f6lL55Y2fdvtsQDvLwdPMs3GOY+5sxNu9KUij9mOfXB1xhDUP4QsdRu+ or+cxVeONrpYnWULYut7UnIJjbTH+fo6+jZkdWuBQOXVSiHarSKhI3LgNepQahS3waez 88CvvcNP/5kEIZJws2nQo/9aLTwGOOv8oVKyYh4e4IsQ1saSU7h/NQ7sUC8aPYeEBDsY cYmX8LlUlMXR2XEK1bn5WTgigkK1yd2YbgB/JAI82y3+/BF7fqdoTdL8VnIj2p9tc+XH 15/kuLuVWDOfi9XVOPz9qk6iIGkdtv4sAr8ig+vErS5SEDJ1NrGQxjiL3Uhp8gIbHAXT 9bYA== Received: by 10.204.129.16 with SMTP id m16mr5850743bks.136.1350522534700; Wed, 17 Oct 2012 18:08:54 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Wed, 17 Oct 2012 18:08:34 -0700 (PDT) In-Reply-To: <201210151112.03393.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> <201210151112.03393.jhb@freebsd.org> From: Alberto Villa Date: Thu, 18 Oct 2012 03:08:34 +0200 X-Google-Sender-Auth: wfNxUXuWSWhmdMsAgebiHKu9CnE Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 01:08:57 -0000 On Mon, Oct 15, 2012 at 5:12 PM, John Baldwin wrote: > Interesting. Can you get an acpidump? Sure: http://people.FreeBSD.org/~avilla/files/avilla.asl.gz I'd be glad to solve my problems with ACPI! -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 18 01:08:56 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C23F0DCF; Thu, 18 Oct 2012 01:08:56 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C3C4C8FC0C; Thu, 18 Oct 2012 01:08:55 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so3731067bkc.13 for ; Wed, 17 Oct 2012 18:08:54 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=P0wLrQSN6kiCl+2ezc/oCnpebpNLDPFmLsvvvVCbnM0=; b=ezPG7+ctR2f6lL55Y2fdvtsQDvLwdPMs3GOY+5sxNu9KUij9mOfXB1xhDUP4QsdRu+ or+cxVeONrpYnWULYut7UnIJjbTH+fo6+jZkdWuBQOXVSiHarSKhI3LgNepQahS3waez 88CvvcNP/5kEIZJws2nQo/9aLTwGOOv8oVKyYh4e4IsQ1saSU7h/NQ7sUC8aPYeEBDsY cYmX8LlUlMXR2XEK1bn5WTgigkK1yd2YbgB/JAI82y3+/BF7fqdoTdL8VnIj2p9tc+XH 15/kuLuVWDOfi9XVOPz9qk6iIGkdtv4sAr8ig+vErS5SEDJ1NrGQxjiL3Uhp8gIbHAXT 9bYA== Received: by 10.204.129.16 with SMTP id m16mr5850743bks.136.1350522534700; Wed, 17 Oct 2012 18:08:54 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Wed, 17 Oct 2012 18:08:34 -0700 (PDT) In-Reply-To: <201210151112.03393.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> <201210151112.03393.jhb@freebsd.org> From: Alberto Villa Date: Thu, 18 Oct 2012 03:08:34 +0200 X-Google-Sender-Auth: wfNxUXuWSWhmdMsAgebiHKu9CnE Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 01:08:57 -0000 On Mon, Oct 15, 2012 at 5:12 PM, John Baldwin wrote: > Interesting. Can you get an acpidump? Sure: http://people.FreeBSD.org/~avilla/files/avilla.asl.gz I'd be glad to solve my problems with ACPI! -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 18 13:47:35 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3273E7B1; Thu, 18 Oct 2012 13:47:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 02FC68FC14; Thu, 18 Oct 2012 13:47:35 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5FDDFB980; Thu, 18 Oct 2012 09:47:34 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Thu, 18 Oct 2012 08:58:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210151112.03393.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210180858.35282.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Oct 2012 09:47:34 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:47:35 -0000 On Wednesday, October 17, 2012 9:08:34 pm Alberto Villa wrote: > On Mon, Oct 15, 2012 at 5:12 PM, John Baldwin wrote: > > Interesting. Can you get an acpidump? > > Sure: > http://people.FreeBSD.org/~avilla/files/avilla.asl.gz > > I'd be glad to solve my problems with ACPI! Ah, looks like your BIOS excludes DOD_DEVID_SCHEME_STD from it's _ADR methods (but does included it in on the list of displays returned by _DOD). Please test this updated version: Index: acpi_video.c =================================================================== --- acpi_video.c (revision 241683) +++ acpi_video.c (working copy) @@ -320,7 +320,8 @@ acpi_video_resume(device_t dev) ACPI_SERIAL_BEGIN(video_output); STAILQ_FOREACH_SAFE(vo, &sc->vid_outputs, vo_next, vn) { if ((vo->adr & DOD_DEVID_MASK_FULL) != DOD_DEVID_LCD && - (vo->adr & DOD_DEVID_MASK) != DOD_DEVID_INTDFP) + (vo->adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) != + (DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP)) continue; if ((vo_get_device_status(vo->handle) & DCS_ACTIVE) == 0) @@ -467,38 +468,40 @@ acpi_video_vo_init(UINT32 adr) ACPI_SERIAL_ASSERT(video); - switch (adr & DOD_DEVID_MASK) { + /* Assume an unknown unit by default. */ + desc = "unknown output"; + type = "out"; + voqh = &other_units; + + switch (adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) { case DOD_DEVID_MONITOR: if ((adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) { /* DOD_DEVID_LCD is a common, backward compatible ID */ desc = "Internal/Integrated Digital Flat Panel"; type = "lcd"; voqh = &lcd_units; - } else { - desc = "VGA CRT or VESA Compatible Analog Monitor"; - type = "crt"; - voqh = &crt_units; } break; - case DOD_DEVID_TV: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR: + desc = "VGA CRT or VESA Compatible Analog Monitor"; + type = "crt"; + voqh = &crt_units; + break; + case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV: desc = "TV/HDTV or Analog-Video Monitor"; type = "tv"; voqh = &tv_units; break; - case DOD_DEVID_EXT: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT: desc = "External Digital Monitor"; type = "ext"; voqh = &ext_units; break; - case DOD_DEVID_INTDFP: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP: desc = "Internal/Integrated Digital Flat Panel"; type = "lcd"; voqh = &lcd_units; break; - default: - desc = "unknown output"; - type = "out"; - voqh = &other_units; } n = 0; @@ -633,21 +636,25 @@ acpi_video_vo_destroy(struct acpi_video_output *vo AcpiOsFree(vo->vo_levels); } - switch (vo->adr & DOD_DEVID_MASK) { + voqh = &other_units; + + switch (vo->adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) { case DOD_DEVID_MONITOR: + if ((vo->adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) + voqh = &lcd_units; + break; + case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR: voqh = &crt_units; break; - case DOD_DEVID_TV: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV: voqh = &tv_units; break; - case DOD_DEVID_EXT: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT: voqh = &ext_units; break; - case DOD_DEVID_INTDFP: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP: voqh = &lcd_units; break; - default: - voqh = &other_units; } STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next); free(vo, M_ACPIVIDEO); @@ -905,8 +912,14 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 l return (AE_OK); for (i = 0; i < argset->dod_pkg->Package.Count; i++) { + /* + * Some systems do not include DOD_DEVID_SCHEME_STD in + * the _ADR of output devices and some do, so just + * ignore DOD_DEVID_SCHEME_STD. + */ if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && - (val & DOD_DEVID_MASK_FULL) == adr) { + (val & DOD_DEVID_MASK_FULL) == + (adr & ~DOD_DEVID_SCHEME_STD)) { argset->callback(handle, val, argset->context); argset->count++; } -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 18 13:47:35 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5B887B3; Thu, 18 Oct 2012 13:47:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95DF68FC16; Thu, 18 Oct 2012 13:47:35 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0D38B98A; Thu, 18 Oct 2012 09:47:34 -0400 (EDT) From: John Baldwin To: Juergen Lock Subject: Re: Dell acpi_video patch Date: Thu, 18 Oct 2012 08:59:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> <20121012163349.GA63588@triton8.kn-bremen.de> In-Reply-To: <20121012163349.GA63588@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210180859.14457.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Oct 2012 09:47:35 -0400 (EDT) Cc: avilla@freebsd.org, freebsd-acpi@freebsd.org, mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:47:35 -0000 On Friday, October 12, 2012 12:33:49 pm Juergen Lock wrote: > On Fri, Oct 12, 2012 at 10:06:17AM -0400, John Baldwin wrote: > > On Friday, October 05, 2012 5:53:16 pm Juergen Lock wrote: > > > Hi! > > > > > > I finally took a closer look why acpi_video found nothing on my > > > Dell laptop (Precision M4500), and came up with this patch: > > > > > > --- sys/dev/acpica/acpi_video.c.orig > > > +++ sys/dev/acpica/acpi_video.c > > > @@ -906,7 +906,7 @@ vid_enum_outputs_subr(ACPI_HANDLE handle > > > > > > for (i = 0; i < argset->dod_pkg->Package.Count; i++) { > > > if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && > > > - (val & DOD_DEVID_MASK_FULL) == adr) { > > > + (val & (DOD_DEVID_MASK_FULL | 0x80000000)) == adr) { > > > argset->callback(handle, val, argset->context); > > > argset->count++; > > > } > > > > > > which gives me: > > > > I think this is correct, but in we need to do more to properly handle that > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > device ID unless that bit is set (except for the special case of > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > spec. I think this larger patch will do that while also fixing your case: > > Thank you, yes that still works for me the same as my original patch: Can you please test this updated patch as well: Index: acpi_video.c =================================================================== --- acpi_video.c (revision 241683) +++ acpi_video.c (working copy) @@ -320,7 +320,8 @@ acpi_video_resume(device_t dev) ACPI_SERIAL_BEGIN(video_output); STAILQ_FOREACH_SAFE(vo, &sc->vid_outputs, vo_next, vn) { if ((vo->adr & DOD_DEVID_MASK_FULL) != DOD_DEVID_LCD && - (vo->adr & DOD_DEVID_MASK) != DOD_DEVID_INTDFP) + (vo->adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) != + (DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP)) continue; if ((vo_get_device_status(vo->handle) & DCS_ACTIVE) == 0) @@ -467,38 +468,40 @@ acpi_video_vo_init(UINT32 adr) ACPI_SERIAL_ASSERT(video); - switch (adr & DOD_DEVID_MASK) { + /* Assume an unknown unit by default. */ + desc = "unknown output"; + type = "out"; + voqh = &other_units; + + switch (adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) { case DOD_DEVID_MONITOR: if ((adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) { /* DOD_DEVID_LCD is a common, backward compatible ID */ desc = "Internal/Integrated Digital Flat Panel"; type = "lcd"; voqh = &lcd_units; - } else { - desc = "VGA CRT or VESA Compatible Analog Monitor"; - type = "crt"; - voqh = &crt_units; } break; - case DOD_DEVID_TV: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR: + desc = "VGA CRT or VESA Compatible Analog Monitor"; + type = "crt"; + voqh = &crt_units; + break; + case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV: desc = "TV/HDTV or Analog-Video Monitor"; type = "tv"; voqh = &tv_units; break; - case DOD_DEVID_EXT: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT: desc = "External Digital Monitor"; type = "ext"; voqh = &ext_units; break; - case DOD_DEVID_INTDFP: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP: desc = "Internal/Integrated Digital Flat Panel"; type = "lcd"; voqh = &lcd_units; break; - default: - desc = "unknown output"; - type = "out"; - voqh = &other_units; } n = 0; @@ -633,21 +636,25 @@ acpi_video_vo_destroy(struct acpi_video_output *vo AcpiOsFree(vo->vo_levels); } - switch (vo->adr & DOD_DEVID_MASK) { + voqh = &other_units; + + switch (vo->adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) { case DOD_DEVID_MONITOR: + if ((vo->adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) + voqh = &lcd_units; + break; + case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR: voqh = &crt_units; break; - case DOD_DEVID_TV: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV: voqh = &tv_units; break; - case DOD_DEVID_EXT: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT: voqh = &ext_units; break; - case DOD_DEVID_INTDFP: + case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP: voqh = &lcd_units; break; - default: - voqh = &other_units; } STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next); free(vo, M_ACPIVIDEO); @@ -905,8 +912,14 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 l return (AE_OK); for (i = 0; i < argset->dod_pkg->Package.Count; i++) { + /* + * Some systems do not include DOD_DEVID_SCHEME_STD in + * the _ADR of output devices and some do, so just + * ignore DOD_DEVID_SCHEME_STD. + */ if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && - (val & DOD_DEVID_MASK_FULL) == adr) { + (val & DOD_DEVID_MASK_FULL) == + (adr & ~DOD_DEVID_SCHEME_STD)) { argset->callback(handle, val, argset->context); argset->count++; } -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 18 19:59:57 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65601250; Thu, 18 Oct 2012 19:59:57 +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 9013E8FC17; Thu, 18 Oct 2012 19:59:56 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 7275C1E000E3; Thu, 18 Oct 2012 21:59:55 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q9IJvOA5010060; Thu, 18 Oct 2012 21:57:24 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q9IJvNTF010059; Thu, 18 Oct 2012 21:57:23 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 18 Oct 2012 21:57:23 +0200 To: John Baldwin Subject: Re: Dell acpi_video patch Message-ID: <20121018195723.GA10042@triton8.kn-bremen.de> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> <20121012163349.GA63588@triton8.kn-bremen.de> <201210180859.14457.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201210180859.14457.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: avilla@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:59:57 -0000 On Thu, Oct 18, 2012 at 08:59:14AM -0400, John Baldwin wrote: > On Friday, October 12, 2012 12:33:49 pm Juergen Lock wrote: > > On Fri, Oct 12, 2012 at 10:06:17AM -0400, John Baldwin wrote: > > > On Friday, October 05, 2012 5:53:16 pm Juergen Lock wrote: > > > > Hi! > > > > > > > > I finally took a closer look why acpi_video found nothing on my > > > > Dell laptop (Precision M4500), and came up with this patch: > > > > > > > > --- sys/dev/acpica/acpi_video.c.orig > > > > +++ sys/dev/acpica/acpi_video.c > > > > @@ -906,7 +906,7 @@ vid_enum_outputs_subr(ACPI_HANDLE handle > > > > > > > > for (i = 0; i < argset->dod_pkg->Package.Count; i++) { > > > > if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && > > > > - (val & DOD_DEVID_MASK_FULL) == adr) { > > > > + (val & (DOD_DEVID_MASK_FULL | 0x80000000)) == adr) { > > > > argset->callback(handle, val, argset->context); > > > > argset->count++; > > > > } > > > > > > > > which gives me: > > > > > > I think this is correct, but in we need to do more to properly handle that > > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > > device ID unless that bit is set (except for the special case of > > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > > spec. I think this larger patch will do that while also fixing your case: > > > > Thank you, yes that still works for me the same as my original patch: > > Can you please test this updated patch as well: > > Index: acpi_video.c > =================================================================== > --- acpi_video.c (revision 241683) > +++ acpi_video.c (working copy) > @@ -320,7 +320,8 @@ acpi_video_resume(device_t dev) > ACPI_SERIAL_BEGIN(video_output); > STAILQ_FOREACH_SAFE(vo, &sc->vid_outputs, vo_next, vn) { > if ((vo->adr & DOD_DEVID_MASK_FULL) != DOD_DEVID_LCD && > - (vo->adr & DOD_DEVID_MASK) != DOD_DEVID_INTDFP) > + (vo->adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) != > + (DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP)) > continue; > > if ((vo_get_device_status(vo->handle) & DCS_ACTIVE) == 0) > @@ -467,38 +468,40 @@ acpi_video_vo_init(UINT32 adr) > > ACPI_SERIAL_ASSERT(video); > > - switch (adr & DOD_DEVID_MASK) { > + /* Assume an unknown unit by default. */ > + desc = "unknown output"; > + type = "out"; > + voqh = &other_units; > + > + switch (adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) { > case DOD_DEVID_MONITOR: > if ((adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) { > /* DOD_DEVID_LCD is a common, backward compatible ID */ > desc = "Internal/Integrated Digital Flat Panel"; > type = "lcd"; > voqh = &lcd_units; > - } else { > - desc = "VGA CRT or VESA Compatible Analog Monitor"; > - type = "crt"; > - voqh = &crt_units; > } > break; > - case DOD_DEVID_TV: > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR: > + desc = "VGA CRT or VESA Compatible Analog Monitor"; > + type = "crt"; > + voqh = &crt_units; > + break; > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV: > desc = "TV/HDTV or Analog-Video Monitor"; > type = "tv"; > voqh = &tv_units; > break; > - case DOD_DEVID_EXT: > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT: > desc = "External Digital Monitor"; > type = "ext"; > voqh = &ext_units; > break; > - case DOD_DEVID_INTDFP: > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP: > desc = "Internal/Integrated Digital Flat Panel"; > type = "lcd"; > voqh = &lcd_units; > break; > - default: > - desc = "unknown output"; > - type = "out"; > - voqh = &other_units; > } > > n = 0; > @@ -633,21 +636,25 @@ acpi_video_vo_destroy(struct acpi_video_output *vo > AcpiOsFree(vo->vo_levels); > } > > - switch (vo->adr & DOD_DEVID_MASK) { > + voqh = &other_units; > + > + switch (vo->adr & (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) { > case DOD_DEVID_MONITOR: > + if ((vo->adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) > + voqh = &lcd_units; > + break; > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR: > voqh = &crt_units; > break; > - case DOD_DEVID_TV: > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV: > voqh = &tv_units; > break; > - case DOD_DEVID_EXT: > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT: > voqh = &ext_units; > break; > - case DOD_DEVID_INTDFP: > + case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP: > voqh = &lcd_units; > break; > - default: > - voqh = &other_units; > } > STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next); > free(vo, M_ACPIVIDEO); > @@ -905,8 +912,14 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 l > return (AE_OK); > > for (i = 0; i < argset->dod_pkg->Package.Count; i++) { > + /* > + * Some systems do not include DOD_DEVID_SCHEME_STD in > + * the _ADR of output devices and some do, so just > + * ignore DOD_DEVID_SCHEME_STD. > + */ > if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && > - (val & DOD_DEVID_MASK_FULL) == adr) { > + (val & DOD_DEVID_MASK_FULL) == > + (adr & ~DOD_DEVID_SCHEME_STD)) { > argset->callback(handle, val, argset->context); > argset->count++; > } > > -- > John Baldwin That still works the same: % sysctl hw.acpi.video. hw.acpi.video.crt0.active: 0 hw.acpi.video.lcd0.active: 0 hw.acpi.video.lcd0.brightness: 100 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.economy: 46 hw.acpi.video.lcd0.levels: 100 46 0 6 13 20 26 33 40 46 53 60 66 73 80 86 93 100 hw.acpi.video.ext0.active: 0 hw.acpi.video.ext1.active: 0 hw.acpi.video.ext2.active: 0 hw.acpi.video.ext3.active: 0 % Thanx, :) Juergen From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 18 20:59:05 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4082A26A; Thu, 18 Oct 2012 20:59:05 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6DE8FC0C; Thu, 18 Oct 2012 20:59:04 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so4228897bkc.13 for ; Thu, 18 Oct 2012 13:59:03 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=yRCrsFAYVtDJQ6lg3erUrRRza9BJI6H75Ty9SzkAnIU=; b=RUCEs9eQdSx0Achlk67bt8hpcRW+uGJQquBA9JZ9CLtGFcs0CxkgoNKVy72Dqy8h70 JENRYs/BmOR1d1oD6iumVaieQuvsnoKdL+MC+UyBqTgGeXgbdNh5QMtOvwUkQC5tl8nD qlzfKWo8zKjNbg4uV7ct4Epxp1KvVdBuhW3iS2VOhQytEp60xgXeX3Tz+pL/zlRampQ3 yh0YE9Q4yzaKqGa4Tv9/9nG8QnICvLZTnkdL1On5URkzh8WjGBCAA3vtRIeaknvr7vP/ 317RIErBy/QjAqerFAKD+WSXVLAr599GDpfeqqM9jqaTL/DC8IThbI7ecT5fhJ28+a03 T/3Q== Received: by 10.204.146.83 with SMTP id g19mr6962919bkv.33.1350593943078; Thu, 18 Oct 2012 13:59:03 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Thu, 18 Oct 2012 13:58:42 -0700 (PDT) In-Reply-To: <201210180858.35282.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210151112.03393.jhb@freebsd.org> <201210180858.35282.jhb@freebsd.org> From: Alberto Villa Date: Thu, 18 Oct 2012 22:58:42 +0200 X-Google-Sender-Auth: bJzDYvtIDVxaUpwTDRAaTDssw7s Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:59:05 -0000 On Thu, Oct 18, 2012 at 2:58 PM, John Baldwin wrote: > Ah, looks like your BIOS excludes DOD_DEVID_SCHEME_STD from it's _ADR > methods (but does included it in on the list of displays returned by > _DOD). > > Please test this updated version: Still the same: hw.acpi.video.out0.active: 1 hw.acpi.video.out1.active: 1 hw.acpi.video.out1.brightness: 100 hw.acpi.video.out1.fullpower: 100 hw.acpi.video.out1.economy: 50 hw.acpi.video.out1.levels: 100 50 0 10 20 30 40 50 60 70 80 90 100 hw.acpi.video.out2.active: 1 -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 18 21:18:07 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58E89B4B; Thu, 18 Oct 2012 21:18:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 24FEC8FC0C; Thu, 18 Oct 2012 21:18:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8E6CCB972; Thu, 18 Oct 2012 17:18:06 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Thu, 18 Oct 2012 17:16:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210180858.35282.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210181716.31486.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Oct 2012 17:18:06 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:18:07 -0000 On Thursday, October 18, 2012 4:58:42 pm Alberto Villa wrote: > On Thu, Oct 18, 2012 at 2:58 PM, John Baldwin wrote: > > Ah, looks like your BIOS excludes DOD_DEVID_SCHEME_STD from it's _ADR > > methods (but does included it in on the list of displays returned by > > _DOD). > > > > Please test this updated version: > > Still the same: > hw.acpi.video.out0.active: 1 > hw.acpi.video.out1.active: 1 > hw.acpi.video.out1.brightness: 100 > hw.acpi.video.out1.fullpower: 100 > hw.acpi.video.out1.economy: 50 > hw.acpi.video.out1.levels: 100 50 0 10 20 30 40 50 60 70 80 90 100 > hw.acpi.video.out2.active: 1 Ok, can you possibly hack acpi_video to output the values returned _DOD (in hex) and the _ADR values (in hex) of your outputs? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 14:34:30 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DAD9FCF; Fri, 19 Oct 2012 14:34:30 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3718FC12; Fri, 19 Oct 2012 14:34:29 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so267706bkc.13 for ; Fri, 19 Oct 2012 07:34:28 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/LGSILkt0ZWEHD/8TnZAMcdJqVeWxxPsKOjkUkXosF4=; b=xCFdm/K7fh2XT/pRiBIkR8ScIDvRJssekOg0COawxu/L/owI3yzN9HAXR4DdEFKeNX Jnxwo+vc1U0Z0BgMVnNEdP1FtN1ZYhhyn9LexPI0Qx01BIWfHTII14ondKhPWgozUirc xLGn2IGzPGw9EiXSci/TCl4WvPAhPR+OuaxSyuqvLYzGABIkmIXgwKklHzryO16pgJLQ PUdbvdbuXr7kdEAH1Tt2FJzirGdPDYEcCQFv4G9XquzHL6/97cGVdsGrCEO8D7gSXw7q yAx0Oj38leo2O/fTJ/tMWW/GkfID1K22/aGyKInsA4Fsm9tRrM69H+8PqSKf8Cl0dUBT KwSA== Received: by 10.204.150.209 with SMTP id z17mr538836bkv.8.1350657268311; Fri, 19 Oct 2012 07:34:28 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 07:34:08 -0700 (PDT) In-Reply-To: <201210181716.31486.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210180858.35282.jhb@freebsd.org> <201210181716.31486.jhb@freebsd.org> From: Alberto Villa Date: Fri, 19 Oct 2012 16:34:08 +0200 X-Google-Sender-Auth: 91KYDWYjvR8EmTZqiqcQ5NUVHzo Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:34:30 -0000 On Thu, Oct 18, 2012 at 11:16 PM, John Baldwin wrote: > Ok, can you possibly hack acpi_video to output the values returned _DOD (in > hex) and the _ADR values (in hex) of your outputs? I've read the ACPI spec and checked my dump, now I see what you mean. Nonetheless, I think you have confused the _STD bit with the _BIOS one: 0x00010100, 0x00010118, 0x00010121 So acpi_video.c behaves just as expected. By the way, the GFX device has a _DOD method too, which returns 0x0400 (an LCD device)... -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 15:24:20 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05A3AB18; Fri, 19 Oct 2012 15:24:20 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 005788FC12; Fri, 19 Oct 2012 15:24:18 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so293350bkc.13 for ; Fri, 19 Oct 2012 08:24:17 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/uDFjawd0zwwGUoX1aNeebeBVsEjt6Ds2nFyALIubLc=; b=hGptjki8NP4ytDtYNQvvaygCZA8MPUMaBwtMVzatZPzyqLxxMc7robXt6Paso0bR3Q yC7a6WmC+0iUwrf7tigtIeGBlQ1abe5sWKyBLKWRDnvByPZO1VTaRMOkHrrHri9buKJN qq2uRP0igtk35T+MuX/ZEkfwdMlniRdTx+UnRuobOWFXzY7twbfBq+88ZNlmzVtpDDdM g0/LYhwk+EVMsKiQYDbvyJ4O1guAppwlTHOZ7TcfexuVuP2X1CNWHpeLTnnPTG5OVkgM pIOZIKh0mWvVD7hzAKe13IQdz8nJiNTye97Gdzydv52sflItNK5w7YIF3y6qPlI1oOJL kXjg== Received: by 10.205.118.136 with SMTP id fq8mr569814bkc.24.1350660257659; Fri, 19 Oct 2012 08:24:17 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 08:23:57 -0700 (PDT) In-Reply-To: <201210121006.17276.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> From: Alberto Villa Date: Fri, 19 Oct 2012 17:23:57 +0200 X-Google-Sender-Auth: -e10-WbPE1ONQz6s4UALnIwk8fQ Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:24:20 -0000 On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin wrote: > I think this is correct, but in we need to do more to properly handle that > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > device ID unless that bit is set (except for the special case of > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > spec. I think this larger patch will do that while also fixing your case: By the way, it looks like also 0x0100 and 0x0200 should be handled as legacy values: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/acpi/video.h;h=61109f2609fc3ee446ec43e242875b28ae719344;hb=HEAD http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/acpi/video.c;h=f94d4c818fc74dc9a076e8f67fe98d7bc6620a61;hb=HEAD -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 15:24:20 2012 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05A3AB18; Fri, 19 Oct 2012 15:24:20 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 005788FC12; Fri, 19 Oct 2012 15:24:18 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so293350bkc.13 for ; Fri, 19 Oct 2012 08:24:17 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/uDFjawd0zwwGUoX1aNeebeBVsEjt6Ds2nFyALIubLc=; b=hGptjki8NP4ytDtYNQvvaygCZA8MPUMaBwtMVzatZPzyqLxxMc7robXt6Paso0bR3Q yC7a6WmC+0iUwrf7tigtIeGBlQ1abe5sWKyBLKWRDnvByPZO1VTaRMOkHrrHri9buKJN qq2uRP0igtk35T+MuX/ZEkfwdMlniRdTx+UnRuobOWFXzY7twbfBq+88ZNlmzVtpDDdM g0/LYhwk+EVMsKiQYDbvyJ4O1guAppwlTHOZ7TcfexuVuP2X1CNWHpeLTnnPTG5OVkgM pIOZIKh0mWvVD7hzAKe13IQdz8nJiNTye97Gdzydv52sflItNK5w7YIF3y6qPlI1oOJL kXjg== Received: by 10.205.118.136 with SMTP id fq8mr569814bkc.24.1350660257659; Fri, 19 Oct 2012 08:24:17 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 08:23:57 -0700 (PDT) In-Reply-To: <201210121006.17276.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> From: Alberto Villa Date: Fri, 19 Oct 2012 17:23:57 +0200 X-Google-Sender-Auth: -e10-WbPE1ONQz6s4UALnIwk8fQ Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:24:20 -0000 On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin wrote: > I think this is correct, but in we need to do more to properly handle that > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > device ID unless that bit is set (except for the special case of > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > spec. I think this larger patch will do that while also fixing your case: By the way, it looks like also 0x0100 and 0x0200 should be handled as legacy values: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/acpi/video.h;h=61109f2609fc3ee446ec43e242875b28ae719344;hb=HEAD http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/acpi/video.c;h=f94d4c818fc74dc9a076e8f67fe98d7bc6620a61;hb=HEAD -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 15:32:33 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20EC7D0; Fri, 19 Oct 2012 15:32:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E59A78FC17; Fri, 19 Oct 2012 15:32:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 518E8B98E; Fri, 19 Oct 2012 11:32:32 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Fri, 19 Oct 2012 10:53:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210181716.31486.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201210191053.20041.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Oct 2012 11:32:32 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:32:33 -0000 On Friday, October 19, 2012 10:34:08 am Alberto Villa wrote: > On Thu, Oct 18, 2012 at 11:16 PM, John Baldwin wrote: > > Ok, can you possibly hack acpi_video to output the values returned _DOD= (in > > hex) and the _ADR values (in hex) of your outputs? >=20 > I've read the ACPI spec and checked my dump, now I see what you mean. > Nonetheless, I think you have confused the _STD bit with the _BIOS > one: >=20 > 0x00010100, > 0x00010118, > 0x00010121 >=20 > So acpi_video.c behaves just as expected. By the way, the GFX device > has a _DOD method too, which returns 0x0400 (an LCD device)... I'm looking at section B.4.2 in the 3.0b spec, it has a sample _DOD of: Method (_DOD, 0) { Return ( Package() { 0x00000110, // Primary LCD panel, not detectable by BIOS 0x80000100, // CRT type display, not detectable by BIOS 0x80000220, // TV type display, not detectable by the BIOS 0x80000411, // Secondary LCD panel, not detectable by BIOS } ) } The description of bit 31 is quite clear: Device ID Scheme 31 1 =E2=80=93 Uses the bit-field definitions above (bits 15:0) 0 =E2=80=93 Other scheme, contact the Video Chip Vendor Then there is table B-3: Table B-3: Example Device Ids Bits Definition 0x000xyyyy Bit 31 =3D 0. Other proprietary scheme - 0x110 Device ID is an e= xception. (See Note 3) 0x00000110 Integrated LCD Panel #1 using a common, backwards compatible ID 0x80000100 Integrated VGA CRT or VESA compatible Monitor #1 on Port0 0x80000240 Integrated TV #1 on Port4 0x80000410 Integrated Internal LCD Panel #1 on Port1 0x80000421 LVDS Panel #2 Dual-Link using Port2 & 3. (See Note 4) 0x80000131 VGA CRT or VESA compatible Monitor #2 on Port3 0x80000121 Dual-Link VGA CRT or VESA compatible Monitor #2 using Port2 & 3.= (See Note 4.) 0x80000320 DVI Monitor #1 on Port2 (shares Port2 with a Dual-Function DVI/T= V Encoder). (See Note 5) 0x80000331 DVI Monitor #2 on Port3 0x80000330 Dual-Link DVI Monitor #1 using Port2 & 3 0x80000231 TV #2 on Port2 (shares Port2 with a Dual-Function DVI/TV Encoder= ). (See Note 5) Notes: 3. When Bit 31 is 0, no assumptions can be made on which ID will be used for any particular display type. Contact the Video Chip vendor for details of the ID scheme employed. Looking back at earlier ACPI specs (1.0b and 2.0c), they did not mention bit 31 at all (well, it was required to be zero). Their examples are different= as well, but they don't define any meaning to the low bits, so I think we are correct in calling all of them plain outputs. Specifically, the "Display Type" bitfield (Bits 8:11) are undefined in the earlier specs, and 3.0b only claims they are defined if bit 31 is set. =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 15:32:33 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF18AD2; Fri, 19 Oct 2012 15:32:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8098FC18; Fri, 19 Oct 2012 15:32:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E090EB91C; Fri, 19 Oct 2012 11:32:32 -0400 (EDT) From: John Baldwin To: Juergen Lock Subject: Re: Dell acpi_video patch Date: Fri, 19 Oct 2012 11:14:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210180859.14457.jhb@freebsd.org> <20121018195723.GA10042@triton8.kn-bremen.de> In-Reply-To: <20121018195723.GA10042@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210191114.10340.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Oct 2012 11:32:33 -0400 (EDT) Cc: avilla@freebsd.org, freebsd-acpi@freebsd.org, mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:32:33 -0000 On Thursday, October 18, 2012 3:57:23 pm Juergen Lock wrote: > On Thu, Oct 18, 2012 at 08:59:14AM -0400, John Baldwin wrote: > > On Friday, October 12, 2012 12:33:49 pm Juergen Lock wrote: > > > On Fri, Oct 12, 2012 at 10:06:17AM -0400, John Baldwin wrote: > > > > On Friday, October 05, 2012 5:53:16 pm Juergen Lock wrote: > > > > > Hi! > > > > > > > > > > I finally took a closer look why acpi_video found nothing on my > > > > > Dell laptop (Precision M4500), and came up with this patch: > > > > > > > > > > --- sys/dev/acpica/acpi_video.c.orig > > > > > +++ sys/dev/acpica/acpi_video.c > > > > > @@ -906,7 +906,7 @@ vid_enum_outputs_subr(ACPI_HANDLE handle > > > > > > > > > > for (i = 0; i < argset->dod_pkg->Package.Count; i++) { > > > > > if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && > > > > > - (val & DOD_DEVID_MASK_FULL) == adr) { > > > > > + (val & (DOD_DEVID_MASK_FULL | 0x80000000)) == adr) { > > > > > argset->callback(handle, val, argset->context); > > > > > argset->count++; > > > > > } > > > > > > > > > > which gives me: > > > > > > > > I think this is correct, but in we need to do more to properly handle that > > > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > > > device ID unless that bit is set (except for the special case of > > > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > > > spec. I think this larger patch will do that while also fixing your case: > > > > > > Thank you, yes that still works for me the same as my original patch: > > > > Can you please test this updated patch as well: Sorry, one more request. I think I want to commit just your fix separately, but I have a slightly different version of it. Can you just double check this version: Index: acpi_video.c =================================================================== --- acpi_video.c (revision 241688) +++ acpi_video.c (working copy) @@ -906,7 +906,8 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 l for (i = 0; i < argset->dod_pkg->Package.Count; i++) { if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && - (val & DOD_DEVID_MASK_FULL) == adr) { + (val & DOD_DEVID_MASK_FULL) == + (adr & DOD_DEVID_MASK_FULL)) { argset->callback(handle, val, argset->context); argset->count++; } -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 15:42:19 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66C25B54; Fri, 19 Oct 2012 15:42:19 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 777388FC14; Fri, 19 Oct 2012 15:42:18 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so301813bkc.13 for ; Fri, 19 Oct 2012 08:42:17 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9UpxAq9voTX19mhjcRVCBHd516HjYz0dIlFrHU87bqM=; b=gHisjkW6nHLADK/Gk5X+8GDpbZ9WJPWi7LzGJzOpbd2dh0nSozU9XyQQTrJ+H2MYyA iV9gV3P+2+0YmDupZcEeZzUN80M8gmmmK2hWkoV+jd93MAiu7QXROh3YtMztutzlu3uM KrIg8kn09jcwVmA2Rqe9CE0Uo5pBAQF7q/JJtOy84EPF91s7Sd75gTlTT9r/0iyEwLc3 oNdmNeEhk1xpdTW5AzF69GP+IpJpVADFjeL5jkdjD2Mh68MMVn5X0viS6WltzahTaJJM Rw6Ti5R/84q9zFIHkgJgyL6ekJJ/x2s0syyOkTcEO/UAcPN2Dt852Sjdjdr7/hptXMFc mNuw== Received: by 10.204.8.215 with SMTP id i23mr578916bki.44.1350661336973; Fri, 19 Oct 2012 08:42:16 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 08:41:56 -0700 (PDT) In-Reply-To: <201210191053.20041.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210181716.31486.jhb@freebsd.org> <201210191053.20041.jhb@freebsd.org> From: Alberto Villa Date: Fri, 19 Oct 2012 17:41:56 +0200 X-Google-Sender-Auth: cmUE8NSMWzqhxfshs88JJFY75mM Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:42:19 -0000 On Fri, Oct 19, 2012 at 4:53 PM, John Baldwin wrote: > I'm looking at section B.4.2 in the 3.0b spec, it has a sample _DOD of: I've read section B.3.2 of 5.0 spec, which looks the same as 3.0b, but my IDs don't have bit 31 set, they have bit 16 (which is the difference between _DOD and _ADR you were probably talking about). Or am I missing the point? -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 18:12:39 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3B5463D; Fri, 19 Oct 2012 18:12:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 74F9D8FC17; Fri, 19 Oct 2012 18:12:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CCBEDB987; Fri, 19 Oct 2012 14:12:38 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Fri, 19 Oct 2012 13:13:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210191053.20041.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210191313.14246.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Oct 2012 14:12:38 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:12:39 -0000 On Friday, October 19, 2012 11:41:56 am Alberto Villa wrote: > On Fri, Oct 19, 2012 at 4:53 PM, John Baldwin wrote: > > I'm looking at section B.4.2 in the 3.0b spec, it has a sample _DOD of: > > I've read section B.3.2 of 5.0 spec, which looks the same as 3.0b, but > my IDs don't have bit 31 set, they have bit 16 (which is the > difference between _DOD and _ADR you were probably talking about). Or > am I missing the point? Yes, unless bit 31 is set, we can't know anything about bits 0-15 except that they are "unique". Specifically, we can't look at the "Display Type" bits to determine if an output device is a CRT vs LCD vs TV, etc. You can only do that if bit 31 is set. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 18:12:40 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7A3D649; Fri, 19 Oct 2012 18:12:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9783A8FC19; Fri, 19 Oct 2012 18:12:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 00282B98E; Fri, 19 Oct 2012 14:12:40 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Fri, 19 Oct 2012 13:34:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210191334.38712.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Oct 2012 14:12:40 -0400 (EDT) Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:12:40 -0000 On Friday, October 19, 2012 11:23:57 am Alberto Villa wrote: > On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin wrote: > > I think this is correct, but in we need to do more to properly handle that > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > device ID unless that bit is set (except for the special case of > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > spec. I think this larger patch will do that while also fixing your case: > > By the way, it looks like also 0x0100 and 0x0200 should be handled as > legacy values: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/acpi/video.h;h=61109f2609fc3ee446ec43e242875b28ae719344;hb=HEAD > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/acpi/video.c;h=f94d4c818fc74dc9a076e8f67fe98d7bc6620a61;hb=HEAD I considered that, but 1) it wouldn't help your laptop, and 2) the ACPI 3.0b spec where bit 31 is added specifically states (in the Note 3 I included in my prior e-mail) that 0x110 is the only valid legacy ID. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 18:12:40 2012 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7A3D649; Fri, 19 Oct 2012 18:12:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9783A8FC19; Fri, 19 Oct 2012 18:12:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 00282B98E; Fri, 19 Oct 2012 14:12:40 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Fri, 19 Oct 2012 13:34:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210191334.38712.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Oct 2012 14:12:40 -0400 (EDT) Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:12:40 -0000 On Friday, October 19, 2012 11:23:57 am Alberto Villa wrote: > On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin wrote: > > I think this is correct, but in we need to do more to properly handle that > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > device ID unless that bit is set (except for the special case of > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > spec. I think this larger patch will do that while also fixing your case: > > By the way, it looks like also 0x0100 and 0x0200 should be handled as > legacy values: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/acpi/video.h;h=61109f2609fc3ee446ec43e242875b28ae719344;hb=HEAD > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/acpi/video.c;h=f94d4c818fc74dc9a076e8f67fe98d7bc6620a61;hb=HEAD I considered that, but 1) it wouldn't help your laptop, and 2) the ACPI 3.0b spec where bit 31 is added specifically states (in the Note 3 I included in my prior e-mail) that 0x110 is the only valid legacy ID. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 18:47:55 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B52C4B7; Fri, 19 Oct 2012 18:47:55 +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 0F9128FC0A; Fri, 19 Oct 2012 18:47:54 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id D7A261E00107; Fri, 19 Oct 2012 20:47:46 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q9JIkHk8045126; Fri, 19 Oct 2012 20:46:17 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q9JIkHJI045125; Fri, 19 Oct 2012 20:46:17 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 19 Oct 2012 20:46:17 +0200 To: John Baldwin Subject: Re: Dell acpi_video patch Message-ID: <20121019184617.GA45092@triton8.kn-bremen.de> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210180859.14457.jhb@freebsd.org> <20121018195723.GA10042@triton8.kn-bremen.de> <201210191114.10340.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201210191114.10340.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: avilla@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:47:56 -0000 On Fri, Oct 19, 2012 at 11:14:10AM -0400, John Baldwin wrote: > On Thursday, October 18, 2012 3:57:23 pm Juergen Lock wrote: > > On Thu, Oct 18, 2012 at 08:59:14AM -0400, John Baldwin wrote: > > > On Friday, October 12, 2012 12:33:49 pm Juergen Lock wrote: > > > > On Fri, Oct 12, 2012 at 10:06:17AM -0400, John Baldwin wrote: > > > > > On Friday, October 05, 2012 5:53:16 pm Juergen Lock wrote: > > > > > > Hi! > > > > > > > > > > > > I finally took a closer look why acpi_video found nothing on my > > > > > > Dell laptop (Precision M4500), and came up with this patch: > > > > > > > > > > > > --- sys/dev/acpica/acpi_video.c.orig > > > > > > +++ sys/dev/acpica/acpi_video.c > > > > > > @@ -906,7 +906,7 @@ vid_enum_outputs_subr(ACPI_HANDLE handle > > > > > > > > > > > > for (i = 0; i < argset->dod_pkg->Package.Count; i++) { > > > > > > if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && > > > > > > - (val & DOD_DEVID_MASK_FULL) == adr) { > > > > > > + (val & (DOD_DEVID_MASK_FULL | 0x80000000)) == adr) { > > > > > > argset->callback(handle, val, argset->context); > > > > > > argset->count++; > > > > > > } > > > > > > > > > > > > which gives me: > > > > > > > > > > I think this is correct, but in we need to do more to properly handle that > > > > > flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the > > > > > device ID unless that bit is set (except for the special case of > > > > > DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b > > > > > spec. I think this larger patch will do that while also fixing your case: > > > > > > > > Thank you, yes that still works for me the same as my original patch: > > > > > > Can you please test this updated patch as well: > > Sorry, one more request. I think I want to commit just your fix separately, > but I have a slightly different version of it. Can you just double check > this version: > > Index: acpi_video.c > =================================================================== > --- acpi_video.c (revision 241688) > +++ acpi_video.c (working copy) > @@ -906,7 +906,8 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 l > > for (i = 0; i < argset->dod_pkg->Package.Count; i++) { > if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && > - (val & DOD_DEVID_MASK_FULL) == adr) { > + (val & DOD_DEVID_MASK_FULL) == > + (adr & DOD_DEVID_MASK_FULL)) { > argset->callback(handle, val, argset->context); > argset->count++; > } > > -- > John Baldwin Yup that still works the same: % sysctl hw.acpi.video hw.acpi.video.crt0.active: 0 hw.acpi.video.lcd0.active: 0 hw.acpi.video.lcd0.brightness: 100 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.economy: 46 hw.acpi.video.lcd0.levels: 100 46 0 6 13 20 26 33 40 46 53 60 66 73 80 86 93 100 hw.acpi.video.ext0.active: 0 hw.acpi.video.ext1.active: 0 hw.acpi.video.ext2.active: 0 hw.acpi.video.ext3.active: 0 % Thanx, :) Juergen From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 22:21:24 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DBE9BFB; Fri, 19 Oct 2012 22:21:24 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4978FC17; Fri, 19 Oct 2012 22:21:22 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so414064bkc.13 for ; Fri, 19 Oct 2012 15:21:21 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=UcxbJ84Szc2sPDtfBiH96MdjshHCIZomEPWaRifUH4c=; b=GciRJDuK3szbD6TaIizN5q4MQeXm87yQurep0sU6QogtbkpXw7EE22V96GtlFzDjeb qPp9bcjjdCXBHsS6v1HSTCwLHsFzS03fmvZMu/rY4ZOB5R/8g6vrsQraJEqLkh8ZaSl1 3qp3fner1qWWK8h+CmzAz1Ugvcu/ijt8ok0iV4ko/A02ACzWV+AWmnGfhJ4iOWfAz1rS S+u+6jHfvY0GVRHujzkeU0BIExBTUFjjhkZZTMeVEUMPVBtnr8KaLHdsYBvd81hdHaon 6TfHpeG5ecqpQJh5EksRsYPl/1KxWv3z01+9TDqTOEQMNqBRdUlJskFBF0TReNGZoiZ9 K62w== Received: by 10.204.8.215 with SMTP id i23mr826432bki.44.1350685281670; Fri, 19 Oct 2012 15:21:21 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 15:21:00 -0700 (PDT) In-Reply-To: <201210191313.14246.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210191053.20041.jhb@freebsd.org> <201210191313.14246.jhb@freebsd.org> From: Alberto Villa Date: Sat, 20 Oct 2012 00:21:00 +0200 X-Google-Sender-Auth: GI_-WgKHty-gIz7H-iq6DtBZJ0k Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:21:24 -0000 On Fri, Oct 19, 2012 at 7:13 PM, John Baldwin wrote: > Yes, unless bit 31 is set, we can't know anything about bits 0-15 except > that they are "unique". Specifically, we can't look at the "Display Type" > bits to determine if an output device is a CRT vs LCD vs TV, etc. You > can only do that if bit 31 is set. I know, I was saying that you probably confused bit 31 with bit 16, so the patch you proposed (about bit 31 being set in _DOD but not in _ADR) was not correct. ;) -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 22:24:58 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0791CA2; Fri, 19 Oct 2012 22:24:58 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D92268FC14; Fri, 19 Oct 2012 22:24:57 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so414761bkc.13 for ; Fri, 19 Oct 2012 15:24:56 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=0uIwboGC90JtcIURgExIqQ0EgQybddcJ40OOgyr6zGI=; b=PGr9vRB6wZHsuQUP40lqI0jHY5v7nNmDOo/pE98P+8MckZwijb0RbHj4FJRdWE3vNq uGjiKHUO7yK0FIDZ7UPvHWCybra0meIB1c6dVO5BYr9k8SuyVpyaPh2UCenbL4LomUEh opTdVFUeVHklCE+q6NIgdghEZHcGMaWKYlCwJ0k+nfHizmubu+U5HZsyWpHjzkjDiCaZ 1jUsw4P1QEdWLyZRJZIBAioXiTH9AO2JTMGM7v+aicBaZVTRKDM9eH93NccoHRWK/uc3 HUW5b9/Thmfyiej5NUQxSGg5KjTip/0881xs6bD2zW+t678wEy7YsudN5+o+O+DDaz4k rQFg== Received: by 10.204.129.16 with SMTP id m16mr848766bks.136.1350685496553; Fri, 19 Oct 2012 15:24:56 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 15:24:36 -0700 (PDT) In-Reply-To: <201210191334.38712.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> <201210191334.38712.jhb@freebsd.org> From: Alberto Villa Date: Sat, 20 Oct 2012 00:24:36 +0200 X-Google-Sender-Auth: 9KnMOMNW0KS2q0SctLucByfZl0g Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:24:59 -0000 On Fri, Oct 19, 2012 at 7:34 PM, John Baldwin wrote: > I considered that, but 1) it wouldn't help your laptop, and 2) the ACPI 3.0b > spec where bit 31 is added specifically states (in the Note 3 I included in > my prior e-mail) that 0x110 is the only valid legacy ID. Sure, it wasn't about my laptop, but a general consideration; also spec 5.0 lists only 0x0110, so it's better to stick to the spec as you say. By the way, I think the name of devices is not used anywhere (apart for an X.Org piece of code which I'm going to patch), so it's not important. -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 22:24:58 2012 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0791CA2; Fri, 19 Oct 2012 22:24:58 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D92268FC14; Fri, 19 Oct 2012 22:24:57 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so414761bkc.13 for ; Fri, 19 Oct 2012 15:24:56 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=0uIwboGC90JtcIURgExIqQ0EgQybddcJ40OOgyr6zGI=; b=PGr9vRB6wZHsuQUP40lqI0jHY5v7nNmDOo/pE98P+8MckZwijb0RbHj4FJRdWE3vNq uGjiKHUO7yK0FIDZ7UPvHWCybra0meIB1c6dVO5BYr9k8SuyVpyaPh2UCenbL4LomUEh opTdVFUeVHklCE+q6NIgdghEZHcGMaWKYlCwJ0k+nfHizmubu+U5HZsyWpHjzkjDiCaZ 1jUsw4P1QEdWLyZRJZIBAioXiTH9AO2JTMGM7v+aicBaZVTRKDM9eH93NccoHRWK/uc3 HUW5b9/Thmfyiej5NUQxSGg5KjTip/0881xs6bD2zW+t678wEy7YsudN5+o+O+DDaz4k rQFg== Received: by 10.204.129.16 with SMTP id m16mr848766bks.136.1350685496553; Fri, 19 Oct 2012 15:24:56 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 15:24:36 -0700 (PDT) In-Reply-To: <201210191334.38712.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210121006.17276.jhb@freebsd.org> <201210191334.38712.jhb@freebsd.org> From: Alberto Villa Date: Sat, 20 Oct 2012 00:24:36 +0200 X-Google-Sender-Auth: 9KnMOMNW0KS2q0SctLucByfZl0g Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: acpi@freebsd.org, freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:24:59 -0000 On Fri, Oct 19, 2012 at 7:34 PM, John Baldwin wrote: > I considered that, but 1) it wouldn't help your laptop, and 2) the ACPI 3.0b > spec where bit 31 is added specifically states (in the Note 3 I included in > my prior e-mail) that 0x110 is the only valid legacy ID. Sure, it wasn't about my laptop, but a general consideration; also spec 5.0 lists only 0x0110, so it's better to stick to the spec as you say. By the way, I think the name of devices is not used anywhere (apart for an X.Org piece of code which I'm going to patch), so it's not important. -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 19 22:31:02 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C843D7A; Fri, 19 Oct 2012 22:31:02 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AC0CF8FC0C; Fri, 19 Oct 2012 22:31:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so415986bkc.13 for ; Fri, 19 Oct 2012 15:31:00 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=lsSBQfmDJUT9GfFv++KhBFRO3JYAiD5ui4KK3VOvzvw=; b=Fnhg5VUj26I2KJEs0lSrPKHPJTc2Q/MU4OFhTD4v1OK4l/R8p6tLnrPN1s2q3NLmGM f2AyXSkDVGDA7PdXcL5gv2DSOCj/oa7ofLZkP0E2wnBlyw39wJayCZILLr8/AHyyVx+Y t22PWW4gmuqi/S7XJ8JjGYfgTdi16oON1WroumsQ+wS8AbqzL8A/qChzKAlUWslhiKwD DNysC7FTUsqgZeNCLsGR5SOUlofzqxr/ESI12+gFa08uEbrxi6aXDORih4Yj+AGssjyt 9hyUrEtG2p0Ini6Bog4Sl5cSifI+wCazKGOIJkj5As0LGr1bg8cKvpHI/7Sxt55sn/ND /OzQ== Received: by 10.205.118.136 with SMTP id fq8mr841304bkc.24.1350685860475; Fri, 19 Oct 2012 15:31:00 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.205.81.1 with HTTP; Fri, 19 Oct 2012 15:30:40 -0700 (PDT) In-Reply-To: References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210191053.20041.jhb@freebsd.org> <201210191313.14246.jhb@freebsd.org> From: Alberto Villa Date: Sat, 20 Oct 2012 00:30:40 +0200 X-Google-Sender-Auth: QdSJZ0Ue4rasO4dtcHkRsijpcAk Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:31:02 -0000 On Sat, Oct 20, 2012 at 12:21 AM, Alberto Villa wrote: > I know, I was saying that you probably confused bit 31 with bit 16, so > the patch you proposed (about bit 31 being set in _DOD but not in > _ADR) was not correct. ;) You assumption, actually. The patch you committed was fine. :) -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-acpi@FreeBSD.ORG Sat Oct 20 12:53:05 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25524EB0; Sat, 20 Oct 2012 12:53:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB6538FC17; Sat, 20 Oct 2012 12:53:04 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4845FB93B; Sat, 20 Oct 2012 08:53:04 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Sat, 20 Oct 2012 08:40:48 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210191313.14246.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210200840.48613.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 20 Oct 2012 08:53:04 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 12:53:05 -0000 On Friday, October 19, 2012 06:21:00 PM Alberto Villa wrote: > On Fri, Oct 19, 2012 at 7:13 PM, John Baldwin wrote: > > Yes, unless bit 31 is set, we can't know anything about bits 0-15 except > > that they are "unique". Specifically, we can't look at the "Display > > Type" bits to determine if an output device is a CRT vs LCD vs TV, etc. > > You can only do that if bit 31 is set. > > I know, I was saying that you probably confused bit 31 with bit 16, so > the patch you proposed (about bit 31 being set in _DOD but not in > _ADR) was not correct. ;) Oh, no, I hadn't been able to tell from your ASL that bit 16 was set (it's not that easy to guess as it computes the ID's dynamically at runtime. I was merely guessing that since I had changed the matching logic to look at bit 31 that that was the cause, but it wasn't the matching logic that was different (comparing _ADR to _DOD), but the logic that parsed _DOD is what treated your laptop differently. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Sat Oct 20 13:38:07 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D587451; Sat, 20 Oct 2012 13:38:07 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id A00E38FC22; Sat, 20 Oct 2012 13:38:06 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hr7so929057wib.13 for ; Sat, 20 Oct 2012 06:38:00 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Zcv0bSGaQokDqfW0W7BcL64jr7+YDNt8EhOa7/X/S7s=; b=b9Ejciu3XtuJp7diGDfzR+je2H1XJluDRnVayhDZqwhDCKeTru60xzbfnmcbp728QN daDoYgDdlL+WJq2PRdQEoYeui9h/Hn6awxcxcr8kr5hNVS1yPFmrnEB6T9tMJbD9b26L YnNyWyTEbZKzGwJMdlfDmhtu+lCE6yHndwtNo0LMW6cEBDmJHTIklda2PXD801Ul8b2u teEJ152AYb2Kb+d6QyKCic3OWmCTmJ3oXVBb1XgW7D0PRQ2uONHmRzhy4cqu99vXuKTK samjsqZEx3TZiWo5GAGvAqh//kMGWqCiwmbcWkxBLuBSfqh4xW83tHGmZqe+O5iEMOdG aJjA== Received: by 10.180.8.40 with SMTP id o8mr25387174wia.9.1350740280454; Sat, 20 Oct 2012 06:38:00 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.216.200.17 with HTTP; Sat, 20 Oct 2012 06:37:40 -0700 (PDT) In-Reply-To: <201210200840.48613.jhb@freebsd.org> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210191313.14246.jhb@freebsd.org> <201210200840.48613.jhb@freebsd.org> From: Alberto Villa Date: Sat, 20 Oct 2012 15:37:40 +0200 X-Google-Sender-Auth: BWtantbM5o_-Eu1Rhp0Tzr2SZHo Message-ID: Subject: Re: Dell acpi_video patch To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 13:38:07 -0000 On Sat, Oct 20, 2012 at 2:40 PM, John Baldwin wrote: > Oh, no, I hadn't been able to tell from your ASL that bit 16 was set (it's > not that easy to guess as it computes the ID's dynamically at runtime. I see. > I was merely guessing that since I had changed the matching logic to look at > bit 31 that that was the cause, Oh, no, it wasn't working before too, it just changed from "crt" to "out" because of your change (which makes sense). > but it wasn't the matching logic that was > different (comparing _ADR to _DOD), but the logic that parsed _DOD is what > treated your laptop differently. So, just to be sure, you don't need any other information from me, right? I don't think, by the way, that a list of known non-standard configurations is worth being added to the code for this issue. -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla