Boron cleanup

johnraff · 2023-12-10 01:28:57

hhh wrote:

Dealing with another dual-monitor issue, I also spent a LOT of time working with the 'big cursor'.

Is that issue only with multi monitors? Any way to reproduce it on a single monitor?

What worked for me...
Adding 'Xcursor.size: 32' to the bottom of ~/.Xresources. This made the cursor normal on both desktops.

On my VM that made the cursor too big, so to add commented-out I guess, with a note "For HiDPI"?

Changing the ~/.config/gtk-3.0/settings.ini entry 'gtk-cursor-theme-size=48' to 'gtk-cursor-theme-size=32', or else the cursor becomes huge in Firefox, xfce4-terminal, etc...

There's no such line in our gtk-3.0/settings.ini. I'm not even sure if it's possible to usefully make that setting. Could you try just deleting that 'gtk-cursor-theme-size=48' line? How did it get there anyway?

Finally, lightdm-gtk-greeter had both a huge cursor AND the login window and the panel would switch from display to display depending where the cursor was. They would initially appear on the second display, my joined.sh layout doesn't get run until login.
The fix for that was to add the following lines to the bottom of he [greeter] section of/etc/lightdm/lightdm-gtk-greeter.conf...
active-monitor=0
cursor-theme-name=DMZ-White
cursor-theme-size=32
cursor-theme-size doesn't work without cursor-theme-name being defined as well.

But that cursor-theme size will be too big for some users (eg me). Can we usefully just add the 'active-monitor=0' line by default, and the cursor setting commented-out?

Last edited by johnraff (2023-12-10 01:29:51)

hhh · 2023-12-10 01:41:50

The big cursor appears (for me) only when a second monitor is attached via an HDMI port. I can't speak to any other setup. If the HDMI cable is attached after logging in I see a normal cursor all around. But that's not the usual setup for people, if they have a second screen attached they usually have it connnected all the time. When booting with that setup, the cursor is 48px and the back-and-forth login window happens, and then the cursor is messed up on the desktop as well.

Honestly, I think we should not do any configuration for dual monitors, as I said, but just be aware of the issues so we can offer support on the forum. Current GNOME with gdm3 handles dual monitors with no fuss, from what I've been experiencing over the last year, and people with dual monitors usually have enough RAM to rum GNOME or Plasma. If someone runs Openbox with multi-monitors, they should know there's some legwork involved.

Hey, I just had a thought... tomorrow I'll test if switching lightdm for gdm3 improves things. Again, just to be aware of possible workarounds, not to put in our ISOs.

rbh · 2023-12-10 10:24:57

johnraff wrote:

hhh wrote:
Changing the ~/.config/gtk-3.0/settings.ini entry 'gtk-cursor-theme-size=48' to 'gtk-cursor-theme-size=32', or else the cursor becomes huge
There's no such line in our gtk-3.0/settings.ini. I'm not even sure if it's possible to usefully make that setting. Could you try just deleting that 'gtk-cursor-theme-size=48' line? How did it get there anyway?

The repository contradicts you. From https://github.com/BunsenLabs/bunsen-co … ttings.ini:

gtk-cursor-theme-size=0

It is same in Beryllium.

When testing dists, it is good to use default settings.

rbh · 2023-12-10 10:28:09

hhh wrote:

But that's not the usual setup for people, if they have a second screen attached they usually have it connnected all the time.

I think it is just as common to have an laptop which often connects to external monitor.

hhh · 2023-12-10 14:21:13

rbh wrote:

The repository contradicts you. From https://github.com/BunsenLabs/bunsen-co … ttings.ini:
gtk-cursor-theme-size=0

Nice catch! I thought I was using default settings except for changing the themes to darkred, but maybe not. I'll check some things later today, but I'm more or less waiting for the next ISO to do a proper check on things with everything fresh.

If it's a laptop that connects to an external monitor at home and/or office, the user would still need a workaround if they make the connection before booting and/or they are at that location for an extended amount of time and logout/power off.

Last edited by hhh (2023-12-10 14:24:23)

johnraff · 2023-12-11 06:39:31

rbh wrote:

