bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

charlie hemlock
1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
     a. confirm builds and runs ok when run local
2. Login to windows box, launch ssh -X putty session to linux host with
emacs 26 installed.  (windows xserver: vcxsrv or xming)
3. emacs -Q
4. Emacs does not display correctly. Missing minibuffer, & can't type in buffer.  Compare to attached screenshot.

I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.

However, when attempting to ssh -X to host via PuTTY 0.70 and launch  the Emacs gui  (emacs -Q), emacs is not displaying correctly. Using Windows xserver program VcXsrv (1.19.6.3).

See attached screenshot - no default welcome screen, and missing minibuffer too.

I suspect this issue is related to some combination of GTK and
Xming/VcXsrv, however the behavior does change between Emacs 25.3 and 26.1 RC1, see table below:

I'ved tried the follow commits, and only 25.3 is ok over PuTTY/SSH/X11 & xming/vcxsrv
 emacs-25.3 bd299e7       # Sep 12, 2017  # good
 emacs-26.0.90  906224    # Oct 11, 2017  # bad
 emacs-26.0.91 752fba99   # Jan 13, 2018  # bad
 emacs-26.1-rc1 c2674216  # Apr 9, 2018   # bad


The following ./configure options are desired:
--with-x-toolkit=gtk3 --with-xwidgets  --with-modules --with-mailutils
Where gtk3 is required for xwidgets, so other x-toolkits are not the best solution.
Also --with-x-toolkit=gtk2  has same issues.

Similiar information posted here:
 - https://emacs.stackexchange.com/questions/41021/emacs-26-1-rc1-display-issues-over-ssh-x11-with-xming-vcxsrv
Possibly related posts:
 - https://emacs.stackexchange.com/questions/40990/emacs-aborted-core-dumped-centos-7-0-emacs-25-3-please-help
 - https://bugs.launchpad.net/elementaryos/+bug/1355274
 - https://bugzilla.gnome.org/show_bug.cgi?id=85715

Also attempted on CentOS 7 / GTK+ Version 3.22.10 with similar behavior.
Thanks,
CH


In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.20.10)
 of 2018-04-10 built on atlas
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:    openSUSE Leap 42.3

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure --with-x-toolkit=gtk3 --with-xwidgets --with-modules
 --with-mailutils --prefix=/home/brian/sandbox/
emacs_26.1'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES
THREADS XWIDGETS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting xwidget-internal
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 95213 9039)
 (symbols 48 20393 2)
 (miscs 40 74 143)
 (strings 32 28418 1528)
 (string-bytes 1 751586)
 (vectors 16 14028)
 (vector-slots 8 493536 10574)
 (floats 8 49 68)
 (intervals 56 229 0)
 (buffers 992 12)
 (heap 1024 41537 1116))

