Klipperscreen only showing console

[nannyogg82]

 

Hi,

A few weeks ago I started encountering a problem with my Voron 2.4 I couldn't diagnose or fix. Before this I had Klipperscreen installed with a Raspberry Pi 7" screen. I decided to do a fresh install and clean up previous errors I had made and do some upgrades. However, when I reinstalled Klipperscreen the touscreen just wouldn't respond at all. I know that this is not a hardware problem as the screen was working prior to this, and I installed Pi OS just to double check the screen worked there, which it did.

I went to the troubleshooting link here:

Troubleshooting - KlipperScreen

And followed the instructions for changing the input. However, once I did this the screen went black and now only shows the console. I tried following the instructions for when the console is showing in the same link but this brings up some user interface in the SSH that I don't know how to interact with.

If I'm reading this error right, am I basically on the wrong channel and just can't figure out how to change it?https://twemoji.maxcdn.com/2/72x72/1f937-200d-2642-fe0f.png

 

KlipperScreen.log

[atrushing]

The other command, nano /usr/share/X11/xorg.conf.d/99-fturbo.conf will make the file if it isn't there. In the screenshot you sent, you are inside of Nano (the text editor). You just need to type in the /dev/fb0 part and exit/save the file.

7 hours ago, nannyogg82 said:

I'm a newbie when it comes to this...

We were all there once. It looks more daunting than it is, once you figure out the basics it gets easier.

[atrushing]

What is the output when you run

ls /dev/fb*

 

[atrushing]

30 minutes ago, nannyogg82 said:

If I'm reading this error right, am I basically on the wrong channel and just can't figure out how to change it?

 

ls /dev/fb* should return /dev/fb0 or /dev/fb1 (or both or more)

You need to add one of them to the 99-fbturbo.conf file to tell Klipper Screen which output to use. Then use [ctrl]+[X] to exit the file and select "Y" to save the file. If the first one doesn't work then edit the file again with the other value.

 

[nannyogg82]

 

Thanks for the reply, when I run that command I get the following:

ls /dev/fb0

When I this command - cat /usr/share/X11/xorg.conf.d/99-fbturbo.conf | grep /dev/fb

It says that there is no such file or directory. Is that why the following GUI screen is blank? Do I need to create the directory before I can add in anything? I'm a newbie when it comes to this...

 

 

[nannyogg82]

35 minutes ago, atrushing said:

The other command, nano /usr/share/X11/xorg.conf.d/99-fturbo.conf will make the file if it isn't there. In the screenshot you sent, you are inside of Nano (the text editor). You just need to type in the /dev/fb0 part and exit/save the file.

We were all there once. It looks more daunting than it is, once you figure out the basics it gets easier.

IT WORKED! Thank you so much, this has been annoying the hell out of me for days now! 

[nannyogg82]

Ok, it sort of works! lol

So I had to physically create the 99-fbturbo.conf file and populate it with /dev/fb0, problem now though is that every time I shut down the printer this file disappears and I have to go through the whole process again...

[atrushing]

1 hour ago, nannyogg82 said:

every time I shut down the printer this file disappears and I have to go through the whole process again...

This is something I haven't seen before.. There is probably a solution to make the file permanent but I'll try to show you a way to create the file automatically on startup.

The first step will be to use Nano to create a shell script:

nano fturbo.sh

and put the following text in it:

#!/bin/sh
echo "/dev/fb0" > /usr/share/X11/xorg.conf.d/99-fturbo.conf

Then after you exit/save the file you need to make it executable:

chmod +x fturbo.sh

Then we need to tell the Pi to run it at startup:

 

crontab -e
@reboot sh /home/pi/fturbo.sh

Hopefully this file doesn't disappear too!

 

Edited January 10, 2023 by atrushing

[smirk]

13 hours ago, atrushing said:

crontab -e
@reboot sh /home/pi/fturbo.sh

If it help's - the "crontab  -e"  launches an editor (to edit your cron "table" file), in that editor you then add a the line "@reboot sh /home/pi/fturbo.sh" which is just telling the cron daemon to run that fturbo.sh command every time the system boots.

 

