Puppy Linux Discussion Forum

Hi,

I installed BookwormPup64 10.0.6 yesterday on a USB. I'm using an Acer Swift 1 laptop that has 4G of ram.

I use an external monitor via HDMI and want to have the laptop lid closed when using my machine. Is there any way within Bookworm Puppy to achieve this? If not, is there another Puppy distro that I can achieve this with?

Cheers.

I don't use BookwormPup64 ..but it might be similar to other puppies. I use Fossapup64 and on this system - and all the previous puppies I've used - there has been a file called 00000080 in the directory /etc/acpi/LID

On previous puppies it has been this file which controls what happens when the LID is closed. If that file exists on your Bookworm system, then you should be able to rename it to something else and see if that works for you.
In my case, I simply repoint it to one of my own scripts which does exactly what I want it to do.

If it doesn't work for you for some reason, then just rename it back to it's original name - and your system will remain unchanged.

Brilliant!

Thanks so much. I renamed the file to something random and could close my lid immediately.

mow9902 wrote: ↑Fri Apr 26, 2024 12:26 am

I don't use BookwormPup64 ..but it might be similar to other puppies. I use Fossapup64 and on this system - and all the previous puppies I've used - there has been a file called 00000080 in the directory /etc/acpi/LID

On previous puppies it has been this file which controls what happens when the LID is closed. If that file exists on your Bookworm system, then you should be able to rename it to something else

That's an awful hack, but who cares if it works
It shouldn't be necessary in the first place because 00000080 (symlinked to /etc/acpi/actions/suspend.sh) is designed not to suspend as long as an USB device is mounted:

# do not suspend if usb media mounted
if [ "$DISTRO_TARGETARCH" = "x86" ]; then
	USBS=$(probedisk2|grep '|usb' | cut -d'|' -f1 )
	for USB in $USBS
	do
		mount | grep -q "^$USB" && rm -f "$LOCKFILE" && exit 0
	done
fi

However in 64bit Puppies like @radky 's BW64 or @rockedge 's F96-CE this code fails.
The condition [ "$DISTRO_TARGETARCH" = "x86" ] is never true because in those distros the value of DISTRO_TARGETARCH is "x86_64"
In order to make the condition suitable for 32 and 64bit Puppies it would have to be changed to something like [[ $DISTRO_TARGETARCH = x86* ]]

Frankly I don't know why the exemption in case of USB mounts exists at all. IMHO it would be better to prevent suspend on lid closing when an external moniitor is attached and running. On the other hand suspend makes sense when no monitor is attached. Should be easy to implement.

..sure, I realize this is a bit 'crude' - but what I have also done is create a very small script called pcsleep.sh containing (amongst other things I want to do) these lines:
# sleep the pc
echo mem > /sys/power/state

I then just attached that to a desktop file called PCSleep.desktop and created a symlink to it in /usr/share/applications.
This means I have a menu entry which I can execute to 'manually' sleep the laptop whenever I want.

However in 64bit Puppies like @radky 's BW64 or @rockedge 's F96-CE this code fails.
The condition [ "$DISTRO_TARGETARCH" = "x86" ] is never true because in those distros the value of DISTRO_TARGETARCH is "x86_64"

I was not aware that it does not work in F96-CE_4. I didn't have a computer that has a lid to close at the time the distro was being developed.

I like the idea of this line -> [[ $DISTRO_TARGETARCH = x86* ]] or in this form:

# do not suspend if usb media mounted
if [ "$DISTRO_TARGETARCH" = "x86" ] || [ "$DISTRO_TARGETARCH" = "x86_64" ] ; then
	USBS=$(probedisk2|grep '|usb' | cut -d'|' -f1 )
	for USB in $USBS
	do
		mount | grep -q "^$USB" && rm -f "$LOCKFILE" && exit 0
	done
fi

Though further down in the program starting around line 43:

# process before suspend
# sync for non-usb drives
sync
[ "$DISTRO_TARGETARCH" = "x86" ] && rmmod ehci_hcd

