GNOME Bugzilla – Bug 472494
totem messes with xrandr in fullscreen mode
Last modified: 2008-01-10 20:33:27 UTC
Please describe the problem: I'm running a dual-head setup with the x.org-ati driver (radeon/r300) and totem messes with the xrandr settings. With the new drivers (latest git, with real xrandr 1.2 support) my external monitor is deactivated. Steps to reproduce: With the older drivers (prior to the merge of the randr-1.2 branch) I got this, when running wine in parallel: 1. I noticed this behaviour first when running a game in wine this switched my desktop to 800x600, 2. I switched to 1824x768 (1024x768 first head, 800x600 second head) manually, 3. started totem, moved it to second head and switched to fullscreen 4. exit the game, which restores the original resolution of 3080x1050 5. exit fullscreen of totem - which brings me back to the 1824x768 resolution The bug is the behaviour in 5. - I see absolutely no reason, that totem messes with the xrandr info (it did not resize the screen in the first place). With the new branch of the x.org-ati driver it gets even worse (running only totem). There the second head is disabled, when I switch to full screen mode - so basicly with the new drivers I can't use totem anymore for serious media playing. Actual results: Expected results: Does this happen every time? Other information:
This patch helps to make totem working again (I asume this disables all resizing support - which I would consider irrelevant when running with XVideo): --- /home/mblaesing/bacon-resize.c 2007-08-31 17:15:56.000000000 +0200 +++ src/backend/bacon-resize.c 2007-08-31 17:17:22.000000000 +0200 @@ -46,6 +46,8 @@ #ifdef HAVE_XVIDMODE int event_basep, error_basep; + return FALSE; + /* FIXME multihead */ XLockDisplay (GDK_DISPLAY());
> The bug is the behaviour in 5. - I see absolutely no reason, that totem > messes with the xrandr info (it did not resize the screen in the first place). It does. It's only supposed to resize the screen on which you fullscreen/unfullscreen it, when you have a viewport, so that instead of showing a small part of the video, the screen is resized to fit the whole screen. !----------------------! !--------------! ! ! ! ! ! ! ! ! ! ! ! visible ! ! ! resized ! ! area ! ! -> ! area ! ! ! ! ! ! !--------------- ! !--------------- ! ! ! viewport ! ------------------------ Given that I don't have the kit to reproduce this problem, I'll have to leave you to "fix it". First, we'd need to pass the video widget to those functions, so that we know which physical screen it's on. Then we can get the right configuration from the video widget: - XRRGetScreenInfo needs to be run in bacon_resize() - gdk_screen_width and gdk_screen_height need to be replaced by monitor functions, such as gdk_screen_get_monitor_geometry() (do you get multiple GdkScreens, or just one?) Let me know if you need more info. This is probably related to bug 370099.
Created attachment 94754 [details] Xrandr output The xrandr output indicates, that there is one screen, with multiple outputs. I'll try to code some tests in python, to check what the gdk functions return.
So it would look like one screen, multiple monitors. I'm not sure the XRandR 1.0 functions we're using would be able to handle multiple monitors though. I'm sure the results of your tests would help.
The quick'n'dirty fix (without passing the videowidget and Co) would be to disable resizing support when multi-head is found. I asume most graphic cards today offer a XV-Port (at least I would be pretty suprised to find a dual-head capable card without XV) and at least I have currently no problem using the xv scaling on both heads.
It's not multi-head, it's multi-monitor. And the problem isn't Xv, it's viewports. There's nothing relating to Xv scaling or whatever you might think this resizing is used for. The sole purpose is not having viewports when watching a video, so that the full video appears on screen. I thought the diagram above made that clear.
Created attachment 94757 [details] [review] disable resizing support for multiscreen/multimonitor configurations
totem still shouldn't be restoring the screen back to the maximum size if it didn't change the resolution in the first place. Consider this use case: 1. I change the resolution to 800x600, so I can attach an external screen that only works in that resolution 2. I start totem's fullscreen mode, which doesn't change the resolution and works great 3. Now I want to start a new movie, so I exit fullscreen mode 4. Totem changes the resolution back to the maximum, so I now have to attach the original monitor again to restore the resolution I want.
(In reply to comment #8) > totem still shouldn't be restoring the screen back to the maximum size if it > didn't change the resolution in the first place. I already explained how to fix this problem in comment 2, but no-one sent me a tested patch for it...
I attached a patch that at least turned this bug-causeing feature into a noop. I just upgraded to 2.20 and got immediatelly annoyed. Currently I run it on the second head, maximized without control elements. This can't be a solution. Especially as this works as expected when this feature is turned off.
The patch is not what I want to see in Totem. I'd like this to be fixed properly. So to repeat, the changes would need to be: > - XRRGetScreenInfo needs to be run in bacon_resize() > - gdk_screen_width and gdk_screen_height need to be replaced by monitor > functions, such as gdk_screen_get_monitor_geometry() (do you get multiple > GdkScreens, or just one?)
Ok, I looked some more into it. This seems to be the situation. My Setup: An LVDS (Laptop Display) with external Monitor. I get only X-Display with one screen. Into this screen multiple monitors can look into (as far as I understand this can be quite arbitrary). Here some examples (The first monitor is the LVDS always at 1680x1050): mblaesing@prometheus:~$ xrandr --output VGA-0 --mode 1024x768 --pos 100x100 This shows an 1024x768 window on the VGA Monitor. Starting at 100x100 of the LVDS (aka clone mode). mblaesing@prometheus:~$ xrandr --output VGA-0 --mode 1024x768 --pos 1680x0 This puts the window right of the LVDS (aka extended desktop) mblaesing@prometheus:~$ xrandr --output VGA-0 --mode 1024x768 --pos 1690x0 This creates a 10px gab between my Laptop Screen and the external monitor. mblaesing@prometheus:~$ xrandr --output VGA-0 --mode 1400x1050 --right-of LVDS Bringing back my "normal" config. So to bring it down: I have a Virtal Size of 3080x1050 (configurated to that size - default is much smaller) and I can create arbitrary viewports into this area. I don't see how you want to integrate that into the model you currently assuming. But then I don't understand why you mix xvidmode extension and xrandr (as far as I understood xrandr should be a superset of xvidmode extension). This brings me back to my "solution". You don't know why the viewports were created this way - so don't mess with them.
Created attachment 96495 [details] screen-info.c Attached is a short program I wrote that outputs the data that the bacon_resize code is using. I have a dual head XRANDR 1.2 dual head setup like the original reporter mentioned with two 1280x1024 monitors. I ran the program before changing to full screen and got the following output: Screen size: 2560 x 1024 Current vid mode: hdisplay = 1280, vdisplay = 1024 XRANDR screen sizes: * 1280 x 1024 1280 x 960 1024 x 768 800 x 600 640 x 480 720 x 400 So it seems that the XF86VidMode and XRANDR 1.0/1.1 extensions is only returning information about the first output. I guess that this information is indistinguishable fro the case of a panned viewport you were trying to handle originally. After switching to Totem's full screen mode, I got the following output: Screen size: 1280 x 1024 Current vid mode: hdisplay = 1280, vdisplay = 1024 XRANDR screen sizes: * 1280 x 1024 1280 x 960 1024 x 768 800 x 600 640 x 480 720 x 400 The result is that the second head has been switched off. Exiting full screen mode leaves me in this video mode with only one head (and by the look of it, you can't use the XRANDR 1.0/1.1 APIs to fix things).
Another thing: this code in bacon_resize() and bacon_restore() looks fishy: /* Check if there's a viewport */ width = gdk_screen_width (); height = gdk_screen_height (); if (width > modeline.hdisplay && height > modeline.vdisplay) { XUnlockDisplay (GDK_DISPLAY()); return; } If the aim is to check if the screen is larger than the video mode, the check should be: if (width > modeline.hdisplay || height > modeline.vdisplay) { ... } If the aim is to check that the screen is smaller, then it should probably be: if (width <= modeline.hdisplay && height <= modeline.vdisplay) { ... } I am not sure what situation the code as it is is trying to detect. That said, I don't think it should be fucking with the video mode anyway ...
(In reply to comment #14) > Another thing: this code in bacon_resize() and bacon_restore() looks fishy: > /* Check if there's a viewport */ > width = gdk_screen_width (); > height = gdk_screen_height (); > if (width > modeline.hdisplay > && height > modeline.vdisplay) { > XUnlockDisplay (GDK_DISPLAY()); > return; > } > > If the aim is to check if the screen is larger than the video mode, the check > should be: > if (width > modeline.hdisplay || height > modeline.vdisplay) { ... } > > If the aim is to check that the screen is smaller, then it should probably be: > if (width <= modeline.hdisplay && height <= modeline.vdisplay) { ... } Nope, it's neither. We're trying to see whether the screen is using a viewport. So if both the width and the height of the screen (visible screen) are bigger than the current viewport, then we'd leave it at that. > I am not sure what situation the code as it is is trying to detect. I've explained already, in comment 2. When a there is a viewport on the current screen, we change the resolution of that screen so you don't need to pan to see the video. After exiting fullscreen, you'd get your viewport back. > That said, I don't think it should be fucking with the video mode anyway ... Yes, it should be, for that one use case. At least your tests show that I wouldn't be able to solve this problem with XRandR 1.0 APIs, and that Matthias' patch should be applied. Please commit to gnome-2-20 and trunk.
(In reply to comment #15) > > If the aim is to check if the screen is larger than the video mode, the > > check should be: > > if (width > modeline.hdisplay || height > modeline.vdisplay) { ... } > > > > If the aim is to check that the screen is smaller, then it should probably > > be: > > if (width <= modeline.hdisplay && height <= modeline.vdisplay) { ... } > > Nope, it's neither. We're trying to see whether the screen is using a > viewport. So if both the width and the height of the screen (visible > screen) are bigger than the current viewport, then we'd leave it at that. Well, in the pre XRANDR 1.2 world, I could potentially have a 1280x960 mode panning over a 1280x1024 viewport. In this case (1280 > 1280 && 1024 > 960) is false, but there is a panning viewport. If you are trying to exit if the screen fits within the video mode's display region, then the check should be: if (width <= modeline.hdisplay && height <= modeline.vdisplay) { /* exit without fiddling with modes */ } > > I am not sure what situation the code as it is is trying to detect. > > I've explained already, in comment 2. When a there is a viewport on the > current screen, we change the resolution of that screen so you don't need > to pan to see the video. After exiting fullscreen, you'd get your viewport > back. That appears to be by chance. The bacon_restore() function does the same comparison of video mode to screen size that bacon_resize() does, but it is comparing the resized screen dimensions. These will likely be equal, so (width > modeline.hdisplay && height > modeline.vdisplay) will evaluate false and the size of the first output will indeed be restored. I would have thought that the restore code should always restore the video mode if it originally adjusted it. > > That said, I don't think it should be fucking with the video mode anyway ... > > Yes, it should be, for that one use case. At least your tests show that I > wouldn't be able to solve this problem with XRandR 1.0 APIs, and that > Matthias' patch should be applied. > > Please commit to gnome-2-20 and trunk. I am not sure Matthias's patch is the best option. Perhaps disabling resizing if the RANDR extension version is >= 1.2 would be better. Checking on my laptop (a simple single-screen setup), I haven't been able to switch to a panned viewport mode despite being able to switch to other resolutions via RANDR.
(In reply to comment #15) > > Yes, it should be, for that one use case. At least your tests show that I > wouldn't be able to solve this problem with XRandR 1.0 APIs, and that Matthias' > patch should be applied. > > Please commit to gnome-2-20 and trunk. > Not sure whether you meant me, but I can't do that. At least I asume you need an account on the svn servers to commit. So it would be nice if someone with commit rights does this. If you didn't mean me - forget it - and thanks for taking the patch in.
Looking at https://bugs.freedesktop.org/show_bug.cgi?id=11418, it seems that the lack of viewport support with RANDR-1.2 enabled drivers may be considered a bug, so my previous suggestion about just checking the RANDR version is not appropriate. Matthias's patch only checking for multiple monitors (not multiple screens) is probably the best solution. I'll test that and commit.
Any progress?
Created attachment 99870 [details] [review] disable resizing support on multi-monitor configuration Another try - without looking for multiple screen, but just multiple monitors on the default display - this is not nice, but at least makes it usable for me. This will still break, when the second head is turned on, after the init was done . Maybe this should be folded into the resize function ...
*** Bug 507987 has been marked as a duplicate of this bug. ***
I made some changes to bacon-resize in SVN trunk. Could any of you please test and let me know it fixes the problem?
(In reply to comment #22) > I made some changes to bacon-resize in SVN trunk. Could any of you please test > and let me know it fixes the problem? Nope, same problem...
This fixes it for me. XF86VidMode just doesn't know about multiple monitors, and gives me the details for the _other_ monitor (ie. I was getting the details for my builtin LCD when Totem was getting info from the VGA output). If you see screens blinking, it's a known X bug, see: https://bugs.freedesktop.org/show_bug.cgi?id=13907 2008-01-10 Bastien Nocera <hadess@hadess.net> * src/backend/bacon-resize.c: (bacon_resize), (bacon_restore): Don't try to change the resolution in multi monitor mode, as the VidMode extension doesn't allow for multiple monitors (Closes: #472494) 2008-01-08 Bastien Nocera <hadess@hadess.net> * src/backend/bacon-resize.c: (bacon_resize_init), (bacon_resize), (bacon_restore): * src/backend/bacon-resize.h: Pass the GtkWidget of the video widget when resizing for fullscreen, use multi-head aware function to get the Screen, Display and Root Window, only get the XRandR screen configuration when going into fullscreen, not when init is called. * src/backend/bacon-video-widget-gst-0.10.c: (bacon_video_widget_set_fullscreen): * src/backend/bacon-video-widget-xine.c: (bacon_video_widget_set_fullscreen): Update for changed API
Confirmed, works for me. Thanks Bastien!