Out of interest can you remember which version of the distro that you are running on the machine (what name did it give itself). I have seen manual alterations dissappearing when the system config is actually automatically generated (from another set of config files), it's really annoying as you then have to learn a different set of config commands, to make alterations. The other possibility (long shot) is the "/usr/share/X11/xorg.conf.d" is actually mounted on a temporary filesystem (a RAM disk), can't really see why but you never know.

If you did a "df /usr/share/X11/xorg.conf.d" comannd the "df" will report on disk usage and say where (and what) the directory is mounted on. The first entry in the output is the device the directory is mounted on. For example (I don't have X11 or klipper screen), so I'll use the /run directory:

pi@voronpi2:~ $ df /run
Filesystem     1K-blocks  Used Available Use% Mounted on
tmpfs             186644  9708    176936   6% /run

That is on a temporary (or "ram disk"). As I say that's a long shot, more likely there's some automagic configuration going on.

[nannyogg82]

On 1/10/2023 at 6:07 PM, atrushing said:

This is something I haven't seen before.. There is probably a solution to make the file permanent but I'll try to show you a way to create the file automatically on startup.

The first step will be to use Nano to create a shell script:

nano fturbo.sh

and put the following text in it:

#!/bin/sh
echo "/dev/fb0" > /usr/share/X11/xorg.conf.d/99-fturbo.conf

Then after you exit/save the file you need to make it executable:

chmod +x fturbo.sh

Then we need to tell the Pi to run it at startup:

crontab -e
@reboot sh /home/pi/fturbo.sh

Hopefully this file doesn't disappear too!

Ok, this is really annoying me now.

So I have been adding this file into the directory each time using WinSCP. For the first few times it worked perfectly, even though I had to redo it every time at restart.

Now however, not even this is working now. I re-enter the file details into WinSCP as I have before and now nothing happens. The file disappears and the screen is now only showing the console. Won't work at all now.

I tried the crontab command as suggested above and that doesn't work either. Any more advice? 

[mvdveer]

Can imagine this is annoying and frustrating. All I can think of doing, other than starting with a new SD card and install, is to use kiauh and completely uninstall both mainsail and Klipper, restart the pi an then reinstall first mainsail and then Klipperscreen. The reason for suggesting a mainsail re-install is that some time ago mainsail changed its directory structure and I am wondering if somehow, somewhere this is causing your problem.

[claudermilk]

It was Moonraker changing the directory structure.

[mvdveer]

18 minutes ago, claudermilk said:

It was Moonraker changing the directory structure.

You are right, sorry my mistake

[smirk]

13 hours ago, mvdveer said:

changed its directory structure

I noticed as part of my recent MainsailOS build (last few days) that it has "normalised" the new directory structure. Basically there's no longer any of the symlinks to the "original" locations basically the new structure is the only structure. Granted that does not really help in this situation but I mention as background.

 

17 hours ago, nannyogg82 said:

I tried the crontab command as suggested above and that doesn't work either. Any more advice? 

Was it working, but then stopped working (along with the manual fix)? A duff SD card surely would produce other weirdness as well (pretty rare to affect only one very small file, since that would be smaller than a duff block). I keep coming back to somethiing automagically removing/overwriting the config. I've dug out a screen so I'll have a poke at the klipper-screen setup and see if it jogs anything.

Personally I would not go for a deinstall and reinstall (of just the Klipper/mainsail elements). There are limits to how good deinstallers can be - depending on how screwed up things are something might be left to taint the new setup. If you're going down that route I would just go for a complete reimage of the SD-card - for clarity, I view the OS/software setup inside the printer as a kinda of "disposable" commodity. Beyond some simply captured config, macros and the like, which are stored in some well-defined CFG files everything else is easily blown away and started afresh to get you back to a "known good" state, from that point you can use "kiauh" to install the other components.

Not having used "kiauh" I presume the starting point is a very generic OS install? Personally I've had great success with so-called "mainsailos"

[atrushing]

4 minutes ago, smirk said:

Personally I've had great success with so-called "mainsailos"

I have had a good experience with MainsailOS as well and if you have a backup of your config files, starting with a clean install isn't as bad as you might expect.

18 hours ago, nannyogg82 said:

So I have been adding this file into the directory each time using WinSCP.

I am also curious about using WinSCP instead of just using a remote shell like PuTTY so that you can create/edit files directly on the Pi with Nano. I wonder if there might be permission or owner/group conflicts with system files being copied in.

All of the commands that I outlined before were intended to be run on the Pi through SSH (PuTTY). Copying files over to the Pi won't necessarily have the same effect.

[claudermilk]

Sorry, that sounded kind of short @mvdveer. I was somewhat distracted and frustrated when posting that. So, Moonraker moved the config file from klipper_config to printer_data/config. Updating an existing install can be a PITA requiring you to run a fixit script that effectively creates symlinks from the old location to the new; it works, my printer is back running after using that script.

For @nannyogg82's problem I also think it might just be easier to backup the printer config files and reimage the SD card.

[smirk]

7 hours ago, atrushing said:

I wonder if there might be permission or owner/group conflicts with system files being copied in.

I was just trying winscp as an experiment (your permission comment made me think), the winscp client does give a quite clear "permission denied" error when trying to copy something to somewhere verbotten.  There doesn't seem to be a way of turning the error off (by accident) so there's not "ignore this message" tickbox.

However,I agree that editing should be done directly on the PI, trouble with using WIndows (and I presume windows as the client is WinSCP) is that it can introduce funny line endings into text files which can cock up things in the *NIX world (basically *NIX uses single LF characterto denote a line end, whilst WIndows uses two characters LF + CR to denote line ends, so you end up with extraneous junk white-space in your files on *NIX).

[nannyogg82]

I'm going to have to bump this again. 

So I tried ALL of the solutions above and it sort of worked intermittently where I could usually get Klipperscreen to show with 3-4 reboots. Now after a software update I can't get it to work at all.

I have tried repeatedly to get this working again after a software update but every time I try to save the /dev/fb0 file to the right location it immediately disappears! So frustrating. Anyone got any ideas?

[Slushy_Trout]

I'm having a similar issue.  I installed Klipperscreen, however the screen will only display the console.  Can't seem to get it to change.  I also went through the troubleshooting and creating the fburbo.conf and adding fb0 or fb1 does not change the display. My screen is using the DSI connection, if that matters.  

[royassas]

@nannyogg82 I've got the same problem on an Raspberry Pi 3B with current Klipper and all updates/upgrades done (Using the BTT TFT50 screen via dsi cable). The file disappears on every restart regardless of me manually editing the cat /usr/share/X11/xorg.conf.d/99-fbturbo.conf file or by using the cronjob approach. 
 

After installing klipper-screen I got the screen working, but touch didn't work. I followed the troubleshooting guides on https://klipperscreen.readthedocs.io/en/latest/ and after rebooting only got the console. I'm unsure if changing the config.txt file according to "Touch not working on debian Bullseye" did break things - but having read your thread, I suppose it was just the reboot that got me to the command prompt, too.

[Arland]

I have this same issue - following to see if it is solved.

[polygonprint]

3 hours ago, Arland said:

I have this same issue - following to see if it is solved.

Same here with a WaveShare touch screen. Screen is displaying just fine but touch will not work. As I'm having other issues with my new Trident build I decided the screen is not such a priority (secretly hoping a upcoming update to something might magically fix it)

[Slushy_Trout]

I resolved my issue by using a pi 4. There must be some issue with the pi 3 that is causing the touchscreens to not function.  I tried my BTT PI TFT43 on 2 different pi 3B's with the same results.  Soon as I hooked up the pi4, worked perfectly after following the trouble shooting guide for Klipperscreen.  

[claudermilk]

I'll have to keep that in mind. I have a 4B 2GB on my Trident and KlipperScreen just worked. That might be why. I have a couple of Pi 3s hoarded for future projects--though probably not going to run Klipperscreen on them.