@MochiMoppel Would this change also be a valid fix?

# process before suspend
# sync for non-usb drives
sync
[ "$DISTRO_TARGETARCH" = "x86*" ] && rmmod ehci_hcd

Here is a chance to make some changes for an updated F96-CE_5

This script is super old, and I think it tries to work around problems with flash drives that disconnect and lose data on suspend, something I haven't seen for many years.

Until https://github.com/puppylinux-woof-CE/woof-CE/pull/2984, it didn't suspend if a flash drive is attached, which meant Puppy that boots from a flash drive with persistency doesn't suspend on lid close (!!!). Laptops are more common now compared to the time this script was written (and battery life matters), but for some reason nobody complained for over a decade. When I disabled this silly condition in 2022, I did so only for 64-bit because those who build or use 32-bit Puppy releases tend to be more conservative, and nobody asked me to remove this condition altogether.

@dimkr Thanks for the info! Makes better sense now

rockedge wrote: ↑Fri Apr 26, 2024 11:16 am

I was not aware that it does not work in F96-CE_4. I didn't have a computer that has a lid to close at the time the distro was being developed.

My current PC doesn't have a lid either and on netbooks I usually have an external monitor attached where I keep the lid open to improve cooling. I never expected the netbook to suspend on lid close and I wouldn't have liked it. I prefer to suspend with a keyboard shortcut.

@MochiMoppel Would this change also be a valid fix?

Code: Select all

# process before suspend
# sync for non-usb drives
sync
[ "$DISTRO_TARGETARCH" = "x86*" ] && rmmod ehci_hcd

This would be an unfix of @dimkr's fix and it wouldn't be valid code either. When using wildcards like '*' you can't use single brackets. They work in double brackets, where in this case you don't need quotation marks, but if you use them, the wildcard must not be included.

@dimkr It would be a great help if you would leave a small comment in the code when you make such changes. Could have spared me a lot of head scratching. Even better would have been to communicate the problem in the forum because - as you can see - more than one user want the laptop not to suspend when the lid is closed. I'm sure that with a bit of brain storming there could have been found a solution that pleases both factions.

The original idea of not letting it suspend if a USB drive is plugged in and running Puppy from it, with the save on the USB.

If the save is setup to write to it every few minutes automatically (option in pupmode13).

Good chance the save could get corrupted or data lost.

What if it goes into suspend during this writing process.

There was a time when ext2 format was used a lot on USB drives.
That format is easy to corrupt.

Puppies overall processes, may be better coded to deal with this, than they were in the past.
Not sure about that?

The idea was more let's not take a chance and just not let it suspend.

@MochiMoppel I agree, I think that suspending on lid close unless connected to an external monitor is the most intuitive default behavior.

Somebody will need to contribute this change to woof-CE.

https://github.com/puppylinux-woof-CE/woof-CE/pull/4278

I hope the logic is correct, this will need some testing

dimkr wrote: ↑Sat Apr 27, 2024 10:01 am

https://github.com/puppylinux-woof-CE/woof-CE/pull/4278

I hope the logic is correct, this will need some testing

Maybe something like this, before or after the initial case "$DISABLE_SUSPEND" ... esac command:

# Do not suspend if external monitor connected 
[ $(xrandr -q | grep -c ' connected') -gt 1 ] && exit

This should also work:

[ $(grep -l ^connected /sys/class/drm/*/status | wc -l ) -gt 1 ] && exit

Since the internal laptop monitor is always connected, more than 2 monitors indicate at least one external monitor

Ensure that xrandr disables monitors with --off

It turns off (blanks) the monitor and in xandr output the asterisk marker disappears but the status remains "enabled". Strangely this status doesn't even change when the external monitor is powered off. I found no reliable way to test if an external monitor is actually running or not, and maybe it isn't even important. Rule could be: If a monitor is connected to laptop via cable, closing lid doesn't trigger suspend.

Verify that eDP-1 is a good assumption on various old laptops

Not a good assumption. Never seen it because none of my laptops supports Display Port. I read that it could also be eDP1, just as my laptop monitors are either LVDS-1 or LVDS1. What are you trying to do? Turn off the internal monitor? If so, why?

MochiMoppel wrote: ↑Sat Apr 27, 2024 2:13 pm

This should also work:

Code: Select all

[ $(grep -l ^connected /sys/class/drm/*/status | wc -l ) -gt 1 ] && exit

