Recent Trixie update causes HamClock to overlay the taskbar

[g7ruh]

Describe the bug
A clear and concise description of what the bug is.

A recent update to Trixie causes HamClock to overlay the taskbar (when at top (default position))

To Reproduce
Steps to reproduce the behaviour:

1. Download and install 2026-04-13-raspios-trixie-arm64.img.xz on a Pi500 plus, or Pi4 (other models not tested)
2. DO NOT update when install process asks.
3. cd
   curl -OL https://hamclock.co.uk/install-hc-rpi
   chmod u+x install-hc-rpi
   ./install-hc-rpi

From https://qso365.co.uk/2024/05/how-to-set-up-a-hamclock-for-your-shack/

4. output from install process:

This script will install HamClock on Raspberry Pi OS.

Proceed? [y/n] y

A transcript of this installation may be found in /home/rp/install-hc-rpi.log
Installing required helper packages ...

Downloading https://ohb.hamclock.app/ham/HamClock/ESPHamClock.zip ...

Exploding ESPHamClock.zip into ESPHamClock ...

build for web access only (no hardware display)? [y/n] n

Display size appears to be 1920x1080.

1. 800x480
2. 1600x960
   Select desired HamClock size (1-2): 2

Building hamclock-1600x960 ...
finished

install HamClock desktop icon? [y/n] y

install User Guide on desktop? [y/n] y
jq: error (at :5): Cannot index string with string "name"
jq: error (at :5): Cannot index string with string "name"

start HamClock automatically each time Pi is booted? [y/n] y
HamClock installation is complete.
You may now run HamClock by typing hamclock.

** Note minor error above for "install User Guide on desktop" Not part of this issue. Did not occur on Pi4

6. Click on HamClock icon and Hamclock starts OK
7. Reboot Pi so that HamClock autostarts
8. HamClock starts up as expected with the screen grey bar below the PI OS taskbar.
9. Screen picture

10. Run apt update and apt full-upgrade
11. reboot Pi so HamClock autostarts
12. now the HamClock screen, with no grey header bar overlays the Pi taskbar

Screen picture:

13. Alternate test: install 2026-04-13 Trixie, run updates then install HamClock as above. HamClock then starts overlaying Pi taskbar.

OS: Pi OS Trixie 2026-04-13 version

• Browser Not applicable

Additional context
It looks like it has only happened recently, suggesting a recent Trixie update.

Also tested on a P4, Same result.
Also tested 800x480 screen. Same result.

Ending HamClock and restarting using desktop icon to start HamClock has the same result: Pi taskbar hidden

[wasatch-dev]

Shouldn’t HamClock run in full screen direct? I have never seen it as an app like this when I put it in full screen direct

[g7ruh]

I am using a 1920 x 1080 screen so I don't run it in full screen mode. My setting on Page 5 is Full scrn direct? = No
I use the Pi with the larger screen for other things. My 800x480 touch screen runs in full screen mode.

[g6nhu]

I think you caught the userguide error during the brief period where it wasn't quite linking correctly. It was fixed yesterday evening at 18:29z on PR #188

I did a fresh install today to check that and it was all OK.

I'm not sure about the default position though.

[g7ruh]

I think you caught the userguide error during the brief period where it wasn't quite linking correctly

OK that explains that error. I noticed it while testing the taskbar hiding problem.

[komacke]

Was this issue resolved by the documentation?

[g7ruh]

No this is a O/S issue, the documentation was something I had when I was testing the main problem, that was a glitch on the install PDF link during the install process.
It really looks like an update to Trixie has broken something. If it helps I have seen a kind of similar comment about funny things with Wayland. May be different, but if it helps...

Some text from that post is here. The last line suggests the physical display being smaller than the screen size, but strange none the less.

`Yes, but I don't want to force people to do that. I have after discussions
with Claude (yes, the 'AI') and with Carlo V who has been incredibly
helpful I've decided to put in a code hack. Both t30dpy and t30dpy3 check
to see if wayland is being used and if so check the physical window size
and if it is smaller than the startup size minus a protective margin they
resize to that size. The protective margin is because an app can't query
for anything useful or important like the task bar dimensions, so a fixed
128 pixels is used. Wayland and labwc also don't allow an app to specify
where the window is to be opened(!), they decide. Why? It was considered a
'security issue' if allowed. Really? Insane.

Also noting again that p7sim suffers from the same issue. My modded version
of that allows a size setting to be given on the command line so that can
be used.
There is no reliable fix for an app window being able to slide over the
taskbar, that is a labwc issue. That can be avoided by using a different
desktop compositor like Gnome.

Just to be clear, this is also a problem only if your physical display is
smaller than whatever size you start the app with...... `

Trouble is, using a different desktop is not really a workable detour as it is the default Pi desktop which has the problem.

I stress that this problem does not occur with the April release of the Pi OS, only when you use apt to do a current update.

[komacke]

I don't have pi OS so I can't recreate this. It looks to me like the app is just slightly above the top of the screen so you can't grab the title bar. I asked AI how to move a window in Wayland when the title bar is above the screen.

Please review the ideas below and note 2 points:

• how to get the window back
• if you get it back, does it stay that way after a reboot? If not, something else might need a change

It's not clear to me there is anything the HamClock installer should do but let's try to understand what's going on:

I couldn't get it to paste with reasonable formatting so here's a screenshot of the response:

[g7ruh]

Thanks, I will get to this in a day or so, house maintaining stuff over the weekend, help for that arrives this afternoon. Thanks for posting ideas.

