Bug 31475 - LibreOffice fails to set the fullscreen when the screen size changes(using opensource radeon driver)
Summary: LibreOffice fails to set the fullscreen when the screen size changes(using op...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-08 10:07 UTC by Maximiliano Castañón
Modified: 2017-01-03 19:49 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maximiliano Castañón 2010-11-08 10:07:29 UTC
This happens on OpenOffice 3.3.0m12 and LibreOffice 3.3.0m9
i'm using radeon opensource driver, Fedora 14

i will appreciate to  provide any required information.

http://img143.imageshack.us/img143/829/libreofficefail.png
http://img180.imageshack.us/img180/18/libreofficefail2.png
Comment 1 Maximiliano Castañón 2010-11-11 18:51:30 UTC
i'm using Metacity, 

Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
	ModulePath   "/usr/lib64/xorg/modules"
	FontPath     "catalogue:/etc/X11/fontpath.d"
	FontPath     "built-ins"
EndSection

Section "Module"
	Load  "dri2"
	Load  "glx"
	Load  "extmod"
	Load  "dri"
	Load  "record"
	Load  "dbe"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "auto"
	Option	    "Device" "/dev/input/mice"
	Option	    "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
	#DisplaySize	  340   190	# mm
	Identifier   "Monitor0"
	VendorName   "AUO"
	ModelName    "20ec"
EndSection

Section "Device"
	Option	    "RenderAccel" 	"true"
 	Identifier  "Card0"
	Driver      "radeon"
	BusID       "PCI:1:5:0"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	SubSection "Display"
		Viewport   0 0
		Depth     1
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     4
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     8
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     15
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     16
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection
Comment 2 Maximiliano Castañón 2010-11-12 09:02:22 UTC
ok, this is not a bug of radeon driver, this is related to OpenOffice/LibreOffice, the developer of radeon opensource driver told me 

"<agd5f> it needs to re-org itself when the screen geomtry changes"


https://bugs.freedesktop.org/show_bug.cgi?id=31482
Comment 3 Maximiliano Castañón 2010-11-12 09:18:33 UTC
http://img210.imageshack.us/img210/5763/weblogic2.png
Comment 5 Maximiliano Castañón 2010-11-13 21:14:49 UTC
http://img194.imageshack.us/img194/9500/openoffice.png
Comment 6 Maximiliano Castañón 2010-11-13 21:16:44 UTC
In my case, using opensource radeon driver, xorg-x11-drv-ati
Fedora 14, 2.6.35.6
Comment 7 Maximiliano Castañón 2010-11-14 15:02:42 UTC
http://img573.imageshack.us/img573/2091/libreoffice6.png KDE works better, not best.
http://img249.imageshack.us/img249/5669/libreoffice7.png KDE too Dual Screen

http://img3.imageshack.us/img3/3773/libreofficeexpected.png This is how it should look.
Comment 8 Maximiliano Castañón 2010-11-14 15:23:16 UTC
I believe this problem it's related to another problem, it's true that LibreOffice and OpenOffice works better with the KDE enviroment and with GTK it work worst... but, it's true too it's another bug not related with LO/OO...

Like this image show when i change to dual screen... that image it's just for few seconds then it fixes... 
http://img16.imageshack.us/img16/6563/radeond.png

and how you can compare:
http://img404.imageshack.us/img404/5441/weblogic3.png GTK
http://img225.imageshack.us/img225/9334/weblogic4.png GTK 
http://img573.imageshack.us/img573/2091/libreoffice6.png KDE
http://img249.imageshack.us/img249/5669/libreoffice7.png KDE 
http://img3.imageshack.us/img3/3773/libreofficeexpected.png KDE

I ran it with "OOO_FORCE_DESKTOP=kde /opt/libreoffice3/program/simpress" 

GTK keeps the first image size, KDE keeps last screen size, but still doesn't show the entire image. see image http://img573.imageshack.us/img573/2091/libreoffice6.png

We could say, we have a little problem with GTK, when it try to resize the fullscreen, but we can say we have another big bug... with something who resize the screen, probably the Xrandr? other project? virtual desktops?
Comment 10 Petr Mladek 2010-11-16 09:13:02 UTC
Maximiliano, could you please try few more things?

Does it help you to disable the check-box "Tools/Options.../LibreOffice/View/Use hardware acceleration"

Does it help you to ignore the GNOME integration? Just try to start the office the following way:
 
    OOO_FORCE_DESKTOP=none /opt/libreoffice/program/soffice

BTW: Have you had this problem also with older OOo versions?
Comment 11 Maximiliano Castañón 2010-11-16 13:24:16 UTC
Good command, i haven't tried it before....ok, it works bad too, same screen problem, i believe it's related to XRANDR, because that programs seems to set the screen size...

i have attached a bug at:

https://bugs.freedesktop.org/show_bug.cgi?id=31625
Comment 12 Maximiliano Castañón 2010-11-18 13:07:58 UTC
Ok, i have tested Mozilla at fullscreen, evince at fullscreen, no one fails, just LO at fullscreen... i have tested it with: 

[maximi89@localhost grub]$ xrandr --output LVDS --mode 1024x768
[maximi89@localhost grub]$ xrandr --output LVDS --mode 1366x768

and i get this, First it looks like:
http://img210.imageshack.us/img210/5763/weblogic2.png
Then change to:
http://img404.imageshack.us/img404/5441/weblogic3.png 

And some times like this:
http://img225.imageshack.us/img225/9334/weblogic4.png
Comment 13 Petr Mladek 2010-11-22 08:57:46 UTC
Thorsten, I think that you solved similar bugs in the past. Could you please have a look?
Comment 14 Thorsten Behrens (CIB) 2010-11-23 02:09:03 UTC
Maximiliano, I'm sorry but I'm a bit at a loss here - what are you actually doing? Please provide a step-by-step explanation, like "starting libreoffice, loading an Impress file, looks like <pic1>, then pressing F5, looks like <pic2>, then pressing magic hw button, now looks crappy like <pic3>". Also, please attach the output of "xrandr -q --verbose" both in normal and in dual screen mode (I gather you switch modes, and this causes the problem?). A few screenshots look a bit like you use slideshow preview mode (i.e. displaying inside the main window), did I get that right?
Comment 15 Maximiliano Castañón 2010-11-23 06:39:53 UTC
Hi, well, i just open OO or LO, then i create a simple Impress file, then i connect the external monitor, then i press F5, everything ok at this point.... but when i want to use the external monitor, pressing HW button, all screw up, like all the images show... i was doing some test, lot of programs works fine, just OO and LO are failing with this... it seems the Fullscreen of LO it's not sending information to Xorg server when it changes the screen size, because, the external monitor have a maximum of 1024x768, and my laptop screen it's set to 1366x768, i guess the LO it's taking the size of laptop screen, but when Xrandr change the screen it set it to 1024x768, i will send more information later.
Comment 16 Thorsten Behrens (CIB) 2010-11-23 08:09:11 UTC
Caolan, with the step above, could you quickly reproduce this problem? Gtk really should notify us via monitors-changed, wonders what's going wrong ...
Comment 17 Maximiliano Castañón 2010-11-23 09:01:30 UTC
I have tested with:
OOO_FORCE_DESKTOP=gtk /opt/libreoffice/program/soffice
OOO_FORCE_DESKTOP=kde /opt/libreoffice/program/soffice
OOO_FORCE_DESKTOP=none /opt/libreoffice/program/soffice

no one works...
Comment 18 Maximiliano Castañón 2010-11-23 09:47:57 UTC

OOO_FORCE_DESKTOP=none /opt/libreoffice/program/soffice

http://img225.imageshack.us/img225/5472/libreofficenonebad.png
http://img502.imageshack.us/img502/9467/libreofficenonebad2.png
http://img263.imageshack.us/img263/4508/libreofficenonebad3.png

OOO_FORCE_DESKTOP=gtk /opt/libreoffice/program/soffice

The same as none it's reproduce able with GTK...

http://img225.imageshack.us/img225/5472/libreofficenonebad.png
http://img502.imageshack.us/img502/9467/libreofficenonebad2.png
http://img263.imageshack.us/img263/4508/libreofficenonebad3.png

OOO_FORCE_DESKTOP=kde /opt/libreoffice/program/soffice

works very well, but still have a little problem with one of the modes...
this case it's not working with KDE:
http://img580.imageshack.us/img580/4247/libreofficekdebad.png
it should appear like this, it's not the same case, but it show a part who doesn't show the other one:
http://img18.imageshack.us/img18/114/libreofficekdenormal.png



Another thing, the image below appear with GTK and NONE, but it doesn't with KDE:
http://img59.imageshack.us/img59/3251/libreofficegtkgood.png

That image show a state who doesn't appear using KDE one...
Comment 19 Maximiliano Castañón 2010-11-23 09:49:43 UTC
the image http://img59.imageshack.us/img59/3251/libreofficegtkgood.png

never fail... all times it's good
Comment 20 Thorsten Behrens (CIB) 2010-11-23 09:55:51 UTC
Maximiliano, ok, so you're saying with enabled presenter console, none & gtk come out right, is that correct?

What exactly is your setting in Slideshow->Slideshow Settings then, for the failing cases?
Comment 21 Maximiliano Castañón 2010-11-23 10:32:42 UTC
GTK: 
first mode bothscreen the same.
Second mode the presenter console.
third mode just the external monitor.
fourth mode, just the local monitor. 

GTK FAILS AT:
Third and fourth mode, and without out of slideshow, if you choose again bothscreen(first mode) it will be fail too.


KDE:
first mode bothscreen the same. without borders.
Second mode background image in the external monitor and slideshow in the local monitor. with borders.
third mode just the external monitor. without borders.
fourth mode, just the local monitor. with borders.

KDE FAILS AT:
Second and fourth mode.
Comment 22 Maximiliano Castañón 2010-11-23 10:39:41 UTC
in Range it say "all slides", Type "Default", Options: "Animations allowed", "Change slides by clicking on background", and in Multiple Display "display 1(primary)"
Comment 23 Thorsten Behrens (CIB) 2010-11-23 11:33:35 UTC
Ah! Ok, gotcha - so, indeed, switching monitor setup *while* slideshow is running is indeed unsupported currently - it *should* behave correctly though if you only enter slideshow mode *after* switching modes.

Regarding the location of the presenter screen - Caolan, do we have the fix http://www.openoffice.org/issues/show_bug.cgi?id=112421 in 3.3 (and if not, would you consider it safe to add)?
Comment 24 Maximiliano Castañón 2010-11-23 11:38:13 UTC
nice to hear that, but KDE works better than GTK one... because using KDE it's just part of the slideshow who is out, but using GTK it's like half of the slideshow who doesn't appear...
Comment 25 Caolán McNamara 2010-11-23 12:36:19 UTC
re: "do we have the fix http://www.openoffice.org/issues/show_bug.cgi?id=112421 in 3.3". Yeah we do, but (at runtime) only is guaranteed to work if the runtime gtk is >= 2.20.0. 

If built against >= 2.14.0 then an additional fallback is used which will almost certainly work correctly if deployed against >= 2.14.0 even if its < 2.20.0.

See GtkSalDisplay::GetDefaultMonitorNumber
Comment 26 Björn Michaelsen 2011-12-22 11:53:19 UTC
answered, no more NEEDINFO
Comment 27 Thorsten Behrens (CIB) 2013-09-12 16:14:56 UTC
Apologies for not having gotten around fixing this bug yet; unfortunately in future I'll have even less time at my disposal for this, so I'm freeing up ownership for other volunteers to take over.
Comment 28 QA Administrators 2014-10-23 17:32:20 UTC
Please read this message in its entirety before responding.

Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed.

If you have time please do the following:
1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer).
2) If it is present please leave a comment telling us what version of LibreOffice and your operating system.
3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System

Please DO NOT
1) Update the version field
2) Reply via email (please reply directly on the bug tracker)
3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 29 QA Administrators 2015-12-20 16:17:29 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later)
   https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 

3. Leave a comment with your results. 

4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 

4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Comment 30 QA Administrators 2017-01-03 19:49:47 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice 
(5.1.6 or 5.2.3  https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and 
your operating system, and any changes you see in the bug behavior
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave 
a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug-20170103