Since the internal laptop monitor is always connected, more than 2 monitors indicate at least one external monitor

The question is not connected or not but enabled or not. Not every connected monitor is enabled. If the laptop is connected to an external monitor that's disabled, you don't want to disable the internal monitor when the lid is closed because this means all monitors are disabled.

MochiMoppel wrote: ↑Sat Apr 27, 2024 2:13 pm

Rule could be: If a monitor is connected to laptop via cable, closing lid doesn't trigger suspend.

How do you detect that? In my work laptop I use a monitor attached to a USB-C dock.

What are you trying to do? Turn off the internal monitor? If so, why?

Turn off the internal monitor on lid close, otherwise it's still enabled. It eats power and you can still put windows there (the open windows you had before connecting the external monitor are hidden there) or move the cursor there although you can't see it. (Normally, xlock takes care of disabling the internal display when the system is suspended, using DPMS.)

dimkr wrote: ↑Sat Apr 27, 2024 4:04 pm

The question is not connected or not but enabled or not.

I made it the question.because it seems to me that this is the only question that a user and the code can reliably answer. "Enabled" is very ambiguous. One example, tested on a netbook (HP Mini 210) and a notebook (Acer Aspire ONE 722). The laptop is turn off. My external monitor is connected through its VGA port, it is also switched off and its power cord is unplugged, dead as a brick. After booting up the computer with such (unpowered) monitor attached, is the monitor "enabled"? From a user point of view certainly not, still looks dead, but the system shows "enabled":

# grep . /sys/class/drm/*/enabled
/sys/class/drm/card0-LVDS-1/enabled:enabled
/sys/class/drm/card0-VGA-1/enabled:enabled

What is enabled is the VGA port (not the monitor itself), regardless if the connected monitor is dead or alive. At least that's how I understand it.

Not every connected monitor is enabled.

As far as I can test, after booting it is - again only in the sense that the port is enabled. And every connected monitor (port) stays enabled even when later switching off the monitor. The only way I know to "disable" a connected monitor is by using a xrandr command, but I doubt that this is the way a normal and sane user would switch off his monitor.

If the laptop is connected to an external monitor that's disabled, you don't want to disable the internal monitor when the lid is closed because this means all monitors are disabled.

True, in this case I don't want to disable the internal monitor, so I don't. Why would I?

MochiMoppel wrote: ↑Sat Apr 27, 2024 2:13 pm

Rule could be: If a monitor is connected to laptop via cable, closing lid doesn't trigger suspend.

How do you detect that? In my work laptop I use a monitor attached to a USB-C dock.

I can detect that via eyeballs or the code I posted

What are you trying to do? Turn off the internal monitor? If so, why?

Turn off the internal monitor on lid close, otherwise it's still enabled. It eats power and you can still put windows there

I don't understand this. We are talking about sending the computer to sleep. What is the benefit of running something like xrandr --output <display> --off before this exercise when the internal monitor is turned off anyway by the following echo mem > /sys/power/state command . AFAIK in suspended state the computer runs on very little power, just to keep RAM alive. How can the monitor "eat power" in this state when even the USB ports are powered down?

@MochiMoppel Please test /etc/acpi.map and /etc/acpi/actions/suspend.sh from the PR and report back if you have any issues.

For open issues/questions see my previous post.

@MochiMoppel The current code should address your concerns

Vanilla Dpup 9.3.40 and 10.0.52 include https://github.com/puppylinux-woof-CE/woof-CE/pull/4278, to gather feedback. It works fine for me.

