Search not seeing Steam Input On-Screen Keyboard

[kohend]

I use a Steam Deck and I have an on screen keyboard issue, I wanted to work around it using xdotool, but it doesn't see the keyboard window in search, I can get the window name and class name by ID that I find through getmouselocation, but not via search, I tried a partial name with and without a regex wildcard, I even looked at the source code to see if there's some option tested there, but didn't see anything obvious.
Is this a bug? Do exluded from tray and/or toolbar windows not appear in search?

[FascinatedBox]

Are you able to paste the results of running xprop on that window? Excluding windows from the taskbar is done by adding SKIP_TASKBAR to a window's _NET_WM_STATE, so that shouldn't impede your ability to run the search. If I can see what properties the on screen keyboard has, I can give you an idea of how to find it through search.

[kohend]

Here they are:

STEAM_NOTIFICATION(CARDINAL) = 0
STEAM_OVERLAY(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
XdndProxy(WINDOW): window id # 0x5000061
_VARIABLE_REFRESH(CARDINAL) = 1
_NET_WM_ICON(CARDINAL) =        Icon (128 x 128):
        (not shown)

STEAM_GAME(CARDINAL) = 769
XdndAware(ATOM) = BITMAP
_NET_WM_NAME(UTF8_STRING) = "Steam Input On-screen Keyboard"
WM_NAME(UTF-8) = "Steam Input On-screen Keyboard"
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 28229646
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
_NET_WM_PID(CARDINAL) = 25689
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLASS(STRING) = "steamwebhelper", "steam"
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: False
                window id # of group leader: 0xda698029
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 0, 0
                program specified minimum size: 1280 by 360
                program specified maximum size: 1280 by 360
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0

[FascinatedBox]

_NET_WM_NAME(UTF8_STRING) = "Steam Input On-screen Keyboard"
WM_NAME(UTF-8) = "Steam Input On-screen Keyboard"

Thank you! So here's the issue: xdotool doesn't search for names correctly. It's probably skipping the WM_NAME because it's marked as utf-8. It doesn't even check _NET_WM_NAME because, again, the search is broken.

Go into xdo_search.c and look for _xdo_match_window_name. Delete everything in that function and replace it with this:

  unsigned char *name;
  int name_len;
  int name_type;

  xdo_get_window_name(xdo, window, &name, &name_len, &name_type);

  char *title = "";
  int result;

  if (name_len)
    title = (char *)name;

  result = regexec(re, title, 0, NULL, 0);
  free(name);
  return result == 0;

You may want to put in the entire title, because you can't search multiple criteria at once in xdotool (another fun bug that's been around for years).

[jordansissel]

xdotool doesn't search for names correctly

Interesting, and the behavior sounds like a bug. xdo search (_xdo_match_window_title) uses XGetWMName and loops over the result which assumes utf8 (using Xutf8TextPropertyToTextList). It's been a while since I've looked at this code, but it doesn't seem to ignore utf8. Something else might be going wrong here?

I do notice that it uses different code than xdo_get_window_name, though, which doesn't use XTextProperty internally and instead wraps XGetWindowProperty. Your code sample doesn't check name_type and may not work for certain value types. From memory, I am not sure how common different types (utf8, string, etc) are in this scenario.

[FascinatedBox]

Xutf8TextPropertyToTextList is failing with -3 (encoding not found), because UTF-8 should instead be the standard UTF8_STRING. It appears to fail by returning an empty string instead of returning the input. Unfortunately Steam is also doing this with the main Steam window. Maybe they'll also stop tagging the main steam window with STEAM_GAME (I can dream, can't I?)

[kohend]

Is there a way to work around that issue from xdotool's end?

[FascinatedBox]

You'd need to rebuild xdotool with the adjustment that I mentioned above. If you do that, xdotool will check _NET_WM_NAME which IS set correctly and should work before the broken WM_NAME. Apart from that, no.