bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 30 Oct 2014 11:46:29 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> 
> 
> [1:multipart/mixed Hide]
> 
> 
> [1/1:text/plain Hide]
> 
> In the following single-headed setup GNU Emacs behaves as intended:
> 
>   Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
>   VGA1 connected primary (normal left inverted right x axis y axis)
>      1280x720      59.86 +
>      1024x768      75.08    70.07    60.00
>      832x624       74.55
>      800x600       72.19    75.00    60.32    56.25
>      640x480       75.00    72.81    66.67    60.00
>      720x400       70.08
>   LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y
> axis) 228mm x 131mm
>      1024x600      59.99*+
>      800x600       60.32    56.25
>      640x480       59.94
> 
> In this setup, as you can see, only the LVDS1 output is enabled.
> 
> However in my usual setup I have both outputs enabled for a dual-headed
> display:
> 
>   Screen 0: minimum 320 x 200, current 2304 x 720, maximum 4096 x 4096
>   VGA1 connected primary 1280x720+0+0 (normal left inverted right x axis
> y axis) 340mm x 270mm
>      1280x720      59.86*+
>      1024x768      75.08    70.07    60.00
>      832x624       74.55
>      800x600       72.19    75.00    60.32    56.25
>      640x480       75.00    72.81    66.67    60.00
>      720x400       70.08
>   LVDS1 connected 1024x600+1280+120 (normal left inverted right x axis y
> axis) 228mm x 131mm
>      1024x600      59.99*+
>      800x600       60.32    56.25
>      640x480       59.94
> 
> In this setup GNU Emacs corrupts the mode-line (a graphical glitch)
> drawing over it the buffer's line that would otherwise be below it.
> 
> Refreshing the window with 'xrefresh' or just switching to another
> window and back again repaints the mode-line content, so it looks
> normal, until the next buffer scroll operation, when it gets corrupt
> again.
> 
> Starting Emacs with the '-Q' option, without changing the frame's
> geometry, and typing 'C-x d /dev <RET>' is sufficient to reproduce the
> bug.  Actually, most of the time, Emacs windows that hold text
> underneath the mode-line trigger the problem.

Please show the output of each one the following forms, evaluated in
both the "good" and "bad" configurations, when you start "emacs -Q"
and visit the same /dev directory:

  (window-height)
  (window-pixel-height)

You can evaluate each form using M-:, as in

  M-: ((window-height) RET

Please compare the return value of window-height with the actual
number of lines available in that window, and tell if the two match.