dimkr wrote: ↑Sun Apr 28, 2024 12:27 pm

@MochiMoppel The current code should address your concerns

I tried my best to answer all your questions. In return it would have been nice to have my own questions answered here in the forum. This is what the forum is for.

One of my questions was

What is the benefit of running something like xrandr --output <display> --off before this exercise when the internal monitor is turned off anyway by the following echo mem > /sys/power/state command

As far as I can see your new code makes great efforts to "guess" the display name and turn the internal display off (= disable it) when the lid is closed and consequently tries to enable it when the lid is opened after suspend. Again: Why? Not only is it unnecessary when sending the laptop into suspend (lids closed or not), it is also unnecessary because in all laptops I know the internal display shuts down when the lid it closed. I assume that this is built into the HW because this works even when the laptop displays the BIOS setup, i.e. it works without running an OS. Are there any lapfops out there that keep the display on when the lid is closed ?

@MochiMoppel At least on my displays, they don't turn off on lid close (unless the system is suspended). This is handled in software, something needs to disable the display (so X moves windows away from it) and turn it off (so no backlight, heat and power drain) while the system keeps running. You can remove the xrandr line to see if it makes any difference on your laptop. I think you misread the code and ask the wrong questions, because it doesn't turn off the display if the system is suspended.

I've been following this discussion though I don't use external displays and my Fujitsu S761 and S762 laptops all do turn off the display on lid close. Gently, gently, I ask. Since laptop suspend, both machine to machine / kernel to kernel / and user to user needs vary so widely, why not extend and make fuller use of /etc/acpi/acpi.conf to allow for and handle special cases like those discussed here. Might it be simpler than trying to cover all bases automatically?

Just thoughts,

Marv wrote: ↑Mon May 06, 2024 1:49 pm

I've been following this discussion though I don't use external displays and my Fujitsu S761 and S762 laptops all do turn off the display on lid close.

We all agree that the display turns off automatically when the system is suspended.

But the new code has nothing to do with suspend - it turns off and disables the internal display on lid close (and disables suspend), if the laptop is connected to an external monitor. It's the suspend, not the lid close that turns off the display when the system is suspended.

dimkr wrote: ↑Mon May 06, 2024 1:58 pm

t turns off and disables the internal display on lid close

Third attempt: @Marv 's Fujitsus (and my Fujitsu, Acer, HP and Lenovo) all turn off the internal display without the need for any software. I read that this is done via magnets in the display frame. Or are you saying that this mechanism does not work when an external monitor is connected?

Just confirming. My laptops (see my post above) and previous Fujitsus have all turned off the backlight when suspend is disabled. Just works, even sitting in the BIOS setup on them. The backlight is the main power draw there and on these when I played with that and various suspend modes it was almost as good as suspend. Don't have the power draw numbers any more, sorry.

Any thoughts on using acpi.conf to extend flexibility in suspend??

MochiMoppel wrote: ↑Mon May 06, 2024 2:22 pm

dimkr wrote: ↑Mon May 06, 2024 1:58 pm

t turns off and disables the internal display on lid close

Third attempt: @Marv 's Fujitsus (and my Fujitsu, Acer, HP and Lenovo) all turn off the internal display without the need for any software. I read that this is done via magnets in the display frame. Or are you saying that this mechanism does not work when an external monitor is connected?

X thinks the monitor is still turned on, in my case.

dimkr wrote: ↑Mon May 06, 2024 2:31 pm

X thinks the monitor is still turned on, in my case.

Question was if the display visibly turns off or not. Does it?
X will tell you that the display is still "connected" and "enabled", and that's not a contradiction. Where did you find what X "thinks"? Don't know if there is a file that lets you check the status of the backlight. But why would this be important anyway?

MochiMoppel wrote: ↑Mon May 06, 2024 2:58 pm

dimkr wrote: ↑Mon May 06, 2024 2:31 pm

X thinks the monitor is still turned on, in my case.

