From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: display-mm-width return value off on Windows Date: Sat, 08 Jul 2006 22:27:24 +0100 Message-ID: References: <87slldpd8s.fsf@neutrino.caeruleus.net> <44AFB1E1.20906@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1152394184 20369 80.91.229.2 (8 Jul 2006 21:29:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 8 Jul 2006 21:29:44 +0000 (UTC) Cc: Ralf Angeli , Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 08 23:29:41 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FzKMo-0006he-On for ged-emacs-devel@m.gmane.org; Sat, 08 Jul 2006 23:29:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzKMn-0002pk-VG for ged-emacs-devel@m.gmane.org; Sat, 08 Jul 2006 17:29:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FzKMb-0002ok-Vh for emacs-devel@gnu.org; Sat, 08 Jul 2006 17:29:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FzKMZ-0002oY-Sc for emacs-devel@gnu.org; Sat, 08 Jul 2006 17:29:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzKMZ-0002oV-Nv for emacs-devel@gnu.org; Sat, 08 Jul 2006 17:29:19 -0400 Original-Received: from [194.106.33.237] (helo=outmail.freedom2surf.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FzKNH-00020C-KB; Sat, 08 Jul 2006 17:30:03 -0400 Original-Received: from wanchan.jasonrumney.net (i-83-67-23-108.freedom2surf.net [83.67.23.108]) by outmail.freedom2surf.net (Postfix) with ESMTP id 1D65E6C1185; Sat, 8 Jul 2006 22:29:18 +0100 (BST) Original-Received: from TONKOTSU-RAMEN (tonkotsu-ramen.jasonrumney.net [10.0.0.28]) by wanchan.jasonrumney.net (Postfix) with ESMTP id A1D666E5; Sat, 8 Jul 2006 22:29:17 +0100 (BST) Original-To: Lennart Borgman In-Reply-To: <44AFB1E1.20906@student.lu.se> (Lennart Borgman's message of "Sat, 08 Jul 2006 15:23:45 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (windows-nt) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:56822 Archived-At: Lennart Borgman writes: > Is there any reason to believe the result should be correct? As I > pointed out in a previous message the information does not seem to be > available to the display driver. Built in LCDs in notebooks and LCD panels connected via digital connectors are able to report details about the monitor back to the video drivers/OS, though I am not sure whether manufacturers always report accurate information, or whether Windows uses the information. Monitors connected via analog connectors are not able to report this information, and Windows seems to always guess 320 as the width, and the height is reported as consistent with the width:height ratio assuming square pixels. I have tried the following: 1024x768 built in 15.1" notebook LCD reports 320x240 1440x900 built in 14.1" widescreen notebook LCD reports 320x200 1280x1024 analog connected 19" monitor reports 320x256 But using LOGPIXELSX/LOGPIXELSY is not going to be any more accurate than what monitors report, or Windows makes up, since it is based on a dpi setting that is user configurable, defaulting to 96dpi, and AFAIK for screen devices square pixels are assumed (LOGPIXELSX==LOGPIXELSY), so if your monitor has non-square pixels and reports a size to the OS, then that size (or the aspect ratio associated with it) is more likely to be accurate than a calculation involving LOGPIXELSX/LOGPIXELSY.