bbidulock / icewm

A window manager designed for speed, usability, and consistency
Other
571 stars 97 forks source link

Retroarch (w/ SwitchRes) doesn't display properly in fullscreen #676

Closed Slider-Whistle closed 1 year ago

Slider-Whistle commented 1 year ago

Haven't experienced this in any other window manager. I imagine it relies on some particularity that just this one lacks. Willing to do some tests if anyone has an idea what to investigate. Issue disappears when switching to a different workspace and then back, might be a useful hint but it's a bit of a nuisance as a workaround. Maybe IceWM is somehow failing to let the fullscreen window know its been rescaled?

Here's some screenshots to illustrate: Thu 20 Oct 09:42:54 UTC 2022 Thu 20 Oct 09:42:56 UTC 2022 The resolution itself here isn't a bug, I use a CRT. Just the way that the window appears to fail to rescale itself to the new desktop resolution in the first screenshot.

Tested on latest git commit.

gijsbers commented 1 year ago

Haven't experienced this in any other application. I imagine it relies on some particularity that just this application lacks. Maybe the application is somehow failing to realize it is fullscreened? Feels like another example of having to prove the bug in the application. The best thing you can do is provide a detailed foolproof step-by-step recipe how to reproduce this. Include installation steps. Assume zero knowledge about games. The second best thing is provide the output of xwininfo -tree -frame on the failed window and also the output of icesh list spy when you go fullscreen.

Slider-Whistle commented 1 year ago

I'm sorry about my rude attitude, I didn't mean to sound so entitled. I'm grateful that you're still willing to offer advice.

I did test it with some more window managers, and it turns out the first three that worked as I personally expected were part of a very small set. Specifically, it has worked on dwm, openbox, and fluxbox so far, but not blackbox, twm, fvwm, window maker, or even metacity. I'd test it with some newer window managers, but I find them kind of ugly. At this point, I'm beginning to understand that it might not just be icewm missing out on a newer feature. I'm sorry for the assumption.

Just in case there's anything that sticks out immediately, I'll share the results of those tests you gave me: retroarch & sleep 5 ; xwininfo -tree -frame ; sleep 2 ; xwininfo -tree -frame (Before and after tabbing out workspaces):

xwininfo: Window id: 0x1208650 "Frame"

  Root window id: 0x21a (the root window) (has no name)
  Parent window id: 0x21a (the root window) (has no name)
     1 child:
     0x1208651 "Container": ()  800x600+0+0  +0+0
        1 child:
        0x4600002 "RetroArch  ": ("retroarch" "retroarch")  800x600+0+0  +0+0

xwininfo: Window id: 0x1208650 "Frame"

  Root window id: 0x21a (the root window) (has no name)
  Parent window id: 0x21a (the root window) (has no name)
     1 child:
     0x1208651 "Container": ()  320x240+0+0  +0+0
        1 child:
        0x4600002 "RetroArch  ": ("retroarch" "retroarch")  320x240+0+0  +0+0

retroarch & sleep 5 ; icesh list spy as I tab in and out:

0x3c00002   1  1425 "RetroArch  "       : (retroarch.retroarch) 800x600+0+0
38:09.049: 0x3c00002: WM_NAME = RetroArch
38:10.653: 0x3c00002: Defocus Grab Ancestor
38:10.841: 0x3c00002: Defocus WhileGrabbed Nonlinear
38:10.841: 0x3c00002: Leave Normal Nonlinear Nofocus
38:10.841: 0x3c00002: Unmap 0x3c00002
38:10.841: 0x3c00002: Configure 0x3c00002 320x240+0+0
38:10.841: 0x3c00002: _NET_WM_STATE = _NET_WM_STATE_FULLSCREEN
38:10.846: 0x3c00002: _WIN_LAYER = 4
38:10.885: 0x3c00002: Configure 0x3c00002 320x240+0+0 Send
38:10.942: 0x3c00002: Configure 0x3c00002 320x240+0+0 Send
38:11.125: 0x3c00002: Mapped 0x3c00002
38:11.125: 0x3c00002: Visibility PartiallyObscured
38:11.141: 0x3c00002: Enter Normal Nonlinear Nofocus
38:11.151: 0x3c00002: _NET_WM_STATE = _NET_WM_STATE_FOCUSED, _NET_WM_STATE_FULLSCREEN
38:11.153: 0x3c00002: _WIN_LAYER = 14
38:11.158: 0x3c00002: Visibility Unobscured
38:11.158: 0x3c00002: Focus WhileGrabbed Nonlinear
38:11.301: 0x3c00002: Defocus Ungrab Pointer
38:11.301: 0x3c00002: Focus Ungrab Ancestor
38:11.332: 0x3c00002: WM_NAME = RetroArch
38:12.108: 0x3c00002: Visibility FullyObscured
38:12.127: 0x3c00002: Visibility Unobscured
38:12.128: 0x3c00002: Visibility FullyObscured
38:12.130: 0x3c00002: Visibility Unobscured
38:12.131: 0x3c00002: Visibility FullyObscured
38:12.170: 0x3c00002: Visibility Unobscured
38:13.105: 0x3c00002: Unmap 0x3c00002
38:13.105: 0x3c00002: Defocus Normal Nonlinear
38:13.105: 0x3c00002: Leave Normal Ancestor Nofocus
38:13.105: 0x3c00002: Destroyed 0x3c00002