Question was if the display visibly turns off or not. Does it?
Where did you find what X "thinks"?

The panel and some windows are still on the laptop monitor, which is turned off, and the window manager still allows me to move windows to the the internal monitor. I need to disable the monitor, X-wise, for X to know it's off.

---

Same thing with dwl and labwc (= Wayland, not X), btw -

If I kill acpid and close the lid, I can see the backlight around the edges (laptop is warmer, battery life is reduced).

wlr-randr still thinks the monitor is connected+enabled:

eDP-1 "LG Display 0x0450 (eDP-1)"
[...]
  Enabled: yes

If I try to move a window to the internal display, it allows me to do this although I can't see it.

Once I restart acpid and close the lid (with the fixes in the PR applied in acpi.map and suspend.sh), I see that
1) The display is disabled - I can't move a window from display 2 to display 1
2) The panel moves to display 2
3) Backlight is off
4) wlr-randr says the internal display is disabled

eDP-1 "LG Display 0x0450 (eDP-1)"
[...]
  Enabled: no

dimkr wrote: ↑Mon May 06, 2024 3:30 pm

If I kill acpid and close the lid, I can see the backlight around the edges (laptop is warmer, battery life is reduced).

I can't confirm this with any of my laptops, but if your machine behaves this way then you have a point ... and maybe a broken laptop?

If I try to move a window to the internal display, it allows me to do this although I can't see it.

Normally when you have such a monitor configuration where a virtual desktop extends over 2 monitors and you can move windows between monitors, it is a deliberate choice of the user and it would make no sense to close the lid because it would defeat the purpose. However what you describe reminds me of my Acer. While my Netbooks by default would show a copy of the laptop desktop (=mirror the same desktop on 2 monitors), the Acer defaults to a desktop spanning over 2 monitors. I have to correct this via script by disabling the internal monitor and setting the external monitor to the correct resolution.

Once I restart acpid and close the lid (with the fixes in the PR applied in acpi.map and suspend.sh), I see that
1) The display is disabled - I can't move a window from display 2 to display 1

Because the fix works for you. Doesn't mean that the fix always works. Doesn't work for me:

xrandr --output eDP-1 --off || xrandr --output eDP1 --off || xrandr --output LVDS-1 --off || xrandr --output LVDS1 --off

My monitor is named LVDS, and on a Japanese site I even came across a name LVDS-1-0. Your code would work for none of them .There are several ways to retrieve the exact name of the monitor and avoid guessing.

2) The panel moves to display 2
3) Backlight is off

As expected

4) wlr-randr says the internal display is disabled

xrandr should say the same, but which option? I didn't find an option or list that would tell me if a monitor is enabled or disabled. xrandr tells me only if it is connected or not.

Another issue I noticed has nothing to do directly with your code. I noticed that on my Netbook the command xrandr --output LVDS --off would reliably disable the monitor, but the opposite command xrandr --output LVDS --auto , also used in your code, would not turn the display on again, at least not reliably. Sometimes it works, sometimes it doesn't. Also other commands to explicitly set the mode would not work. Dropping out of X and running xwin again works, but that's not a solution. Funny thing is that when checking /sys/class/drm the enabled file tells me that it is enabled, so the -auto option worked but the display remains off. By chance I now discovered that I can get the backlight back when engaging the screensaver and move the mouse to turn the screensaver off. Very strange. All I can say is that getting the display back when opening the lid might not work as expected.

MochiMoppel wrote: ↑Thu May 09, 2024 4:22 am

it is a deliberate choice of the user

I don't see any reason why someone would want X to think that the internal display is still enabled (and keep the JWM tray and open windows there) after the lid is closed.

MochiMoppel wrote: ↑Thu May 09, 2024 4:22 am

xrandr should say the same, but which option?

I don't remember, but without the xrandr call I added in suspend.sh, which tells X that the internal display is disabled (equivalent to wlr-randr --off), open windows and the JWM tray stay on the internal display (which I can't see) instead of moving to the external monitor.