From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: x-display-pixel-width/height inconsistency Date: Thu, 02 May 2013 13:09:45 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> <83mwtu4p7c.fsf@gnu.org> <83vc8h313t.fsf@gnu.org> <5073D6B8-95E4-4012-AA74-106F428379DC@swipnet.se> <8BD4B041-5A3F-4D7C-AFD3-E997E194AA9D@swipnet.se> <02B98FCD-71DB-47EC-B58B-41A2539FF61A@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1367467801 9866 80.91.229.3 (2 May 2013 04:10:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 04:10:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 02 06:09:59 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UXkqF-0008Fv-3l for ged-emacs-devel@m.gmane.org; Thu, 02 May 2013 06:09:59 +0200 Original-Received: from localhost ([::1]:39850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXkqE-0003QZ-LC for ged-emacs-devel@m.gmane.org; Thu, 02 May 2013 00:09:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXkqA-0003QR-8c for emacs-devel@gnu.org; Thu, 02 May 2013 00:09:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXkq6-0002yC-3z for emacs-devel@gnu.org; Thu, 02 May 2013 00:09:54 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:57524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXkq5-0002xB-Ee for emacs-devel@gnu.org; Thu, 02 May 2013 00:09:50 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id C4021C055D; Thu, 2 May 2013 13:09:45 +0900 (JST) In-Reply-To: <02B98FCD-71DB-47EC-B58B-41A2539FF61A@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159258 Archived-At: >>>>> On Wed, 1 May 2013 11:58:15 +0200, Jan Dj=E4rv s= aid: >> This guess was not right. GDK rejects XRandR in Xquartz and uses >> Xinerama instead. The distinction is made by comparing the output >> name with "default". >>=20 >> in init_randr13 (gdkscreen-x11.c): >>=20 >> XRROutputInfo *output =3D >> XRRGetOutputInfo (dpy, resources, resources->outputs[i]); >>=20 >> /* Non RandR1.2 X driver have output name "default" */ >> randr12_compat |=3D !g_strcmp0 (output->name, "default"); > I did not know that. I've made adjustments for this in the patch, tested= on XQuartz which indeed does not seem to have a 1.2-compatible driver. St= range that. > I also added name and source (the latter mostly for debugging) to the Lis= p structure returned. > I also check for XRRGetScreenResourcesCurrent in configure as that is a 1= .3 version function. I tried the patch for Xaw build with XQuartz 2.7.4 on OSX 10.8, and it hit the following assertion failure: src/xfns.c:3989: Emacs fatal error: assertion failed: 0 <=3D (i) && (i) <= ASIZE (monitor_frames) 3981 FOR_EACH_FRAME (rest, frame) 3982 { 3983 struct frame *f =3D XFRAME (frame); 3984=09 3985 if (FRAME_X_P (f) && FRAME_X_DISPLAY_INFO (f) =3D=3D dpyinfo 3986 && !EQ (frame, tip_frame)) 3987 { 3988 i =3D x_get_monitor_for_frame (f, monitors, n_monitors); 3989 ASET (monitor_frames, i, Fcons (frame, AREF (monitor_frames, i))); 3990 } 3991 } This is because XRRGetScreenResourcesCurrent returns the following bogus value where the `noutput' member is 0. (gdb) p *resources $5 =3D { timestamp =3D 1653376136,=20 configTimestamp =3D 1653376136,=20 ncrtc =3D 0,=20 crtcs =3D 0x101457270,=20 noutput =3D 0,=20 outputs =3D 0x101457270,=20 nmode =3D 0,=20 modes =3D 0x101457270 } GDK also uses XRRGetScreenResourcesCurrent. So, in the GDK code, what actually distinguished XRandR in XQuartz from the other implementationswas not the comparison of the output name with "default", but the positiveness of the `noutput' member. static gboolean init_randr13 (GdkScreen *screen) { : monitors =3D g_array_sized_new (FALSE, TRUE, sizeof (GdkX11Monitor), resources->noutput); : x11_screen->n_monitors =3D monitors->len; : return x11_screen->n_monitors > 0; } YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp