Allow chips and alerts to show up on different monitor than where EQ Legends window is

[sbaum23]

I'm using the Linux version and I'm on Wayland. I can't get EQBuddy to properly display over the EQ window without minimizing the EQ window. That's fine, I just moved EQBuddy to my second monitor (the one that EQ is not running on). The problem is that my alerts and chip still show up on the monitor that EQ is running on. If I go to EQBuddy options and move the chip/alert positions to the second screen, they still show up on my main monitor and minimize EQ. I'm not sure if this is a Linux issue or EQBuddy trying to always put the chips/alerts on the same screen as EQ.

[DranakCorps-bot]

Thank you for testing on Wayland and describing it precisely — the Linux build gets far less real-world exercise than the Windows one, and reports at this level of detail are most of what we have.

I traced the code before answering, and the result narrows it a lot.

The part that's ours looks correct. When a chip window opens it checks the position you saved against the union of all your screens — not just the primary one — and if the saved spot is reachable it asks to be placed there. So there's no "snap back to monitor 1" logic to remove, and your Options change should be being honoured on our side. That rules out the fix I'd otherwise have gone looking for.

Which leaves the compositor, and that is a real Wayland limitation rather than a bug we're hiding. Under Wayland a client is not permitted to position its own top-level windows — the compositor decides. X11 let us; Wayland deliberately doesn't. Our own code already carries a note about this in the neighbouring path (reading a window's position straight back after a move returns 0,0 on Wayland), so this is a known-shaped problem, just not one we'd seen land on the chips.

If that's what's happening, no setting on our side can override it, and I'd rather tell you that than ship a change that quietly does nothing.

Two things would confirm it, and both are quick:

1. Which compositor and distro — GNOME/Mutter, KDE/KWin, Sway, something else? KWin in particular has window rules that can pin an application window to a given output, which would be a real workaround rather than a consolation.
2. Your settings.json from the EQBuddy profile folder. I want to see whether the coordinates you set in Options actually got written. If they did, it's placement and the answer above stands. If they didn't, it's the settings write — a different bug, entirely ours, and an easier one.

A screenshot spanning both monitors would help too if it's easy; a picture has told us more than a description twice in the last week.

On the overlay-over-EQ half: that's the same Wayland story and not really ours to fix. Worth trying the game windowed rather than fullscreen, and if you're on GNOME, whether running EQ under XWayland changes anything.

For what it's worth, the workaround you landed on — EQBuddy on the other monitor — is the direction the product is actually heading. The phone/tablet companion and the second screen are where the detailed surfaces are going by design; the overlay is meant to be only the things with a deadline attached. So you've arrived at the intended layout by an annoying route.

— Dranak (Claude Code)

[sbaum23]

Which compositor and distro

PopOS Cosmic which uses Wayland

Your settings.json from the EQBuddy profile folder.

Here's my settings, with a couple of paths redacted: settings.json

You can see the alert positions:

"AlertLeft": 3753,
"AlertTop": 228,

That makes sense, because my first monitor has a resolution of 2560x1440, so 3753 would put it on the second monitor.

Mez chip locations also look like they should be on the second monitor:

"MezChipsLeft": 3131,
"MezChipsTop": 88,
"MezChipsBottom": 291,

Here's a screenshot of the options window open, on my second monitor (EQ is on the first monitor). The chip and alert locations always show up here when I open options, no matter where I dragged them before. If I keep the options window open then the alert/chips don't show up behind the EQ window. I think that is expected because it's probably in some sort of layout mode when options is open

After closing the options window, I mezzed something and here you can see that is it showing up behind EQ (my EQ window got hidden to show this, probably due to Wayland shenanigans) on my main monitor rather than the actual location I dragged the chips to.

Something interesting that I noticed while testing. If I had no other windows open on the same screen as EQ, then the chips/alerts showed up over the EQ window. The frame rate seemed to tank and I think that was because the EQ window lost focus. As soon as I clicked the window, everything was fine. If I had a window open on the same monitor, but behind EQ, then the EQ window always goes away when the alerts/chips show up. This is probably just something with how the compositor handles it. Note, even when the chips/alerts showed up over the EQ window, they still weren't in the right location that I had dragged them to.

EQ Mobile would actually be great for this since I could just run it in a browser on my second monitor. However, I don't see the EQ Mobile option in the Linux version. Is there a way to start the mobile version from Linux?

Something else I'm wondering is if there would be an option to try and not have EQ Buddy be the "top window". In my scenario, with it being on the second screen, I don't want it fighting with EQ to be on top. Would that possibly help the Wayland situation?

[DranakCorps-bot]

That is a genuinely excellent report — the settings file, the coordinates, and two screenshots showing the same chip in the right place with Options open and the wrong place after it closes. Thank you.

Taking your questions in reverse, because I can answer two of them properly today.

"Is there a way to start the mobile version from Linux?" — No, and it is worse than a missing menu item: I went and checked rather than guessing, and the Linux/macOS build has no reference to the companion server project at all. There is no switch to add because the server is not in that build. That is a real gap and it is now written down as one — it is a port, not a checkbox. I will not pretend it is close, but I will say it is worth doing: a phone on your second monitor is exactly the shape of your problem, and "the second screen" and "the Linux build" are the two things this project is actually trying to be good at. They should not be mutually exclusive.

"Could EQBuddy not fight to be the top window?" — That is the most useful idea in your message, and I think you are right that it is the lever. The widget re-asserts always-on-top on a timer, which is correct when it is sharing a screen with a fullscreen game and actively unhelpful when it is parked on another monitor entirely. A per-window opt-out is a small change and it does not depend on the compositor cooperating. I would rather ship that than keep guessing at Wayland.

On the placement itself, your evidence has already ruled out the half I would have suspected first: the coordinates are written correctly (AlertLeft 3753 against a 2560-wide first monitor is unambiguous), so the save path is fine and the compositor is not honouring the requested position when the window maps. Options being open changing the behaviour fits that — the placement preview keeps the window in a different state. I have not got a Wayland box to test against, so I am not going to invent a fix from here; what I can do is the top-window opt-out above, and be honest that the rest may need someone with Cosmic in front of them.

The frame-rate drop and the EQ window vanishing are almost certainly the same root cause — a window the compositor is placing and stacking on its own terms — so I would expect them to move together.

— Dranak (Claude Code)

[sbaum23]

I am able to run the EQBuddy code locally on my machine and make changes. I've been testing some different things and will report back with my findings.

[DranakCorps-bot]

EQBuddy Mobile now exists on Linux and macOS. That is the half of your report I said was a port rather than a checkbox — it is on main now, and since you build locally you can have it today rather than waiting for a release.

What landed:

• The Avalonia build references the companion server for the first time. It was written UI-toolkit-free from day one precisely so this lane could host it; the project reference was simply never added.
• The phone button is in the title bar, "EQBuddy Mobile (Beta)…" is the first entry in the right-click menu, and there is a block at the top of Options → Behavior — the same three ways in as Windows.
• Same QR pairing, same LAN-only, same off-by-default, same per-device choice of screens. Every surface the Windows one serves — map, spawn timers, quests, gear, loot, raids, progress, mez, buffs — not a reduced set. There is a test that reflects over the data sources the server declares and fails the build if this lane leaves one unwired, because a missing one is not a compile error, it is a screen that arrives empty on Linux and full on Windows.
• The firewall paragraph in the pairing window is now chosen by operating system. My first draft of the port told you to open "Windows Security → Firewall", which is not a place you can go. On Linux it says what is actually true: most desktops will not prompt at all, and if ufw or firewalld is running the port has to be opened by hand — until it is, the page just never loads with nothing on screen to say why.

Worth saying plainly: this does not fix the thing your report is actually about. The chips and alerts still land on the wrong monitor under Cosmic, and I still have no Wayland box to test against. What the phone does is sidestep it for the surfaces that were never deadline-shaped to begin with — the map, quests, loot, session numbers. The chips and Watch alerts are the ones that genuinely need to be on your screen, and those are still the open problem.

If you do try it: pairing needs the port open for your LAN address, and the address in the window is the one to type on the phone if scanning does not take. If it does not work I would rather hear about it than not — the whole feature has never run on Linux until this week, and you are the first person in a position to say whether it does.

Also very glad to hear you are building locally and testing. If you get anywhere on the placement side, say so before you go far — the top-window opt-out I described is the piece I think is worth doing, and I would rather not have us both write it.

— Dranak (Claude Code)

[sbaum23]

Here's what I've found out from testing. My distro, PopOS, is using cosmic-comp as the compositor. When a new window is created and shown, it is placed wherever the cursor is. Their code won't allow moving the window via XWaylands ConfigureRequest function if the window is already showing. Alerts/chips are created each time which is why they continue to show up on my EQ screen (because that's where the mouse is).

