From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 09:09:02 2011 Received: (at submit) by debbugs.gnu.org; 29 Dec 2011 14:09:02 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgGfE-0002Fw-4t for submit@debbugs.gnu.org; Thu, 29 Dec 2011 09:09:01 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgGfB-0002Fo-Dp for submit@debbugs.gnu.org; Thu, 29 Dec 2011 09:08:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgGcN-0008Fd-Do for submit@debbugs.gnu.org; Thu, 29 Dec 2011 09:06:07 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:56475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgGcN-0008FZ-C9 for submit@debbugs.gnu.org; Thu, 29 Dec 2011 09:06:03 -0500 Received: from eggs.gnu.org ([140.186.70.92]:57554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgGcH-0003Op-SM for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 09:06:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgGcE-0008EE-0i for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 09:05:57 -0500 Received: from dancol.org ([96.126.100.184]:33789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgGcD-0008EA-J8 for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 09:05:53 -0500 Received: from dancol by dancol.org with local (Exim 4.72) (envelope-from ) id 1RgGcD-0007na-7d for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2011 06:05:53 -0800 Date: Thu, 29 Dec 2011 06:05:53 -0800 Message-Id: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> From: Daniel Colascione Subject: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: bug-gnu-emacs@gnu.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) Under remote desktop, Windows returns the wrong number of colors from GetDeviceCaps (hdc, NUMCOLORS). I hit this bug myself, and MSDN comments seem to indicate that others hit it as well. The workaround seems harmless: on non-palettized displays, calculating the number of display colors based on display bitness should produce good results. --- src/w32fns.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/w32fns.c b/src/w32fns.c index 822e353..4b94f16 100644 --- a/src/w32fns.c +++ b/src/w32fns.c @@ -4510,7 +4510,10 @@ If omitted or nil, that stands for the selected frame's display. */) if (dpyinfo->has_palette) cap = GetDeviceCaps (hdc, SIZEPALETTE); else - cap = GetDeviceCaps (hdc, NUMCOLORS); + // GetDeviceCaps (NUMCOLORS) is buggy under remote desktop and sometimes + // returns the number of system reserved colors (20) instead of + // the actual number of available colors. + cap = -1; /* We force 24+ bit depths to 24-bit, both to prevent an overflow and because probably is more meaningful on Windows anyway */ -- 1.7.5.1 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 11:17:00 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 16:17:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgIf6-0005GX-0q for submit@debbugs.gnu.org; Thu, 29 Dec 2011 11:17:00 -0500 Received: from mail-pz0-f44.google.com ([209.85.210.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgIf3-0005GP-N3 for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 11:16:58 -0500 Received: by dajz8 with SMTP id z8so9188076daj.3 for <10397@debbugs.gnu.org>; Thu, 29 Dec 2011 08:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=soMwXNjCaq7de3biBEWrshL5tCZeBgSBM5cIdzu1ctQ=; b=BfNGkr6oZ74jP4r7CGPD6lDK7fpeFOEXVvcD8Q5lZLA4jlZT+hT+5pl9hHYgxMbrwh ydMdqHwgQcaWcRVfgH0OlZqvc/WNE+kroSlPb6OEQ/txxf59cZ2GX/rxsbhn/aDgxZAu a5A3QvWAm8ziCplvBB8fiTVoYiuL8Y34ti1yk= Received: by 10.68.73.165 with SMTP id m5mr85438173pbv.108.1325175246212; Thu, 29 Dec 2011 08:14:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.28 with HTTP; Thu, 29 Dec 2011 08:13:25 -0800 (PST) In-Reply-To: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> From: Juanma Barranquero Date: Thu, 29 Dec 2011 17:13:25 +0100 Message-ID: Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: Daniel Colascione Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Thu, Dec 29, 2011 at 15:05, Daniel Colascione wrote: > The workaround > seems harmless: on non-palettized displays, calculating the number of > display colors based on display bitness should produce good results. Even so, why fix what is not broken? Why can't you just do =3D=3D=3D modified file 'src/w32fns.c' --- src/w32fns.c 2011-12-04 08:02:42 +0000 +++ src/w32fns.c 2011-12-29 16:10:33 +0000 @@ -4511,5 +4511,12 @@ cap =3D GetDeviceCaps (hdc, SIZEPALETTE); else - cap =3D GetDeviceCaps (hdc, NUMCOLORS); + { + cap =3D GetDeviceCaps (hdc, NUMCOLORS); + /* GetDeviceCaps (NUMCOLORS) is buggy under remote desktop and + sometimes returns the number of system reserved colors (20) + instead of the actual number of available colors. */ + if (cap =3D=3D 20) + cap =3D -1; + } /* We force 24+ bit depths to 24-bit, both to prevent an overflow > + =C2=A0 =C2=A0// GetDeviceCaps (NUMCOLORS) is buggy under remote desktop= and sometimes > + =C2=A0 =C2=A0// returns the number of system reserved colors (20) inste= ad of > + =C2=A0 =C2=A0// the actual number of available colors. Please, don't use "C++ / modern C" style comments; use /* */ instead. =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 11:26:52 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 16:26:52 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgIoe-0005Uz-5G for submit@debbugs.gnu.org; Thu, 29 Dec 2011 11:26:52 -0500 Received: from dancol.org ([96.126.100.184]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgIob-0005Us-Qp for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 11:26:50 -0500 Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RgIlq-0007zK-K5; Thu, 29 Dec 2011 08:23:58 -0800 Message-ID: <4EFC9416.6090005@dancol.org> Date: Thu, 29 Dec 2011 08:23:50 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juanma Barranquero Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6EF818CAE123F88A897ABCF1" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.3 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6EF818CAE123F88A897ABCF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/11 8:13 AM, Juanma Barranquero wrote: > On Thu, Dec 29, 2011 at 15:05, Daniel Colascione wr= ote: >=20 >> The workaround >> seems harmless: on non-palettized displays, calculating the number of >> display colors based on display bitness should produce good results. >=20 > Even so, why fix what is not broken? Why can't you just do >=20 > =3D=3D=3D modified file 'src/w32fns.c' > --- src/w32fns.c 2011-12-04 08:02:42 +0000 > +++ src/w32fns.c 2011-12-29 16:10:33 +0000 > @@ -4511,5 +4511,12 @@ > cap =3D GetDeviceCaps (hdc, SIZEPALETTE); > else > - cap =3D GetDeviceCaps (hdc, NUMCOLORS); > + { > + cap =3D GetDeviceCaps (hdc, NUMCOLORS); > + /* GetDeviceCaps (NUMCOLORS) is buggy under remote desktop and > + sometimes returns the number of system reserved colors (20) > + instead of the actual number of available colors. */ > + if (cap =3D=3D 20) > + cap =3D -1; > + } Why? What's the point of adding the extra complexity? Setting cap to -1 leads to this line 1 << min (dpyinfo->n_planes * dpyinfo->n_cbits, 24); which produces a reasonable result for direct color displays. Why keep using NUMCOLORS, which we know to be broken? > /* We force 24+ bit depths to 24-bit, both to prevent an overflow >=20 >> + // GetDeviceCaps (NUMCOLORS) is buggy under remote desktop and so= metimes >> + // returns the number of system reserved colors (20) instead of >> + // the actual number of available colors. >=20 > Please, don't use "C++ / modern C" style comments; use /* */ instead. >=20 That block slipped through. --------------enig6EF818CAE123F88A897ABCF1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk78lBwACgkQ17c2LVA10Vv9QQCfY8xo8g026phR1lOSTzlpI+sE AmQAnRXyoCKYwAkeUdijyVii3DE8I2Z6 =hEBS -----END PGP SIGNATURE----- --------------enig6EF818CAE123F88A897ABCF1-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 11:31:23 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 16:31:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgIt0-0005bw-On for submit@debbugs.gnu.org; Thu, 29 Dec 2011 11:31:23 -0500 Received: from mail-pw0-f44.google.com ([209.85.160.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgIsy-0005bp-Nb for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 11:31:21 -0500 Received: by pbdd12 with SMTP id d12so8230628pbd.3 for <10397@debbugs.gnu.org>; Thu, 29 Dec 2011 08:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=R51y+DForfzsz5205vMFxGkb1yB8eX1+UD2RFAjGo5k=; b=x40iNNsOePSxqftOf5xiveZ//yJeDIaD/fcUwsTICllu2Kf4vuS+WBaafAeND2Osb7 bBQHv1ulIBuTDof6E9Trxn0pdc9IVxFVVG44pgtPAYpDZv8/AVURZJNBYb7Re0psBx/u yRzXFbHSsVYaVJ3Q6r/HfEDCA5lfTRh9w11fw= Received: by 10.68.75.132 with SMTP id c4mr62930443pbw.23.1325176109177; Thu, 29 Dec 2011 08:28:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.28 with HTTP; Thu, 29 Dec 2011 08:27:48 -0800 (PST) In-Reply-To: <4EFC9416.6090005@dancol.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> From: Juanma Barranquero Date: Thu, 29 Dec 2011 17:27:48 +0100 Message-ID: Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: Daniel Colascione Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Thu, Dec 29, 2011 at 17:23, Daniel Colascione wrote: > Why? What's the point of adding the extra complexity? > Setting cap to -1 leads to this line > > =C2=A0 =C2=A01 << min (dpyinfo->n_planes * dpyinfo->n_cbits, 24); > > which produces a reasonable result for direct color displays. > Why keep using NUMCOLORS, which we know to be broken? No, you said that NUMCOLORS is known to be broken in a very specific case. In the general, non-RemoteDektop case, it works. Can you guarantee that for every non-palettized display, it will produce the same number? Because otherwise you're changing the current behavior for people who's not affected by the RemoteDeskopt-related bug. =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 11:45:34 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 16:45:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJ6k-0005uv-58 for submit@debbugs.gnu.org; Thu, 29 Dec 2011 11:45:34 -0500 Received: from dancol.org ([96.126.100.184]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJ6h-0005uo-Tt for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 11:45:32 -0500 Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RgJ3w-00080y-59; Thu, 29 Dec 2011 08:42:40 -0800 Message-ID: <4EFC987D.2020901@dancol.org> Date: Thu, 29 Dec 2011 08:42:37 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juanma Barranquero Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93F1F243C853B3A9B7070891" X-Spam-Score: -2.4 (--) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.4 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93F1F243C853B3A9B7070891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/11 8:27 AM, Juanma Barranquero wrote: > On Thu, Dec 29, 2011 at 17:23, Daniel Colascione wr= ote: >=20 >> Why? What's the point of adding the extra complexity? >> Setting cap to -1 leads to this line >> >> 1 << min (dpyinfo->n_planes * dpyinfo->n_cbits, 24); >> >> which produces a reasonable result for direct color displays. >> Why keep using NUMCOLORS, which we know to be broken? >=20 > No, you said that NUMCOLORS is known to be broken in a very specific > case. In the general, non-RemoteDektop case, it works.=20 I'm not convinced there aren't other bugs lurking in the code backing NUMCOLORS; after all, it's doing the same simple calculation we are, and it's somehow doing it wrong. http://msdn.microsoft.com/en-us/library/dd144877%28v=3DVS.85%29.aspx#3 suggests that NUMCOLORS is generally flaky. > Can you > guarantee that for every non-palettized display, it will produce the > same number? Because otherwise you're changing the current behavior > for people who's not affected by the RemoteDeskopt-related bug. No, I can't guarantee that my original change always produces the same results: it might fix other bugs. --------------enig93F1F243C853B3A9B7070891 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk78mH4ACgkQ17c2LVA10VuX3QCg2yQgvwHOWcx+OfmCVzBCd5D5 lm4AnRxVwDI35bL/V7Cr/z8NvCM0SNcb =/KMv -----END PGP SIGNATURE----- --------------enig93F1F243C853B3A9B7070891-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 11:49:19 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 16:49:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJAM-00060P-KX for submit@debbugs.gnu.org; Thu, 29 Dec 2011 11:49:19 -0500 Received: from mail-pw0-f44.google.com ([209.85.160.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJAK-00060I-Nj for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 11:49:17 -0500 Received: by pbdd12 with SMTP id d12so8238007pbd.3 for <10397@debbugs.gnu.org>; Thu, 29 Dec 2011 08:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ivmNkw4tiJ4dKdG0HRlehzbydbMP51TQwduGZ6zJdEs=; b=RS0IZf8qllt4/16sH8yUfqpQdKmD/T9tvdrazBg+3mjc59uOtCnMidEEpYy5PdunH+ 0Jka8cl7myLQJeTPSIGvCZHd/eJGFl+n4NPWw3MtosGgRrCGWYQheyztYfUFAFDamnyK eg5gU+QRDdVzdrUP617jwALv8r9s4XCHWy/js= Received: by 10.68.73.135 with SMTP id l7mr85054379pbv.57.1325177185152; Thu, 29 Dec 2011 08:46:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.28 with HTTP; Thu, 29 Dec 2011 08:45:44 -0800 (PST) In-Reply-To: <4EFC987D.2020901@dancol.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> From: Juanma Barranquero Date: Thu, 29 Dec 2011 17:45:44 +0100 Message-ID: Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: Daniel Colascione Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Thu, Dec 29, 2011 at 17:42, Daniel Colascione wrote: > I'm not convinced there aren't other bugs lurking in the code backing > NUMCOLORS; after all, it's doing the same simple calculation we are, and > it's somehow doing it wrong. You have also no proof. I don't see why should we try to fix bugs we don't even know are real. Better to fiix the one you know it *is* real, IMO. > No, I can't guarantee that my original change always produces the same > results: it might fix or introduce > other bugs. =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 18:02:13 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 23:02:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgOzF-0007C5-4E for submit@debbugs.gnu.org; Thu, 29 Dec 2011 18:02:13 -0500 Received: from dancol.org ([96.126.100.184]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgOzD-0007Bx-Ha for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 18:02:12 -0500 Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=edith.local) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RgOwQ-0008O4-GB; Thu, 29 Dec 2011 14:59:18 -0800 Message-ID: <4EFCF0BF.1020907@dancol.org> Date: Thu, 29 Dec 2011 14:59:11 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juanma Barranquero Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5F291A41ACAE860C56CB61E1" X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5F291A41ACAE860C56CB61E1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/11 8:45 AM, Juanma Barranquero wrote: > On Thu, Dec 29, 2011 at 17:42, Daniel Colascione wr= ote: >=20 >> I'm not convinced there aren't other bugs lurking in the code backing >> NUMCOLORS; after all, it's doing the same simple calculation we are, a= nd >> it's somehow doing it wrong. >=20 > You have also no proof. I don't see why should we try to fix bugs we > don't even know are real. Better to fiix the one you know it *is* > real, IMO. What about this: we'll distrust any NUMCOLORS response less than 256. You'll never use direct color with a bit depth that small, so any answer in that range must be bogus. This approach would address my concerns about wrong values other than exactly 20 being returned. --------------enig5F291A41ACAE860C56CB61E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk788MAACgkQ17c2LVA10Vs5wgCdEFP4KLm8Qk4WIyCBApE8BfTt 3aUAmwSgs4+MYG3P1boLMKxYmej2/3g4 =s9Wl -----END PGP SIGNATURE----- --------------enig5F291A41ACAE860C56CB61E1-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 18:14:34 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 23:14:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgPBC-0007Sj-C6 for submit@debbugs.gnu.org; Thu, 29 Dec 2011 18:14:34 -0500 Received: from mail-pw0-f44.google.com ([209.85.160.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgPB8-0007SZ-Cq for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 18:14:32 -0500 Received: by pbdd12 with SMTP id d12so8391773pbd.3 for <10397@debbugs.gnu.org>; Thu, 29 Dec 2011 15:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=xXWFmh0bE/bx2vhMoQlevF63aZFVchWuE1+c6imp5+0=; b=kholEB7/7Wyw7WTeTlke224CLPidCui31IligtBVuqMNZe3hRzKDD3nrZnXxJay8XH BrpE3346gOy7mmemf54vYTuJkuLFKYIVgNYP1RHMD4J3kq24a/j99pzeGvD3lmLo+GVm GqOEG/ChHZyLsg7QTEIf1XAWrZE4TPpRcoBWs= Received: by 10.68.73.135 with SMTP id l7mr87841135pbv.57.1325200297151; Thu, 29 Dec 2011 15:11:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.28 with HTTP; Thu, 29 Dec 2011 15:10:56 -0800 (PST) In-Reply-To: <4EFCF0BF.1020907@dancol.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> From: Juanma Barranquero Date: Fri, 30 Dec 2011 00:10:56 +0100 Message-ID: Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: Daniel Colascione Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Thu, Dec 29, 2011 at 23:59, Daniel Colascione wrote: > What about this: we'll distrust any NUMCOLORS response less than 256. > You'll never use direct color with a bit depth that small, so any answer > in that range must be bogus. =C2=A0This approach would address my concern= s > about wrong values other than exactly 20 being returned. OK, assuming you're talking post-24.1. =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 18:16:00 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 23:16:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgPCa-0007Uz-0T for submit@debbugs.gnu.org; Thu, 29 Dec 2011 18:16:00 -0500 Received: from dancol.org ([96.126.100.184]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgPCX-0007Us-FS for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 18:15:58 -0500 Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=edith.local) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RgP9k-0008PK-Jv; Thu, 29 Dec 2011 15:13:04 -0800 Message-ID: <4EFCF3FE.3080508@dancol.org> Date: Thu, 29 Dec 2011 15:13:02 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juanma Barranquero Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3EE61EE5525806D05E35DEC" X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC3EE61EE5525806D05E35DEC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/11 3:10 PM, Juanma Barranquero wrote: > On Thu, Dec 29, 2011 at 23:59, Daniel Colascione wr= ote: >=20 >> What about this: we'll distrust any NUMCOLORS response less than 256. >> You'll never use direct color with a bit depth that small, so any answ= er >> in that range must be bogus. This approach would address my concerns >> about wrong values other than exactly 20 being returned. >=20 > OK, assuming you're talking post-24.1. >=20 > Juanma >=20 Would it be possible to get the more limited (exactly 20) fix into 24.1? --------------enigC3EE61EE5525806D05E35DEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk788/8ACgkQ17c2LVA10Vs9uwCgrW3rANWK+Bdkp4+v78xa5Mq3 LG0AoKQUyYo8tQg0QqHBXO8H2CGNktJK =5GJ1 -----END PGP SIGNATURE----- --------------enigC3EE61EE5525806D05E35DEC-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 18:22:08 2011 Received: (at 10397) by debbugs.gnu.org; 29 Dec 2011 23:22:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgPIW-0007dk-K4 for submit@debbugs.gnu.org; Thu, 29 Dec 2011 18:22:08 -0500 Received: from mail-pw0-f44.google.com ([209.85.160.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgPIU-0007dd-CP for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 18:22:07 -0500 Received: by pbdd12 with SMTP id d12so8394294pbd.3 for <10397@debbugs.gnu.org>; Thu, 29 Dec 2011 15:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=XqtqUUianitDqj/m1La+bolA2acFfxKVtE0+CRstovg=; b=hvJWFSpvJLSx9O6rb3o9H+NeOdjI62WLFVKcSNc2XKES7OfomaPZkPKG2nf/gT8Zlk DR3k+wV4ONZ+WnGcdSMLrJ3/Mqv5skW+FvIXGsuTLd/+2rKObO9tpkBzPYgjp8OnUnBb ddtOmnZ2Jr0/6visWiLVW/plF7MJibGiSbAto= Received: by 10.68.191.6 with SMTP id gu6mr58101429pbc.91.1325200753169; Thu, 29 Dec 2011 15:19:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.28 with HTTP; Thu, 29 Dec 2011 15:18:32 -0800 (PST) In-Reply-To: <4EFCF3FE.3080508@dancol.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFCF3FE.3080508@dancol.org> From: Juanma Barranquero Date: Fri, 30 Dec 2011 00:18:32 +0100 Message-ID: Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: Daniel Colascione Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Fri, Dec 30, 2011 at 00:13, Daniel Colascione wrote: > Would it be possible to get the more limited (exactly 20) fix into 24.1? The "20-check" is a bug fix against a specific bug. OOH, it's not a regression, OTOH, its impact is limited to Windows. You'll have to ask Chong and/or Stefan; it's their decision. =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 20:07:19 2011 Received: (at 10397) by debbugs.gnu.org; 30 Dec 2011 01:07:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgQwI-0001Zf-Q2 for submit@debbugs.gnu.org; Thu, 29 Dec 2011 20:07:19 -0500 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgQwG-0001ZV-5z for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 20:07:17 -0500 Received: by iabz21 with SMTP id z21so2362293iab.3 for <10397@debbugs.gnu.org>; Thu, 29 Dec 2011 17:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=nMxfodxNsmdfkusUK5ZqFajn6eh6S4bnMQMwn0YR0Pw=; b=Y5FyLqV8GN2VIOmKKAY9vmBSCXCm0ThF7CB5t3wY5V9QFHA2i+a+cfo3ul++SMpnel CQmJ6U8mgTYdS4jGWhswouPwV56Y2TPZzqIrYHYK5kHsfhhndmakIDjV065j+oLTIgk8 xagWtT5HbhXxokj0reWZNbvQEsZny8Us3xB00= Received: by 10.50.202.105 with SMTP id kh9mr42489699igc.3.1325207062982; Thu, 29 Dec 2011 17:04:22 -0800 (PST) Received: from home.jasonrumney.net ([180.75.74.4]) by mx.google.com with ESMTPS id t5sm71252580igb.4.2011.12.29.17.04.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 17:04:22 -0800 (PST) Received: by home.jasonrumney.net (Postfix, from userid 1000) id BE7CB16E9; Fri, 30 Dec 2011 09:04:16 +0800 (MYT) From: Jason Rumney To: Daniel Colascione Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> Date: Fri, 30 Dec 2011 09:04:16 +0800 In-Reply-To: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> (Daniel Colascione's message of "Thu, 29 Dec 2011 06:05:53 -0800") Message-ID: <877h1ehnu7.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) Daniel Colascione writes: > Under remote desktop, Windows returns the wrong number of colors from > GetDeviceCaps (hdc, NUMCOLORS). I hit this bug myself, and MSDN > comments seem to indicate that others hit it as well. The workaround > seems harmless: on non-palettized displays, calculating the number of > display colors based on display bitness should produce good results. I've always been under the impression that this is deliberate, and related to the bandwidth that is available, so at least applications that want to improve performance over low bandwidth links can restrict their use of colors. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 20:13:48 2011 Received: (at 10397) by debbugs.gnu.org; 30 Dec 2011 01:13:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgR2Z-0001iA-Jd for submit@debbugs.gnu.org; Thu, 29 Dec 2011 20:13:47 -0500 Received: from dancol.org ([96.126.100.184]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgR2X-0001i1-84 for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 20:13:46 -0500 Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=edith.local) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RgQzj-00005b-AW; Thu, 29 Dec 2011 17:10:51 -0800 Message-ID: <4EFD0F94.8090406@dancol.org> Date: Thu, 29 Dec 2011 17:10:44 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jason Rumney Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <877h1ehnu7.fsf@gnu.org> In-Reply-To: <877h1ehnu7.fsf@gnu.org> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F848171C9731087038C4536" X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F848171C9731087038C4536 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/11 5:04 PM, Jason Rumney wrote: > Daniel Colascione writes: >=20 >> Under remote desktop, Windows returns the wrong number of colors from >> GetDeviceCaps (hdc, NUMCOLORS). I hit this bug myself, and MSDN >> comments seem to indicate that others hit it as well. The workaround >> seems harmless: on non-palettized displays, calculating the number of >> display colors based on display bitness should produce good results. >=20 > I've always been under the impression that this is deliberate, and > related to the bandwidth that is available, so at least applications > that want to improve performance over low bandwidth links can restrict > their use of colors. A remote desktop user can change the depth of the virtual display presented to applications on the server. If a user wants to trade fidelity for bandwidth, he can configure his client to use an 8bpp visual. Some users (me) configure their clients for a relatively high bit depth, but find that the OS lies to applications some of the time (NUMCOLORS is wrong, but the display bitness is accurate). I think the NUMCOLORS behavior is a real bug; if it weren't, the lie would be more consistently presented. --------------enig0F848171C9731087038C4536 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk79D5YACgkQ17c2LVA10VvawACg3HO9VvbBzPT0DaIfXEnWihJ0 HLoAn2k0M/tclAvHfPOsudC3R8/vRHsK =1EtR -----END PGP SIGNATURE----- --------------enig0F848171C9731087038C4536-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 22:11:27 2011 Received: (at 10397) by debbugs.gnu.org; 30 Dec 2011 03:11:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgSsP-0004LT-W4 for submit@debbugs.gnu.org; Thu, 29 Dec 2011 22:11:27 -0500 Received: from mail-pw0-f44.google.com ([209.85.160.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgSsN-0004LL-Hq for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 22:11:24 -0500 Received: by pbdd12 with SMTP id d12so8459454pbd.3 for <10397@debbugs.gnu.org>; Thu, 29 Dec 2011 19:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Mkk/Ts3ysq1+x4dOTeQAaQcaCcbJBgGP0mNC7i5ggnY=; b=ofwXbYFhdgi2NCwX3nqnjyexhYqeWECDRWb8o+iNR/bUVXpfQ3AwF3Vt1kuipNt1Gr vVL+lc0W+i9I/p00wAlx6hlzkyU4CZTvB3URUY2NAnGbt6CWujlDbz2sDNsSxvbWjXQx 36Ext4MQwUDYgKO+huewyA94g9q3DBikj99vM= Received: by 10.68.72.198 with SMTP id f6mr90052124pbv.6.1325214509330; Thu, 29 Dec 2011 19:08:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.28 with HTTP; Thu, 29 Dec 2011 19:07:48 -0800 (PST) In-Reply-To: <4EFCF0BF.1020907@dancol.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> From: Juanma Barranquero Date: Fri, 30 Dec 2011 04:07:48 +0100 Message-ID: Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: Daniel Colascione Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Thu, Dec 29, 2011 at 23:59, Daniel Colascione wrote: > What about this: we'll distrust any NUMCOLORS response less than 256. > You'll never use direct color with a bit depth that small, so any answer > in that range must be bogus. Hmm. Shouldn't in fact GetDeviceCaps (hdc, NUMCOLORS) always be <=3D 256? According to http://msdn.microsoft.com/en-us/library/dd144877(v=3Dvs.85).as= px NUMCOLORS Number of entries in the device's color table, if the device has a color depth of no more than 8 bits per pixel. For devices with greater color depths, 1 is returned. (It says "1", but it's a typo for "-1".) =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 22:21:21 2011 Received: (at 10397) by debbugs.gnu.org; 30 Dec 2011 03:21:21 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgT21-0004bA-6I for submit@debbugs.gnu.org; Thu, 29 Dec 2011 22:21:21 -0500 Received: from dancol.org ([96.126.100.184]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgT1y-0004b0-Qs for 10397@debbugs.gnu.org; Thu, 29 Dec 2011 22:21:19 -0500 Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=edith.local) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RgSzA-0000Cz-5f; Thu, 29 Dec 2011 19:18:24 -0800 Message-ID: <4EFD2D75.3030603@dancol.org> Date: Thu, 29 Dec 2011 19:18:13 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Juanma Barranquero Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA8334856D1EF176FF2F8474A" X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10397 Cc: 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA8334856D1EF176FF2F8474A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/11 7:07 PM, Juanma Barranquero wrote: > On Thu, Dec 29, 2011 at 23:59, Daniel Colascione wr= ote: >=20 >> What about this: we'll distrust any NUMCOLORS response less than 256. >> You'll never use direct color with a bit depth that small, so any answ= er >> in that range must be bogus. >=20 > Hmm. Shouldn't in fact GetDeviceCaps (hdc, NUMCOLORS) always be <=3D 25= 6? >=20 > According to http://msdn.microsoft.com/en-us/library/dd144877(v=3Dvs.85= ).aspx >=20 > NUMCOLORS > Number of entries in the device's color table, if the device has a > color depth of no more than 8 bits per pixel. For devices with greater > color depths, 1 is returned. >=20 > (It says "1", but it's a typo for "-1".) Good catch. What about this (untested) code? hdc =3D GetDC (dpyinfo->root_window); if (dpyinfo->has_palette) cap =3D GetDeviceCaps (hdc, SIZEPALETTE); else if (dpyinfo->n_cbits <=3D 8) /* According to the MSDN, GetDeviceCaps (NUMCOLORS) is valid only for devices with at most eight bits per pixel. It's supposed to return -1 for other displays, but because it actually returns other, incorrect values under some conditions (e.g., remote desktop), only use it when we know it's valid. */ cap =3D GetDeviceCaps (hdc, NUMCOLORS); else cap =3D -1; --------------enigA8334856D1EF176FF2F8474A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk79LXcACgkQ17c2LVA10VvKxQCfZDp9vKb01FeYhP1bKSQ7wdQc +N4AnRuoGZgqwr6OeuYM+xhdXWdWexIq =7Jjc -----END PGP SIGNATURE----- --------------enigA8334856D1EF176FF2F8474A-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 03:55:34 2011 Received: (at 10397) by debbugs.gnu.org; 30 Dec 2011 08:55:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgYFS-0004SA-Mb for submit@debbugs.gnu.org; Fri, 30 Dec 2011 03:55:34 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgYFQ-0004S1-18 for 10397@debbugs.gnu.org; Fri, 30 Dec 2011 03:55:33 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LX000400DRTOO00@a-mtaout20.012.net.il> for 10397@debbugs.gnu.org; Fri, 30 Dec 2011 10:51:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LX0003VJDY2H1J0@a-mtaout20.012.net.il>; Fri, 30 Dec 2011 10:51:40 +0200 (IST) Date: Fri, 30 Dec 2011 10:51:40 +0200 From: Eli Zaretskii Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround In-reply-to: <4EFD2D75.3030603@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <8362gyv3vn.fsf@gnu.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 10397 Cc: lekktu@gmail.com, 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Thu, 29 Dec 2011 19:18:13 -0800 > From: Daniel Colascione > Cc: 10397@debbugs.gnu.org > > > Hmm. Shouldn't in fact GetDeviceCaps (hdc, NUMCOLORS) always be <= 256? > > > > According to http://msdn.microsoft.com/en-us/library/dd144877(v=vs.85).aspx > > > > NUMCOLORS > > Number of entries in the device's color table, if the device has a > > color depth of no more than 8 bits per pixel. For devices with greater > > color depths, 1 is returned. > > > > (It says "1", but it's a typo for "-1".) > > Good catch. What about this (untested) code? > > hdc = GetDC (dpyinfo->root_window); > if (dpyinfo->has_palette) > cap = GetDeviceCaps (hdc, SIZEPALETTE); > else if (dpyinfo->n_cbits <= 8) > /* According to the MSDN, GetDeviceCaps (NUMCOLORS) is valid only > for devices with at most eight bits per pixel. It's supposed > to return -1 for other displays, but because it actually > returns other, incorrect values under some conditions (e.g., > remote desktop), only use it when we know it's valid. */ > cap = GetDeviceCaps (hdc, NUMCOLORS); > else > cap = -1; There's a comment near the end of the GetDeviceCaps documentation saying this: NUMCOLORS doesn't always return one with more than 256 colors The documentation for NUMCOLORS is wrong, devices that support more than 256 colors often return -1 and some virtual machines can return the number of Windows reserved colors (i.e. 20), even in high color mode. Combine the NUMCOLORS return value with BITSPIXEL and PLANES to reliably detect indexed color. So how about using `1 << (n_planes * n_cbits)' (which we compute when NUMCOLORS call returns -1) unconditionally? IOW, why do we need to call GetDeviceCaps(..., NUMCOLORS) here in the first place? From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 04:03:23 2011 Received: (at 10397) by debbugs.gnu.org; 30 Dec 2011 09:03:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgYMz-0004eB-FC for submit@debbugs.gnu.org; Fri, 30 Dec 2011 04:03:22 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgYMv-0004e0-RT for 10397@debbugs.gnu.org; Fri, 30 Dec 2011 04:03:19 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LX000K00EATQL00@a-mtaout23.012.net.il> for 10397@debbugs.gnu.org; Fri, 30 Dec 2011 11:00:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LX000K9UECJG9D0@a-mtaout23.012.net.il>; Fri, 30 Dec 2011 11:00:22 +0200 (IST) Date: Fri, 30 Dec 2011 11:00:20 +0200 From: Eli Zaretskii Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround In-reply-to: <4EFD2D75.3030603@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <8339c2v3h7.fsf@gnu.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 10397 Cc: lekktu@gmail.com, 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) > Date: Thu, 29 Dec 2011 19:18:13 -0800 > From: Daniel Colascione > Cc: 10397@debbugs.gnu.org > > > NUMCOLORS > > Number of entries in the device's color table, if the device has a > > color depth of no more than 8 bits per pixel. For devices with greater > > color depths, 1 is returned. > > > > (It says "1", but it's a typo for "-1".) > > Good catch. What about this (untested) code? > > hdc = GetDC (dpyinfo->root_window); > if (dpyinfo->has_palette) > cap = GetDeviceCaps (hdc, SIZEPALETTE); > else if (dpyinfo->n_cbits <= 8) > /* According to the MSDN, GetDeviceCaps (NUMCOLORS) is valid only > for devices with at most eight bits per pixel. It's supposed > to return -1 for other displays, but because it actually > returns other, incorrect values under some conditions (e.g., > remote desktop), only use it when we know it's valid. */ > cap = GetDeviceCaps (hdc, NUMCOLORS); > else > cap = -1; Looks good to me. I think this could go into 24.1, unless Jason (or someone else) objects. As I wrote elsewhere, past 24.1, we could explore the possibility of not calling GetDeviceCaps here at all (assuming that using the number of planes and bits per plane does the job even when the latter is 8 or less). From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 07:28:32 2011 Received: (at 10397) by debbugs.gnu.org; 30 Dec 2011 12:28:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgbZX-000291-K0 for submit@debbugs.gnu.org; Fri, 30 Dec 2011 07:28:32 -0500 Received: from mail-pz0-f44.google.com ([209.85.210.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgbZV-00028u-Gn for 10397@debbugs.gnu.org; Fri, 30 Dec 2011 07:28:30 -0500 Received: by dajz8 with SMTP id z8so9602632daj.3 for <10397@debbugs.gnu.org>; Fri, 30 Dec 2011 04:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=rrBidc58IfT0QZ+H0138lX/J6TuPPjFR4dS9RrxKdjA=; b=cgMT5yc3B8sxaPRIYsJocvtSf3bmuYp7W6lXB9Oe6tj4enuoNcqZQFDroVkEYI71QW QQprqCrho+zubXIhiyh1dR3YamCtpYHgVWQm1BINA5F8forYNPchwts3TrNS4z6mdlIp qFpGPXIEjQYD+mIra8eJ5QxtgKw8Uqye4luqE= Received: by 10.68.199.231 with SMTP id jn7mr93876454pbc.125.1325247933303; Fri, 30 Dec 2011 04:25:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.28 with HTTP; Fri, 30 Dec 2011 04:24:52 -0800 (PST) In-Reply-To: <8339c2v3h7.fsf@gnu.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> <8339c2v3h7.fsf@gnu.org> From: Juanma Barranquero Date: Fri, 30 Dec 2011 13:24:52 +0100 Message-ID: Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 10397 Cc: Daniel Colascione , 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) On Fri, Dec 30, 2011 at 10:00, Eli Zaretskii wrote: > Looks good to me. =C2=A0I think this could go into 24.1, unless Jason > (or someone else) objects. > > As I wrote elsewhere, past 24.1, we could explore the possibility of > not calling GetDeviceCaps here at all (assuming that using the number > of planes and bits per plane does the job even when the latter is 8 or > less). Agreed. =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 13:21:36 2012 Received: (at 10397) by debbugs.gnu.org; 7 Aug 2012 17:21:36 +0000 Received: from localhost ([127.0.0.1]:40114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SynTM-0001e5-8l for submit@debbugs.gnu.org; Tue, 07 Aug 2012 13:21:36 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:62078) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SynTJ-0001dx-JW for 10397@debbugs.gnu.org; Tue, 07 Aug 2012 13:21:34 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M8E00500A0XC200@a-mtaout21.012.net.il> for 10397@debbugs.gnu.org; Tue, 07 Aug 2012 20:13:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8E005LLAI1AD40@a-mtaout21.012.net.il>; Tue, 07 Aug 2012 20:13:14 +0300 (IDT) Date: Tue, 07 Aug 2012 20:13:14 +0300 From: Eli Zaretskii Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround In-reply-to: X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83txwefwwl.fsf@gnu.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> <8339c2v3h7.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 10397 Cc: Juanma Barranquero , 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 07 Aug 2012 01:19:27 -0700 > From: Daniel Colascione > > Under remote desktop, Windows returns the wrong number of colors from > GetDeviceCaps (hdc, NUMCOLORS). I hit this bug myself, and MSDN > comments seem to indicate that others hit it as well. The workaround > seems harmless: on non-palettized displays, calculating the number of > display colors based on display bitness should produce good results. > --- > src/w32fns.c | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/src/w32fns.c b/src/w32fns.c > index b82d4bc..7fc5cf5 100644 > --- a/src/w32fns.c > +++ b/src/w32fns.c > @@ -4513,8 +4513,15 @@ If omitted or nil, that stands for the selected frame's display. */) > hdc = GetDC (dpyinfo->root_window); > if (dpyinfo->has_palette) > cap = GetDeviceCaps (hdc, SIZEPALETTE); > - else > + else if (dpyinfo->n_cbits <= 8) > + /* According to the MSDN, GetDeviceCaps (NUMCOLORS) is valid only > + for devices with at most eight bits per pixel. It's supposed > + to return -1 for other displays, but because it actually > + returns other, incorrect values under some conditions (e.g., > + remote desktop), only use it when we know it's valid. */ > cap = GetDeviceCaps (hdc, NUMCOLORS); > + else > + cap = -1; > > /* We force 24+ bit depths to 24-bit, both to prevent an overflow > and because probably is more meaningful on Windows anyway */ Last time we spoke, the conclusion (at least mine ;-) was that it might be better not to call GetDeviceCaps at all, and instead reuse the code below this, which uses the number of planes and bits per plane. If you agree with that reasoning, could you please see if that change solves your problem? In any case, let's separate between this patch and the rest of "w32 GUI with Cygwin" patches, as they are really unrelated. In particular, as soon as we agree on this one, you cam go ahead and commit it regardless of the rest. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 13:41:29 2012 Received: (at 10397) by debbugs.gnu.org; 7 Aug 2012 17:41:30 +0000 Received: from localhost ([127.0.0.1]:40142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Synmb-000277-Iw for submit@debbugs.gnu.org; Tue, 07 Aug 2012 13:41:29 -0400 Received: from dancol.org ([96.126.100.184]:39499) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SynmZ-00026z-1Y for 10397@debbugs.gnu.org; Tue, 07 Aug 2012 13:41:28 -0400 Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Synen-0007cq-8H; Tue, 07 Aug 2012 10:33:25 -0700 Message-ID: <50215163.1000206@dancol.org> Date: Tue, 07 Aug 2012 10:33:23 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> <8339c2v3h7.fsf@gnu.org> <83txwefwwl.fsf@gnu.org> In-Reply-To: <83txwefwwl.fsf@gnu.org> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93354792DF11C1866B077EE3" X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10397 Cc: Juanma Barranquero , 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93354792DF11C1866B077EE3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/7/12 10:13 AM, Eli Zaretskii wrote: >> Date: Tue, 07 Aug 2012 01:19:27 -0700 >> From: Daniel Colascione >> >> Under remote desktop, Windows returns the wrong number of colors from >> GetDeviceCaps (hdc, NUMCOLORS). I hit this bug myself, and MSDN >> comments seem to indicate that others hit it as well. The workaround >> seems harmless: on non-palettized displays, calculating the number of >> display colors based on display bitness should produce good results. >> --- >> src/w32fns.c | 9 ++++++++- >> 1 files changed, 8 insertions(+), 1 deletions(-) >> >> diff --git a/src/w32fns.c b/src/w32fns.c >> index b82d4bc..7fc5cf5 100644 >> --- a/src/w32fns.c >> +++ b/src/w32fns.c >> @@ -4513,8 +4513,15 @@ If omitted or nil, that stands for the selected= frame's display. */) >> hdc =3D GetDC (dpyinfo->root_window); >> if (dpyinfo->has_palette) >> cap =3D GetDeviceCaps (hdc, SIZEPALETTE); >> - else >> + else if (dpyinfo->n_cbits <=3D 8) >> + /* According to the MSDN, GetDeviceCaps (NUMCOLORS) is valid only= >> + for devices with at most eight bits per pixel. It's supposed >> + to return -1 for other displays, but because it actually >> + returns other, incorrect values under some conditions (e.g., >> + remote desktop), only use it when we know it's valid. */ >> cap =3D GetDeviceCaps (hdc, NUMCOLORS); >> + else >> + cap =3D -1; >> =20 >> /* We force 24+ bit depths to 24-bit, both to prevent an overflow >> and because probably is more meaningful on Windows anyway */ >=20 > Last time we spoke, the conclusion (at least mine ;-) was that it > might be better not to call GetDeviceCaps at all, and instead reuse > the code below this, which uses the number of planes and bits per > plane. If you agree with that reasoning, could you please see if that > change solves your problem? Sorry about that --- I'm bringing a lot of this up form very cold mental storage. It's been a little while since I've had a chance to do any Emacs hacking. I'm perfectly happy using the planes-and-bits code instead of calling GetDeviceCaps. I'll remove this patch from the cygw32 changeset and check the (now, much simpler) fix for the colors issue into the trunk, if that's all right. --------------enig93354792DF11C1866B077EE3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlAhUWMACgkQ17c2LVA10VtdwgCgo25ck6VoPpm+ZRQNo2t8q55n PAQAoLcPEvLzRVErDHvJ3xomOzSdbh1+ =bY37 -----END PGP SIGNATURE----- --------------enig93354792DF11C1866B077EE3-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 14:15:06 2012 Received: (at 10397) by debbugs.gnu.org; 7 Aug 2012 18:15:06 +0000 Received: from localhost ([127.0.0.1]:40198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyoJ7-0002uK-Qa for submit@debbugs.gnu.org; Tue, 07 Aug 2012 14:15:06 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:36880) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyoJ5-0002tt-H7 for 10397@debbugs.gnu.org; Tue, 07 Aug 2012 14:15:04 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M8E00K00CWM5T00@a-mtaout22.012.net.il> for 10397@debbugs.gnu.org; Tue, 07 Aug 2012 21:07:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8E00JO5CZPXZ40@a-mtaout22.012.net.il>; Tue, 07 Aug 2012 21:07:02 +0300 (IDT) Date: Tue, 07 Aug 2012 21:07:02 +0300 From: Eli Zaretskii Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround In-reply-to: <50215163.1000206@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83mx26fuex.fsf@gnu.org> References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> <8339c2v3h7.fsf@gnu.org> <83txwefwwl.fsf@gnu.org> <50215163.1000206@dancol.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 10397 Cc: lekktu@gmail.com, 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 07 Aug 2012 10:33:23 -0700 > From: Daniel Colascione > CC: Juanma Barranquero , 10397@debbugs.gnu.org > > > Last time we spoke, the conclusion (at least mine ;-) was that it > > might be better not to call GetDeviceCaps at all, and instead reuse > > the code below this, which uses the number of planes and bits per > > plane. If you agree with that reasoning, could you please see if that > > change solves your problem? > > Sorry about that --- I'm bringing a lot of this up form very cold > mental storage. It's been a little while since I've had a chance to do > any Emacs hacking. No need to apologize. It's not that my memory is better than yours, I just looked up the bug report and re-read the entire thread... > I'm perfectly happy using the planes-and-bits code instead of calling > GetDeviceCaps. I'll remove this patch from the cygw32 changeset and > check the (now, much simpler) fix for the colors issue into the trunk, > if that's all right. Please go ahead, but I hope you have a way to check the change you will commit with remote desktop, because I don't. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 01:25:46 2016 Received: (at 10397) by debbugs.gnu.org; 25 Feb 2016 06:25:46 +0000 Received: from localhost ([127.0.0.1]:44605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYpMw-0000hH-Ls for submit@debbugs.gnu.org; Thu, 25 Feb 2016 01:25:46 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:38526) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYpMv-0000h9-9H for 10397@debbugs.gnu.org; Thu, 25 Feb 2016 01:25:45 -0500 Received: from [175.103.25.178] (helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aYpMX-0004ds-3F; Thu, 25 Feb 2016 07:25:21 +0100 From: Lars Ingebrigtsen To: Daniel Colascione Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> <8339c2v3h7.fsf@gnu.org> <83txwefwwl.fsf@gnu.org> <50215163.1000206@dancol.org> Date: Thu, 25 Feb 2016 16:55:15 +1030 In-Reply-To: <50215163.1000206@dancol.org> (Daniel Colascione's message of "Tue, 07 Aug 2012 10:33:23 -0700") Message-ID: <87lh69wblg.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1aYpMX-0004ds-3F X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1456986322.16609@bByUm1YTtXw6rXetUgag0A X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 10397 Cc: Juanma Barranquero , Eli Zaretskii , 10397@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Daniel Colascione writes: >>> hdc = GetDC (dpyinfo->root_window); >>> if (dpyinfo->has_palette) >>> cap = GetDeviceCaps (hdc, SIZEPALETTE); >>> - else >>> + else if (dpyinfo->n_cbits <= 8) >>> + /* According to the MSDN, GetDeviceCaps (NUMCOLORS) is valid only >>> + for devices with at most eight bits per pixel. It's supposed >>> + to return -1 for other displays, but because it actually >>> + returns other, incorrect values under some conditions (e.g., >>> + remote desktop), only use it when we know it's valid. */ >>> cap = GetDeviceCaps (hdc, NUMCOLORS); >>> + else >>> + cap = -1; Looking at w32fns.c, I can't really find anything that resembles the surrounding code in this patch. Instead there seems to be newer code that does... stuff... to palettes. So is this all outdated now, and this stuff works fine? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 12 19:04:50 2016 Received: (at 10397-done) by debbugs.gnu.org; 13 Dec 2016 00:04:50 +0000 Received: from localhost ([127.0.0.1]:39757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGaaQ-0007MJ-5f for submit@debbugs.gnu.org; Mon, 12 Dec 2016 19:04:50 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGaaO-0007M5-N0 for 10397-done@debbugs.gnu.org; Mon, 12 Dec 2016 19:04:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cGaaJ-0000ON-4U for 10397-done@debbugs.gnu.org; Mon, 12 Dec 2016 19:04:43 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGaaJ-0000OJ-1n for 10397-done@debbugs.gnu.org; Mon, 12 Dec 2016 19:04:43 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1cGaaI-0001sy-Ko; Mon, 12 Dec 2016 19:04:42 -0500 From: Glenn Morris To: 10397-done@debbugs.gnu.org Subject: Re: bug#10397: [PATCH] Under Remote Desktop, NUMCOLORS is unreliable; workaround References: <69c9ec930ef1d48655624d437aa66d0fce275d3e.1325166766.git.dancol@dancol.org> <4EFC9416.6090005@dancol.org> <4EFC987D.2020901@dancol.org> <4EFCF0BF.1020907@dancol.org> <4EFD2D75.3030603@dancol.org> <8339c2v3h7.fsf@gnu.org> <83txwefwwl.fsf@gnu.org> <50215163.1000206@dancol.org> <87lh69wblg.fsf@gnus.org> X-Spook: Iraq Gulf Cartel bluebird electronic surveillance Avian X-Ran: PO7d2e0t\F#,KyTn{r+8@Hg1YXm%&W-7/{O|2K@5dq0*Zvn (Lars Ingebrigtsen's message of "Thu, 25 Feb 2016 16:55:15 +1030") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 10397-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) Version: 24.3 I see this was fixed in emacs-24.2-3079-g821812e. From unknown Fri Sep 05 20:55:56 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 10 Jan 2017 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator