From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#16517: Emacs and display resolution change Date: Wed, 22 Jan 2014 08:32:31 +0100 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b343b4edd3cff04f08a210a X-Trace: ger.gmane.org 1390376045 23019 80.91.229.3 (22 Jan 2014 07:34:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jan 2014 07:34:05 +0000 (UTC) To: 16517@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 22 08:34:12 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1W5sKA-0000wo-0x for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Jan 2014 08:34:10 +0100 Original-Received: from localhost ([::1]:34036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5sK9-0004zv-GV for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Jan 2014 02:34:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5sK4-0004zO-IA for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 02:34:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5sK3-0003XX-Fg for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 02:34:04 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5sK3-0003XT-Bm for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 02:34:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W5sK2-0001Zi-E9 for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 02:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Jan 2014 07:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 16517 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13903759885979 (code B ref -1); Wed, 22 Jan 2014 07:34:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 22 Jan 2014 07:33:08 +0000 Original-Received: from localhost ([127.0.0.1]:60165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5sJ8-0001YL-El for submit@debbugs.gnu.org; Wed, 22 Jan 2014 02:33:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56992) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5sJ5-0001YD-MD for submit@debbugs.gnu.org; Wed, 22 Jan 2014 02:33:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5sJ4-0003NA-8k for submit@debbugs.gnu.org; Wed, 22 Jan 2014 02:33:03 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:36015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5sJ4-0003N6-5m for submit@debbugs.gnu.org; Wed, 22 Jan 2014 02:33:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5sIz-0004wD-Qt for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 02:33:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5sIu-0003Lq-FE for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 02:32:57 -0500 Original-Received: from mail-ea0-x230.google.com ([2a00:1450:4013:c01::230]:52020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5sIu-0003Ll-7E for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2014 02:32:52 -0500 Original-Received: by mail-ea0-f176.google.com with SMTP id h14so4302069eaj.7 for ; Tue, 21 Jan 2014 23:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=mlLjTAKVetisdISeIFarX/8yB4Caw/IL5uaJzqDWXFw=; b=eWzBSVvBav7HXfru1xtql13ji8WjHanSNjfZFxVMLYTZcP3aV4cPkaJ2zzwsyQ8Fw3 C5wwU91wokMbfyLHqBqS4UOwhUxN2sRcAZEpNExGMLQpapLcJABi5G/pv4P8ZR7h/kxH W51AITk2je0BcKFBap4uUHnF4Xye+j0iyw+XQVbYsl2xUUhHH4OfyPQi7PoisXzgaxUV EP8pkpSwvqqG+mq1bbgY1m847K/iqByp8edUa5VizSVg/tn/ICNFLcSLYzbx9MSOnZnl wQ5O6NOphZs12gfMSKhL0abbq5iR3UT59rw4D8/K9Is/2gZEr32Vkz8mAAMB0gjJVwz2 czKw== X-Received: by 10.14.182.199 with SMTP id o47mr28160581eem.7.1390375971141; Tue, 21 Jan 2014 23:32:51 -0800 (PST) Original-Received: by 10.14.8.196 with HTTP; Tue, 21 Jan 2014 23:32:31 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:83870 Archived-At: --047d7b343b4edd3cff04f08a210a Content-Type: text/plain; charset=ISO-8859-1 Hi, The current Emacs trunk does not seem to honour display resolution change under Windows. There is one case where it is annoying: when the frame is fullsized. I have a laptop. I run `emacs -Q' , then `M-x toggle-frame-fullscreen'. Next I connect an external display with a higher resolution. The frame displays undecorated, but with a size of the previous screen resolution. I need to call `M-x toggle-frame-fullscreen' twice to get back a fullsized frame. I think that for handling at least this case, the following patch could be applied: === modified file 'src/w32term.c' --- src/w32term.c 2014-01-06 17:22:52 +0000 +++ src/w32term.c 2014-01-22 05:49:45 +0000 @@ -4841,6 +4844,7 @@ if (f) { dpyinfo->n_cbits = msg.msg.wParam; + x_check_fullscreen(f); DebPrint (("display change: %d %d\n", (short) LOWORD (msg.msg.lParam), (short) HIWORD (msg.msg.lParam))); However I'm not sure of any possibly harmful side effects. One thing I have observed is that if you start with a normal frame, lower the resolution to some point where the y resolution is less than the height of the frame, then the frame will become height-maximized. So if you raise the resolution again, it will stay height-maximized. I'm fine with that, but I'm not sure what users would expect. Memorizing the frame geometry so that it will be restored in case of several resolution change maybe more complex. Apologies if I missed obvious points or ways to handle that. Regards, Fabrice Popineau --047d7b343b4edd3cff04f08a210a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The current Emacs trunk does not se= em to honour display resolution change under Windows.
There is on= e case where it is annoying: when the frame is fullsized.
I have = a laptop. I run `emacs -Q' , then `M-x toggle-frame-fullscreen'.
Next I connect an external display with a higher resolution.
The frame displays undecorated, but with a size of the previous screen res= olution.
I need to call `M-x toggle-frame-fullscreen' twice t= o get back a fullsized frame.

I think that for handling at least this case, the follo= wing patch could be applied:

=3D=3D=3D modifi= ed file 'src/w32term.c'
--- src/w32term.c =A0 =A0 =A0 201= 4-01-06 17:22:52 +0000
+++ src/w32term.c =A0 =A0 =A0 2014-01-22 05:49:45 +0000
@@ -= 4841,6 +4844,7 @@
=A0 =A0 =A0 =A0 =A0 if (f)
=A0 = =A0 =A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 dpyinfo->n_c= bits =3D msg.msg.wParam;
+ =A0 =A0 =A0 =A0 =A0 =A0 x_check_fullsc= reen(f);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 DebPrint (("display change: %d %d\n&q= uot;,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(short) = LOWORD (msg.msg.lParam),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(short) HIWORD (msg.msg.lParam)));

However I'm not sure of any possibly harmful side effect= s.

One thing I have observed is that if you start = with a normal frame, lower the resolution to some point where the y resolut= ion is less than the height of the frame, then the frame will become height= -maximized. So if you raise the resolution again, it will stay height-maxim= ized.
I'm fine with that, but I'm not sure what users would expect. = Memorizing the frame geometry so that it will be restored in case of severa= l resolution change maybe more complex.

Apologies = if I missed obvious points or ways to handle that.=A0

Regards,

Fabrice Popineau
--047d7b343b4edd3cff04f08a210a--