ratpoison, feh, "MWM hints"

TaylanUB · 2010-02-25 17:40:35

Using ratpoison 1.4.5-2 and feh 1.3.4-6.

When i use the fullscreen option of feh, i get:

feh WARNING: Window Manager does not support MWM hints. To get a borderless window I have to bypass your wm.

And feh keybindings break, along with some other awkward behaviour like the image disappearing if i once change to another window and back.

This magically gets fixed for the rest of the X session if i run and quit MPlayer once. (And i think there were other ways, like running and quitting the Motif WM.)

Thanks in advance.

lunixhood · 2017-12-29 13:20:06

After 7 years and more, I actually have the same problem whith spectrwm instead of ratpoison, please did someone have the solution !!!?

It worked nicely before I installed some other window manager (fluxbox and i3)... It seems to work with them, but I merely get happy with spectrwm.
It seems like the new WMs messed up spectrwm (I already tryed to reinstall it).

seth · 2017-12-29 14:17:47

a) don't necrobump
b) This makes absolutely no sense

It seems like the new WMs messed up spectrwm

Looking at the feh sourcecode, it tries to obtain the "_MOTIF_WM_HINTS" atom from the server. If that doesn't exist (because nothing else randomly created it in doubt - the likely reason for the workaround in the OP) it creates an override_redirect window (ie. a window that is not input managed by the WM, stupid idea)

This seems a bug in feh, because
a) MWM is no way required nowadays (since about 2005?) to create fullscreenwindows *reasonably*
b) the presence of the atom does no way indicate MWM support by the WM

You can artificially create the atom using eg. xprop but ideally file a bug against feh.

Edit, inb4:

xprop -root -f "_MOTIF_WM_HINTS" 32a -set "_MOTIF_WM_HINTS" 0

Last edited by seth (2017-12-29 14:21:09)

Trilby · 2017-12-29 14:32:33

Also note that "borderless" is somewhat ambiguous. Generally in a context like this, that means an undecorated window. This meaning is completely irrelevant for non-reparenting WMs like spectrwm and ratpoison: there is no need to tell the WM not to create a title-bar and border, they already don't.

The other meaning of borderless, though, is the actual X11 window border property. Client programs can set this themselves, but many non-reparenting WMs also override this with their own preference (to give focused windows a scpecific color of a border for example). While I'm not familiar with Motif hints (before my time - not for usage, just for coding), none of the modern hint systems will be relevant for this kind of border. EWMH has atoms for fullscreen / borderless / various other types of windows. But these are not for WMs that set the border property of the client window itself (like spectrwm). There is no general mechanism to prevent WMs from doing this. But most WMs that do this do have their own system: window rules (I have no idea if spectrwm has these or not).

I find the feh error odd though. I don't have any MWM hints, and when I run `fex -x ...` I don't get an error message, nor do I end up with an override redirect window. It just works. And I can assure you, my WM is dumber than yours.

seth · 2017-12-29 14:38:29

*Any* client could have create the MWM hint before - in an effort to set it on its own window.
If that happened ever on the running X11 server, the atom is there and feh will be happy.

This is not strictly related to the WM (though a WM supporting MWM will liekly have created the atom)

There's actually no "no decoration please" hint besides MWM, EWMH operates on the type of the window rather than allowing the client to create the look by itself.
_NET_FRAME_EXTENTS is supposed to be set by the WM to inform the client, not the other way round.

Trilby · 2017-12-29 15:02:21

seth wrote:

There's actually no "no decoration please" hint besides MWM

Well there is if you want fullscreen, as a _NET_WM_STATE_FULLSCREEN window should be undecorated. But that is beside the point here as the WMs in question do not decorate anyways.

EDIT: Ah, and now I see what you mean about any client creating the atom: I just looked at feh's code. That is bad. I also wrote a quick check, the atom is set on my system (it makes me curious, what client is creating such an old atom!) I have virtually nothing other than urxvt and qutebrowser in my X session. Hmm, even with just urxvt the atom has been created, yet urxvt doesn't use the property on it's window (according to xprop).

EDIT 2: Yep, as long as it is compiled with "frills" urxvt creates that atom. Although urxvt does the same kind of check for whether the atom exists and makes an inference about the WM based on the existence of the atom ... when urxvt itself creates the atom. Now that is absurd behavior. (To be fair I'm pretty sure it checks for the existence prior to creating it itself, but this would only help for the first instance of urxvt run. Every subsequent instance of urxvt would pick up the atom that the previous one created.)

Last edited by Trilby (2017-12-29 15:17:57)

Arch Linux

#1 2010-02-25 17:40:35

ratpoison, feh, "MWM hints"

#2 2017-12-29 13:20:06

Re: ratpoison, feh, "MWM hints"

#3 2017-12-29 14:17:47

Re: ratpoison, feh, "MWM hints"

#4 2017-12-29 14:32:33

Re: ratpoison, feh, "MWM hints"

#5 2017-12-29 14:38:29

Re: ratpoison, feh, "MWM hints"

#6 2017-12-29 15:02:21

Re: ratpoison, feh, "MWM hints"

Board footer