back in business, and troubles

matmutant · 2026-09-21 20:15:33

Hi everyone, hope everything's good on your sides!
There's a loooooong time i didn't post out there: last i had a device running Bunsenlabs was my old ASUS 1011PX.

I am writing from Panasonic FZ-M1 with an iKey keyboard, but I can't say it went that smooth as for the install:

Standard install failed because I couldn't load the proper wifi firmware: installer was complaining that iwlwifi-8265-22 to 36 were missing but i couldn't find any but 34 and 36 and it couldn't seem to get grabbed from the drive i've put them on.

As wifi was working out of the box on the live USB, I did not gave up there and tried the netinstall method from a barebone Debian as documented, for which wget got a 404 for some reason

wget https://github.com/bunsenlabs/bunsen-netinstall/archive/carbon.tar.gz

Strangely enough i could get it from another device, put it on a drive, mounted and cp it to ~/
Install went smoothly from there.

Next steps for me are :
1/ Find a way to enhance tablet mode (enabling on screen kb, finding a way to trigger right click by touch)
2/ increase scaling a little
3/ checking if everything works properly (BT, camera, etc)

Sector11 · 2026-09-22 12:42:28

Welcome back. Good luck.

matmutant · 2026-09-22 18:47:47

Thank you,

A little update on the topic :
- Bluetooth, mobile broadband are working flawlessly.
- Got gestures/scrolling with

export MOZ_USE_XINPUT2=1

in .Xsessionrc and touchegg
- Increased DPI a little with

Xft.dpi=120

in ~/.Xresources

sooooo, seems this little 7" tablet is liking Bunsenlabs a lot!

matmutant · 2026-10-01 12:27:04