emacs26_PuTTY.png (123K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

Eli Zaretskii
> From: charlie hemlock <[hidden email]>
> Date: Sun, 15 Apr 2018 20:09:42 -0400
>
> 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
>      a. confirm builds and runs ok when run local
> 2. Login to windows box, launch ssh -X putty session to linux host with
> emacs 26 installed.  (windows xserver: vcxsrv or xming)
> 3. emacs -Q
> 4. Emacs does not display correctly. Missing minibuffer, & can't type in buffer.  Compare to attached
> screenshot.

Is this all you see in the Emacs frame?  It looks like a part of a
frame, did you clip the image, perhaps?  If so, please show all of the
frame.

> I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
>
> However, when attempting to ssh -X to host via PuTTY 0.70 and launch  the Emacs gui  (emacs -Q), emacs
> is not displaying correctly. Using Windows xserver program VcXsrv (1.19.6.3).
>
> See attached screenshot - no default welcome screen, and missing minibuffer too.

It sounds like Emacs is hung or infloops somewhere.  Does it eat CPU
cycles?  Can you exit it with "C-x C-c" or do you have to kill it by a
signal?  Can you attach GDB to it (on the GNU/Linux side) and show a C
backtrace?  Please do this several times, restarting Emacs each time,
to make sure the backtrace points to the same place.

> I suspect this issue is related to some combination of GTK and
> Xming/VcXsrv, however the behavior does change between Emacs 25.3 and 26.1 RC1, see table below:

To make sure this is related to GTK, could you try building with a
different toolkit, just to see if that build starts as expected?

> Possibly related posts:
>  -
> https://emacs.stackexchange.com/questions/40990/emacs-aborted-core-dumped-centos-7-0-emacs-25-3-please-help
>
>  - https://bugs.launchpad.net/elementaryos/+bug/1355274
>  - https://bugzilla.gnome.org/show_bug.cgi?id=85715

These don't look related to me, because the problems they describe
existed before Emacs 25, which you say worked OK for you.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

charlie hemlock
> Is this all you see in the Emacs frame?  It looks like a part of a
> frame , did you clip the image, perhaps?  If so, please show all of the frame.

That was all the frame. Including new attachment [emacs26_gtk3.png] for clarity. (show a little of background and putty window). I tried resizing window and same result.

> To make sure this is related to GTK, could you try building with a
> different toolkit, just to see if that build starts as expected?

Attached with "motif" x-toolkit screenshot. [emacs26_motif.png].
Appears OK,  but I can't ./configure --with-xwidgets 

  > Does it eat CPU cycles? 
No - just looked a 'top' output.

> Can you exit it with "C-x C-c" or do you have to kill it by a
signal? 
C-x C-x works.

> Can you attach GDB to it (on the GNU/Linux side) and show a C
backtrace?

I attempted to do GDB backtrace even though its starting to get beyond my comfort zone.
Results attached for CentOS7 and Leap 42.3.  Likely I didn't do this correctly to be useful - please advise.

Thanks!
CH



On Mon, Apr 16, 2018 at 1:40 PM, Eli Zaretskii <[hidden email]> wrote:
> From: charlie hemlock <[hidden email]>
> Date: Sun, 15 Apr 2018 20:09:42 -0400
>
> 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
>      a. confirm builds and runs ok when run local
> 2. Login to windows box, launch ssh -X putty session to linux host with
> emacs 26 installed.  (windows xserver: vcxsrv or xming)
> 3. emacs -Q
> 4. Emacs does not display correctly. Missing minibuffer, & can't type in buffer.  Compare to attached
> screenshot.

Is this all you see in the Emacs frame?  It looks like a part of a
frame, did you clip the image, perhaps?  If so, please show all of the
frame.

> I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
>
> However, when attempting to ssh -X to host via PuTTY 0.70 and launch  the Emacs gui  (emacs -Q), emacs
> is not displaying correctly. Using Windows xserver program VcXsrv (1.19.6.3).
>
> See attached screenshot - no default welcome screen, and missing minibuffer too.

It sounds like Emacs is hung or infloops somewhere.  Does it eat CPU
cycles?  Can you exit it with "C-x C-c" or do you have to kill it by a
signal?  Can you attach GDB to it (on the GNU/Linux side) and show a C
backtrace?  Please do this several times, restarting Emacs each time,
to make sure the backtrace points to the same place.

> I suspect this issue is related to some combination of GTK and
> Xming/VcXsrv, however the behavior does change between Emacs 25.3 and 26.1 RC1, see table below:

To make sure this is related to GTK, could you try building with a
different toolkit, just to see if that build starts as expected?

> Possibly related posts:
>  -
> https://emacs.stackexchange.com/questions/40990/emacs-aborted-core-dumped-centos-7-0-emacs-25-3-please-help
>
>  - https://bugs.launchpad.net/elementaryos/+bug/1355274
>  - https://bugzilla.gnome.org/show_bug.cgi?id=85715

These don't look related to me, because the problems they describe
existed before Emacs 25, which you say worked OK for you.

Thanks.


centos7.txt (22K) Download Attachment
emacs26_gtk3.png (359K) Download Attachment
emacs26_motif.png (418K) Download Attachment
leap43.2.txt (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

Eli Zaretskii
> From: charlie hemlock <[hidden email]>
> Date: Mon, 16 Apr 2018 19:37:44 -0400
> Cc: [hidden email]
>
> > Is this all you see in the Emacs frame?  It looks like a part of a
> > frame , did you clip the image, perhaps?  If so, please show all of the frame.
>
> That was all the frame. Including new attachment [emacs26_gtk3.png] for clarity. (show a little of background
> and putty window). I tried resizing window and same result.
>
> > To make sure this is related to GTK, could you try building with a
> > different toolkit, just to see if that build starts as expected?
>
> Attached with "motif" x-toolkit screenshot. [emacs26_motif.png].
> Appears OK,  but I can't ./configure --with-xwidgets

The Motif frame looks better, but still not entirely normal: what's
that empty space to the right of the window?

Is that similar to what you see locally on the GNU/Linux box?

>   > Does it eat CPU cycles?  
> No - just looked a 'top' output.
>
> > Can you exit it with "C-x C-c" or do you have to kill it by a
> signal?  
> C-x C-x works.

If "C-x C-c" works, then does "M-x redraw-display RET" redraw the
frame to its normal appearance?

What about "C-x 5 b RET" -- does it create a new frame, and does that
frame look correctly?

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

charlie hemlock
> The Motif frame looks better, but still not entirely normal: what's that empty space to the right of the  window? Is that similar  to what you see locally on the GNU/Linux box?

That empty narrow space looks similar as locally launched Emacs. That narrow area is where line wrap indicators show up.


> If "C-x C-c" works, then does  "M-x redraw-display RET" redraw the frame to its normal appearance?

No.

> What about "C-x 5 b  RET" -- does it create a new frame, and does that frame look correctly?

Creates new frame. Does not look correct - same as first.

C-x 2   does split frame. But still missing minibuffer and can't type in either buffer.

I also clicked the "File" button on menu bar, and got several errors below, and the File Menu did not display:
However, Clicking the Open File icon did open the file browser .
 - Can't say if these are related to the original display issues discussed here or entire separate issue

% ~/release/emacs_26.1/bin/emacs -Q

(emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

[[removed several repeats]]

(emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

(emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node arrow, owner GtkMenu)

(emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node arrow, owner GtkMenu)
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

(emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1, extents 6x6) while allocating gadget (node menuitem, owner GtkMenuItem)

(emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1, extents 4x4) while allocating gadget (node menuitem, owner GtkMenuItem)

[[removed several repeats]]


In my original post - I forgot to mention with xming 6.9.0.31 (not vcxsrv) I get different emacs behavior (the test combinations are growing) .
The emacs gui launches and appears ok, but core dumps as soon as I attempt anything else.
% ~/release/emacs_26.1/bin/emacs -Q
# click anywhere
X protocol error: BadRequest (invalid request code or no such operation) on protocol request 130
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted

But I did include that bug link in original post.   I can't say if these are closely or distantly or not related.

Anyone else experiencing or able to replicate?
Thanks!

On Mon, Apr 16, 2018 at 10:34 PM, Eli Zaretskii <[hidden email]> wrote:
> From: charlie hemlock <[hidden email]>
> Date: Mon, 16 Apr 2018 19:37:44 -0400
> Cc: [hidden email]
>
> > Is this all you see in the Emacs frame?  It looks like a part of a
> > frame , did you clip the image, perhaps?  If so, please show all of the frame.
>
> That was all the frame. Including new attachment [emacs26_gtk3.png] for clarity. (show a little of background
> and putty window). I tried resizing window and same result.
>
> > To make sure this is related to GTK, could you try building with a
> > different toolkit, just to see if that build starts as expected?
>
> Attached with "motif" x-toolkit screenshot. [emacs26_motif.png].
> Appears OK,  but I can't ./configure --with-xwidgets

The Motif frame looks better, but still not entirely normal: what's
that empty space to the right of the window?

Is that similar to what you see locally on the GNU/Linux box?

>   > Does it eat CPU cycles? 
> No - just looked a 'top' output.
>
> > Can you exit it with "C-x C-c" or do you have to kill it by a
> signal? 
> C-x C-x works.

If "C-x C-c" works, then does "M-x redraw-display RET" redraw the
frame to its normal appearance?

What about "C-x 5 b RET" -- does it create a new frame, and does that
frame look correctly?

Thanks.

Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

Eli Zaretskii
> From: charlie hemlock <[hidden email]>
> Date: Tue, 17 Apr 2018 20:30:33 -0400
> Cc: [hidden email]
>
> > The Motif frame looks better, but still not entirely normal: what's that empty space to the right of the
> window? Is that similar  to what you see locally on the GNU/Linux box?
>
> That empty narrow space looks similar as locally launched Emacs. That narrow area is where line wrap
> indicators show up.

That's the fringe.  And that's already bad: why isn't it being
displayed?  The fringe on the left displays correctly.  Do you see
anything in the *Messages* buffer that could hint on the problem?

Maybe the Motif build bit-rotted.  Is it possible for you to try
building with Lucid instead?  If the Lucid build shows the same
problem when run locally, I think the local display problems need to
be investigated first, but I wonder how come no one else sees these
display problems, they are pretty apparent and cannot be missed.

> I also clicked the "File" button on menu bar, and got several errors below, and the File Menu did not display:
> However, Clicking the Open File icon did open the file browser .
> Related to this menu issue:
>  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
>  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
>  - Can't say if these are related to the original display issues discussed here or entire separate issue

This bug says the problem is fixed in GTK+ 3.22.25.  Can you try that
version of GTK+?

> % ~/release/emacs_26.1/bin/emacs -Q
>
> (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
>
> [[removed several repeats]]
>
> (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
>
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
>
> (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget
> (node arrow, owner GtkMenu)
>
> (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget
> (node arrow, owner GtkMenu)
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
>
> (emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1, extents 6x6) while allocating
> gadget (node menuitem, owner GtkMenuItem)
>
> (emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1, extents 4x4) while allocating gadget
> (node menuitem, owner GtkMenuItem)

And Emacs 25, which works for you in the same setup, uses the same
version of GTK+ as the 26.1RC1 build?

> The emacs gui launches and appears ok, but core dumps as soon as I attempt anything else.
> % ~/release/emacs_26.1/bin/emacs -Q
> # click anywhere
> X protocol error: BadRequest (invalid request code or no such operation) on protocol request 130
> When compiled with GTK, Emacs cannot recover from X disconnects.
> This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
> For details, see etc/PROBLEMS.
> Fatal error 6: Aborted
>
> But I did include that bug link in original post.   I can't say if these are closely or distantly or not related.

Those are for Emacs 23, 24, and 25, whereas you said Emacs 25 worked
for you.  So how can those be the same problems?  And if they are the
same problem, clearly the solution should be in GTK+, not in Emacs,
right?



Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

Noam Postavsky
In reply to this post by charlie hemlock
charlie hemlock <[hidden email]> writes:

> 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
>      a. confirm builds and runs ok when run local
> 2. Login to windows box, launch ssh -X putty session to linux host with
> emacs 26 installed.  (windows xserver: vcxsrv or xming)
> 3. emacs -Q
> 4. Emacs does not display correctly. Missing minibuffer, & can't type in buffer.  Compare to attached screenshot.
>
> I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
>
> However, when attempting to ssh -X to host via PuTTY 0.70 and launch
> the Emacs gui (emacs -Q), emacs is not displaying correctly. Using
> Windows xserver program VcXsrv (1.19.6.3).
>
> See attached screenshot - no default welcome screen, and missing minibuffer too.

This looks similar to Bug#25474, does adding

    (modify-frame-parameters nil '((inhibit-double-buffering . t)))

to your init.el as suggested there help?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474



Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

charlie hemlock
In reply to this post by Eli Zaretskii
> That's the fringe.  And that's already bad: why isn't it being
> displayed?  The fringe on the left displays correctly. 

Ah ok.  I suspect this could be a vcxsrv issue. As if I resize the emacs window it can go away. See 2 attachments build with lucid.
Only change is resizing window.


> Do you see anything in the *Messages* buffer that could hint on the problem?

No messages. Note I can't see it in gtk builds - but I can save the messages buffer to file and confirm its just the default message.
"For information about GNU Emacs and the GNU system, type C-h C-a."


> Maybe the Motif build bit-rotted.  Is it possible for you to try
> building with Lucid instead? If the Lucid build shows the same
> problem when run locally, I think the local display problems need to
> be investigated first, but I wonder how come no one else sees these
> display problems, they are pretty apparent and cannot be missed.

See attachments (remote display emacs lucid).  I don't believe I have any local display issues.


Sorry for the repeated links for the gtk menu bugs (long day), they should have been:
- https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
- https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/992464


> This bug says the problem is fixed in GTK+ 3.22.25.  Can you try that version of GTK+?
See table below.

> Those are for Emacs 23, 24, and 25, whereas you said Emacs 25 workedf or you.  So how can those be the same problems?  And if they are the
> same problem, clearly the solution should be in GTK+, not in Emacs,right?

So Emacs 25.3 gtk3 displayed via xming also core dumps.  Like I said the # of combinations is growing.
Also feels like there we're dealing with more than one bug here.  
I'd feel a lot better if someone else could replicate.

An attempt to recap (xming 6.9.0.31, VcXsrv  1.19.6.3)

CentOS7, gtk: 2.24.31,  gtk3: 3.22.10
| emacs      | Xming     | VcXsrv                 |
+------------+-----------+------------------------+
| 25.3  gtk2 | ok        | ok                     |
| 25.3  gtk3 | core dump | display ok, menus bad  |
| 26.1  gtk2 | ok        | bad, but menus ok      |
| 26.1  gtk3 | core dump | bad, menus bad         | 

OpenSUSE Leap 42.3 , gtk2: 2.24.31,  gtk3: 3.22.10
| emacs      | Xming     | VcXsrv             |
+------------+-----------+--------------------+
| 25.3  gtk2 | ok        | ok                 |
| 25.3  gtk3 | core dump | ok                 |
| 26.1  gtk2 | ok        | bad, but menus ok  |
| 26.1  gtk3 | core dump | bad, but menus ok  | 


OpenSUSE Tumbleweed, gtk2: 2.24.32,  gtk3: 3.22.29
| emacs      | Xming     | VcXsrv
+------------+-----------+---------------------------+
| 25.3  gtk2 | ok        | ok                        |
| 25.3  gtk3 | ok        | ok                        |
| 26.1  gtk2 | ok        | sometimes bad?!, menus ok |
| 26.1  gtk3 | ok        | bad, but menus ok         |

bad = bad display of minibuffer and main buffer.
menu ok = refers to clicking File Menu and buttons.

(tumbleweed and centos are VMs)

Thanks,
CH


On Wed, Apr 18, 2018 at 9:20 AM, Eli Zaretskii <[hidden email]> wrote:
> From: charlie hemlock <[hidden email]>
> Date: Tue, 17 Apr 2018 20:30:33 -0400
> Cc: [hidden email]
>
> > The Motif frame looks better, but still not entirely normal: what's that empty space to the right of the
> window? Is that similar  to what you see locally on the GNU/Linux box?
>
> That empty narrow space looks similar as locally launched Emacs. That narrow area is where line wrap
> indicators show up.

That's the fringe.  And that's already bad: why isn't it being
displayed?  The fringe on the left displays correctly.  Do you see
anything in the *Messages* buffer that could hint on the problem?

Maybe the Motif build bit-rotted.  Is it possible for you to try
building with Lucid instead?  If the Lucid build shows the same
problem when run locally, I think the local display problems need to
be investigated first, but I wonder how come no one else sees these
display problems, they are pretty apparent and cannot be missed.

> I also clicked the "File" button on menu bar, and got several errors below, and the File Menu did not display:
> However, Clicking the Open File icon did open the file browser .
> Related to this menu issue:
>  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
>  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
>  - Can't say if these are related to the original display issues discussed here or entire separate issue

This bug says the problem is fixed in GTK+ 3.22.25.  Can you try that
version of GTK+?

> % ~/release/emacs_26.1/bin/emacs -Q
>
> (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
>
> [[removed several repeats]]
>
> (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
>
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
>
> (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget
> (node arrow, owner GtkMenu)
>
> (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget
> (node arrow, owner GtkMenu)
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
>
> (emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1, extents 6x6) while allocating
> gadget (node menuitem, owner GtkMenuItem)
>
> (emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1, extents 4x4) while allocating gadget
> (node menuitem, owner GtkMenuItem)

And Emacs 25, which works for you in the same setup, uses the same
version of GTK+ as the 26.1RC1 build?

> The emacs gui launches and appears ok, but core dumps as soon as I attempt anything else.
> % ~/release/emacs_26.1/bin/emacs -Q
> # click anywhere
> X protocol error: BadRequest (invalid request code or no such operation) on protocol request 130
> When compiled with GTK, Emacs cannot recover from X disconnects.
> This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
> For details, see etc/PROBLEMS.
> Fatal error 6: Aborted
>
> But I did include that bug link in original post.   I can't say if these are closely or distantly or not related.

Those are for Emacs 23, 24, and 25, whereas you said Emacs 25 worked
for you.  So how can those be the same problems?  And if they are the
same problem, clearly the solution should be in GTK+, not in Emacs,
right?


emacs26.1_lucid.PNG (408K) Download Attachment
emacs26.1_lucid2.PNG (428K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

charlie hemlock
In reply to this post by Noam Postavsky
> This looks similar to Bug#25474, does adding

    (modify-frame-parameters nil '((inhibit-double-buffering . t)))

> to your init.el as suggested there help?

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474


I quickly tested this in tumbleweed, leap 42.3, and centos 7 and appears to help :)
Wow, Thanks!

I don't get the emacs logo - just plain text welcome, but at least I can see minibuffer and type.

However, in Centos7 (with vcxsrv), the file menus don't appear OK when clicked as previously reported (see gtk errors in previous posts)
A different issue?

Thanks!


On Wed, Apr 18, 2018 at 8:42 PM, Noam Postavsky <[hidden email]> wrote:
charlie hemlock <[hidden email]> writes:

> 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
>      a. confirm builds and runs ok when run local
> 2. Login to windows box, launch ssh -X putty session to linux host with
> emacs 26 installed.  (windows xserver: vcxsrv or xming)
> 3. emacs -Q
> 4. Emacs does not display correctly. Missing minibuffer, & can't type in buffer.  Compare to attached screenshot.
>
> I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
>
> However, when attempting to ssh -X to host via PuTTY 0.70 and launch
> the Emacs gui (emacs -Q), emacs is not displaying correctly. Using
> Windows xserver program VcXsrv (1.19.6.3).
>
> See attached screenshot - no default welcome screen, and missing minibuffer too.

This looks similar to Bug#25474, does adding

    (modify-frame-parameters nil '((inhibit-double-buffering . t)))

to your init.el as suggested there help?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474

Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

Noam Postavsky
charlie hemlock <[hidden email]> writes:

> However, in Centos7 (with vcxsrv), the file menus don't appear OK when
> clicked as previously reported (see gtk errors in previous posts) A
> different issue?

Yeah, the other bug specifically mentions that menus work fine, so it
sounds like you're hitting some other issue as well.



Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

Eli Zaretskii
In reply to this post by charlie hemlock
retitle 31169 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv due to double-buffering
thanks

> From: charlie hemlock <[hidden email]>
> Date: Wed, 18 Apr 2018 21:18:15 -0400
> Cc: [hidden email]
>
> > This looks similar to Bug#25474, does adding
>
>     (modify-frame-parameters nil '((inhibit-double-buffering . t)))
>
> > to your init.el as suggested there help?
>
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474 
>
> I quickly tested this in tumbleweed, leap 42.3, and centos 7 and appears to help :)
> Wow, Thanks!
>
> I don't get the emacs logo - just plain text welcome, but at least I can see minibuffer and type.

Great, thanks to Noam for reminding the double-buffering issues.

I hope Daniel (CC'ed) will be able to look at those problems some time
soon.



Reply | Threaded
Open this post in threaded view
|

bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv

Eli Zaretskii
In reply to this post by Noam Postavsky
> From: Noam Postavsky <[hidden email]>
> Date: Wed, 18 Apr 2018 21:27:40 -0400
> Cc: [hidden email]
>
> charlie hemlock <[hidden email]> writes:
>
> > However, in Centos7 (with vcxsrv), the file menus don't appear OK when
> > clicked as previously reported (see gtk errors in previous posts) A
> > different issue?
>
> Yeah, the other bug specifically mentions that menus work fine, so it
> sounds like you're hitting some other issue as well.

And according to the table you show, those menu problems are resolved
in a later version of GTK+, is that right?