Open dspiatkowski opened 3 years ago
Ooops... I had commented yesterday, it disappeared.
First, your problem is that MPlayer thinks your screen width is sum of width of two monitor screen not a active monitor screen. Probably, SNAP driver would provide APIs for this. However, MPlayer does not know of it. Currently, I have no plans to fix this because I have no SNAP enabled hardware.
Second, I'll look into geometry option. I've confirmed MPlayer for OS/2 does not respect geometry option.
Thanks for your report!
KO, Yeah, it is a weird issue because even when the window does come up, as you shift it from head_0 to head_1 and then back, the re-paint behaviour is not the same.
Case in point: 1) window is up, head_0 paints, head_1 does not 2) I shift the window to head_0, as that is being done the window on head_0 continues to be re-painted but head_1 stays black until the window has been completely moved over to head_1, only than does it actually re-paint successfully and shows actual playback
HOWEVER
3) when I then shift the window back to head_0, the instance window co-ordinates cross to head_0 all of the remaining head_1 window is re-painted black while head_0 starts to show correct playback
Anyways, this behaviour does NOT happen in VLC 3.0.10, although smPlayer shows something similar to mplayer (I suspect b/c it's based on mplayer?).
Alright, I'll watch for updated to the playback window GEO locating troubleshooting! Thank you!!!
Sorry, I was wrong about VLC, I had it set to DIVE and didn't catch that during my inital test. Once it's set to SNAP is shows the same behaviour. Sorry about the confusion.
Try this for -geometry
:
For dual head problem, I'm afraid I have no plan to deal it now. I have no hardware to test, nor time. If DIVE/VMAN works on dual head, then please use it.
YES...that change works, the window can now be positioned as per the description of the mplayer options. I tested both the % location, as in: 'geometry=10%' and the actual position, as in: '+400+400', both work fine!
Thank you for this change, it allows me to correctly locate the playback window on a single display.
Good. But I'll leave this ticket opened for multi-head problems.
Thanks a lot!
Ko, Will you be releasing an updated mplayer drop with this fix in it, or am I OK to continue to use the EXE you provided?
I had originally posted on OS2World about this, so I'm going to update that thread to indicate that you have a good fix for the '-geometry' positioning parameter.
Also, same applies to the VLC issue (didn't want to update that ticket since it's closed now).
Thanks! -Dariusz
I'll release according to offical release. But it's ok to use the above fixed EXE. This is true for VLC.
Super, thank you again Ko!
So this is a little weird, but I have a dual-head display here, so 1920x1200x2, total desktop size of 3840x1200 (so side-by-side monitors). Video hardware is the old trusty ATI 850 XT PE display with the latest AOS SMP safe SNAP drivers.
Mplayer comes up fine but it is always positioned in the CENTER of the two screens (which is not ideal because it spans two physical screens, and that produces a break in the image) but what is worse is the fact that with SNAP drivers only 1 of the displays actually shows a video, the other part remains BLACK.
Of course once I shift the playback window over to either screen it is OK as long as the display remains on that single screen.
I tried using the mplayer screen positioning options (to force the playback window to locate on a single screen) such as "geometry=25%:25%" but none of the combinations I could find worked (through the HOME/.mplayer/config file option).