Bug 1378

Adverse changes the window size I see after turn on / off second screen. And also after switch from internal display to external screen / and also after switch back. However, the kicker and desktop for me adjust size properly.

Another problem is that after restoring a maximized window may be restored onto already unavailable screen.

And one more : After turn on the second screen will become invisible in the taskbar windows that were opened in single-screen mode. Switching by using Alt+Tab works for all windows properly.

Turn on / off second screen I doing using xrandr.

(In reply to comment #1)
> Adverse changes the window size I see after turn on / off second screen. And
> also after switch from internal display to external screen / and also after
> switch back. However, the kicker and desktop for me adjust size properly.
> 
> Another problem is that after restoring a maximized window may be restored onto
> already unavailable screen.
> 
> And one more : After turn on the second screen will become invisible in the
> taskbar windows that were opened in single-screen mode. Switching by using
> Alt+Tab works for all windows properly.
> 
> Turn on / off second screen I doing using xrandr.

I think that doesn't have much in common with the bug I've reported. I use two X screens simultaneously. I am not adding external monitor at runtime, I have both monitors avalible when launching X and they are configured as separate X screens in xorg.conf.
So I actually have two kickers and two kdesktops running.

I did some (a lot of) research and testing about this, and I have finally found the source of this bug.

It is caused by this commit: http://git.trinitydesktop.org/cgit/qt3/commit/?id=6ff026570df6bf0d2988e5e94465fc8d19ef2133

So the easiest solution is to undo that commit. 

It says it fixes "resize fail on some systems". But it screwes things up. The code obviously had a reason to be where it was.
Please undo the commit.

Thanks

Without that commit an equally serious bug is introduced whereby the desktop does not resize properly on some systems, potentially leaving controls off-screen and effectively forcing a restart of TDE.  Reverting the commit is a sledgehammer solution that merely exchanges one bug for another.

The only ways I see for the linked diff to cause the failure described is if:
1.) XRRRootToScreen( appDpy, event->xany.window ) is returning an incorrect screen ID
OR
2.) desktop()->screen( scr ) is returning the wrong widget ID
OR
3.) Something is intercepting the desktop resized() event but ignoring the screen parameter

I am raising the priority on this bug to BLOCKER and will see what I can do to resolve it.

After considerable research and debugging (and resolving several other problems present in the displayconfig module) I have come to the conclusion that the issue reported is in fact not a bug, and that the old behavior was likely due to a (now fixed) bug that ended up masking the usage of an incorrect xrandr command.

It appears that there may be some misunderstanding as to how xrandr actually works.  This page provides a relatively good explaination of the xrandr concept and virtual screens: http://www.thinkwiki.org/wiki/Xorg_RandR_1.2

The command you provided (xrandr -s 1024x768) attempts to resize the XRandR virtual screen itself, and therefore would instruct TDE that it now only has 1024x768 total pixels to work with.  Therefore, TDE takes the correct action and resizes all critical interfaces to fit within that new envelope.

"xrandr --output VGA1 --mode 1024x768" may be closer to what you are actually looking for, where VGA1 is the desired output name as given by "xrandr -q".

If I have misunderstood something please feel free to reply to this bug and give a more concrete example of what is failing and how to make it fail. :-)

Thanks!

Tim

Unfortunately, it is usually not me trying to change the resolution. The resize is often caused by fullscreen OpenGL apps (e.g. games).

Just to be clear, I'll repeat the problem here, since I think many users use same setup as mine:
Using multiple X screens, EACH running its own kicker and kdesktop.
Launching a fullscreen game on single screen causes the resize of each kicker and kdesktop on EACH screen.

I can NOT modify every game and application to use "the right" xrandr parameter - many of them are even closed source.

Furthermore, the resize does not affect any other app than those who use your patched Qt3 (everything using GTK, Qt4, Fox, Motif, Tk or even Athena toolkit is not resized by changing resolution on different screen!!!), so this is obviously NOT CORRECT BEHAVIOUR.

And that would be the new information I was looking for. :-)  Reopening the report.

(In reply to comment #7)
> And that would be the new information I was looking for. :-)  Reopening the
> report.

Do you still experience this bug if you quit krandrtray before attempting to resize the screen?

(In reply to comment #6)
> Unfortunately, it is usually not me trying to change the resolution. The resize
> is often caused by fullscreen OpenGL apps (e.g. games).
> 
> Just to be clear, I'll repeat the problem here, since I think many users use
> same setup as mine:
> Using multiple X screens, EACH running its own kicker and kdesktop.
> Launching a fullscreen game on single screen causes the resize of each kicker
> and kdesktop on EACH screen.

So, just for clarification, the game leaves the secondary displays active and Xorg does not resize thir pixel dimensions, but kicker/kdesktop change resolution anyway?

When you say multiple X screens, do you mean multiple Xinerama screens?

I ask because I am having difficulty reproducing the bug on my Intel hardware.  When I execute the xrandr -s 1024x768 command, the secondary display shuts off.  If you can post the output of "xrandr -q" for your setup it might help me to reproduce the problem.

> So, just for clarification, the game leaves the secondary displays active and
> Xorg does not resize thir pixel dimensions, but kicker/kdesktop change
> resolution anyway?

Yes.

> When you say multiple X screens, do you mean multiple Xinerama screens?

No, they are separate X screens, each running its own window manager.

> I ask because I am having difficulty reproducing the bug on my Intel hardware. 
> When I execute the xrandr -s 1024x768 command, the secondary display shuts off.
>  If you can post the output of "xrandr -q" for your setup it might help me to
> reproduce the problem.

xrandr -q on first display:
Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-2 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 473mm x 296mm
   1680x1050      59.9*+   60.0
   1440x900       59.9
   1280x1024      75.0     60.0
   1280x960       60.0
   1280x800       59.8
   1152x864       75.0
   1024x768       75.0     70.1     60.0
   800x600        75.0     72.2     60.3     56.2
   640x480        75.0     72.8     59.9
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-I-3 disconnected (normal left inverted right x axis y axis)

xrandr -q on second display:
Screen 1: minimum 8 x 8, current 1024 x 768, maximum 16384 x 16384
DVI-I-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm
   1024x768       60.0*+   75.0     70.1  
   800x600        75.0     72.2     60.3     56.2  
   640x480        75.0     72.8     59.9  

GPU is nvidia 560ti with proprietary drivers.

I'd like to do some more testing, but tomorrow I have really hard exam (functional programming in Scheme) and then I'll have to learn for another exams, so I won't have much time next few weeks.

Regards.

Thank you for the additional information; I will probably need to fire up an nVidia based test system to see what might be going wrong; the fact that the proprietary drivers are in use opens up the possibility that they are doing something wrong.

Please note that just because something works in other toolkits does NOT mean that those toolkits 1.) are working properly according to the applicable standards or 2.) haven't hacked around some broken graphics drivers.

I am going to test it with nouveau as soon as I have some time.

I was able to track down the source of the bug and have patched it in GIT hashes b85cdab (Qt3) and cae2992 (TQt3).

Thank you for bearing with me while I attempted to track down the issue; you were correct in that there was a Qt3 problem, however the fix ended up being more complex than just reverting a patch. ;-)