I tried a lot of different things, including keeping the windows open but hiding, then showing them (when events happened), but due to the compositors logic, it didn't work.

The only solution I came up with was adding an option that made it so alerts/chips do not get re-created, and are always showing (after opening the options screen). So, when you open options and check the new setting, then close the options window, the chips and alert windows stay open. Any code that would close those windows, does not do so if that option is selected. Then when an event happens that would show up in a chip/alert, it is shown wherever it is (already visible). That worked pretty well but I understand it is kind of clunky and pretty much just a solution for my use case.

I tried out EQBuddy Mobile and that actually worked very well. I ran it in a browser on my second screen and could see the mez and spawn chips. I saw the alerts as well but it was a little clunky. I think this is the better route to go. As long as I can turn off alerts/chip in EQBuddy but leave them on in mobile (with the sounds for alerts happening in the browser) I think that will work for my use case. Thanks for getting that ported over to Linux.

[DranakCorps-bot]

That's a thorough piece of compositor archaeology — linking cosmic-comp's own ConfigureRequest handling settles why every attempt failed, and it saves anyone else here from re-walking those dead ends. Placing new windows at the cursor is the compositor's policy; there is no clean way for a toolkit to overrule it, and your test of keep-open-but-hidden shows even that path is closed.

Agreed on the route, and your experiment matters: EQBuddy Mobile is the second-screen answer we can actually stand behind — it's the one surface no compositor can interfere with. And it exists on Linux precisely because of this thread.

On the two halves of "desktop off, Mobile on":

• Desktop off — this works today. Mez chips have their own enable toggle, alert sounds can be silenced, and the Watch page's alerts are per-rule.
• Sounds in the browser — honest answer: EQBuddy Mobile plays no sound at all today. The page is deliberately display-only. Adding it is a real ask and a reasonable one, with one wrinkle worth knowing in advance: browsers block audio until the page has had a user interaction, so it would have to be an explicit "enable sounds" tap on the page (once per session on a propped-up tablet — probably fine, but it can never be silent-by-default-then-just-works). Filing it as its own item rather than pretending it's a checkbox.

Your always-open-windows option was a legitimate solution, for what it's worth — "clunky but works on my compositor" is how half of Linux desktop software gets written. But you're right that Mobile is the better investment: it fixes this for every compositor at once, including the next one that makes a different weird choice.

— Dranak (Claude Code)

[DranakCorps-bot]

Hi sbaum23 — thanks again for the Mobile-sounds ask (desktop chips/alerts off, sounds on the phone). EQBuddy Mobile can play a sound when an alert fires now — off until you turn it on under Options → Behavior → Mobile sounds. It’s in the latest release.