99-fbturbo.conf

[Oliverio Gallman]

Theother 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.

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.

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...

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:

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.

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.

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.

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.

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.

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.

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).

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?

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.

@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 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.

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)

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.

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.

The latest kernel does not use the ads7846_device module any more but uses device tree configuration instead. The instructions are now updated accordingly, thank you to Lauri Anttila for reporting this.

One evening I was browsing around ebay.com and came across these pretty cheap less than $30 (including postage) LCD touch screens for Raspberry Pi. I happen to have one Raspberry Pi B+ lying around that didn't work that well in its original intention, but I have had some plans to repurpose it as a controlling device for solar panel charging and electricity in our summer house. A small touch screen would fit that purpose quite nicely, so let's order one of these and try it out first.

Well, you get what you pay for and with this price it seems reasonable, so let's just get assembling. After several attempts I finally got the thing into a respectable state, which actually looks pretty nice!

At this point I'm all excited to get this running, right? So I go to the official download site, download the latest Raspbian image (which is quite widely supported) and copy it to my SD card. After getting the keyboard, network, HDMI and power wires connected, the device boots very nicely and greets us with the usual Raspbian configuration screen.

Now that we have everything set up but the screen doesn't show anything, more problems come up. When I try to fit the small DVD that came with the device to my Macbook Pro DVD drive, it just doesn't fit there (or rather fits too deep), so I have no drivers or instructions. We would be totally screwed at this point..if we didn't have the Internet!

Now we should have all the drivers we need, so let's look at a GitHub issue we found discussing this exact same device, looks like someone else has a better DVD drive and has already posted logs from the official drivers, which is almost all we need to get the LCD running.

This may seem cryptic, but when you look at it for a while it it's telling you quite many things. First, the GPIO pins for reset and dc (data command) are detected to be 25 and 24 respectively. Second, initializing the screen requires 11 writes with one 250ms delay in the middle. Third, the screen has resolution of 480x320 with 20fps frame rate and 16000kHz data transfer rate, no programmable backlight and it is located on SPI bus 0 chip 0. Fourth, we have a touchscreen on SPI bus 0 chip 1 with transfer rate of 500kHz.

One information missing from that log is the regwidth, which some of our friends on GitHub have already found out to be 16 bits. The flexfb driver supports giving custom init sequences as an array by using -1 for write command, -2 for delay and -3 for end of init sequence. Therefore on the console we can try the following:

3a8082e126