[PATCH] x11 vo drivers override user settings for window placement
This bug (so far) only exists in the svn version of mplayer. Here's what happens: 1. Kermit uses mplayer to play a video. 2. mplayer opens a window. At this point, the window manager or session manager places the window where it thinks is best, taking into account Kermit's preferences and the size hint already supplied by mplayer. 3. mplayer moves the window to the center of the screen. The window manager of course has the opportunity to override this, but it would need a compelling reason. 4. Kermit complains to me, saying "hey, I really wanted that mplayer window to be placed according to my settings." First of all, since you're setting the size hint, the only reason to move the window at all is in case there isn't a window manager running. While that probably happens more often for a video player than most applications, I'd still wager it's pretty rare. However, you don't have to give up on that case to resolve this. You can just move the window before mapping it. I've supplied a patch to do just that, and it works. Oh, and it also makes the gl2 driver set the size hint before mapping -- that's pretty important. I'll be in #mplayerdev as _markt all day, in case you have any questions. Mark
On Sun, 24 Jun 2007 12:03:24 -0700 "Mark Tiefenbruck" <mark@fluxbox.org> wrote:
First of all, since you're setting the size hint, the only reason to move the window at all is in case there isn't a window manager
No, the reason for this is to _force_ a certain position of the window, overriding the window manager. I proposed this way of doing it based on some "standard" i've read at that time about forcing the window position (it should be the ICCCM, but i'm not sure)
running. While that probably happens more often for a video player than most applications, I'd still wager it's pretty rare. However, you don't have to give up on that case to resolve this. You can just move the window before mapping it.
That wont work. Most window manager move the window _after_ mapping, thus overriding MPlayers prefered position. What you are looking for is to use -geometry. Attila Kinali -- Linux ist... wenn man einfache Dinge auch mit einer kryptischen post-fix Sprache loesen kann -- Daniel Hottinger
First of all, since you're setting the size hint, the only reason to move the window at all is in case there isn't a window manager
No, the reason for this is to _force_ a certain position of the window, overriding the window manager. I proposed this way of doing it based on some "standard" i've read at that time about forcing the window position (it should be the ICCCM, but i'm not sure)
running. While that probably happens more often for a video player than most applications, I'd still wager it's pretty rare. However, you don't have to give up on that case to resolve this. You can just move the window before mapping it.
That wont work. Most window manager move the window _after_ mapping, thus overriding MPlayers prefered position.
I see the problem here. You've confused mplayer with a window manager. Here are some quotes from that strange document you mentioned, which can be found at http://tronche.com/gui/x/icccm/sec-4.html . "To permit window managers to perform their role of mediating the competing demands for resources such as screen space, the clients being managed must adhere to certain conventions and must expect the window managers to do likewise. These conventions are covered here from the client's point of view." "Each window manager will implement a particular window management policy; the choice of an appropriate window management policy for the user's circumstances is not one for an individual client to make but will be made by the user or the user's system administrator." "For example, the claim is often made: "The client I'm writing is important, and it needs to be on top." Perhaps it is important when it is being run in earnest, and it should then be run under the control of a window manager that recognizes "important" windows through some private protocol and ensures that they are on top. However, imagine, for example, that the "important" client is being debugged. Then, ensuring that it is always on top is no longer the appropriate window management policy, and it should be run under a window manager that allows other windows (for example, the debugger) to appear on top." Keep reading on your own. Mark
On Sun, 24 Jun 2007 13:57:18 -0700 "Mark Tiefenbruck" <mark@fluxbox.org> wrote:
I see the problem here. You've confused mplayer with a window manager.
No we don't. MPlayer doesn't manage its window. It just tells the WM in an unmistakable way what it preferes at _mapping_time_.
Here are some quotes from that strange document you mentioned,
Strange document? It's the standard on how X11 clients should communicate with each other. And if you are really a fluxbox developer as your email adress suggests, then you should know it by heart.
Keep reading on your own.
I've read it quite a few times when the code in question was written. What you have here is a missunderstanding on what MPlayer should be doing and what not. Rule of thumb is that an application should not force a specific window position or size on the user/WM. But, unlike with other application, people want that the video window is at the top and centered on their screen on startup. MPlayer does that, but it is also the only thing it does. Everything what happens _after_ the move/resize is up to the user/WM and MPlayer will neither complain about it nor force its believe on what is right on the user/WM. The code you are questioning here has been written at an very early stage of the MPlayer development and had got its share of testing and review. And so far, i don't remember anyone complain about the fact that the MPlayer window comes up centered (actualy there were a lot of complaints when it didn't happen). So, you being the first one who dislikes this behavior in 5 or 6 years, i guess the code cannot be that wrong. So, again, to solve your problem use -geometry. If that is not enough for you and you really want that MPlayer does not set its position and size at mapping time, make a patch that disables this behaviour by a command line switch, but leave it enabled by default. Anything else is not acceptable. Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
Hello, On Mon, Jun 25, 2007 at 10:06:03AM +0200, Attila Kinali wrote: [...]
The code you are questioning here has been written at an very early stage of the MPlayer development and had got its share of testing and review. And so far, i don't remember anyone complain about the fact that the MPlayer window comes up centered (actualy there were a lot of complaints when it didn't happen). So, you being the first one who dislikes this behavior in 5 or 6 years, i guess the code cannot be that wrong.
Actually there should still be an open bug report about something like this in the bugzilla. Some window-managers are really hard to convince that their default window-placement algorithms aren't always right. I'd also like to mention that changing this code would break both -geometry _and_ -xineramascreen, and quite a few window managers still have trouble handling xinerama in a nice way and usually offer few to none options on where to place and how to fullscreen in this situation. Greetings, Reimar Doeffinger
Attila Kinali wrote:
The code you are questioning here has been written at an very early stage of the MPlayer development and had got its share of testing and review. And so far, i don't remember anyone complain about the fact that the MPlayer window comes up centered (actualy there were a lot of complaints when it didn't happen). So, you being the first one who dislikes this behavior in 5 or 6 years, i guess the code cannot be that wrong.
I'm not 100% positive that this is the same behaviour you're talking about, but: Once upon a time, I had my window manager set to remember MPlayer's window position, i.e. to place the window in a specific place on screen. Then someone came along with a complaint about the window no location no longer being correct after changing videos while in fullscreen; Reimar committed a fix for that behaviour as r18718, and now the window appears in the center of the screen no matter what I do (short of extensive experimentation with the -geometry option which seems far more than should be reasonable); the window manager's Remember setting has no effect whatsoever. I mentioned this on -svnlog at the time, and there was a patch posted on 06-20-2006 which AFAIR did not fix the problem for me. Since I had no arguments beyond the ones I had already used, and Reimar, being the only developer involved in the discussion, did not seem remotely persuaded by those - and indeed, given that the patch he posted did not fix the problem I had described, did not seem to entirely understand the problem itself - I more or less dropped the subject. However, the fact remains that I am *not* happy about being completely unable - short, again, of more experimentation to find correct values for -geometry than seems reasonable (given that the WM can handle this automagically) - to have MPlayer appear at any location *other* than the center of the screen. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
Hello, On Mon, Jun 25, 2007 at 07:14:33AM -0400, The Wanderer wrote: [...]
I mentioned this on -svnlog at the time, and there was a patch posted on 06-20-2006 which AFAIR did not fix the problem for me. Since I had no arguments beyond the ones I had already used, and Reimar, being the only developer involved in the discussion, did not seem remotely persuaded by those - and indeed, given that the patch he posted did not fix the problem I had described, did not seem to entirely understand the problem itself - I more or less dropped the subject.
The only thing I remember was about making MPlayer remember the position when playing more than one file, which would be something entirely different. And I am of course not convinced since both from a theoretical standpoint it makes more sense for the geometry option to actually work since it's already there, it simplified the code and lastly I had the impression it actually _reduced_ the overall number of complaints - but maybe I just scared everyone into shutting up :-P.
However, the fact remains that I am *not* happy about being completely unable - short, again, of more experimentation to find correct values for -geometry than seems reasonable (given that the WM can handle this automagically) - to have MPlayer appear at any location *other* than the center of the screen.
Well, finding the right -geometry options should be a matter of seconds (-geometry +xpos+ypos) unless you want some different behaviour than it offers. I guess it wouldn't be too much of an effort to extend -geometry by something that says "don't set position", but to me it seems to minor to invest my time (as an illustration why: at LinuxTag I alone had 3 people ask about some placement and fullscreen issues related with xinerama but none about general placement). This also matches my overall experience, I remember lots of complaints about the default placements the windows managers did but besides these two none about the forced MPlayer way... Greetings, Reimar Doeffinger
Hi Reimar Doeffinger! On 2007.06.25 at 15:25:26 +0200, Reimar Doeffinger wrote next:
Well, finding the right -geometry options should be a matter of seconds (-geometry +xpos+ypos) unless you want some different behaviour than it offers. I guess it wouldn't be too much of an effort to extend -geometry by something that says "don't set position", but to me it seems to minor to invest my time (as an illustration why: at LinuxTag I alone had 3 people ask about some placement and fullscreen issues related with xinerama but none about general placement). This also matches my overall experience, I remember lots of complaints about the default placements the windows managers did but besides these two none about the forced MPlayer way...
Well people got accustomed to it and consider it strictly a feature, not a bug. At least I don't see anything wrong with media player being (probably the only) application which doesn't preserve its old position and doesn't follow "smart" window placement, like other windows. It just seems logical to have it always in the center of the screen. As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying. -- Vladimir
Hello, On Mon, Jun 25, 2007 at 06:59:42PM +0400, Vladimir Mosgalin wrote:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
I sent patches for both. Nobody cared. End of story. Greetings, Reimar Döffinger
Hi Reimar Döffinger! On 2007.06.25 at 17:21:31 +0200, Reimar Döffinger wrote next:
On Mon, Jun 25, 2007 at 06:59:42PM +0400, Vladimir Mosgalin wrote:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
I sent patches for both. Nobody cared. End of story.
May I have them (googling mailing list doesn't really help)? I apply and keep a bunch of patches up-to-date for my own mplayer build anyway, don't think two more would hurt. Unless this part changed too much and they need massive changes, of course... I really miss keep-fullscreen ability. -- Vladimir
Hello, On Mon, Jun 25, 2007 at 07:53:21PM +0400, Vladimir Mosgalin wrote:
On 2007.06.25 at 17:21:31 +0200, Reimar Döffinger wrote next:
On Mon, Jun 25, 2007 at 06:59:42PM +0400, Vladimir Mosgalin wrote:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
I sent patches for both. Nobody cared. End of story.
May I have them (googling mailing list doesn't really help)? I apply and keep a bunch of patches up-to-date for my own mplayer build anyway, don't think two more would hurt. Unless this part changed too much and they need massive changes, of course... I really miss keep-fullscreen ability.
The fullscreen patch was actually only for aspect changes with the same file and was in the thread named "vo_gl - fullscreen problem on config change" about a year ago. The real solution for that is fixed-vo=yes in the config file (does anything speak against making this the default?) No idea where the other patch is, but I think it should be somewhere close to Wander's complaint mail, maybe he can give a hint? Greetings, Reimar Döffinger
Hi Reimar Döffinger! On 2007.06.25 at 18:34:35 +0200, Reimar Döffinger wrote next:
The fullscreen patch was actually only for aspect changes with the same file and was in the thread named "vo_gl - fullscreen problem on config
Well, since -vo gl has problems with aspect changes in different files anyway (only with -fixed-vo, of course) I don't really care about that, however losing fullscreen status is really annoying.
The real solution for that is fixed-vo=yes in the config file (does anything speak against making this the default?)
It _should_ be default. I remember a thread a year ago or maybe two about making it default, it was accepted.
No idea where the other patch is, but I think it should be somewhere close to Wander's complaint mail, maybe he can give a hint?
Alright, I'm not that interested in aspect patch, but as I wrote in other mail, -vo gl + -fixed-vo drops fullscreen status for me. According to you, it shouldn't. -- Vladimir
Hello, On Mon, Jun 25, 2007 at 11:46:14PM +0400, Vladimir Mosgalin wrote:
On 2007.06.25 at 18:34:35 +0200, Reimar Döffinger wrote next:
The fullscreen patch was actually only for aspect changes with the same file and was in the thread named "vo_gl - fullscreen problem on config
Well, since -vo gl has problems with aspect changes in different files anyway (only with -fixed-vo, of course) I don't really care about that, however losing fullscreen status is really annoying.
Not aware of it. Details?
The real solution for that is fixed-vo=yes in the config file (does anything speak against making this the default?)
It _should_ be default. I remember a thread a year ago or maybe two about making it default, it was accepted.
Just checked, it is not.
No idea where the other patch is, but I think it should be somewhere close to Wander's complaint mail, maybe he can give a hint?
Alright, I'm not that interested in aspect patch, but as I wrote in other mail, -vo gl + -fixed-vo drops fullscreen status for me. According to you, it shouldn't.
It does not for me. Neither xv, x11, gl nor gl2 do. Though x11 funnily places the video on the top left instead of centering it. Greetings, Reimar Döffinger
Hi Reimar Döffinger! On 2007.06.25 at 22:21:42 +0200, Reimar Döffinger wrote next:
Well, since -vo gl has problems with aspect changes in different files anyway (only with -fixed-vo, of course) I don't really care about that, however losing fullscreen status is really annoying. Not aware of it. Details?
Hmm. MPlayer dev-SVN-r23011-4.1.2 (C) 2000-2007 MPlayer Team (yeah I know it isn't new but I don't want to lose dts decoding functionaly - "ffmpeg" dts decoder is basically unworkable, and the only working one was removed). metacity-2.18.3 as window manager. No obscure settings and tweakers installed. fglrx 8.37.6 driver. xorg-x11-server-Xorg-1.2.0 server. mplayer just switches back to window on video change. It also does this on aspect ratio change --- F1 switch_ratio 1.33333 F2 switch_ratio 1.77778 F3 switch_ratio 1.85 F4 switch_ratio 2.3 F5 switch_ratio 0 --- in config (with xvidix, it worked correctly - but vidix is broken for a long time for me, so I can't test it). Also after mplayer switches to window on video change, aspect of previous video preserves. When switching to fullscreen with 'f', aspect is correct for new video. When switching back to window with 'f', aspect is broken again. In other words, aspect ratio for window mode breaks unless mplayer was in window mode when switching video.
It _should_ be default. I remember a thread a year ago or maybe two about making it default, it was accepted. Just checked, it is not.
Very strange. Well, it doesn't matter anyway. -- Vladimir
Hello, On Tue, Jun 26, 2007 at 01:28:45AM +0400, Vladimir Mosgalin wrote:
On 2007.06.25 at 22:21:42 +0200, Reimar Döffinger wrote next:
Well, since -vo gl has problems with aspect changes in different files anyway (only with -fixed-vo, of course) I don't really care about that, however losing fullscreen status is really annoying. Not aware of it. Details?
Hmm. MPlayer dev-SVN-r23011-4.1.2 (C) 2000-2007 MPlayer Team (yeah I know it isn't new but I don't want to lose dts decoding functionaly - "ffmpeg" dts decoder is basically unworkable, and the only working one was removed).
You don't have to make install just to test a newer version. Also ffmpeg dts works fine with -demuxer lavf (which admittedly is not an option of you want subtitles as well though). [...]
mplayer just switches back to window on video change. It also does this on aspect ratio change
This is exactly the same problem as you already reported and shouldn't be specific to -fixed-vo but actually the other way round. [...]
Also after mplayer switches to window on video change, aspect of previous video preserves. When switching to fullscreen with 'f', aspect is correct for new video. When switching back to window with 'f', aspect is broken again. In other words, aspect ratio for window mode breaks unless mplayer was in window mode when switching video.
Are you really sure this is the version you gave above? Without weird patches? As I understand it this is exactly the problem that should have been fixed by r13844 (though only for -fixed-vo). Maybe it broke again somewhen, but I sure didn't notice then. Greetings, Reimar Doeffinger
Hi Reimar Doeffinger! On 2007.06.26 at 11:41:50 +0200, Reimar Doeffinger wrote next:
Hmm. MPlayer dev-SVN-r23011-4.1.2 (C) 2000-2007 MPlayer Team (yeah I know it isn't new but I don't want to lose dts decoding functionaly - "ffmpeg" dts decoder is basically unworkable, and the only working one was removed).
You don't have to make install just to test a newer version. Also ffmpeg dts works fine with -demuxer lavf (which admittedly is not an option of you want subtitles as well though).
You bet. One company which makes particallary nice DVDs (box design/extras/quality) here in Russia is fond of the strange scheme "Russian DTS dub/Russian DD dub/Original DTS track". Since I don't want to listen to dub, dts track is the only choice for me. I also want subtitles (though sometimes I can rip them beforeahead, of course). Anyway, of course I'll try the latest version, since it looks like someone actually cares about these bugs ;)
mplayer just switches back to window on video change. It also does this on aspect ratio change This is exactly the same problem as you already reported and shouldn't be specific to -fixed-vo but actually the other way round.
So, was _this_ one fixed? The Wanderer is trying to tell me that fullscreen status activated with 'f' isn't supposed to override (assumed) global "no-fs" mode. While I consider this to be a wrong behaviour, at least there is logic behind it. But there is no reason at all why mplayer would lose fs status on aspect ratio change.
Also after mplayer switches to window on video change, aspect of previous video preserves. When switching to fullscreen with 'f', aspect is correct for new video. When switching back to window with 'f', aspect is broken again. In other words, aspect ratio for window mode breaks unless mplayer was in window mode when switching video.
Are you really sure this is the version you gave above? Without weird patches? As I understand it this is exactly the problem that should have been fixed by r13844 (though only for -fixed-vo). Maybe it broke again somewhen, but I sure didn't notice then.
Of course, no vo/aspect/geometry - related patches.. Anyway I'll try with latest svn and will report back. Could it be wm-related? -- Vladimir
Hello, On Tue, Jun 26, 2007 at 05:28:53PM +0400, Vladimir Mosgalin wrote: [...]
Anyway, of course I'll try the latest version, since it looks like someone actually cares about these bugs ;)
Sure I do, I "fixed" them all for me. Unfortunately some of the fixes relied on certain other bugs...
mplayer just switches back to window on video change. It also does this on aspect ratio change This is exactly the same problem as you already reported and shouldn't be specific to -fixed-vo but actually the other way round.
So, was _this_ one fixed? The Wanderer is trying to tell me that fullscreen status activated with 'f' isn't supposed to override (assumed) global "no-fs" mode. While I consider this to be a wrong behaviour, at least there is logic behind it. But there is no reason at all why mplayer would lose fs status on aspect ratio change.
No, it's actually the same bug. The vo (currently?) simply has no business knowing when a file ends and another one starts, though an aspect change is the same as a new file. [...]
Could it be wm-related?
Actually it is (see my mail about -fstype). But actually please just apply my [RFC] patch and then report any bugs that still remain after that. Greetings, Reimar Döffinger
Hi Reimar Döffinger! On 2007.06.26 at 16:12:44 +0200, Reimar Döffinger wrote next:
Actually it is (see my mail about -fstype).
-fstype none helps, but I can't switch back to window then ;)
But actually please just apply my [RFC] patch and then report any bugs that still remain after that.
It works really great - both when switching videos and changing aspect, even with my mplayer version. I hope it gets applied. Thanks! -- Vladimir
All right, it's time to come back to this. I hope we can get down to actual discussion of problems, with evidence, and solutions, rather than fighting fire with fire. Not to mention completely off-topic concerns. You claimed you needed to force the window manager to respect your choice because size hints weren't being respected by window managers. Well, I've just run the command "xterm -geometry +90+90" in fluxbox, openbox, blackbox, metacity, kwin, twm, mwm, fvwm, windowmaker, beryl, enlightenment, sawfish, icewm, and xfwm4. Guess what my results were. Guess what xterm uses. If you have honestly been having trouble in this area, then there's something wrong with your methodology. User specified geometry (e.g. the -geometry option) should be conveyed using the USPosition and USSize flags in the size hint. Program specified geometry should use PPosition and PSize. And even if you have been having trouble in this area, the appropriate course of action is to submit bug reports and supply patches, rather than break your own software. I noticed your recent changes to combine the window initialization for all the different vo drivers. I applaud this effort; it was badly needed. It does mean, however, that my patch no longer applies. This is fine, since I've discovered a minor bug in my reasoning anyway. You're creating the window with the specified size and position (this is good; it's what you're supposed to do -- I just forgot) so there's no reason to move the window at all, even if there's no window manager running. Thus, the appropriate fix is actually just to remove the call to vo_x11_nofs_sizepos entirely. So, again, what's the hold-up here? Mark
Hello, On Fri, Jul 06, 2007 at 02:38:17PM -0700, Mark Tiefenbruck wrote: [...]
You're creating the window with the specified size and position (this is good; it's what you're supposed to do -- I just forgot) so there's no reason to move the window at all, even if there's no window manager running. Thus, the appropriate fix is actually just to remove the call to vo_x11_nofs_sizepos entirely.
So, again, what's the hold-up here?
Simply because with MPlayer it is never easy and certainly never as easy as one might think. Your proposed way to fixing it does not work because it breaks resizing the window for the next movie with -fixed-vo. I am also unsure how to provide both the current feature of playing all movies in a centered window with -fixed-vo and let the window-manager do its job. Know of a way to change the position hint without hiding and without destroying the window but that still has a reasonable chance to be respected by the window manager? Greetings, Reimar Döffinger
Simply because with MPlayer it is never easy and certainly never as easy as one might think. Your proposed way to fixing it does not work because it breaks resizing the window for the next movie with -fixed-vo. I am also unsure how to provide both the current feature of playing all movies in a centered window with -fixed-vo and let the window-manager do its job.
The window doesn't have to be centered. As demonstrated by my tests with xterm, every popular window manager (that would honor your configure request anyway) will respect your size hint. If the window manager places your window somewhere else, it's because the user specifically told it to do so. You should take this as equivalent to using the -geometry option. -fixed-vo in this case should therefore work the same way as when using -geometry. If you want to be careful (and you probably should), make sure the window doesn't leave the _NET_WORKAREA.
Know of a way to change the position hint without hiding and without destroying the window but that still has a reasonable chance to be respected by the window manager?
You can move and/or resize the window later when you need to. I don't have a problem with that. The problem here is that the user has no choice over initial position, except by using the relatively inferior -geometry option.
Hello, On Tue, Jun 26, 2007 at 01:28:45AM +0400, Vladimir Mosgalin wrote: [...]
mplayer just switches back to window on video change. It also does this on aspect ratio change
I think I found the problem. -fstype none "fixes" it I think, but actually the behaviour I get is the buggy one. Greetings, Reimar Döffinger
Reimar Döffinger wrote:
Hello, On Mon, Jun 25, 2007 at 07:53:21PM +0400, Vladimir Mosgalin wrote:
On 2007.06.25 at 17:21:31 +0200, Reimar Döffinger wrote next:
I sent patches for both. Nobody cared. End of story.
May I have them (googling mailing list doesn't really help)? I apply and keep a bunch of patches up-to-date for my own mplayer build anyway, don't think two more would hurt. Unless this part changed too much and they need massive changes, of course... I really miss keep-fullscreen ability.
The fullscreen patch was actually only for aspect changes with the same file and was in the thread named "vo_gl - fullscreen problem on config change" about a year ago. The real solution for that is fixed-vo=yes in the config file (does anything speak against making this the default?)
I have not observed it in a while, but there was a period during which I repeatedly (if not consistently) observed two behaviours when playing files of different resolutions with -fixed-vo: Going from wider to narrower, the resolution of the old file would be kept, and the extra space would be filled with bright pink. (Why pink I'm not sure, since apparently my system colorkey is blue or green.) GOing from narrower to wider, the resolution would also be kept, and only part of the new wider file would be displayed. I never reported this officially, because I never managed to identify a pair of files which could reliably trigger either effect. (I tended to notice it primarily while watching tasvideos.org files while drifting off to sleep.)
No idea where the other patch is, but I think it should be somewhere close to Wander's complaint mail, maybe he can give a hint?
I'm not sure offhand what patch you're referring to. The only patch related to "this issue" (and specifically to the complaint mail you mention) which I know of came, as I said, on June 20th, 2006. Lemme look... http://article.gmane.org/gmane.comp.video.mplayer.devel/35198/ As I said, this patch did not appear to address the issue I had raised. For all I know, it may address the one Vladimir is having. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Mon, 25 Jun 2007 17:19:49 -0400 The Wanderer <inverseparadox@comcast.net> wrote:
Going from wider to narrower, the resolution of the old file would be kept, and the extra space would be filled with bright pink. (Why pink I'm not sure, since apparently my system colorkey is blue or green.)
GOing from narrower to wider, the resolution would also be kept, and only part of the new wider file would be displayed.
That sounds strange. It would suggest that MPlayer doesn't set the scaling correctly. What vo do you normaly use? Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
Hello, On Tue, Jun 26, 2007 at 10:57:36AM +0200, Attila Kinali wrote:
On Mon, 25 Jun 2007 17:19:49 -0400 The Wanderer <inverseparadox@comcast.net> wrote:
Going from wider to narrower, the resolution of the old file would be kept, and the extra space would be filled with bright pink. (Why pink I'm not sure, since apparently my system colorkey is blue or green.)
GOing from narrower to wider, the resolution would also be kept, and only part of the new wider file would be displayed.
That sounds strange. It would suggest that MPlayer doesn't set the scaling correctly. What vo do you normaly use?
That was a bug in -vo xv and should be fixed since quite a long time. Greetings, Reimar Doeffinger
Hello, On Mon, Jun 25, 2007 at 07:53:21PM +0400, Vladimir Mosgalin wrote: [...]
May I have them (googling mailing list doesn't really help)? I apply and keep a bunch of patches up-to-date for my own mplayer build anyway, don't think two more would hurt. Unless this part changed too much and they need massive changes, of course... I really miss keep-fullscreen ability.
The one to keep position is in the thread "[MPlayer-dev-eng] [RFC] keep user window position" "Date: Tue, 20 Jun 2006 22:08:24 +0200" Greetings, Reimar Döffinger
On Mon, 2007-06-25 at 18:59 +0400, Vladimir Mosgalin wrote:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
The fullscreen behavior isn't directly related to other placement issues. Fullscreen is an option, and option values are always initialized when starting a new file (to the first available out of file-specific value / global value / default). Keeping fullscreen status would require an option type that would be set to the globally specified value when starting the first file but only modified for later files if there's a file-specific value given.
Hi Uoti Urpala! On 2007.06.25 at 18:22:03 +0300, Uoti Urpala wrote next:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
The fullscreen behavior isn't directly related to other placement issues. Fullscreen is an option, and option values are always initialized when starting a new file (to the first available out of file-specific value / global value / default). Keeping fullscreen status would require an option type that would be set to the globally specified value when starting the first file but only modified for later files if there's a file-specific value given.
That's strange, AFAIR it worked as expected (keeping fullscreen status) some years ago, when I was using xv. Either my memory is wrong it something is fishy here o_O -- Vladimir
Hello, On Mon, Jun 25, 2007 at 07:55:29PM +0400, Vladimir Mosgalin wrote:
On 2007.06.25 at 18:22:03 +0300, Uoti Urpala wrote next:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
The fullscreen behavior isn't directly related to other placement issues. Fullscreen is an option, and option values are always initialized when starting a new file (to the first available out of file-specific value / global value / default). Keeping fullscreen status would require an option type that would be set to the globally specified value when starting the first file but only modified for later files if there's a file-specific value given.
That's strange, AFAIR it worked as expected (keeping fullscreen status) some years ago, when I was using xv. Either my memory is wrong it something is fishy here o_O
Should work fine with all vos with -fixed-vo Greetings, Reimar Döffinger
Hi Reimar Döffinger! On 2007.06.25 at 18:21:46 +0200, Reimar Döffinger wrote next:
Should work fine with all vos with -fixed-vo
It _should_, but it doesn't work for -vo gl. On the other hand, my mplayer isn't very fresh, probably two month old. So if it was fixed very recently, I'm sorry. But in the past, it never worked for -vo gl. -- Vladimir
Am Mon, 25 Jun 2007 18:59:42 +0400 schrieb Vladimir Mosgalin <mosgalin@VM10124.spb.edu>:
Hi Reimar Doeffinger!
At least I don't see anything wrong with media player being (probably the only) application which doesn't preserve its old position and doesn't follow "smart" window placement, like other windows. It just seems logical to have it always in the center of the screen.
I think the window manager should always be allowed to do its job. A xinerama setup is the obvious situation where you don't want the window centered in the (virtual) screen, but there can be others. Personally, I watch video fullscreen or manually move a smaller window to a place where it doesn't disturb other content on screen. I can imagine reserving a certain location in my window layout for the small mplayer window and then have the choice for fullscreen or there. The reason that the lack of support on the mplayer side for that is no big issue for me atm. is just that I don't watch movies on my laptop/desktop system very often. I have a big tube TV connected to a Dxr3 card for that... For sure, specifying a proper geometry parameter and making this persistent via shell/Xresources (?) means should work, but window managers offer easier ways to handle that (fluxbox, at least;-).
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
I agree to that. It makes sense for mplayer to stay in fullscreen mode when I switched to it during playback - also when the next file starts. Same goes for window position - the application shall not question my decision to put it in a certain place. Mplayer may have to resize the window for aspect ratio... perhaps choose the largest rectangle that retains aspect ration within the user-defined size... Alrighty then, Thomas.
Hi Thomas Orgis! On 2007.06.25 at 17:30:28 +0200, Thomas Orgis wrote next:
Mplayer may have to resize the window for aspect ratio... perhaps choose the largest rectangle that retains aspect ration within the user-defined size...
Nah, then when you switch back and forth between videos with different aspect, mplayer window will get smaller till it gets to 1x1.. In case of keeping original window size, mplayer should just keep either current x or current y dimension and resize the other one according to current size and aspect ratio. However, I never thought there is much reason in this, imho coordinate of left upper corner should be preserved, but size can be set anew. With fullscreen being special case, of course. -- Vladimir
On Mon, 25 Jun 2007 17:30:28 +0200 Thomas Orgis <thomas-forum@orgis.org> wrote:
Am Mon, 25 Jun 2007 18:59:42 +0400 schrieb Vladimir Mosgalin <mosgalin@VM10124.spb.edu>:
At least I don't see anything wrong with media player being (probably the only) application which doesn't preserve its old position and doesn't follow "smart" window placement, like other windows. It just seems logical to have it always in the center of the screen.
I think the window manager should always be allowed to do its job. A xinerama setup is the obvious situation where you don't want the window centered in the (virtual) screen, but there can be others.
MPlayer has a smart centering feature, it centers the window on the current xinerama screen and not on the current x11 screen. I know that it does not work with certain setups using nvidia twinview, but i never got anyone to tell my what does not work or even to write a complete bugreport.
Personally, I watch video fullscreen or manually move a smaller window to a place where it doesn't disturb other content on screen. I can imagine reserving a certain location in my window layout for the small mplayer window and then have the choice for fullscreen or there.
use -geometry
Mplayer may have to resize the window for aspect ratio... perhaps choose the largest rectangle that retains aspect ration within the user-defined size...
Doens't -geometry already allow that? If not, send patch. And BTW, it's MPlayer with a capital P. Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
On Tuesday 26 June 2007 12:02, Attila Kinali wrote:
MPlayer has a smart centering feature, it centers the window on the current xinerama screen and not on the current x11 screen. I know that it does not work with certain setups using nvidia twinview, but i never got anyone to tell my what does not work or even to write a complete bugreport.
The behaviour differs between the different vos too. With -vo xv, it does "what I want", with -vo gl I need -fstype none in order to get the placement right. Of course, my "what I want" might be completely different from someone else's :)
Vladimir Mosgalin wrote:
Hi Reimar Doeffinger!
On 2007.06.25 at 15:25:26 +0200, Reimar Doeffinger wrote next:
Well, finding the right -geometry options should be a matter of seconds (-geometry +xpos+ypos) unless you want some different behaviour than it offers. I guess it wouldn't be too much of an effort to extend -geometry by something that says "don't set position", but to me it seems to minor to invest my time (as an illustration why: at LinuxTag I alone had 3 people ask about some placement and fullscreen issues related with xinerama but none about general placement). This also matches my overall experience, I remember lots of complaints about the default placements the windows managers did but besides these two none about the forced MPlayer way...
Well people got accustomed to it and consider it strictly a feature, not a bug. At least I don't see anything wrong with media player being (probably the only) application which doesn't preserve its old position and doesn't follow "smart" window placement, like other windows. It just seems logical to have it always in the center of the screen.
In my case, I have three windows of a Japanese dictionary program already open in "correct" locations, and I want the MPlayer window to appear in a place - which I have clearly defined in my mind, and which does not change with time - which does not overlap with any of them. I can easily imagine that anyone else who wants to do cross-reference or comparison work of any remotely comparable nature would not want the window to be always in the center of the screen.
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, even with -fixed-fo; even more, it loses its fullscreen status, which is really annoying.
It does not lose fullscreen status for me, and never has, except in the case where I had not specified '-fs' before any filenames on the command line. The remainder of that description - losing window position when switching files - is, IIRC, precisely the problem which the change I objected to was supposed to fix. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
Hi The Wanderer! On 2007.06.25 at 17:25:11 -0400, The Wanderer wrote next:
It does not lose fullscreen status for me, and never has, except in the case where I had not specified '-fs' before any filenames on the command line.
Now that I tried it, this trick works for me too. By "losing fullscreen", I always meant "starting in a window -> pressing f -> going to fullscreen -> going to next video -> losing fullscreen status". I never use -fs switch actually. With -fs, fullscreen status isn't lost, but then I can't switch back to window anymore! If I do, mplayer will switch back to fullscreen by itself on the next video. So even if -fs is used, it's still broken. -- Vladimir
Vladimir Mosgalin wrote:
Hi The Wanderer!
On 2007.06.25 at 17:25:11 -0400, The Wanderer wrote next:
It does not lose fullscreen status for me, and never has, except in the case where I had not specified '-fs' before any filenames on the command line.
Now that I tried it, this trick works for me too. By "losing fullscreen", I always meant "starting in a window -> pressing f -> going to fullscreen -> going to next video -> losing fullscreen status". I never use -fs switch actually.
With -fs, fullscreen status isn't lost, but then I can't switch back to window anymore! If I do, mplayer will switch back to fullscreen by itself on the next video. So even if -fs is used, it's still broken.
It's not that it's broken; it's that you're expecting it to do something it isn't designed to do. Fullscreen status is set per-file. When the -fs option (or the -nofs option, which is default) appears before any filename, it sets (or, again by default, unsets) that status for all filenames given. When the -fs option appears after any specific filename, it sets that status for just that file. When you press the 'f' key, AFAICT you toggle that status for just the current file. You apparently want to be able to set the status for all not-yet-played files (and perhaps all already-played ones, in case of skipping backwards in the file queue), whenever you toggle the status for the current fle. MPlayer does not currently support this. It might be worth adding the option, but I for one would not like to see the current behaviour removed entirely. (For example, in a case such as mplayer file1.avi file2.avi -fs file3.avi MPlayer will play the first file windowed, the second in fullscreen, and the third windowed. Likewise, either of mplayer file1.avi -fs file2.avi file3.avi -fs mplayer -fs file1.avi file2.avi -nofs file3.avi should produce the mirror behaviour. Given that the desired fullscreen status has already been specified by the command-line options: how would you expect MPlayer to behave, with either of the command lines above, if you toggled fullscreen in the middle of one of the videos?) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Mon, 25 Jun 2007 18:59:42 +0400 Vladimir Mosgalin <mosgalin@VM10124.spb.edu> wrote:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file,
That's a feature, not a bug ;-)
even with-fixed-fo;
fixed-vo works for me. What problems do you have? Have you send a bugreport? Have you tried to make a patch?
even more, it loses its fullscreen status, which is really annoying.
Therefor you have -fixed-vo Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
Hi Attila Kinali! On 2007.06.26 at 10:55:01 +0200, Attila Kinali wrote next:
As about bugs, imho the worst placement-related bug is that mplayer loses its window position when switching to the next file, That's a feature, not a bug ;-)
Only without fixed-vo. When it happens with it, it's a bug. Fortunately, a patch exists already.
even with-fixed-fo;
fixed-vo works for me. What problems do you have?
start mplayer as mplayer -vo gl -fixed-vo <list of files>. Press f. Press enter/>/seek to the end/etc. Watch as mplayer switches back to window.
Have you send a bugreport? Have you tried to make a patch?
Well, according to explanation in this thread it's a "feature" too, and isn't supposed to work anyway.
even more, it loses its fullscreen status, which is really annoying.
Therefor you have -fixed-vo
Unfortunately, it's not "fixed" enough... -- Vladimir
On Monday 25 June 2007 17:59, Vladimir Mosgalin wrote:
not a bug. At least I don't see anything wrong with media player being (probably the only) application which doesn't preserve its old position
I remember a user in #mplayer that had issues with gmplayer, the controls didn't appear anywhere. Turned out that gmplayer saved the location of that window somewhere, and it was far, far, far offscreen for him.
Reimar Doeffinger wrote:
Hello, On Mon, Jun 25, 2007 at 07:14:33AM -0400, The Wanderer wrote: [...]
I mentioned this on -svnlog at the time, and there was a patch posted on 06-20-2006 which AFAIR did not fix the problem for me. Since I had no arguments beyond the ones I had already used, and Reimar, being the only developer involved in the discussion, did not seem remotely persuaded by those - and indeed, given that the patch he posted did not fix the problem I had described, did not seem to entirely understand the problem itself - I more or less dropped the subject.
The only thing I remember was about making MPlayer remember the position when playing more than one file, which would be something entirely different.
The problem which was posted, which r18718 fixed, was that when playing multiple files in sequence with the -fs option and changing back from fullscreen on something other than the first file the window would not be in the center of the screen. (Or perhaps "where it was supposed to be", which I think was the same thing.) The problem I had was that the commit broke support for window-manager location memory, which seemed - and still in many ways seems! - to be a completely unrelated issue.
And I am of course not convinced since both from a theoretical standpoint it makes more sense for the geometry option to actually work since it's already there, it simplified the code and lastly I had the impression it actually _reduced_ the overall number of complaints - but maybe I just scared everyone into shutting up :-P.
I don't remember there having been complaints about positioning before the one which prompted you to make that change. I don't remember there having been complaints about positioning since then, either, other than my own "this broke WM memory" at the time.
However, the fact remains that I am *not* happy about being completely unable - short, again, of more experimentation to find correct values for -geometry than seems reasonable (given that the WM can handle this automagically) - to have MPlayer appear at any location *other* than the center of the screen.
Well, finding the right -geometry options should be a matter of seconds (-geometry +xpos+ypos) unless you want some different behaviour than it offers.
The trouble is that the correct values for 'xpos' and 'ypos' are not remotely obvious, and have to be found by extensive experimentation - whereas with window-manager position memory, I can just move the window to the desired place, tell the WM "remember this", and have it figure out the correct X/Y automatically. It would probably be possible to obtain the X and Y coordinates the WM uses for positioning the remembered window, but I have no idea how and it - once again - seems like more effort than should be necessary. Except for when calling MPlayer from a program which (one may presume) has its own ways of determining what the appropriate coordinates are, -geometry seems so unwieldy as to be effectively useless IMO.
I guess it wouldn't be too much of an effort to extend -geometry by something that says "don't set position", but to me it seems to minor to invest my time (as an illustration why: at LinuxTag I alone had 3 people ask about some placement and fullscreen issues related with xinerama but none about general placement).
<no immediate comment>
This also matches my overall experience, I remember lots of complaints about the default placements the windows managers did but besides these two none about the forced MPlayer way...
Default window manager placement can be problematic, yes - I almost invariably prefer the "center of the screen" to what the WMs would choose by default. *However*, once I have chosen the position I want and told the WM about that, then the WM's position is *not* its default anymore - and MPlayer honored that placement before r18718, but has ignored it since then. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
Hi, On Mon, Jun 25, 2007 at 05:29:16PM -0400, The Wanderer wrote:
Well, finding the right -geometry options should be a matter of seconds (-geometry +xpos+ypos) unless you want some different behaviour than it offers.
The trouble is that the correct values for 'xpos' and 'ypos' are not remotely obvious, and have to be found by extensive experimentation - whereas with window-manager position memory, I can just move the window to the desired place, tell the WM "remember this", and have it figure out the correct X/Y automatically.
It would probably be possible to obtain the X and Y coordinates the WM uses for positioning the remembered window, but I have no idea how and it - once again - seems like more effort than should be necessary.
The program xwininfo can be used to get the geometry information of a window. Erik
On Mon, 25 Jun 2007 07:14:33 -0400 The Wanderer <inverseparadox@comcast.net> wrote:
I'm not 100% positive that this is the same behaviour you're talking about, but:
[bug description] Sounds strange. I remember having read something like that but i thought it was fixed. I'll try to have a look at it this weekend. Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
On Mon, 25 Jun 2007, Attila Kinali wrote:
On Sun, 24 Jun 2007 13:57:18 -0700 "Mark Tiefenbruck" <mark@fluxbox.org> wrote: I've read it quite a few times when the code in question was written. What you have here is a missunderstanding on what MPlayer should be doing and what not. Rule of thumb is that an application should not force a specific window position or size on the user/WM. But, unlike with other application, people want that the video window is at the top and centered on their screen on startup. MPlayer does that, but it is also
They do? I don't want that. It's always annoyed me that mplayer does this. Insisting that the application start centered and on top is something I expect from windows applications designed for people with small screens that only use one program at a time. I want the mplayer window to appear where it doesn't cover up other windows.
I see the problem here. You've confused mplayer with a window manager.
No we don't. MPlayer doesn't manage its window. It just tells the WM in an unmistakable way what it preferes at _mapping_time_.
No, you're telling us what MPlayer wants _after_ mapping time. That's the problem here. Once you map the window, placement is our business. For -geometry, use the USPosition setting in the size hint. That's what it's for. But when -geometry isn't given, use PPosition. That's what it's for. That's how applications and window managers play together to distinguish when a geometry was given by the user and when it came from the client. I don't care if the center is your default position; we respect that if the user hasn't specified another one. I care if the center is your _only_ position.
The code you are questioning here has been written at an very early stage of the MPlayer development and had got its share of testing and review. And so far, i don't remember anyone complain about the fact that the MPlayer window comes up centered (actualy there were a lot of complaints when it didn't happen). So, you being the first one who dislikes this behavior in 5 or 6 years, i guess the code cannot be that wrong.
Frankly, you're wrong about this. In the past, Kermit told us to remember MPlayer's position, and we did. MPlayer didn't move its window back to the middle of the screen. This ONLY happens in MPlayer's svn version. And don't get the idea that I'm following your project closely -- this has already annoyed your users enough to report it to me. You don't seem to understand why this is a bad thing, so let me give you some examples. We have a placement policy where new windows appear under the mouse. This is useful for people who have the window focus follow the mouse. How should that be solved with -geometry? We have a placement policy where new windows are placed to minimize overlap with other windows. How should that be solved with -geometry? We have placement policies where new windows are placed in columns or rows. How should that be solved with -geometry? Frankly, -geometry is from the stone ages of X11. Requiring people to use it in order to have any control over window placement whatsoever is going in the wrong direction. Do you really think that there should be no possibility in X11 for placing windows intelligently? Your arguments about media players being special and deserving the center of the screen is a fallacy. In fact, it was contradicted by the ICCCM in one of the quotes that I gave you. That is not a choice for the individual client to make. Let the window manager do its job.
So, again, to solve your problem use -geometry. If that is not enough for you and you really want that MPlayer does not set its position and size at mapping time, make a patch that disables this behaviour by a command line switch, but leave it enabled by default. Anything else is not acceptable.
You've spent too much time in Windows. Or maybe not enough. People shouldn't have to search for obscure configuration settings to get their software to stop annoying the hell out of them. Mark
Hello, On Mon, Jun 25, 2007 at 11:36:55AM -0700, Mark Tiefenbruck wrote: [...]
Your arguments about media players being special and deserving the center of the screen is a fallacy. In fact, it was contradicted by the ICCCM in one of the quotes that I gave you. That is not a choice for the individual client to make. Let the window manager do its job.
I'm not motivated to try and see if maybe this time, finally the majority of window managers might actually not suck so much that we do not get loads of complaints as long as we have only 2 1/2 users complaining... And certainly I am not fine with a patch that I expect to end in a tug war, where we have a patch "fixing" it one way and 6 months later another one "fixing" it back to the original behaviour again. Also the current behaviour is the only way I found that at least makes the behaviour consistent between different window managers, which is a value in itself, esp. when it comes to bug reports (like "I'm using -xineramascreen 1 but the window does not open on screen 1!"). Greetings, Reimar Döffinger
I'm not motivated to try and see if maybe this time, finally the majority of window managers might actually not suck so much that we do not get loads of complaints as long as we have only 2 1/2 users complaining...
There are only 2 1/2 users complaining because it's still only in svn. If you release this, it will become a swarm. We get a swarm from a bug with aMSN's system tray icon, which most people can't even reproduce, and nobody can reproduce consistently. I think a whole lot more people use MPlayer in the first place, and they'll definitely notice when their core window manager settings stop working. Remember when it happened with just the gl2 driver? I'm asking you to stay out of my living room because you're not invited. Don't forget, however, that I do have a shotgun. I've already written the patch to fluxbox that rejects your flimsy little configure requests. I'm here arguing because I care about high quality software, and I don't want you to make this mistake. But I don't expect any of you to listen for me. Fluxbox has a reputation in some circles of non-compliance with standards, but I've been working hard to change that (both the compliance and the reputation). If I find an expert in the area of the ICCCM, EWMH, and client-window manager interactions (say, from gnome or kde), would you consider his input sincerely? Mark
Hello, On Mon, Jun 25, 2007 at 12:24:24PM -0700, Mark Tiefenbruck wrote: [...]
There are only 2 1/2 users complaining because it's still only in svn. If you release this, it will become a swarm. We get a swarm from a bug with aMSN's system tray icon, which most people can't even reproduce, and nobody can reproduce consistently. I think a whole lot more people use MPlayer in the first place, and they'll definitely notice when their core window manager settings stop working. Remember when it happened with just the gl2 driver?
No idea what you are referring to in case of gl2. But I think we have had far worse breakage in releases so I am not too scared to try it out. I wouldn't mind a proper solution that works for all either though. But I'd like to emphasize that these changes were based on bug reports (mostly xineramascreen not working as documented, so you might argue that we should change the documentation instead...).
I'm asking you to stay out of my living room because you're not invited. Don't forget, however, that I do have a shotgun. I've already written the patch to fluxbox that rejects your flimsy little configure requests. I'm here arguing because I care about high quality software, and I don't want you to make this mistake.
If you think that improves the situation, fine. But I think that solution, just like your patch, will fix it for some and break it for others. And are you absolutely certain that your window manager provides for everything that -xineramascreen does? And even if it does, sure all other windows managers everyone might be using do as well? That we refuse your solution maybe is also be due to stupidity or stubbornness, but certainly not only.
But I don't expect any of you to listen for me. Fluxbox has a reputation in some circles of non-compliance with standards, but I've been working hard to change that (both the compliance and the reputation). If I find an expert in the area of the ICCCM, EWMH, and client-window manager interactions (say, from gnome or kde), would you consider his input sincerely?
Only if it is an expert on real world behaviour who would be willing to bet his name that it will 1) work as expected and 2) work as desired for maybe 95 % of users. I honestly doubt that this exists. The alternative is allowing to configure it. All of which would be much less complicated if we hadn't the same code messed all over the place. I guess I might even look at it again myself one day, but it's not a priority right now. Greetings, Reimar Döffinger
On Mon, 2007-06-25 at 22:15 +0200, Reimar Döffinger wrote:
If you think that improves the situation, fine. But I think that solution, just like your patch, will fix it for some and break it for others. And are you absolutely certain that your window manager provides for everything that -xineramascreen does?
If the user explicitly specifies -xineramascreen then workarounds specific to xinerama would be justified, but I don't think that case should dictate all window placement in MPlayer. I agree with the original poster that by default MPlayer should not try to override the window manager. If a window manager is broken then the user should explicitly configure MPlayer to work around it; the default should not be to force users of working window managers to work around MPlayer's brokenness.
Hi all, I am trying to run mplayer on a via epia cn10000 (CN700) through framebuffer. I have compiled viaarena's linux-fbdev-kernel-src_2.6.00.03.tgz and I can insert viafb with accel=1 and fbcon without errors in 2.6.21-5. Then, I can see movies with the constraints below: 1. With -vo fbdev I see the movie on the left top corner of the screen, at the movie's resolution and B&W 2. With -fs -vo fbdev I see the movie centered on the screen, at the movie's resolution, and B&W 3. With -vo fbdev2 I see the movie on the left top corner of the screen, at the movie's resolution and color 4. With -fs -vo fbdev2 I see the movie centered on the screen, at the movie's resolution, and color Besides, it always swallows a lot of cpu, so I think there is no 2D acceleration at all. I do not know whether this is a constraint of the mplayer output drivers or if it is a problem of viafb. In the first case I am interested in contributing somehow improving these output drivers. I am experienced in C but I am not in developing drivers, so maybe I can join some developer/s here with the same interest. Otherwise I would need some support to get a starting point. Any help will be very appreciated. Thanks in advance. Best regards. Antonio
On Sun, 24 Jun 2007 12:03:24 -0700 "Mark Tiefenbruck" <mark@fluxbox.org> wrote:
First of all, since you're setting the size hint, the only reason to move the window at all is in case there isn't a window manager running. While that probably happens more often for a video player than most applications, I'd still wager it's pretty rare. However, you don't have to give up on that case to resolve this. You can just move the window before mapping it. I've supplied a patch to do just that, and it works. Oh, and it also makes the gl2 driver set the size hint before mapping -- that's pretty important.
Did we reach any resolution about this issue? Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
Hello, On Mon, Jul 09, 2007 at 01:48:14PM +0200, Attila Kinali wrote:
On Sun, 24 Jun 2007 12:03:24 -0700 "Mark Tiefenbruck" <mark@fluxbox.org> wrote:
First of all, since you're setting the size hint, the only reason to move the window at all is in case there isn't a window manager running. While that probably happens more often for a video player than most applications, I'd still wager it's pretty rare. However, you don't have to give up on that case to resolve this. You can just move the window before mapping it. I've supplied a patch to do just that, and it works. Oh, and it also makes the gl2 driver set the size hint before mapping -- that's pretty important.
Did we reach any resolution about this issue?
No, but maybe everyone can test attached patch and comment what they like or don't like about it. Greetings, Reimar Döffinger
Hello, On Mon, Jul 09, 2007 at 03:11:31PM +0200, Reimar D?ffinger wrote:
On Mon, Jul 09, 2007 at 01:48:14PM +0200, Attila Kinali wrote:
On Sun, 24 Jun 2007 12:03:24 -0700 "Mark Tiefenbruck" <mark@fluxbox.org> wrote:
First of all, since you're setting the size hint, the only reason to move the window at all is in case there isn't a window manager running. While that probably happens more often for a video player than most applications, I'd still wager it's pretty rare. However, you don't have to give up on that case to resolve this. You can just move the window before mapping it. I've supplied a patch to do just that, and it works. Oh, and it also makes the gl2 driver set the size hint before mapping -- that's pretty important.
Did we reach any resolution about this issue?
No, but maybe everyone can test attached patch and comment what they like or don't like about it.
And I will start: I really don't like that it behaves inconsistent with -fixed-vo: The first movie will be played at the position indicated by the window manager while all others will play centered - possibly even on a different screen. Greetings, Reimar Döffinger
And I will start: I really don't like that it behaves inconsistent with -fixed-vo: The first movie will be played at the position indicated by the window manager while all others will play centered - possibly even on a different screen.
Yes, I need to make some adjustments to it, according to my latest response. If the window is placed somewhere else by the window manager, I think this placement should be treated like -geometry. The same goes for the case where the window is moved by the user. I'll try to get the patch fixed up soon, but since I've already addressed the problem in fluxbox, I'm not in a rush. Mark
participants (12)
-
Antonio Nevado -
Attila Kinali -
Erik Auerswald -
Jan Knutar -
Mark Tiefenbruck -
Reimar Doeffinger -
Reimar Döffinger
-
The Wanderer -
Thomas Orgis -
Trent Piepho -
Uoti Urpala -
Vladimir Mosgalin