[g7ruh]

Update after further testing:

There is still a problem with the current version of Raspberry Pi OS Trixie as described above.

This occurs when installing:
2026-04-13-raspios-trixie-arm64.img.xz downloaded from https://www.raspberrypi.com/software/operating-systems/ using HamClock ver 4.25 or ver 4.26

and running a full update. NOTE: the fault does not occur when using the downloaded file before any updates.

The Pi O/S runs Wayland GUI by default and this problem caused by a recent software update will occur when HamClock is installed with default settings.

Detour 1: As per @komacke just above: "The Super + Drag Shortcut" holding down the Raspberry logo key and mouse click anywhere in the HamClock window allows the HamClock pane to be dragged into the screen area.

Detour 2: use sudo raspi-config to change the default GUI to X11:

Raspi-config Main menu:

1. select 6) Advanced Options
2. then select Option A7 Wayland then select W1 X11 and reboot.

Normal operation is restored and the HamClock window is placed on the screen below the task bar as expected.

The remaining issues:

The Raspberry Pi folks have decided that the Wayland interface is the default going forwards. It is possible that X11 support will be removed in a future Pi O/S release. HamClock users then have a problem.

Anyone installing HamClock on a Raspberry Pi Model 4 or 5 (not tested on 3B) running Trixie using the screen size option and selecting a smaller display area will get the HamClock window covering the taskbar and may not know about the fault or the detours.

Anyone changing to the X11 interface may find other programs do not work as expected.

The result: folks installing HamClock using a window smaller than the offered window size (e.g. 800x480 or 1600x960 on a 1920x1080 screen) will not have smooth install experience. This could reflect badly on the maintainers and support.

I think this issue will require further consideration and possible identification of a fix to reduce the risk of a bad user experience caused by the recent updates to Wayland in Raspberry Pi O/S.

At least there is a current detour as described above.

Happy to help test any potential fixes.

[komacke]

As I mentioned I don't have Raspberry OS running on anything. I have Fedora 44 which is wayland-native. I happen to have X11 compatibility installed for other reasons: xorg-x11-server-Xwayland.

I compiled hamclock-800x480. It runs fine. I have the top bar. I can close the window, minimize, maximize.

I'm not certain if your issue is caused by HamClock. If you rebuild hamclock natively under trixie, do you see the same issue? Do you suspect there's some compile-time compatibility issue that causes it to be locked into old X11? Do you know if you any X11 compatibility installed?

[komacke]

Could you try this branch:
https://github.com/openhamclock/hamclock/tree/x11-test-fix

I can only confirm it works in Wayland with xorg-x11-server-xwayland install. I don't know if it works in pure x11 or if it will resolve the upgrade issue you are observing.

If this does resolve the issue we'll need to consider what testing it should undergo before we merge it into main.

[g7ruh]

Not sure if we are talking at cross-purposes. To clarify:

I am running Rasp O/S as above; In Trixie it uses Wayland enabled by default. I compile HamClock natively under Trixie using @g6nhu install method (install script). Compiling HamClock using the April 2026 Rasp O/S with no updates, HamClock compiles and runs perfectly. When I use apt to update to current version and reboot, HamClock then ends up with the HamClock pane obscuring the taskbar as screenshots above. So it is a change in the Rasp O/S updates between release and today (and recently, I think) that has 'broken' HamClock functionality. It goes wrong without a recompile: just apt update and reboot, then HamClock goes wrong.

Therefore it is a recent Wayland change in Rasp O/S (Trixie) that has caused HamClock to break without any recompile to HamClock. Recompile Hamclock or install the O/S, perform apt updates then compile HamClock and it goes wrong.

The problem is caused by a recent Rasp O/S update. It may be that a default option has changed and now HamClock goes wrong because of that. So we may need to determine what has changed in Wayland to cause the problem. I am afraid I do not have the skill set to dig that deep into Wayland related things.

Based on your AI based suggestion above, I decided to use the raspi-config option to switch to X11, reboot and test: it works fine. Switch back to Wayland and reboot and it goes wrong.

I just saw your post re 'try this branch'. I will do so later this evening UK time.

[wasatch-dev]

Do you have X11 enabled in raspi config?

First off, to make that work you need to be in the X11 desktop not the Wayland. You can change this in sudo raspi-config in the advanced menu. Then you need to use the xrandr --output HDMI-1 --scale-from 1600x960 --display :0. Next, to make the changes stick after reboot, you need to nano into the ~/.xsessionrc. file and add that resolution line.

[g7ruh]

OK, we are still talking cross-purpose: I can enable the Pi using Trixie with X11 and it works fine using the object compiled with Wayland enabled. Swap back to Wayland (and reboot) and the taskbar gets covered by the HamClock pane. Swap back to X11 (and reboot) and HamClock works fine. Without recompile every time for either GUI method.

When I looked at your code, I thought it was an X11 test. X11 works fine on the Pi.

The issue is that the Pi uses Wayland by default so any user trying to install HamClock on a Pi with smaller than monitor screen size will get this problem. Hence saying I am concerned that it could discourage folk in using HamClock on a Pi.

That is why I tested for a detour / temp fix while we try to discover what was changed recently in the Pi O/S updates to cause HamClock to 'break' when it was working fine up to very recently (say last month or so).

Since the compiled object has not changed, it is most likely a Wayland update which has triggered this condition.

[wasatch-dev]

This sounds like users of Raspberry Pi need to setup for X11 if using HamClock.