johnraff wrote:
hhh wrote:
Changing the ~/.config/gtk-3.0/settings.ini entry 'gtk-cursor-theme-size=48'...
There's no such line in our gtk-3.0/settings.ini. I'm not even sure if it's possible to usefully make that setting. Could you try just deleting that 'gtk-cursor-theme-size=48' line? How did it get there anyway?
The repository contradicts you. From https://github.com/BunsenLabs/bunsen-co … ttings.ini:
gtk-cursor-theme-size=0
It is same in Beryllium.

Yes it is! When I checked the file yesterday I completely missed that line, possibly because I was in a hurry and looking for "=48" not expecting "=0".

I remember when those entries were decided, some years ago, devs at the time considered which GTK settings would be sensible to use, and which were on the point of being deprecated upstream, so gtk-cursor-theme-size must have been one of those chosen. Then why set at "=0"? I completely forget but I'll try a forum search. If it was in the CrunchBang days, though, it will be gone. It would probably be worthwhile checking the GTK3 docs one more time to see if we are setting anything which is now meaningless.

Previous discussions about GTK settings , xsettings and xsettingsd:
https://forums.bunsenlabs.org/viewtopic.php?id=6786
https://github.com/BunsenLabs/bunsen-utilities/pull/71

GTK3 & GTK4 settings:
https://docs.gtk.org/gtk3/property.Sett … -size.html
https://docs.gtk.org/gtk4/property.Sett … -size.html

Anyway gtk-cursor-theme-size=0 is the default and is what BL should be setting (and is setting). Users can change it of course.

Last edited by johnraff (2023-12-11 07:54:03)

johnraff · 2023-12-11 06:42:38

hhh wrote:

I'm more or less waiting for the next ISO to do a proper check on things with everything fresh.

I'm pretty busy atm with all kinds of outside stuff, but I have been pushing this forward (last-minute package upgrades etc). Expecting to build RC1 maybe tomorrow.

hhh · 2023-12-12 04:28:44

^ All good. I didn't mean that I was impatient for it.

johnraff · 2023-12-12 04:55:17

I'm impatient for it!!

hhh · 2023-12-12 05:17:41

Lol. All good things to those who wait, I guess.

johnraff · 2023-12-12 09:49:14

All packages checked and up to date. The live-build package lists look OK.
Hoping to build RC1 amd64 tomorrow (not today as promised ).

hhh · 2023-12-12 14:50:42

It's ready when it's something something...

johnraff · 2023-12-13 05:37:20

Builder VM all set up, now waiting for click to start the RC1 build.

But we don't want to build with a broken kernel
https://forums.bunsenlabs.org/viewtopic … 03#p130803

So as soon as 6.1.67-1 comes in I'll hit Enter.

EDIT: 07:54 UTC the upgrade still hasn't arrived so build will have to wait one more day.
Sorry.

Last edited by johnraff (2023-12-13 07:55:36)

johnraff · 2023-12-14 01:33:27

On my Debian Bookworm iso builder VM, after running 'sudo apt update' of course:

john@bookworm-builder:~$ apt policy linux-image-amd64
linux-image-amd64:
  Installed: 6.1.38-4
  Candidate: 6.1.66-1
  Version table:
     6.1.66-1 500
        500 https://deb.debian.org/debian bookworm/main amd64 Packages
     6.1.52-1 500
        500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages
 *** 6.1.38-4 100
        100 /var/lib/dpkg/status

So still no go.

It's in proposed-updates, though, so should arrive before too long...

hhh · 2023-12-14 02:17:38

Wait, so the two bugs referenced are marked serious, and render systems unusable, but getting the patch into stable is only medium urgency? Since when does running Debian stable require sid levels of attention?

Maybe we should ship the backported kernel, the 6.1 series is getting stale at this point.

https://tracker.debian.org/news/1483809 … backports/

Last edited by hhh (2023-12-14 02:18:25)

johnraff · 2023-12-14 05:06:49

hhh wrote:

Wait, so the two bugs referenced are marked serious, and render systems unusable, but getting the patch into stable is only medium urgency?

Yeah I don't get that either. 6.1.67-1 still hasn't arrived.

Since when does running Debian stable require sid levels of attention?

Exactly. This is very un-Debian-like. And I wonder why they didn't wind the kernel back to the last stable version instead of leaving a buggy one on the server.

Maybe we should ship the backported kernel, the 6.1 series is getting stale at this point.
https://tracker.debian.org/news/1483809 … backports/

