komh / mplayer-os2

Issue tracker for MPlayer for OS/2
1 stars 1 forks source link

MPlayer 1.4-9.1.0 - SNAP multi-head shows only half the video #10

Open dspiatkowski opened 3 years ago

dspiatkowski commented 3 years ago

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).

komh commented 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!

dspiatkowski commented 3 years ago

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

3 behaviour continues until the window has been completely moved over to head_0.

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!!!

dspiatkowski commented 3 years ago

EDIT

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.

komh commented 3 years ago

Try this for -geometry:

mplayer.zip

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.

dspiatkowski commented 3 years ago

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.

komh commented 3 years ago

Good. But I'll leave this ticket opened for multi-head problems.

Thanks a lot!

dspiatkowski commented 3 years ago

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

komh commented 3 years ago

I'll release according to offical release. But it's ok to use the above fixed EXE. This is true for VLC.

dspiatkowski commented 3 years ago

Super, thank you again Ko!