odd windowing issue (perl Tk)

Mike Scott · 2026-07-08T11:03:51+00:00

Hi all. A bit of an odd problem here.I've a perl program that opens an X window using Tk. I specify the geometry 1400x700+0+0.Running under Mint, it works fine, and opens exactly as expected in the top left screen corner.On the Pi (pi4, 11/bullseye), it opens a window with the correct size but a very odd position:xwininfo: Window id: 0x1a00013 "Display" Absolute upper-left X: 1782 Absolute upper-left Y: 30 Relative upper-left X: 2 Relative upper-left Y: 30 Width: 1400 Height: 700 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +1782+30 --1262+30 --1262-350 +1782-350 -geometry 1400x700+1780+0which is well off to the right, with the title bar concealed underneath the top task bar.Any thoughts please as to what might be going on?(I know bulldog isn't the latest but I don't have any pressing need to upgrade. This machine is dedicated to running this one program.I also see xrandr returns unexpected output about not being able to fetch the gamma value for the screen, which it calls "default". But maybe that's a red herring.)

Jul 08, 2026 Last reply: 8 hours ago 64 Replies

Rate this thread:

The Natural Philosopher 1 day ago

Except when it does not.

Systemd depends on everyone rewriting init scripts to take into account dependencies, which a simple serial loading of daemons by init, rendered unnecessary.

Now Poettering and other onanists would argue that's not systemd's problem. BUT it resulted in a huge amount of work to restore the stability of systems that had been stable for years.

The same applies to logfiles.

When you fundamentally change the way the whole core system of daemons are spawned and monitored, for the sake of shaving a few seconds off boot times, it behoves you to pay attention to those daemons and either rewrite them, or at least rewrite their initialisation and configuration scripts.

And that applies to packages, or combinations of packages, that probably haven't been touched in years.

Vote

druck 1 day ago

It didn't work very well because for inexplicable reasons other distros (including otherwise sensible ones, and I'm looking at you Debian) have adopted Red Hat's poison chalice(s).

But the plan was Red Hat customers once on systemd wouldn't want to go through the pain of migrating all their scripts to a multitude of init alternatives they thought all the other distros would adopt for after failing to agree a common solution.

---druck

Vote

rbowman 19 hours ago

The reasons are rather explicable. Remember Upstart? Debian had a long discussion about whether to switch to Upstart or systemd from sysVinit. Systemd won. Ubuntu wasn't that attached to their own dog food and switche from Upstart to systemd. Fedora also switched from Upstart to systemd. Upstart has been on life support for about 8 years.

Runit is another attempt to replace sysV. It's the default on antiX and Void and can be used with a couple of others. MX didn't follow antiX and defaults to sysV with systemd as an option.

Distribution maintainers were looking for an alternative to sysV that allowed more flexibility. At least two replacements other than systemd were available. systemd won. Live with it or specify sysV on a distrowatch search. There are 54. Most are based on MX, antiX, Devuan, or Slackware. For a Pi Devuan is one option.

formatting link

Vote

Richard Kettlewell 13 hours ago

Debian’s decision was deeply contested within the project, but the reasoning is well documented.

I suspect Upstart is abandonware now.

IIRC there were upwards of a dozen attempts to replace sysvinit, although only handful that ever reached meaningful levels of adoption (Upstart, systemd, OpenRC; plus launchd if we look beyond Linux).

Vote

Ian <$ 8 hours ago

And IMO, systemd is a pretty decent init system, doing all the things the hodge-podge collection of sysvinit scripts did in a somewhat consistent way.

My issue with systemd is its viral tendancy to want to take over everything:

systemd-hostnamed systemd-journald systemd-logind systemd-networkd systemd-resolved systemd-timedated systemd-udevd ...

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required