I feel your impatience, but:

1) Our claim is to base on Debian Stable. A backported kernel would change some things, maybe only subtly, but I think it should be a user choice. (Or else a policy change, announced in advance, preceded by an experimental phase when people can check it over.)

2) Practical level: reconfiguring live-build to use the backported kernel is something I've never done, so even if it worked right off, would still need testing. I'm pretty sure that would push the RC1 release back longer than just waiting for the stable kernel to show up.
6.1.66 was accepted into proposed-updates 12/10 and arrived here the next day 12/11.
6.1.67 was accepted 12/13 so ought to arrive soon...
https://tracker.debian.org/pkg/linux-signed-amd64

Last edited by johnraff (2023-12-14 05:10:01)

hhh · 2023-12-14 06:39:51

^ Right, let's just wait it out. Ugh.

johnraff · 2023-12-14 06:53:33

I was sure it would come in today, but no luck so far.

johnraff · 2023-12-15 03:33:51

OK so regular users can just add proposed-updates to their apt sources and get the 6.1.67-1 with the upgrade:
https://forums.bunsenlabs.org/viewtopic … 26#p130826

I'm now going to look into how to do a live-build with that kernel in the system, preferably without adding the extra apt line to the installed sources.list...

johnraff · 2023-12-15 08:17:56

EDIT adding proposed-updates is now unnecessary because the fixed kernel is now in stable-updates.

Found how to add proposed-updates to the build: just add a file config/archives/proposed-updates.list.chroot with the apt line:

deb https://deb.debian.org/debian bookworm-proposed-updates main contrib non-free non-free-firmware

That repo will be checked for packages along with regular bookworm, but there's not much in there atm except that 6.1.67-1 kernel, which gets installed to the system. The repo is not added to the installed sources.list, which seems right.

Did an RC1 build and found a couple of configs I'd forgotten so it will need another build now that the updated bunsen-configs has been uploaded. But, more than that, if you enable bookworm-backports after install then the backports kernel gets higher apt priority and apt will ask you to upgrade to it... That's because 6.1.67-1 doesn't have a "home" repo. If you add bookworm-proposed-updates to apt sources then its apt priority goes to 500 and it's OK.

In live-build that should be a renaming of the file from proposed-updates.list.chroot to proposed-updates.list
The build I'm just about to do will test that (and add the missing theme configs).

So the price of shipping a kernel version that's higher than the stable repo but without configuring proposed-upgrades is that it's priority is only 100 and it gets outbidded by the backports kernel. We need to keep bookworm-proposed-updates configured in our released Boron, unless the stable kernel upgrade has come in by official release time when it can come out.

Not a huge issue but feels a bit messy to have to ask our users to comment out that line later one.

Anyway, I'll start a new build of RC1 now, and upload it to sourceforge tomorrow for you to check out.

Last edited by johnraff (2023-12-16 07:46:32)

#21 2023-12-10 01:28:57

Re: Boron cleanup

#22 2023-12-10 01:41:50

Re: Boron cleanup

#23 2023-12-10 10:24:57

Re: Boron cleanup

#24 2023-12-10 10:28:09

Re: Boron cleanup

#25 2023-12-10 14:21:13

Re: Boron cleanup

#26 2023-12-11 06:39:31

Re: Boron cleanup

#27 2023-12-11 06:42:38

Re: Boron cleanup

#28 2023-12-12 04:28:44

Re: Boron cleanup

#29 2023-12-12 04:55:17

Re: Boron cleanup

#30 2023-12-12 05:17:41

Re: Boron cleanup

#31 2023-12-12 09:49:14

Re: Boron cleanup

#32 2023-12-12 14:50:42

Re: Boron cleanup

#33 2023-12-13 05:37:20

Re: Boron cleanup

#34 2023-12-14 01:33:27

Re: Boron cleanup

#35 2023-12-14 02:17:38

Re: Boron cleanup

#36 2023-12-14 05:06:49

Re: Boron cleanup

#37 2023-12-14 06:39:51

Re: Boron cleanup

#38 2023-12-14 06:53:33

Re: Boron cleanup

#39 2023-12-15 03:33:51

Re: Boron cleanup

#40 2023-12-15 08:17:56

Re: Boron cleanup

Board footer