You are not logged in.
^ Maybe there is hope after all.
The same thing happened to me (HP) a few years ago.
1) Disconnect all external devices connected to the computer.
2) Disconnect the power from from the computer by first unplugging the power cord from the AC outlet and then unplugging the AC adapter from the computer.
3) Remove the battery and then press the power button and hold it for 60s.
This way static electricity is removed.
Now put the battery back in and turn on the computer.
If it works, restore everything else.
If it doesn't work, remove the battery again and then press the power button and hold it for 60s.
Now put back the AC adapter and try to turn on the computer without the battery.
This will help you find the culprit for the static electricity.
Good luck!
If people would know how little brain is ruling the world, they would die of fear.
Offline
I do really need to test with 4 at some point because there are corner cases I haven't covered yet, like setting up monitors in a 2 x 2 config instead of 4 in a row.
I have an old LG monitor downstairs and my video card has a space for it BUT my desk doesn't have the space.
Nice setup.
Debian 12 Beardog, SoxDog and still a Conky 1.9er
Offline
I have added more directories to xwwall and briefly see the warning with the 300 images.
The selection of a wallpaper only works for the current session. The image is not saved.
At the moment I help myself with an entry in the autostart file of labwc, which causes the selection procedure again.
xwwall >/dev/null 2>&1 &
Do you have any advice?
Edit: Thanks to @bronto
Offline
@unklar it's in tha manual
Startup
You can start the program to restore your background choices from your
autostart or similar file with the following:xwwall --restore
Consult your window manager or compositor documentation for the correct
procedure.Advanced Startup
xwwall supports profiles such that you can have separate profile direc‐
tories under the $HOME/.config/xwwall/ directory. This is useful if you
have different graphical environments setup so that you can have differ‐
ent wallpapers in different sessions. For example, you may have labwc
and openbox on your system. You can create separate profiles for each of
these, and as many as you want, named whatever you want. $HOME/.con‐
fig/xwwall/labwc/ profile directory for labwc and $HOME/.con‐
fig/xwwall/openbox/ profile directory for openbox.Since labwc is a wayland compositor then to make the profile useful you
copy the $HOME/.config/xwwall/cmd file to $HOME/.config/xwwall/labwc/cmdAnd since openbox is an X11 window manager the approach is slightly dif‐
ferent. You need to copy the $HOME/.fehbg executable file to $HOME/.con‐
fig/xwwall/openbox/.fehbg, making sure to preserve the executable per‐
missions on the copied file.Similar procedures can be followed for respective wayland compositors
and X11 window managers.Once you have created your profile it then needs to be included in your
startup routine. You can simply append the name of the profile directory
to the --restore option in your startup routine like so:xwwall --restore openbox
or whatever desired profile directory name you have used.
HTH
#!/bin/sh
echo '#include <stdio.h>\nvoid main() { printf("Hi, bunsenlabs\\n"); return; }' > bunsen.c
gcc bunsen.c -o bunsen
./bunsen
Offline
BINGO!
Thank you very much, @micko01.
I hadn't thought of man xwwall...
Many thanks for your work!
Last edited by unklar (2025-04-25 14:51:41)
Offline
I found a bug with multi-head setup. I used a usb-c to vga adapter to connect the 3rd monitor and it is recognised as DP-1
. The laptop monitor is eDP-1
and the other connected by HDMI is HDMI-A-1
. My condition is too strict to pick up DP-1 so I relaxed it. I do need to come up with a better test I think but for now this will do. I'm not updating the program yet, maybe on the weekend when I can connect 4 outputs.
The last scrot was on X11. This on wayland/labwc
#!/bin/sh
echo '#include <stdio.h>\nvoid main() { printf("Hi, bunsenlabs\\n"); return; }' > bunsen.c
gcc bunsen.c -o bunsen
./bunsen
Offline
I think xwwall is in good shape. I scored another hdmi monitor for AUD $87 brand new, including cable. It was a return so I got a discount. Works fine, just the carton was a bit damaged. So I tested on wayland with 3 external monitors hooked up to my laptop.
I'll bring out a new version soon with a small bugfix.
#!/bin/sh
echo '#include <stdio.h>\nvoid main() { printf("Hi, bunsenlabs\\n"); return; }' > bunsen.c
gcc bunsen.c -o bunsen
./bunsen
Offline
4 monitor setup that's pretty sweet!
Real Men Use Linux
Offline
I didn't know if it would work with my laptop but it was quite simple.
You can either use trial and error to get the monitors configured the way you want or use a software tool to move them around, such as arandr for X11 or wdisplays for wayland. wdisplays
is great as you can drag'n'drop the monitors where you want! However it doesn't save the config. There is a wayland tool caled "kanshi" for that, but you have to code the config yourself which would be more trial and error.
#!/bin/sh
echo '#include <stdio.h>\nvoid main() { printf("Hi, bunsenlabs\\n"); return; }' > bunsen.c
gcc bunsen.c -o bunsen
./bunsen
Offline
@micko01 I was just about to start a new topic on how to "find a test whether an app is running on a wayland compositor" but I had another idea which might possibly do it.
tl:dr
## near top of script if wlr-randr >/dev/null 2>&1 then local_session_type=wayland else local_session_type=xorg fi export local_session_type # now refer to $local_session_type later in script
Maybe I should start a new topic for this?
wlr-randr is already a dependency of xwwall and runs very quickly. Anyway, the test only needs doing once.
I was trying to think of some minimal app which would try to actually make a connection to the Wayland compositor and then exit, wondering how hard it would be to write one in C, then realized that wlr-randr was already around.A thought.
Revisited this yesterday in the context of bl-exit --lock, another place where a script needs to know if it's on Wayland or Xorg.
Discovered two things:
1) On a VT just running a tty, ie no graphical session at all, if there is a Wayland session open on a different VT then wlr-randr runs successfully. So if you just need to know if Wayland is running somewhere it's OK, but not if you want to know about the specific environment a script is running in. I haven't checked what happens if the Wayland session belongs to a different user from the tty, or if there are both Xorg and Wayland sessions running.
2) On Wayland, if xwayland is available - as it usually is - then $DISPLAY is non-zero. So testing for Xorg or Wayland, you have to check for $WAYLAND_DISPLAY first, then if it's not set you can check $DISPLAY.
Maybe I should indeed start a new topic for this?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Maybe I should indeed start a new topic for this?
Yes maybe because that test will need to be used in any number of situations.
It would be good to "standardise" a test to use anywhere, maybe even set something in our own environment?
#!/bin/sh
echo '#include <stdio.h>\nvoid main() { printf("Hi, bunsenlabs\\n"); return; }' > bunsen.c
gcc bunsen.c -o bunsen
./bunsen
Offline
It would be good to "standardise" a test to use anywhere, maybe even set something in our own environment?
Agreed. At least something in bunsen-common's bl-includes file.
Also, Micko, when you have a moment could you run your eye over the last few posts in the bl-exit/locking thread? I have a few changes to suggest. From here: https://forums.bunsenlabs.org/viewtopic … 14#p145014
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline