TBH: Task Bar Hero (3678970)

[RafaelHGOliveira]

Compatibility Report

• Name of the game with compatibility issues: TBH: Task Bar Hero
• Steam AppID of the game: 3678970

System Information

• GPU: NVIDIA GeForce RTX 4070 SUPER
• Video driver version: NVIDIA 595.71.05
• Kernel version: 7.0.10-2-cachyos
• Link to full system information report as Gist: https://gist.github.com/RafaelHGOliveira/305956cb1947cd9aa19630c09bdd6499
• Proton version: Proton Experimental (including the bleeding-edge branch), Proton-CachyOS, GE-Proton

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

Symptoms

TBH: Task Bar Hero renders its UI as a transparent/layered window over the
desktop/taskbar. Under Proton, every region that should be transparent is drawn
as solid black on every Proton version tested. The game image does appear,
but mouse input only reaches the game under GE-Proton — with Proton
Experimental (and its bleeding-edge branch) and Proton-CachyOS the window shows
but is not interactive. The black-instead-of-transparent rendering happens on
all versions, GE-Proton included.

Reproduction

1. Install TBH: Task Bar Hero (AppID 3678970)
2. Set the compatibility tool to Proton Experimental (or Proton-CachyOS)
3. Launch the game — the image appears, but all areas that should be transparent
   are rendered solid black
4. Input does not reach the game window
5. Switch to GE-Proton — input now works and the game is playable, but the
   transparent areas are still rendered solid black

Note

• Only GE-Proton allows interacting with the game; Proton Experimental,
  Experimental bleeding-edge and Proton-CachyOS show the window but do not
  accept input.
• The broken transparency (solid black instead of transparent) reproduces on
  every Proton version, GE-Proton included.

PROTON_LOG attached below (steam-3678970.log.gz).

steam-3678970.log.gz

[ooemir23]

that's the problem

[solarisfire]

TBH: Task Bar Hero creates overlay windows with:
WS_EX_TRANSPARENT | WS_EX_LAYERED | WS_EX_NOACTIVATE

Under GE-Proton10-34, input works, but transparent overlay areas render as solid black.

The Proton log shows Wine creating "Overlay Box" windows with those layered/transparent styles, but x11drv reports shaped 0 for the corresponding X11 windows. GE-Proton also sets GAMESCOPE_XALIA_OVERLAY on them.

This suggests the Windows layered/transparent overlay is recognised but not being translated into an actual shaped/alpha X11 window.

[thekk1]

Additional diagnostic info

Reproduced this on a different setup (Linux Mint Cinnamon / X11, NVIDIA, GE-Proton10-34, wine-staging 10.0) and pulled a PROTON_LOG=1 with the default channels. Two findings that may help narrow down where the actual fix needs to land:

Transparency: it's the DWM composition path, not WS_EX_LAYERED

The game does not appear to use the classic WS_EX_LAYERED + UpdateLayeredWindow / SetLayeredWindowAttributes mechanism. It uses the modern DWM composition extension path. Relevant log lines:

fixme:dwmapi:DwmSetWindowAttribute (00000000000200B0, 2, 000000000010EF18, 4) stub
fixme:dwmapi:DwmExtendFrameIntoClientArea (00000000000200B0, 000000000010E620) stub

Both are pure stubs in current Wine's dwmapi — they return success but do nothing. Since DwmExtendFrameIntoClientArea (with negative MARGINS) is what tells the DWM to composite the host desktop through the client area, and it's a no-op, the supposedly-transparent regions end up rendered as the swapchain's clear color (black) on every Proton flavor.

This is consistent with the original report stating black-instead-of-transparent rendering reproduces on every Proton version including GE-Proton — the underlying dwmapi implementation is shared across all of them.

Input: Pointer Input API is stubbed

The game enables the Windows 8+ Pointer Input API:

fixme:win:NtUserEnableMouseInPointer enable 1 semi-stub!
fixme:win:GetPointerInfo (1 ...): stub
fixme:win:GetPointerType (1 ...): stub      [354 calls in init phase]

EnableMouseInPointer is a semi-stub (returns success without actually switching the input model), and GetPointerInfo / GetPointerType are full stubs. This plausibly explains why input doesn't reach the game window on Proton Experimental / bleeding-edge / CachyOS, while GE-Proton happens to work — likely because of unrelated input-routing patches in GE that let classic WM_LBUTTONDOWN etc. through despite the pointer mode having been "enabled".

Other observations (likely not the cause, just for completeness)

The game also calls UI Automation / MSAA against #32769 (the desktop window class) and walks the shell window hierarchy — presumably to position its sprites relative to real taskbar icons. Those calls are also stubbed (fixme:oleacc:find_class_data, fixme:uiautomation:...). GE-Proton spins up xalia.exe during launch but, as far as I understand, Xalia bridges Wine windows to host accessibility, not the other way around, so this functionality cannot work on Wine regardless.

Setup details

• Distro: Linux Mint 22.x (Ubuntu noble base), kernel 6.17.0-29-generic, Cinnamon on X11
• GPU: AMD Radeon 780M (Phoenix1 iGPU, RDNA3) — different vendor from OP's NVIDIA RTX 4070 SUPER, same symptom
• Proton: GE-Proton10-34, wine-staging 10.0
• Launch options used: PROTON_LOG=1 PROTON_USE_WINED3D=1 PROTON_NO_DESKTOP=1 %command%
• WineD3D vs DXVK made no difference for the transparency symptom
• Log channels were the default (no +win,+x11drv,+d3d), so window styles and X11 visuals aren't directly visible — a follow-up log with WINEDEBUG=+win,+x11drv,+dwmapi would confirm the DwmExtendFrameIntoClientArea margins value and whether the X11 window is created with an ARGB visual

Happy to capture a more verbose log if helpful.

[solarisfire]

Making progress...

[solarisfire]

20260604_173907.webm

Flickers, but it is possible to get this working on KDE plasma... just needs a little more tinkering wiithin proton.

[solarisfire]

Patch is here: GloriousEggroll/proton-ge-custom@master...solarisfire:proton-ge-custom:master but it's still not 100% perfect...

20260604_232811.webm

I'm basically turning every black pixel transparent, but the devs don't make that easy with a load of black pixels in the game itself. I'm sure a proper proton dev can do a better job 😅

[ooemir23]

How can I adjust this?

[thekk1]

Patch is here: GloriousEggroll/proton-ge-custom@master...solarisfire:proton-ge-custom:master but it's still not 100% perfect...
20260604_232811.webm

I'm basically turning every black pixel transparent, but the devs don't make that easy with a load of black pixels in the game itself. I'm sure a proper proton dev can do a better job 😅

I am not able to build it by my self.
Would it be possible for you to release a build and/or start the pull request to Proton GE?

[ooemir23]

Ekran.Kaydi.2026-06-05.20-32-20.webm

Using fabriqa.ai with the Gemini model, I was able to fix this much without knowing any programming. There's a problem with the change on the first boot, but it's fixed when you change its position with the super key. I don't know how to share this with you because I'm not a programmer :D