So, to use my FZ-M1 as the tablet it was designed to be, I'd like to be able to access the virtual KB whenever I need it AND when loggin in.
I set up onboard as defaut kb instead of xvkbd I previously used but that should have any impact on the matter.
So I can access the KB whenever I need it (not only relying on Onboard "intelligent" behavior), I used the "A" programmable button (wasn't that straight forward as Panasonic programmable buttons are not exposed to the kernel directly, see my attempt at modifying tbtn driver)

By enabling accessibility in LightDM GTK Greeter, I can get to the KB when booting the machine and getting into the login screen, so far so good.

As I can't get it to come up when locking the screen, I tried to change the lock screen by default GTK greeter instead of xfce screensaver that doesn't seem to accept the display of the kb properly.

what I did :

mkdir -p ~/.config/bunsen-exit

copying the conf file to my home :

cp /etc/bunsen-exit/bl-exit.conf ~/.config/bunsen-exit/

modifying the lock screen command to :

#XORG_LOCK_SCREEN_COMMAND=(xfce4-screensaver-command --lock)
XORG_LOCK_SCREEN_COMMAND=(dm-tool lock)

But .... when I lauch bl-exit --lock or bl-lock, that is still xfce screensaver that comes up

Any clues?

Thanks !

Last edited by matmutant (2026-10-01 12:30:33)

johnraff · 2026-10-02 01:38:51

^Try 'bash -x bl-exit --lock' in a terminal and see if you can pin down where the lock command is chosen.

But, before even that, you may need to have a look at dm-tool itself. I just tried it on my Carbon system:

john@carbon:~$ dm-tool lock
Unable to lock seat: GDBus.Error:org.freedesktop.DBus.Error.Failed: Failed to lock seat

And anyway, dm-tool is not a reliable way of locking the screen:
https://bugs.launchpad.net/ubuntu/+sour … ug/1806961
Even so, I'm not sure where that DBus error is coming from. In the past, 'dm-tool lock' at least pretended to lock the screen.

Maybe look for an alternative screen-locker (there are several around), or try to figure out why xfce4-screensaver isn't displaying the keyboard...

EDIT: previous discussion about locking: https://forums.bunsenlabs.org/viewtopic.php?id=9515

Last edited by johnraff (2026-10-02 01:41:28)

matmutant · 2026-10-02 06:16:26

Calling `dm-tool lock` from terminal on my system does show the "lock" screen, without complaining in the console.
good point about it is the accessibility menu is available from there...

From

bash -x bl-exit --lock

the conf file seems to be read properly:

+ continue
+ read -r line
+ [[ -n XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) ]]
+ [[ XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) =~ ^[[:blank:]]*# ]]
+ [[ XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) =~ ^[[:blank:]]*\[[[:blank:]]*([[:alpha:]_][[:alnum:]_]*)[[:blank:]]*\][[:blank:]]*(#.*)?$ ]]
+ [[ XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) =~ ^[[:blank:]]*([[:alpha:]_][[:alnum:]_-]*)[[:blank:]]*=[[:blank:]]*('[^']+'|"[^"]+"|[^#[:blank:]]+)[[:blank:]]*(#.*)*$ ]]

but later:

+ get_session_type
+ case $BUNSEN_SESSION_TYPE in
+ session_type=x11
+ return 0
+ case $session_type in
+ LOCK_SCREEN_COMMAND=("${XORG_LOCK_SCREEN_COMMAND[@]}")
+ [[ -n '' ]]
+ command -v xfce4-screensaver-command
++ mktemp
+ tmplockcmd=/tmp/tmp.jFhhlhCS11
+ declare -p LOCK_SCREEN_COMMAND
+ export tmplockcmd
+ case "$1" in
+ on_graphical_session
+ case $session_type in
+ return 0
+ logoutctl lock-session
+ [[ -n '' ]]
+ case $1 in
+ . /tmp/tmp.jFhhlhCS11
++ LOCK_SCREEN_COMMAND=(['0']='xfce4-screensaver-command' ['1']='--lock')
++ declare -a LOCK_SCREEN_COMMAND
+ echo -e '\nlock-session'

 $ cat /tmp/tmp.jFhhlhCS11                                                                                           
declare -a LOCK_SCREEN_COMMAND=([0]="xfce4-screensaver-command" [1]="--lock")

==> detecting a X11 session seems to trigger the xfce4-screensaver, or that temp file messes things up ?

Anyway, i get your concerns,so back to the drawing board: I'll try to understand why I can't get the KB to show on xfce4-screensaver or another one!

Thank you

[Don't take my troubles as complains, there's a while i didn't dig properly into a Linux system, looks like i'm a bit rusted]

johnraff · 2026-10-02 09:45:39

Many thanks for looking at this.
I've just reproduced the issue on my own computer. The fail point is just after those XORG_LOCK_SCREEN_COMMAND= lines:

+ read -r line
+ [[ -n XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) ]]
+ [[ XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) =~ ^[[:blank:]]*# ]]
+ [[ XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) =~ ^[[:blank:]]*\[[[:blank:]]*([[:alpha:]_][[:alnum:]_]*)[[:blank:]]*\][[:blank:]]*(#.*)?$ ]]
+ [[ XORG_LOCK_SCREEN_COMMAND=(dm-tool lock) =~ ^[[:blank:]]*([[:alpha:]_][[:alnum:]_-]*)[[:blank:]]*=[[:blank:]]*('[^']+'|"[^"]+"|[^#[:blank:]]+)[[:blank:]]*(#.*)*$ ]]
+ continue

What happened is that '(dm-tool lock)' including the brackets, failed that last regular expression test:

entry_regex="^[[:blank:]]*([[:alpha:]_][[:alnum:]_-]*)[[:blank:]]*=[[:blank:]]*('[^']+'|\"[^\"]+\"|[^#[:blank:]]+)[[:blank:]]*(#.*)*$"

and the script just passed on, leaving XORG_LOCK_SCREEN_COMMAND unchanged, at the default (array) (xfce4-screensaver-command --lock).

That's the first issue, and I need to look closely at that regex and see why it is rejecting '(dm-tool lock)'.

But there's more.
There's another serious bug with how bl-exit.conf is being parsed.
Those config lines - if uncommented - are being added to a settings associative array, ie in this case:

settings[XORG_LOCK_SCREEN_COMMAND]=(dm-tool lock)

is not splitting (dm-tool lock) into elements of an array, but setting the whole thing as a string.

Inside bl-exit itself, which is a bash script, a line like this:

XORG_LOCK_SCREEN_COMMAND=(dm-tool lock)

makes an array called XORG_LOCK_SCREEN_COMMAND with elements 'dm-tool' and 'lock'. That's what we want, and without any user alternative lockers set in bl-exit.conf it works as intended.

But when I tried with (slock) in bl-exit.conf as a one-word command that passed the regex test, bl-exit was taking it as a command '(slock)' including brackets which failed. It should have made an array LOCK_SCREEN_COMMAND with a single element 'slock'.

So some serious disentangling is needed here...

Meanwhile @matmutant I suggest - as a temporary workaround for your locking utility testing - you comment out your entry in bl-exit.conf, copy /usr/bin/bl-exit to ~/bin/bl-exit and edit the default lock command there at line 85 or so.

---
BTW don't worry about my dm-tool DBus error - it seems to be coming from my non-standard version of lightdm, 1.33.0:
https://bugs.debian.org/cgi-bin/bugrepo … ug=1143981

#1 2026-09-21 20:15:33

back in business, and troubles

#2 2026-09-22 12:42:28

Re: back in business, and troubles

#3 2026-09-22 18:47:47

Re: back in business, and troubles

#4 2026-10-01 12:27:04

Re: back in business, and troubles

#5 2026-10-02 01:38:51

Re: back in business, and troubles

#6 2026-10-02 06:16:26

Re: back in business, and troubles

#7 2026-10-02 09:45:39

Re: back in business, and troubles

Board footer