If you're still willing to try to reproduce it yourself, I would personally install a distribution of retroarch, run it once to generate the user config files, and then add the following configuration changes to $HOME/.config/retroarch/retroarch.cfg:

crt_switch_resolution = "4"
crt_switch_resolution_super = "0"
video_fullscreen = "true"

Optionally, you can also change the "menu_driver" setting to "rgui", just to make sure you're running the same program. You don't need to open a game or anything, they act more or less the same way as the main menu.

Would also just like to add, I'm a very big fan of IceWM. Its stock themes all look great, its panel doesn't come with visual bugs unlike a couple of the standalone ones, and it even includes a built-in inbox checker with support for Maildir. I had a good look around, and no standalone mail widget seems to offer that.

Slider-Whistle commented 1 year ago

Got to add real quick, those two tests were run on 2.9.7, not the latest Git pull. Forgot to switch back to the version under /usr/local.

gijsbers commented 1 year ago

Am I right in assuming that the display resolution is also 320x240 when you switch to fullscreen? The output looks normal to me, except for the triple toggling of visibility at 38:12.108 - 170. I appreciate that you tested on so many window managers. That the application fails on six out of nine is telling. But the formal reasoning is this: IceWM claims to be conformant to the ICCCM and EWMH specifications. That should suffice for applications to function properly. As long as IceWM is standard conformant, the ball lies with the application. To raise an issue then means to prove IceWM is non-conformant in some respect. Consider that the task of a window manager is about directing input focus and about placing windows on the screen. What output is shown by the application is then by definition outside of the scope of the window manager.

Slider-Whistle commented 1 year ago

First bit's correct, according to the monitor's OSD. I understand that IceWM takes its standards compliancy pretty seriously, and still advertises it in its feature lists. I think I'll try testing this program with whatever GNOME and KDE use these days soon. Do you know of any other tests I might be able to try to figure out what exactly's being done differently? Maybe to file a feature request/special case fix, rather than a bug fix. I don't know anything about X11 myself, but just as a complete shot in the dark, what do you know about the "Container"s from the xwininfo log? Maybe the difference lies with how icewm (and other similarly mature WMs, but I'll try testing some very new ones soon) versus some other WMs might decide to handle them?

gijsbers commented 1 year ago

The containers are a way to isolate the application from the window manager. It's a technique most window managers try to do without as it increases the internal complexity of the window manager, but to applications this should be of no concern. Blackbox and fvwm seem to use it too. Again, reasoning that application fails on WM X is due to WM X being wrong, and hence we can bug its maintainer, is mistaken.

Slider-Whistle commented 1 year ago

Of course if that did turn out to be the reason, I wouldn't bug you to remove a piece of perfectly good functionality, or even add a hack config option which guts it out somehow. I couldn't test that program with mutter or kwin, as installing them would require substantial changes to my OS. fvwm and blackbox appeared to also incidentally implement containers, however twm and window maker do not seem to, so I think there's a good chance that it's not icewm's container system confusing retroarch. I retested it with metacity, it turned out as I expected after all, along with dwm, openbox, and fluxbox which also do not implement containers, but I think that's probably just a coincidence now.

I think I'll find some way to privately investigate whether it's icewm's container system (and create an issue with retroarch if that's the case), and maybe some other avenues. Do you know of many other programs that go fullscreen personally, aside from mpv (this one seems to work everywhere)? If I find anything that might make for a valid feature request, I'll reopen this issue. I'm sorry for all of the trouble.