Well, I'm no expert on this, but I think it's the lines following that log line that should tell whether the input is actually added or ignored. On the other hand, it's apparently eudev that presents the lid switch to X in the first place, presumably during its traversal of /sys. Perhaps it traces back to /lib/udev/rules.d/80-libinput-device-groups.rules  or 90-libinput-model-quirks.rules, or some other rule(s), and perhaps there's a suitable knuckle-rap to make eudev ignore the lid switch instead.

Thus I'm thinking that whatever it is that results in the /dev/input/eventX device node should be patched to not do that for the lid switch, and then it won't be presented to X. I tried this by removing /dev/input/eventX manually, and restarting X (not rebooting), which resulted in a log without a "Lid Switch" discovery line. Maybe you could try that as an experiment to see if it makes any difference for your graphics problem. Otherwise it's probably no use in digging deeper.

actually it's the  opposite for in/out .... it's page zoom and not text zoom, but ctrl-+ works now.

Right. I suppose you'll need a sibling or replace of /usr/share/xsessions/xfce.desktop to make that happen. Perhaps by replacing all "xfce" with "mate"; and maybe add some particular hand-crafting to the "Exec=..." line at the bottom. Or, just hang around until someone who knows something swings by

Great. You might even want to lodge a bug report on pm-utils to add the appropriate vendor quirk combination into the database for T400.

You'll probably do need to understand insserv, which is the one using the LSB headers, and manipulating the files /etc/init.d/.depend.{boot,start,stop}, which are the "make files" for the init process. I'm not totally sure where/when/how init uses those files, but as I remember it, those files tell which scripts to run when. The insserv man page points at startpar as the actual driver process, so I guess, all together it's init, insserv and startpar to peruse.

Well, since process ids may have anything between one and five digits, you could as well let the interpreter do the tokenization, making it be like the following:

wmctrl -l -p | while read a b c d ; do echo $c ; done

You may want to peep at "[SOLVED] slim does not set a default session".
A bit old, but possibly relevant still.

Presumably it's because the WM_CLASS property is different between the two cases, and that the resources for urxvt refers to the differing class tag.

Use xprop | grep WM_CLASS to check.

There might be some thinklight brightness control somewhere under  /sys/bus/platform/drivers/thinkpad_acpi/ ?

Maybe the phone has two partitions? E.g. internal and external sd cards?

Great. I think. The command prompt may well be post-pivot, which would mean that you actually have booted Devuan, but that there is an issue with the graphics. A few things to inspect:

# blkid

# dmesg | tail

# tail /var/log/syslog

# ls -l /dev/sd*

Though, I'd say fsmithred has more experience about getting it back into shape from this state, so maybe you should now ignore me

Ok. I don't know why the initrd building worries about the device node, since it should just take what is given at boot time, and not at building time. There might be a number of gremlins under that stone, but maybe you get away with just rolling back and mounting devtmpfs onto /dev before another update-initramfs.

# mount -t devtmpfs none /dev

By idle guesswork, I think the initrd building really would want to find a file /var/lib/initramfs-tools/3.16.0-4-amd64 with content:

fd47cef5-ce5e-4090-8bfa-aef277a49e3e /boot/initrd.img-3.16.0-4-amd64

as its "database entry" of where that initrd is supposed to reside. But it burns my synapses trying to fathom an underlying logic for it.

Anyhow, maybe it'll be happy enough with having devtmpfs mounted.