Opened 12 years ago

Last modified 12 years ago

#1008 new defect

Xinerama screen choosing problem

Reported by: sgsoftware@… Owned by: reimar
Priority: normal Component: vo
Version: HEAD Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:



Default value for the '-xineramascreen' (-1) doesn't work for me. As documentation states, this value means that mplayer window would be put on the current xinerama screen. However, window is always put on the same screen (the one which happens to have lower coordinates). I looked at the source code ('update_xinerama_info' function) and, indeed, it is not quite clear for me how is it supposed to choose the current screen, since window coordinates (vo_dx and vo_dy variables) are initially zero.

I have a vertical screens layout (i.e. one is below another). Here is an output from xrandr:

Screen 0: minimum 320 x 200, current 1280 x 1824, maximum 2000 x 2000
VGA connected 1280x1024+0+800 (normal left inverted right x axis y axis) 0mm x 0mm

1280x1024 60.0*+
1600x1200 60.0
1600x1024 60.0
1400x1050 60.0
1280x960 60.0
1152x864 75.0
1024x768 70.1 60.0
832x624 74.6
800x600 72.2 75.0 60.3 56.2
640x480 72.8 75.0 59.9

LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm

1280x800 60.0*+
1152x768 54.8
800x600 56.2
640x480 59.9

TV disconnected (normal left inverted right x axis y axis)

I run mplayer on the VGA screen, but it always appears on LVDS (unless I set xineramascreen to 0 explicitly).

Change History (8)

comment:1 Changed 12 years ago by reimar

* Bug 1009 has been marked as a duplicate of this bug. *

comment:2 Changed 12 years ago by reimar

  • Owner changed from beastd to Reimar.Doeffinger@…

The current screen is the one that MPlayer is currently displayed on.
This "obviously" does not work when starting with -fs, but that was not the intention.

comment:3 Changed 12 years ago by reimar

Forgot to say: to set the initial position, -geometry is the right option, and I think that should set vo_dx/vo_dy correctly.

comment:4 Changed 12 years ago by sgsoftware@…

Window appears on the same screen regardless of whether or not -fs is specified.

comment:5 Changed 12 years ago by reimar

Sounds like correct behaviour. Now I am completely confused, in what scenario exactly does MPlayer not work as you expect? And please give the full MPlayer output.

comment:6 Changed 12 years ago by sgsoftware@…

Sorry if I described the problem somewhat unclearly, but by the same screen I meant the screen which does not depend on the screen mplayer was run on. So if I run mplayer on screen 1 (i.e. the terminal window on which I run mplayer is on screen 1), mplayer window appears on screen 1 (which is correct). But if I run mplayer on screen 0, the window again appears on screen 1 (which I believe is incorrect). I think that correct behavior is to show mplayer window on the screen it was run on, if it has not been changed explicitly by the -xineramascreen option.

comment:7 Changed 12 years ago by reimar

"But if I run mplayer on screen 0"

What exactly does that mean? How do you run MPlayer on screen 0? I guess it does not mean starting MPlayer and then dragging it onto screen 0? (does that work as expected?)

comment:8 Changed 12 years ago by sgsoftware@…

This means that I launch mplayer from a terminal window which is on screen 0. If I launch it from a window manager command prompt when the active screen is 0, behavior is similar. Window always appear on screen 1. Actually, first it appears on the current screen for a moment, but then immediately is moved to another one.

Sure, I can drag it back to screen 0 after it has appeared.

Note: See TracTickets for help on using tickets.