Bug 4726 - Switching to All-monitors fullscreen fails after maximize
Summary: Switching to All-monitors fullscreen fails after maximize
Status: CLOSED WORKSFORME
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.10.0
Assignee: Pierre Ossman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-25 16:21 CEST by Peter Åstrand
Modified: 2018-05-15 12:41 CEST (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Peter Åstrand cendio 2013-06-25 16:21:59 CEST
Somewhat similar to bug 4725. If I start the client in non-fullscreen mode, convering parts of monitor 2, then maximize the client, and then switch to all-monitors fullscreen, the client will cover both monitors, but the server side session will only have 1 monitor. On this client, this happens both with client 4.0 and 4.1, and both with server 4.0 and 4.1. Occasionally, I also get errors of type:

 VNCSConnST:  FramebufferUpdateRequest 2304x1024 at 0,0 exceeds framebuffer
              1024x768
Comment 1 Peter Åstrand cendio 2018-04-09 08:53:34 CEST
Similar problem when running a fullscreen vncviewer in a ThinLinc session:

* The session is initially 1280x1024 (one screen)

* tlclient requests 2 x 1600x1200

* ThinLinc session is correctly resized.

* The vncviewer inside the ThinLinc session says:

 DesktopWindow: Requesting framebuffer resize from 1280x1024 to 1600x1200
 DesktopWindow: 1 screen(s)
    1681692777 (0x643c9869): 1600x1200+0+0 (flags
              0x00000000)

 Viewport:    Resizing framebuffer from 1280x1024 to 1600x1200


IOW, it will only detect a single screen.
Comment 2 Peter Åstrand cendio 2018-04-17 15:42:32 CEST
(In reply to comment #1)
> Similar problem when running a fullscreen vncviewer in a ThinLinc session:
> 
> * The session is initially 1280x1024 (one screen)
> 
> * tlclient requests 2 x 1600x1200
> 
> * ThinLinc session is correctly resized.
> 
> * The vncviewer inside the ThinLinc session says:
> 
>  DesktopWindow: Requesting framebuffer resize from 1280x1024 to 1600x1200
>  DesktopWindow: 1 screen(s)
>     1681692777 (0x643c9869): 1600x1200+0+0 (flags
>               0x00000000)
> 
>  Viewport:    Resizing framebuffer from 1280x1024 to 1600x1200
> 
> 
> IOW, it will only detect a single screen.

http://www.fltk.org/str.php?L3462
Comment 3 Peter Åstrand cendio 2018-04-18 16:01:14 CEST
(In reply to comment #1)
> Similar problem when running a fullscreen vncviewer in a ThinLinc session:
> 
> * The session is initially 1280x1024 (one screen)
> 
> * tlclient requests 2 x 1600x1200
> 
> * ThinLinc session is correctly resized.
> 
> * The vncviewer inside the ThinLinc session says:
> 
>  DesktopWindow: Requesting framebuffer resize from 1280x1024 to 1600x1200
>  DesktopWindow: 1 screen(s)
>     1681692777 (0x643c9869): 1600x1200+0+0 (flags
>               0x00000000)
> 
>  Viewport:    Resizing framebuffer from 1280x1024 to 1600x1200
> 
> 
> IOW, it will only detect a single screen.

Moved to bug 7156.
Comment 4 Peter Åstrand cendio 2018-04-18 16:03:59 CEST
(In reply to comment #0)
> Somewhat similar to bug 4725. If I start the client in non-fullscreen mode,
> convering parts of monitor 2, then maximize the client, and then switch to
> all-monitors fullscreen, the client will cover both monitors, but the server
> side session will only have 1 monitor. On this client, this happens both with
> client 4.0 and 4.1, and both with server 4.0 and 4.1. Occasionally, I also get
> errors of type:
> 
>  VNCSConnST:  FramebufferUpdateRequest 2304x1024 at 0,0 exceeds framebuffer
>               1024x768

I cannot reproduce this problem on my workstation, not even with 4.1 server and 4.1 client. I could be that something has changed in the desktop environment. Also, I don't remember seeing this for a long time and we have no customer reports. Closing.

Note You need to log in before you can comment on or make changes to this bug.