bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen

In 16.10, things worked as normal, but in Ubuntu 17.04 Emacs starts in
fullscreen mode.  That is, emacs -Q says:

(frame-parameter nil 'fullscreen)
maximized

If I say "emacs -geometry 20x20 -Q", then Emacs isn't fullscreen, but
instead starts with a frame that is approximately 84 characters by 46
characters.

This is on a HiDPI screen:

larsi@mouse:~$ dconf read /com/ubuntu/user-interface/scale-factor
{'eDP1': 11, 'eDP-1': 12}

Emacs 25 appears to behave the same as git Emacs, so whatever's going on
isn't a new bug, I think.

I tried grepping through the Emacs source code to find out what sets the
`maximized' value, and it's perhaps the get_current_wm_state thing?  I'm
not sure.

I also note that Emacs has a gaggle of options to switch fullscreen mode
on, but apparently none to switch it off?  


In GNU Emacs 26.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-06-07 built on stories
Repository revision: 62523863780d3894c92f84dd474278eeddc4a0e0
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description: Debian GNU/Linux 8.7 (jessie)


--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
 > In 16.10, things worked as normal, but in Ubuntu 17.04 Emacs starts in
 > fullscreen mode.  That is, emacs -Q says:
 >
 > (frame-parameter nil 'fullscreen)
 > maximized

Does this match the state of the window manager maximized button?  What
happens when you click it?

 > If I say "emacs -geometry 20x20 -Q", then Emacs isn't fullscreen, but
 > instead starts with a frame that is approximately 84 characters by 46
 > characters.
 >
 > This is on a HiDPI screen:
 >
 > larsi@mouse:~$ dconf read /com/ubuntu/user-interface/scale-factor
 > {'eDP1': 11, 'eDP-1': 12}

Can you try without scaling?

 > Emacs 25 appears to behave the same as git Emacs, so whatever's going on
 > isn't a new bug, I think.
 >
 > I tried grepping through the Emacs source code to find out what sets the
 > `maximized' value, and it's perhaps the get_current_wm_state thing?  I'm
 > not sure.

It should be.  Can you get a backtrace from there?

 > I also note that Emacs has a gaggle of options to switch fullscreen mode
 > on, but apparently none to switch it off?

(set-frame-parameter nil 'fullscreen nil)

or ‘toggle-frame-maximized’.

martin




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
martin rudalics <[hidden email]> writes:

>> In 16.10, things worked as normal, but in Ubuntu 17.04 Emacs starts in
>> fullscreen mode.  That is, emacs -Q says:
>>
>> (frame-parameter nil 'fullscreen)
>> maximized
>
> Does this match the state of the window manager maximized button?  What
> happens when you click it?

The window manager is Unity, and there's no button as such.  But there
is an "unmaximize" menu option, which works as it's supposed to.

>> If I say "emacs -geometry 20x20 -Q", then Emacs isn't fullscreen, but
>> instead starts with a frame that is approximately 84 characters by 46
>> characters.
>>
>> This is on a HiDPI screen:
>>
>> larsi@mouse:~$ dconf read /com/ubuntu/user-interface/scale-factor
>> {'eDP1': 11, 'eDP-1': 12}
>
> Can you try without scaling?

I don't know how to alter it.

>> I tried grepping through the Emacs source code to find out what sets the
>> `maximized' value, and it's perhaps the get_current_wm_state thing?  I'm
>> not sure.
>
> It should be.  Can you get a backtrace from there?

I'll try later.

>> I also note that Emacs has a gaggle of options to switch fullscreen mode
>> on, but apparently none to switch it off?
>
> (set-frame-parameter nil 'fullscreen nil)
>
> or ‘toggle-frame-maximized’.

I meant command line options.  There's --maximized and --fullwidth and
--fullscreen and --fullheight, but no "no, I don't want anything maxed".

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Date: Wed, 14 Jun 2017 18:38:48 +0200
> Cc: [hidden email]
>
> > (set-frame-parameter nil 'fullscreen nil)
> >
> > or ‘toggle-frame-maximized’.
>
> I meant command line options.  There's --maximized and --fullwidth and
> --fullscreen and --fullheight, but no "no, I don't want anything maxed".

There's also no "no, I don't want only black-and-white colors", and no
"no, I don't want any of my scroll bars disappear".

Command-line options are there to change the default behavior, which
maximized frames isn't.  We don't have options to get back the default
behavior, because that behavior should be there, err, by default.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> writes:

> There's also no "no, I don't want only black-and-white colors", and no
> "no, I don't want any of my scroll bars disappear".

--color=never

:-)

But I get your point.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
In reply to this post by martin rudalics
I'm having a hard time making sense of the code flow in xterm.c.  But
what seems to be happening is that Emacs first comes up with a frame in
proper size, and then it's rescaled to be fullsize.

Looking at get_current_wm_state, in that loop there, a matches both
dpyinfo->Xatom_net_wm_state_maximized_horz and
dpyinfo->Xatom_net_wm_state_maximized_vert, which explains why Emacs
gets maximized.

But I'm having no luck in understanding why those fields are being set,
or where...

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
Instead of looking around in the source code, I found out how to change
the DPI settings.  dconf-editor is apparently the thing to use.

The default settings are

{'eDP1': 11, 'eDP-1': 12}

If I change this to

{'eDP1': 11, 'eDP-1': 11}

or anything less than 12, then all the Emacs frame sizes are correct:
Maximization doesn't happen, and --geometry works as expected.  But if I
change that to

{'eDP1': 11, 'eDP-1': 12}

then all my Emacs frames gets maximized.

Could there be a math error somewhere?  And if so, where?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
In reply to this post by Lars Ingebrigtsen
 >> Does this match the state of the window manager maximized button?  What
 >> happens when you click it?
 >
 > The window manager is Unity, and there's no button as such.  But there
 > is an "unmaximize" menu option, which works as it's supposed to.

Which menu?  And what is the frame's size after "unmaximizing" it?

 > I meant command line options.  There's --maximized and --fullwidth and
 > --fullscreen and --fullheight, but no "no, I don't want anything maxed".

If your window manager decides that the frame sould be maxed, Emacs
won't resist.

martin



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
In reply to this post by Lars Ingebrigtsen
 > Instead of looking around in the source code, I found out how to change
 > the DPI settings.  dconf-editor is apparently the thing to use.
 >
 > The default settings are
 >
 > {'eDP1': 11, 'eDP-1': 12}
 >
 > If I change this to
 >
 > {'eDP1': 11, 'eDP-1': 11}
 >
 > or anything less than 12, then all the Emacs frame sizes are correct:
 > Maximization doesn't happen, and --geometry works as expected.

Can you change those settings on a per application basis?

 > But if I
 > change that to
 >
 > {'eDP1': 11, 'eDP-1': 12}
 >
 > then all my Emacs frames gets maximized.

Does the window manager constrain the frame size to the screen?  WOW, if
you specifiy an initial frame larger than your screen, do you get it
that way?

 > Could there be a math error somewhere?  And if so, where?

IIRC GTK Emacs supports scaling only partially.  Could you try with
another toolkit?  Also, ISTR that people complained about mispositioned
scroll bars, menus and tooltips, sometimes alos about misplaced
underlinings and the like.  Do you see any of those effects too?

martin



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
In reply to this post by martin rudalics
martin rudalics <[hidden email]> writes:

>>> Does this match the state of the window manager maximized button?  What
>>> happens when you click it?
>>
>> The window manager is Unity, and there's no button as such.  But there
>> is an "unmaximize" menu option, which works as it's supposed to.
>
> Which menu?  And what is the frame's size after "unmaximizing" it?

You get a menu when you right-click the title bar.  The frame's size is
the size of the screen after unmaximizing it, but you can then pull the
edges and make it smaller.

>> I meant command line options.  There's --maximized and --fullwidth and
>> --fullscreen and --fullheight, but no "no, I don't want anything maxed".
>
> If your window manager decides that the frame sould be maxed, Emacs
> won't resist.

No other windows except Emacs are maximized, so I don't think the window
manager has decided this.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
In reply to this post by martin rudalics
martin rudalics <[hidden email]> writes:

>> If I change this to
>>
>> {'eDP1': 11, 'eDP-1': 11}
>>
>> or anything less than 12, then all the Emacs frame sizes are correct:
>> Maximization doesn't happen, and --geometry works as expected.
>
> Can you change those settings on a per application basis?

Not that I know.  In any case, this seems like it's an Emacs bug, and
shouldn't we fix that?

> Does the window manager constrain the frame size to the screen?  WOW, if
> you specifiy an initial frame larger than your screen, do you get it
> that way?

If I say "xterm -geometry 800x20", then it seems to be constrained to
the screen size.

>> Could there be a math error somewhere?  And if so, where?
>
> IIRC GTK Emacs supports scaling only partially.  Could you try with
> another toolkit?

Well, this isn't about fixing my frames -- I can do that with a couple
of lines of Emacs Lisp.  But Emacs seems to be buggy here, and it would
be nice to fix that bug.

> Also, ISTR that people complained about mispositioned
> scroll bars, menus and tooltips, sometimes alos about misplaced
> underlinings and the like.  Do you see any of those effects too?

Nope.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
If I say "xterm -geometry 800x700" (which is larger than the screen),
Unity will open the screen in "maximized" mode.  Perhaps this means that
Emacs is just miscomputing the size of the frame leading to a
way-too-big window, and then the window manager is snapping it back to
maximized?

So where's the frame size computed, anyway?  :-)

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
In reply to this post by Lars Ingebrigtsen
 >> If your window manager decides that the frame sould be maxed, Emacs
 >> won't resist.
 >
 > No other windows except Emacs are maximized, so I don't think the window
 > manager has decided this.

Did you try starting any other application with a "way too large"
initial window size?

martin



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
In reply to this post by Lars Ingebrigtsen
 >> Can you change those settings on a per application basis?
 >
 > Not that I know.  In any case, this seems like it's an Emacs bug, and
 > shouldn't we fix that?

If it's an Emacs bug we should try to fix it.

 >> IIRC GTK Emacs supports scaling only partially.  Could you try with
 >> another toolkit?
 >
 > Well, this isn't about fixing my frames -- I can do that with a couple
 > of lines of Emacs Lisp.  But Emacs seems to be buggy here, and it would
 > be nice to fix that bug.

The question is whether GTK Emacs is buggy here.  If say, a Lucid build
behaves better, then we would have isolated a possible bug here.

 >> Also, ISTR that people complained about mispositioned
 >> scroll bars, menus and tooltips, sometimes alos about misplaced
 >> underlinings and the like.  Do you see any of those effects too?
 >
 > Nope.

Probably because you did not set GDK_SCALE.

martin



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
In reply to this post by Lars Ingebrigtsen
 > If I say "xterm -geometry 800x700" (which is larger than the screen),
 > Unity will open the screen in "maximized" mode.  Perhaps this means that
 > Emacs is just miscomputing the size of the frame leading to a
 > way-too-big window, and then the window manager is snapping it back to
 > maximized?

Precisely what I expected and why I asked you to conduct this
experiment.  Some window managers do that when mapping a window.

To continue the experiment: I suppose that once your frame has become
visible, you can make it 800x700 characters large.  What happens when
you iconify that frame and make it visible again?

 > So where's the frame size computed, anyway?  :-)

Who knows?  Uusually, I say here that one of Emacs' original sins is to
request a frame size based on that frame's default character size.

martin



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
Man, this stuff is difficult to figure out...

I think I've found the call that resizes the frame erroneously.

I'm running under gdb with

(gdb) run -Q -geometry 80x20

to get a smallish frame.

change_frame_size is called a lot of times, but eventually with the
correct size:

#0  0x00000000004272f9 in adjust_frame_size (f=0x133ec30 <bss_sbrk_buffer+6645648>, new_width=1040, new_height=520, inhibit=0, pretend=true, parameter=XIL(0xd800)) at frame.c:546
#1  0x000000000053b497 in Fx_create_frame (parms=XIL(0x1151c43))
    at xfns.c:3996

So everything is OK up till now: Emacs has popped up a frame, and it has
the right size.

Then shenanigans start, and they are all seemingly triggered from inside
gtk:

0  0x0000000000424bf8 in change_frame_size (f=0x133ec30 <bss_sbrk_buffer+6645648>, new_width=2112, new_height=1040, pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5546
#1  0x000000000054de1d in xg_frame_resized (f=0x133ec30 <bss_sbrk_buffer+6645648>, pixelwidth=2144, pixelheight=1040) at gtkutil.c:886
#2  0x000000000052a10c in handle_one_xevent (dpyinfo=0x2f8a540, event=0x7fffffffb280, finish=0xc6dc14 <current_finish>, hold_quit=0x7fffffffb550)
    at xterm.c:8676
#3  0x000000000052785f in event_handler_gdk (gxev=0x7fffffffb280, ev=0x2d6d3d0, data=0x0) at xterm.c:7538
#4  0x00007ffff66f4c81 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#5  0x00007ffff66f4f39 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x00007ffff66bf259 in gdk_display_get_event ()
    at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#7  0x00007ffff66f4cf2 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#8  0x00007ffff5653377 in g_main_context_dispatch ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff56535e0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff565368c in g_main_context_iteration ()

xg_frame_resized has apparently now decided that the frame should be
2112x1040 instead of 1040x520, which is the real target size.  So...
twice as high, and slightly less as wide.

And then:

#0  0x0000000000424bf8 in change_frame_size (f=0x133ec30 <bss_sbrk_buffer+6645648>, new_width=2528, new_height=1264, pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5546
#1  0x000000000054de1d in xg_frame_resized (f=0x133ec30 <bss_sbrk_buffer+6645648>, pixelwidth=2560, pixelheight=1264) at gtkutil.c:886
#2  0x000000000052a10c in handle_one_xevent (dpyinfo=0x2e75b70, event=0x7fffffff90b0, finish=0xc6dc14 <current_finish>, hold_quit=0x7fffffff9380)
    at xterm.c:8676
#3  0x000000000052785f in event_handler_gdk (gxev=0x7fffffff90b0, ev=0x2d6d6f0, data=0x0) at xterm.c:7538
#4  0x00007ffff66f4c81 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#5  0x00007ffff66f4f39 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x00007ffff66bf259 in gdk_display_get_event ()
    at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#7  0x00007ffff66f4cf2 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#8  0x00007ffff5653377 in g_main_context_dispatch ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff56535e0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff565368c in g_main_context_iteration ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff6bc2275 in gtk_main_iteration ()
    at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x000000000052ade8 in XTread_socket (terminal=0x1275e40 <bss_sbrk_buffer+5

So now gtk decided that the size should be 2528x1264 (which is the max
size and makes Emacs maximized).

So what could be the cause of these xg_frame_resized events?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
Oh, all this is inside Emacs.  I thought it was part of the gtk stuff
somehow.

Anyway, this is from handle_one_xevent, and this is the first of these
calls that expands the size (erroneously):

      if (!f
          && (f = any)
          && configureEvent.xconfigure.window == FRAME_X_WINDOW (f))
        {
          block_input ();
          if (FRAME_X_DOUBLE_BUFFERED_P (f))
            font_drop_xrender_surfaces (f);
          unblock_input ();
          xg_frame_resized (f, configureEvent.xconfigure.width,
                            configureEvent.xconfigure.height);

So something sets configureEvent.xconfigure.width...  And this happens
when the initial basic fonts are realised.

The call sequence here isn't completely obvious.  :-)

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
 > So something sets configureEvent.xconfigure.width...  And this happens
 > when the initial basic fonts are realised.
 >
 > The call sequence here isn't completely obvious.  :-)

Did you try tracing the ‘adjust_frame_size’ call on line 9930 of
‘x_new_font’?

martin




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

Lars Ingebrigtsen
I just noticed something amusing: If I put the mouse over the mode line
things that pop up tooltips, they're all displayed approximately 2x from
the position they're supposed to:

https://youtu.be/oWjmL-8leVo

This is with the current git Emacs, with -Q on Ubuntu 17.04 (with a
HiDPI display).

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

martin rudalics
 > I just noticed something amusing: If I put the mouse over the mode line
 > things that pop up tooltips, they're all displayed approximately 2x from
 > the position they're supposed to:
 >
 > https://youtu.be/oWjmL-8leVo
 >
 > This is with the current git Emacs, with -Q on Ubuntu 17.04 (with a
 > HiDPI display).

See bug#18429, bug#20619, bug#21348, bug#21469 ...

martin



123
Loading...