VOGONS


First post, by madewokherd

User metadata
Rank Newbie
Rank
Newbie

The Linux version of dosbox (0.71) does not set the InputHint flag of WM_HINTS as explained at http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.4

Summary: The InputHint flag tells the window manager whether a window has set the input setting. If the input setting is True, the window manager is allowed to set the keyboard focus to that window; if the input setting is False, the window manager is not allowed to do that.

So apparently that means it's undefined whether the window manager will assign keyboard focus to that window or not. I happen to use a window manager that does not do this (http://madewokherd.nfshost.com/luccawm). I don't want to change the general rule because what it's doing now makes more sense in other cases.

Dosbox should set the InputHint flag so that it can be sure that any ICCCM-compliant window manager will assign keyboard focus to it.

This can be tested using the xprop command. For xfce-terminal, which accepts keyboard focus, it outputs the following:
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x4000044
bitmap id # of mask for icon: 0x400004b
window id # of group leader: 0x4000001

For xclock it shows this:
WM_HINTS(WM_HINTS):
Client accepts input or input focus: False
Initial state is Normal State.
bitmap id # to use for icon: 0x4200001
bitmap id # of mask for icon: 0x4200003

And dosbox:
WM_HINTS(WM_HINTS):
bitmap id # to use for icon: 0x420000e
bitmap id # of mask for icon: 0x420000c

(There is no "Client accepts input or input focus:" line because dosbox does not specify that value.)

I plan to implement a work-around for the window manager I use based on class, but I hope you will fix this problem.

Reply 5 of 10, by madewokherd

User metadata
Rank Newbie
Rank
Newbie

It shouldn't be anything to do with Unicode.

This is a rather low-level X Windows thing so whatever component is using Xlib to create the window is what would directly set this value, probably using the XSetWMHints function.

Apparently you do not deal with X directly and SDL actually sets WM_HINTS. I don't know how SDL determines whether it will set this value, and it could be a bug in dosbox or sdl that's ultimately causing this.

I have no knowledge of how the SDL api works so it would probably be difficult for me to determine what's really going on here.

Reply 7 of 10, by madewokherd

User metadata
Rank Newbie
Rank
Newbie

create_aux_windows in SDL_x11video.c sets InputHint properly. If I'm understanding this, that function should be called whenever a window is created for display.

X11_SetIcon in SDL_x11wm.c would overwrite WM_HINTS with a version that only has IconPixmapHint | IconMaskHint set, effectively unsetting InputHint. If that is being called on your window after create_aux_windows (I assume to set an icon on the window), that would account for this problem (and it would mean that SDL is broken).

I will try to patch the SDL source code to verify that that is the cause of this issue.

Edit: Yep, patching X11_SetIcon so it sets InputHint works.

Reply 8 of 10, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I recall something that you have to set the icon before creating any windows in SDL. (Which dosbox does btw).
So maybe internally they mess up ?

Water flows down the stream
How to ask questions the smart way!