Installing Florence and Matchbox_Keyboard

The article which describes how to use the SD copier to export and compress the Pi OS: https://www.raspberrypi.org/blog/another-update-raspbian/

A post about installing Matchbox Keyboard on the pi, which had warnings in the middle from users who had encountered problems with their desktop icons disappearing (due to Matchbox interfering with the file browser pcmanfm): https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=14719

Another post about the conflict between Matchbox and pcmanfm. At the bottom there is a suggestion that it was somehow fixed in an update, presumably an update to PCMANFM: https://www.raspberrypi.org/forums/viewtopic.php?t=153003

The spec for the touchscreen itself mentions Matchbox, with a quick description of using sudo apt-get install: https://www.element14.com/community/docs/DOC-78156/l/raspberry-pi-7-touchscreen-display

The documentation for Florence itself just shows doing a simple sudo apt-get install: http://florence.sourceforge.net/english/index.html

PCMANFM deleting bookmarks

I accidently hit the eject symbol for the MicroSD card on a file browser in Raspbian. To my surprise, the system continued to function, contrary to what I'd read elsewhere. I think that what happened was not an ejection of the OS but it deleted a link which opens the browser to the OS top level. After some frantic searches, I was reminded that this browser is called PCMANFM and learned that the links in the side panel are "bookmarks". The following article provide enough info for me to manually reestablish the bookmark. It seems like the browser app remembers changes to the list of bookmarks even through restarts. Here is the article that helped me get a handle on what was going on: https://www.raspberrypi.org/forums/viewtopic.php?t=107216

Honey I shrunk the Pi image

A post just on the topic of creating a shrunken pi image backup and then reinstalling it and expanding it.

Adafruit's article which shows the new process for copying a live SD card PI image to another card with automatic shrinking: https://www.raspberrypi.org/blog/another-update-raspbian/

The nice instructible on the topic that was written before the implementation of the SD card copier: http://www.instructables.com/id/How-to-BackUp-and-Shrink-Your-Raspberry-Pi-Image/

Raspberry Pi SVN server

These instructions worked perfectly:

https://www.jeremymorgan.com/tutorials/raspberry-pi/raspberry-pi-how-to-svn-server/

Probably copied from the first link:

http://www.calumtomeny.co.uk/wordpress/simple-svn-server/

Raspberry Pi Thumb Drive Not Mounting

After reassembling our Raspberry Pi 3 system, thumb drives plugged into the USB port are recognized and the dialog box appears that asks if you want to open it in a file browser, but when the browser window opens it fails with a dialog box that says "The specified directory /media/pi/[name of drive] is not valid." The troubling thing is that it used to work fine before.

The answer, after trying dozens of approaches, turned out to be that the permissions on the /media/pi directory weren't set right. Finding this answer was made tricky because I was comparing the directory permissions to those on another pi that didn't have the problem, and the directory permissions matched. I learned however that the other system had an Access Control List set on the directory that gave additional permissions to the pi user. Setting up the original pi to have an access control list to match the working one fixed the problem of the thumb drive not being mounted correctly when plugged in, but then for some reason whenever an eject was done from the file browser the eject widget on the task bar would show an error that the drive had been removed without being ejected. That problem was fixed by updating the lxpanel package on the old pi; it turns out that the eject widget is part of the lxpanel and not a stand-alone app.

Troubleshooting notes taken during the course of figuring all this out follow:

This result from googling the error message is somebody who eventually figured out that his system was missing usbmount. I could try installing usbmount, but it doesn't seem like this would be my problem because USB drives used to mount on my system (unless something somehow got messed up when I cloned the SD card): http://unix.stackexchange.com/questions/325962/the-specified-directory-media-fa-faf9-c03-is-not-valid-error-when-trying-to

By following these instructions, I am able to mount the drive into a new location, access it, and unmount it. I found that the strange serial number in the error message appeared in the list of devices by id, and that a /dev/sda1 device had been created, so all of the assumptions in these instructions about what I would find were true: http://www.raspberrypi-spy.co.uk/2014/05/how-to-mount-a-usb-flash-disk-on-the-raspberry-pi/

Here's another set of instructions on mounting a thumb drive that look good but I haven't really looked at them yet because the first one worked so well: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=35695

Another tutorial about USB drive mounting. Doesn't cover the automounter but has an amazing assortment of tips and tricks that I haven't seen elsewhere:

https://pimylifeup.com/raspberry-pi-mount-usb-drive/


Trying to enable the wifi:

"It should just work" meaning there's a graphical tool from the menu bar (which I can't find): https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=138137

Gorgeous step by step instructions on enabling the wifi from the command line, which worked right up to the point of configuring the wifi password in a plain text file. The problem is that our guest network requires authentication via a web page with a form. But I was able to scan for local networks at least using these steps:

https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md


http://www.makeuseof.com/tag/setup-wi-fi-bluetooth-raspberry-pi-3/

So trying to login this type of network is basically impossible in Pi: https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=152447

The problem is so bad that all of the serious suggestions on this page are ridiculous: raspberrypi.stackexchange.com/questions/34008/connect-to-public-wifi-hotspot

Here's somebody who actually finds an answer, but later on somebody points out that I can just use the portable hot spot from my phone: unix.stackexchange.com/questions/118289/how-do-i-authenticate-to-a-wireless-providers-open-network-without-using-a-br

Just turning on the hotspot on my phone, the hotspot wasn't found when scanning. This set of instructions involves tethering the phone to the Pi over USB before making the connection to the hotspot. Why? I don't know! But it didn't work; the Pi never found the phone, possibly due to whatever problem is occuring with the USB in the first place.

http://www.daveconroy.com/how-to-tether-your-raspberry-pi-with-your-iphone-5/

Returning to working on why automount is failing, looking in the message logs, there are strange error messages such as: "error opening /media/pi/9005-048F/BDMV/index.bdmv"

Somebody reports that these are file types for blu-ray disks? https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=154836

This thread's resolution seems to suggest that it's a power starvation issue (if so this is bad news for my system): https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=124532

About the 'action 17' errors also seen in the log (apparently unrelated stuff):
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=155803
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=152405

So, I downloaded usbmount, and a thumb drive is now mounted and opens in file browser when plugged in.

But it can't be ejected without a dialog asking for the password for the user account (there isn't one, which means that this dialog can't be answered! A couple of search results for the dialog came up with suggestions to change some policy settings:

askubuntu.com/questions/552503/stop-asking-for-authentication-to-mount-usb-stick

Now the eject buttons for the drive in the file browser seem to unmount the drive, but a message appears from tbe eject app saying that the drive was removed wirhout being ejected.

(along the way, found this interesting thread about somebody having problems booting from a usb hd, solved by adding a config parameter for a wait before first access to an external drive:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=109589 )



Things that are different between the working and nonworking images:

File permissions for working system:

/media: drwxr-xr-x root:root
/media/pi: drwxr-x---+ root:root
/media/pi/SETTINGS: drwxr-xr-x root:root

File permissions for the nonworking system:

/media drwxr-xr-x root:root
/media/pi: drwxr-x--- root:root
ls /media/pi: Permission Denied

The SETTINGS directory is apparently the NOOBS config files.

http://raspberrypi.stackexchange.com/questions/60609/settings-drive-accidentally-renamed/60683

Looking at all files under /etc, SETTINGS is mentioned in the mtab file, which is the list of all presently mounted file systems.

the (+) on the file permissions for the working system means that it's an access control list?

https://ubuntuforums.org/showthread.php?t=2206434
https://wiki.archlinux.org/index.php/Access_Control_Lists

Again, in the following example /media/pi has a (+). His drive doesn't automount though and he never gets an answer to his question

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=135178B

Results from getfacl /media/pi in the working system:

#file: media/pi
#owner: root
#group: root
user::rwx
user:pi:r-x
group::--
mask::r-x
other:---

Added an ACL to /media/pi using the example in this page (this page is filled with extremely easy-to-follow instructions BTW):

http://www.htpcguides.com/properly-mount-usb-storage-raspberry-pi/

Now I can access /media/pi as user pi, and when I plug the thumb drive in, it comes up in the browser without error!!! Also, the drive is not greyed out in the eject widget!!!

But there's still something not right that works using the new NOOBS configuration! When I eject it using the eject button in the browser, the eject widget still says "...was removed without ejecting Please use menu to eject before removal" This does not happen in the working system.

Apparently the button in the file manager is separate from the button in the eject widget. There are many, many posts online from people who have problems using the button in the file manager but they are almost all people who don't have the "eject" package installed. I triple checked and it is installed on both of my systems.

Here's are some of those people who simply had to run sudo apt-get install eject. How jealous these links make me!
http://raspberrypi.stackexchange.com/questions/14843/how-to-eject-usb-device-on-raspberry-pi-not-just-unmount
http://kj-til.blogspot.com/2013/11/eject-usb-drive-error-and-fix.html
https://www.raspberrypi.org/forums/viewtopic.php?t=18364

Here's a guy who wants to have the eject buttons in the file browser be removed or disabled. It seems like this would be pertinent to helping me find out how to change their behavior, but sadly nobody answers this forum question! Also this would be pertinent because the file browser is including eject buttons for the main SD card which makes no sense and probably would be bad if somebody hits them: http://askubuntu.com/questions/862592/remove-or-disable-eject-button-in-files-file-manager-for-second-internal-hdd

I did a bunch of googling of how to configure the file browser.

I learned that it's called "File Manager" and it has a menu option for "Preferences" which has settings for how to respond to a USB volume being plugged in!!!!! Strangely there doesn't seem to be settings in preferences for how to respond to requesting and eject? I don't understand why that wouldn't be there. However, I discovered that the File Manager program has a name; it's named PCManFM. Amazingly it was developed in Taiwan, released under GNU public license, and is the default file browser in LDXE which Raspbian is a flavor of.

This wiki article on pcmanfm goes out of its way to mention that pcmanfm handles thumb drives (the keyword is "volumes") but does not point to any specifics about how it is configured. Also the original page seems to have been hacked so this link is to an archived version: https://webcache.googleusercontent.com/search?q=cache:2Sk4YDcqHgEJ:https://wiki.lxde.org/en/PCManFM+&cd=2&hl=en&ct=clnk&gl=us

Here is an overview of what pcmanfm is, with a hint that it handles automounting but it doesn't say anything here about unmounting. It mentions that there is a daemon mode for detecting new removable media, and specifically mentions my USB automounting problem with a link to a different article: https://wiki.archlinux.org/index.php/PCManFM

The link from the pcmanfm link about USB drive authorization problems. This actually is about the policy settings that were discussed in a different answer that I found during my disastrous experiment with installing usbmount; this wiki page is for something called "polkit" which seems to be a tool for modifying the policies that I was manually editing to get usbmount to allow an unmount without a password: https://wiki.archlinux.org/index.php/Polkit#Mounting_storage_without_password

This github README mentions that Volume management is done with glib, which relies on gvfs. Also that there is an --enable-udisks configure option, but doesn't go into detail about how those are setup.https://github.com/lxde/libfm

This blog post from a pcmanfm developer in 2010 gives the hint that the configuration file is named libfm.conf, and there are also relevant configuration parameters in ~/.config/libfm/libfm.conf. Worryingly, a commenter asks downthread if there will be an "unmount safely option," so maybe one didn't get implemented in 2010? https://webcache.googleusercontent.com/search?q=cache:5ufMWNwOmn0J:https://blog.lxde.org/2010/07/04/direct-udisks-support-for-libfm-and-pcmanfm-is-finished/+&cd=2&hl=en&ct=clnk&gl=us

Searching my working unit, I find a virtual pile of applicable .conf files under /etc! These are not necessarily in the locations hinted at by the 2010 blog post, so some tweaking has apparently occured

/etc/xdg/libfm/libfm.conf
/etc/xdg/pcmanfm/default/pcmanfm.conf
/etc/xdg/pcmanfm/LDXE/pcmanfm.conf
/etc/xdg/pcmanfm/LDXE-pi/pcmanfm.conf

Of those, libfm.conf doesn't have anything particularly interesting except for a flag for "use_trash" which means that if I ever need to turn that on or off I now know where to do it. The contents of the other three .conf files vary with respect to each other, with the default and LDXE-pi pcmanfm.conf containing three scant configuration lines in a [volume] block of parameters, none of which seem to include anything about unmounting or what code gets run for mounting! The LDXE pcmanfm.conf oddly doesn't contain a [volume] section. All three have parameters different from each other that seem mostly to do with the look and feel.

This git repository lists the --enable-udisks option as a parameter for building it (sad) but says that it is defaulted to yes (happy)!!! https://github.com/raspberrypi/libfm-1.2.3/blob/master/configure

This man page for udisks indicates that detach and eject are both options, with parameters that are not listed in this page: https://udisks.freedesktop.org/docs/1.0.5/udisks.1.html

This github code indicates that there is a utility named udisks-eject; perhaps this is what is called by pcmanfm on my working system (Update, it's unlikely). If so I wonder how to find the option that specifies it? https://github.com/patrikf/udisks-eject/blob/master/udisks-eject

Unrelatedly, here is an interesting developer's discussion on what context menus to put on the eject options for Nautilus, a similar file browser to pcmanfm. They're talking about the same thing so there's probably interesting stuff to learn here, but it's mostly argument about GUI philosophies.https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/28835

Having learned all that, I keep finding hints that the configuration for pcmanfm is in .desktop files, which I don't know much about but have to learn now I guess.

This guy researched how to customize the pcmanfm option. This is getting soooo close! He's trying to set it up to use udisksctl which I've also seen in other links. He is advised to put something in ~/.local/share/file-manager/actions/umount.desktop http://askubuntu.com/questions/633027/eject-usb-drive-action-for-pcmanfm

Sadly, I don't seem to have ~/.local/share/file-manager/actions/umount.desktop. Actually my ~/.local/share directory doesn't have a file-manager directory, just applications, desktop-directories, gvfs-metadata, and Trash, none of which even contain anything interesting.

This page, which I actually found a while ago, mentions config files in ~/.config! It mentions a .config/pcmanfm directory, which I have! I have a LXDE-pi directory instead of the lubuntu directory mentioned in the post but that all makes sense! And there's pcmanfm.conf! Its contents are a little different from the one in /etc/xdg/pcmanfm/LXDE-pi though. There's some wind size, then interestingly the local one has a parameter close_on_unmount=1! This parameter isn't in any of the three pcmanfm.conf files under /etc/xdg. I wonder where it came from? https://ubuntuforums.org/showthread.php?t=2214272

OMG this link referred to from the previous link has so much relevant information! https://ubuntuforums.org/showthread.php?t=2214389&p=12973843#post12973843

But wait! This post under the pi forums has somebody adding a behavior to pcmanfm by creating a ~/.local/share/file-manager/actions out of thin air and then putting stuff into it. Well, since my working system doesn't have a ~/.local/share/file-manager directory, I know that this can't be how it is doing it, but this still seems like a really potentially useful trick: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=146711

This is all very well and good, but I checked /var/log/syslog on both the working and now-only-slightly-not-working system and they show nearly identical log messages when a drive is ejected from pcmanfm. Both systems have the following messages from udisksd:

udisksd[task number]: Cleaning up mount point /media/pi/ (device 8:1 is not mounted)
udisksd[task number]: Unmounted /dev/sda1 on behalf of uid 1000

Also, that is the message on both systems whether the drive is ejected from pcmanfm or the ejector widget.

So, perhaps the problem that's causing the ejector desktop widget to throw an error message when a drive is ejected from pcmanfm isn't in pcmanfm after all, but in the ejector widget instead.

Could this problem be solvable by adjusting the ejector's configuration? The first step is to find the ascii config files that govern the configuration.

This page doesn't talk about the configuration files, it's about an exercise in setting up the configuration of a generic LXDE desktop to look like the Raspbian desktop, but it's delightfully geeky. www.zdnet.com/article/how-to-customise-your-linux-desktop-lxde/

This page however does go into great specifics on where to find the setup files under /etc/xdg/lxsession/LXDE-pi and ~/.config/lxsession/LXDE-pi.www.raspberrypi-spy.co.uk/2014/05/how-to-autostart-apps-in-rasbian-lxde-desktop/

Interestingly, the actual setup seems to be under ~/.config/lxpanel/LXDE-pi/panels. The file which establishes the ejector is ~/.config/lxpanel/LXDE-pi/panels/panel, and at the end there is just a section as follows:

Plugin {

type=ejecter
Config {
}

}

So, on the working system at least, the Config for "ejecter" is empty. It is interesting that it is spelled "ejecter" though. Googling for more information about it reveals github repositories for ejecter.c. This seems to indicate that, bad news, this is a compiled part of the kernel. Interestingly though the checkin notes in these repositories seem to show that the file might have been updated recently to specifically address the error messages that I'm seeing. It could be that thanks to the horrible old NOOBS that we were shipped that the problem might be just that the problem kernel is old enough not to have recent updates to ejecter.c!

https://github.com/raspberrypi/lxpanel/commits/master/plugins/ejecter

https://github.com/raspberrypi/lxpanel/blob/master/plugins/ejecter/ejecter.c

Reading through the code on the above repositories, I can see that it contains the text from the dialog messages that show up whenever something is ejected either "wrong" or "right" on my troublemaking distro. But there just don't seem to be arguments. It is an internally complicated, but seemingly stand-alone and toasterlike tool. There are calls in the code to a DEBUG routine which probably does stuff if the appropriate compile flags are set, this isn't going to help me. All I've got to pin my hopes to now is that there might be a way to upgrade the app on my crappy system with the version of the app on my good system. But how?

This thread is just some neckbeards helping a noob bang on an only slightly related problem, but lots of minor clues like ways to figure out version numbers of installed packages (debsums? dpkg's -S flag? apt-file?) and the locations of the desktop setup files: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=148101&sid=7830622a975fc16cd8e9db8ec742aceb

Here's a github repo that shows ejecter.c being under the lxpanel app: https://github.com/raspberrypi/lxpanel/blob/master/plugins/ejecter/ejecter.c

Some background on lxpanel and its configuration files, but nothing that specifically mentions ejecter: https://wiki.lxde.org/en/LXPanel#Main_Config_File

A pretty nice introductory tutorial about lxpanel which describes how the applets work (again without specifically mentioning ejecter). It does say something to the effect of "The configuration is stored in ascii files, but it's not a good idea to muck around with them directly." Which is probably a good idea but I can't stop myself. http://pclosmag.com/html/Issues/201010/page07.html

Another description of lxpanel that mentions "volume control" with no further details like if it's built-in or separate. Maybe I have to update all of lxpanel to update ejecter? This was from a search of "lxpanel" on this site, where a search of "ejector" produced no results: https://packages.debian.org/jessie/lxpanel

Alright, now we're getting close: Here's a guy who had a problem in lubuntu running ejecter specifically, and to troubleshoot it he was able to run it from a command line! His problem was that it crashed though, and it's not clear if this was due to a bug or because you can't run it from a command line. The forum thread ends with the discovery that there is a bug report out on ejecter and it is recommended that it not be used! Not sure why there wouldn't be better google hits if this actually happened. https://forum.lxde.org/viewtopic.php?f=8&t=31726

Ok this is interesting: A guy asks if there's an app in ubuntu that will unmount USB drives, and somebody describes in perfect detail how to add ejecter as an "indicator" that can be started at login by adding a config file to ~/.config/autostart. This is the clearest implication that ejecter is a complete and stand-alone executable, and furthermore the responder also show it being downloaded using apt-get! (Note: somebody else replied with a link to a list of file browsers that can be run under ubuntu. It was inapplicable to the original question but actually still interesting): http://askubuntu.com/questions/145087/lubuntu-panel-applet-or-indicator-to-display-mounted-volumes

So now I need to ask, if ejecter is a stand-alone package that can be downloaded using apt-get, is there a way for me to update one of my copies of ejecter? Can I find out what version is running on each of my systems first?

This link has many answers! Apparently I can use sudo apt-get --only-upgrade install [package name]. Some say that just sudo apt-get install is necessary to update. The Synaptic Package Manager has a "mark for upgrade" option but it is not clear if this will upgrade a single package or the entire distro. Apparently sudo apt-cache policy [package name] will get the list of all version numbers, and then it's possible to specify a particular version number when doing sudo apt-get install!!! Someone reported that the syntax for only-upgrade is apt-get --only-upgrade true install [package]. And then there are examples of using dpkg -s to find if something is installed, complete with a gloriously terse one-liner. http://askubuntu.com/questions/44122/how-to-upgrade-a-single-package-using-apt-get

Wow! Hints for how to list available versions! There's a package called rmadison that does it, and apparently the "policy" argumement might apply to apt-cache not apt-get: http://askubuntu.com/questions/447/how-can-i-see-all-versions-of-a-package-that-are-available-in-the-archive

More of the above hints. Also the question is asked how to tell what version is installed but the answer is that unless a -v argument was coded in there's no way to tell: http://askubuntu.com/questions/428772/how-to-install-specific-version-of-some-package/428778

This link, however seems to indicate that aptitude or dpkg will work just fine to get a list of the version numbers of installed packages: http://askubuntu.com/questions/17823/how-to-list-all-installed-packages

Not directly pertinent but still very interesting, this forum thread contains a discussion of how to use the list of version numbers of installed packages to make an exact clone of an installation: http://askubuntu.com/questions/9135/how-to-backup-settings-and-list-of-installed-packages

An unrelated other example of using apt-cache policy to get version numbers: https://www.raspberrypi.org/forums/viewtopic.php?t=136412&p=907548

Based on all of the above, I was able to itereate through getting the installed versions of the lxpanel on both the old and the new pi, then update lxpanel on the old pi, and the error message from the eject plug-in no longer appears when the thumb drive is ejected from the browser!!!

On the new system:

$ lxpanel -v
lxpanel 0.7.2

$apt list --installed | grep lxpanel
lxpanel/stable.now 0.7.2-1+rpi12 armhf [installed]
lxpanel-data/stable.now 0.7.2-1+rpi12 all [installed.automatic]

$apt-cache madison lxpanel
lxpanel | 0.7.2-1+rpi12 | http://archive.raspberrypi.org/debian/ jessie/ui armhf Packages
lxpanel | 0.7.2-1 | http://mirrordirector.raspbian.org/raspian/ jessie/main armhf Packages

$apt-cache policy lxpanel
lxpanel:
Installed: 0.7.2-1+rpi12
Candidate: 0.7.2-1+rpi12
Version table:
*** 0.7.2-1+rpi12 0
500 http://archive.raspberrypi.org/debian/ jessie/ui armhf Packages
100 /var/lib/dpkg/status
0.7.2-1 0
500 http://mirrordirector.raspbian.org/raspian/ jessie/main armhf Packages

On the old system:

$ lxpanel -v
lxpanel 0.7.2

$apt-cache madison lxpanel
lxpanel | 0.7.2-1+rpi16 | http://archive.raspberrypi.org/debian/ jessie/ui armhf Packages
lxpanel | 0.7.2-1 | http://mirrordirector.raspbian.org/raspian/ jessie/main armhf Packages

$apt list --installed | grep lxpanel
lxpanel/now 0.7.2-1+rpi4 armhf [installed,upgradable to: 0.7.2-1+rpi16]
lxpanel-data/now 0.7.2-1+rpi4 all [installed,upgradable to: 0.7.2-1+rpi16]

The above results show that the old system has an older version of lxpanel (0.7.2-1+rpi4 versus 0.7.2-1+rpi12) and furthermore apt-list shows that there is an upgrade waiting (0.7.2-1+rpi16)!

Performed the upgrade using:

sudo apt-get --only-upgrade install lxpanel

checked for any signs of errors in the update, and rebooted. The system came back up, and lxpanel didn't look any different, but now I am able to insert the thumb drive, open it in a file browser, then eject it without getting any alerts from the eject widget in lxpanel. Checking the installed version using apt list --installed shows that the new version is 0.7.2-1+rpi16. Mission accomplished!

Now that that's done, here are a few links to unrelated but interesting learning that I encountered along the way:

Here's how to add a command to an lxpanel menu: https://forum.lxde.org/viewtopic.php?t=31110

Here's how to add a CD eject button (not even remotely close to what I am trying to do, but interesting) to a desktop widget:https://forum.lxde.org/viewtopic.php?f=8&t=36444

Here's another one on adding commands to an lxpanel menu: http://unix.stackexchange.com/questions/177386/how-can-i-add-applications-to-the-lxpanel-application-launch-bar-via-cli

How to write C code to build a new plugin for lxpanel! https://wiki.lxde.org/en/How_to_write_plugins_for_LXPanel:_pre-0.7_version

The wiki for lxpanel itself: https://wiki.lxde.org/en/LXPanel

Some discussions of commands for safely ejecting and unmounting a USB drive. Interesting stuff about the lsblk command and udisksctrl: http://unix.stackexchange.com/questions/178638/eject-safely-remove-vs-umount

Some man pages for the the udisks command line tool: http://manpages.ubuntu.com/manpages/trusty/en/man1/udisks.1.html
http://linuxreviews.org/man/udisks/
https://udisks.freedesktop.org/docs/1.0.5/udisks.1.html

Some C code for something called udisks-eject. Is this somebody's wet dream or actually a standard feature? https://github.com/patrikf/udisks-eject/blob/master/udisks-eject

raspberry pi resize sd card NOOBS image

For some reason we ordered a 16G SD NOOBS card with our Pi, but since I have to CM our SD card image it would be convenient to have a smaller SD card image. Resizing partitions is often done with Linux and the Pi in particular, but it turns out that we shot ourselves in the foot by getting NOOBS because apparently its nontrivial to resize in that case. I could just download a new copy of Raspbian, and in fact I've done that but it came with a bunch of extra stuff and the UI is wildly different from the Debian look, whereas whatever version was installed with NOOBS is basically perfect and looks only slightly different from Debian. So I'm looking into how to remove NOOBS from the installation that I am presently using, and then doing the resizing.

Here is a beautiful tutorial on how to use gparted to resize the partitions, but (*sniff*) it can't be used with a NOOBS image. The author of this page writes so clearly that I have complete confidence in everything written here and reading it will help me understand the general process better: http://www.aoakley.com/articles/2015-10-09-resizing-sd-images.php

Note: The primary tools required for resizing partitions are gparted and dcfldd.

Here is another instructable which seems nice and leads with an awesome "Honey I Shrunk The Pi Image" graphic but is again inappropriate for NOOBS. However, in the comments there are a lot of great links for doing this process different ways: http://www.instructables.com/id/How-to-BackUp-and-Shrink-Your-Raspberry-Pi-Image/

This instructable claims to explain how to do it on a PC, but all it's doing is explaining how to use WinDiskImager and 7Zip. At the end there are some limp handwavings about using gparted to shrink partitions.http://www.instructables.com/id/Backup-Your-Pi/

So, a google search for how to just scrub NOOBS from an installation produced a lot of good hints:

In response to this question, a bunch of unhelpful people say just to give up, until somebody adds on a comment explaining how they do it: http://raspberrypi.stackexchange.com/questions/13324/deleting-noobs-from-sd-card-and-only-keep-raspbian

This forum thread was referenced by the helpful answer in the link above. Interestingly, it is identically named to the one above. It has the same unhelpful answers as the first but the one helpful answer that inspired the helpful answer in the link above is somewhat terse: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=68072

The helpful response in the second link up from this one references this wiki article which is amazingly informative and explains why there are a pile of partitions on a NOOBS installation and why they can be safely removed: https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained

Finally, I stumbled across a link where step-by step instructions on how to remove NOOBS was provided! Walking through the below was super instructive, and for even more instruction I had to figure out one small thing which I had to do differently.

Here is the link on how to remove NOOBS: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=106529

So, the thing that I had to do differently was that since my SD card came pre-formatted with one partition, I had to do an extra step first to remove the partition. Wow! Before doing anything else in fdisk in the first step, I had to use the 'd' command to remove partition one, then write the result, then everything else worked exactly as written.

Now I had a new 16G SD card with Raspbian only, with just two partitions, boot and root.

Unfortunately, this sad version of Raspbian didn't have gparted or dcfldd. While I was googling around for options of doing the partition resize with only parted and dd, I accidentally stumbled across news which solved my problem without gaving to do any partition resizing at all! It turns out that in the current version of Raspbian, 'Jessie,' there is a new utility called "SD Copier" which not only makes a copy of a pi image, but it also can resize the image up or down automatically to match the size of the SD card being copied to!!! Here's one of the links where this clue was found:

http://tech.scargill.net/raspberry-pi-backups/

I'm using Jessie, but OF COURSE my distribution of it doesn't have this utility installed. From the link below I learned that it is a simple matter to install it using apt-get without disturbing anything else, it's actually a stand-alone program called 'piclone' which is a good name on its own. The link below is a forum post from someone who figured this out accidentally between bouts of rage and people unhelpfully telling him to just do a new download, but in rereading the previous link I can see that the person above's first step was to download piclone before trying it out.

https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=155927&p=1018505

Anyhow, despite an unrelated hardware issue with my home Pi, I got piclone installed on my NOOBSless 16G SD card, and then ran piclone to copy the installation onto a 4G SD card with no problems, swapped SD cards and verified that the 4G card boots. Now I can extract the image from the 4G card and it compresses down to 1G before eveb trying any other tricks to improve compression efficiency.

Raspberry Pi PDF viewer

Did a search of this, found a nice solution, then when I downloaded an updated version of NOOBS it came with a much nicer PDF viewer built in along with all the Libre stuff.

This link suggested using the xpdf viewer and gives a command line example. This worked although the xpdf viewer is quite bare-bones. https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=8005

I had another link that showed how to set up the double-click response for a particular file type, but I've lost the link. This other one talks a newbie similar to myself through how to bring up the GUI menu for doing the association (just right-click on the file and find the equivalent option to "Open With..."). https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=98015

Raspberry pi 3 RTC

Now that it's time to add an RTC to the Pi like I did with the Beagle Bone, I can now enjoy the much greater wealth of options for the Pi. I can also finally learn the correct way to install one using Device Tree since Raspian has gone that way like everyone else.

It turns out that the most common RTC is a tiny single-board, single chip solution that takes advantage of how the first four adjacent pins on the GPIO header are power, ground and i2c bus. Links:

The RTC board that I ordered. It seems that there are a couple of manufacturers doing this design and hard to tell who was first: https://www.sunfounder.com/ds3231-real-time-clock-module.html

One setup guide: http://www.raspberrypi-spy.co.uk/2015/05/adding-a-ds3231-real-time-clock-to-the-raspberry-pi/

Another setup guide: https://trick77.com/adding-ds3231-real-time-clock-raspberry-pi-3/

Here is a nice guide that shows configuration methods for both the old (modules) method and the new (Device Tree) method. It mentions steps for disabling the fake hwclock but it doesn't look like it shows the full procedure: http://www.bashpi.org/?page_id=500

Basically all the good guides are from this one google search: https://www.google.com/#q=sunfounder+ds3231+how+to+install

Having followed those installation guides, somehow it was coming up after rebooting with times that were only close to the current time although not reset to any particular default. It really seemed like the "fake hardware clock" was stepping on the rtc chip's time or something like that.

This site seemed to have the magic bullet for turning fake hwclock off, a beautiful single command which somehow alters all the rc.d files that had time setting stuff: http://forum.openmediavault.org/index.php/Thread/8770-RPi-2-RTC-module-from-unruly-Stepchild-to-Wunderkind/?pageNo=3

Specifically:

update-rc.d -f hwclock.sh remove

Unfortunately, after a few tests that seemed to show that the RTC was working, it stopped working. At first it looked like some tests that I had donewith an alternate power supply for the Pi might have damaged something, however a brand new sunfounder RTC continued to behave the same way. Upon reboot, the time would be set to 9:00 Dec 31, 1969 (upon reflection, this likely to be just midnight Jan 1 1970 GMT as viewed from EST although that doesn't quite add up right it should be 4 hours off not three), and attempting to read the hardware clock manually after a reboot resulted in the message "The hardware clock register contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095)."

A review of the messages file in /var/log seems to show that the chip is being registered as the hardware clock during bootup without any problems. /dev contains a device rtc0 with a simlink from /dev/rtc to /dev/rtc0.

A google search for the date 12/31/1969 shows a few people experiencing a similar problem on a variety of platforms with a variety of RTC chips.

A google search for the register message produces several other hits, one of which looks promising:

https://www.raspberrypi.org/forums/viewtopic.php?p=690492

Some suggestions that seem good that I haven't done yet are to turn off ntp:

update-rc.d ntp disable

fix /lib/udev/hwclock-set according to this link: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=16218&start=25

Also look for marcus15's post near the bottom of this page: https://www.raspberrypi.org/forums/viewtopic.php?p=690492

Furthermore, the same genius who began figuring things out in the above threads, marcus15, has worked through how to set things up for the Jessie distribution of Raspbian (which is what I have, so this applies in particular):

https://www.raspberrypi.org/forums/viewtopic.php?p=692662#p692662

The next to last entry on this page, by pemst, covers a lot of the same steps listed in marcus15's answer with some slight variations in technique: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=16218&start=100

Following the instructions in marcus15's and pemst's posts solved the problemThe problem seems to stem from a timing problem in the original configuration files in Raspbian, in that the usual setting in the hwclock.txt file to read the time from the hardware clock on boot is not being called before some code that decides that the time hasn't been read from the hardware clock and then writes crap to the RTC. The solution, aside from turning off fakehwclock and ntp, is to create a new service that reads the hwclock and then enable that service because apparently services are set up earlier in the boot sequence. Cutting and pasting from the forum threads above:

basic setup: Edit /boot/config.txt to include the following (notice unusual setup of i2c baud rate which I haven't seen anywhere else but which looks like a useful thing):

dtparam=i2c_arm=on
dtoverlay=i2c-rtc,ds3231
dtparam=i2c_baudrate=400000

Next create a service script named hwcock-start.service in /lib/systemd/system by copying hwclock-save.service and editing it to look like this. Note that the call to hwclock is more fancy that normal, with the -D option to print diagnostic to the log files in the event of a problem and the --hctosys option to use the local time zone.:

[Unit]
Description=Synchronize Hardware Clock to System Clock
DefaultDependencies=no
After=sysinit.target

[Service]
Type=oneshot
ExecStart=/sbin/hwclock -D --hctosys

[Install]
WantedBy=graphical.target multi-user.target

Then execute the commands to enable the new service. NTP off is shown below also for good measure.

sudo systemctl daemon-reload
sudo systemctl enable hwclock-start
sudo systemctl disable ntp

Then set the system time and save it to rtc0 and on the next boot the time is read correctly from the RTC.

sudo date -s "MM/DD/YYYY hh:mm"
sudo hwclock -w -f /dev/rtc0

Raspberry Pi 3 root password

It's embarrassing that I even had to look this up, but when I did, I learned: 1) the first rule of Raspberry Pi 3 root password is you do not use a password for root, you just sudo su. 2) This is the same question from a newbie which has answer 1 in it, but then disintegrates into a hilarious neckbeard war about shell security from which many useful things can actually be learned: https://www.raspberrypi.org/forums/viewtopic.php?f=27&t=48293

debian set file browser default view to list

Duh, it's a setting for the browser. Find "Preferences" under "Edit" and set it there.

The link that helped me realize this simple answer. The funny part is that this forum thread is for Ubuntu: https://ubuntuforums.org/showthread.php?t=1179613

raspberry pi 3 switch between touchscreen and hdmi

Research into running a touch screen and an external monitor either at the same time or switchable between them.

Bottom line: With Raspian you can't run two screens at once, and can't hot-switch screens. However, it is possible to tweak configuration files such that the Pi comes up using the desired screen after a reboot, basically the same solution that I used with the Beagle Bone. The configuration files to tweak are different though.

Links:

Background: it is possible to turntbe backlight on and off live by writing a value to a particular dev file.

It's also possible for the version 1.1 screen to adjust the brightness, by writing a value between 0-511 to a slightly different dev file, with 256 being a nice default brightness:

http://raspberrypi.stackexchange.com/questions/46225/adjusting-the-brightness-of-the-official-touchscreen-display

Here is a sort of officialish FAQ about the touchscreen which repeats the statement that I've often seen that certain apps (Ok just omxplayer) can use the HDMI port while the touch screen is in use. It seems to be a lucky side-effect of the configurability of xserver somehow. Also covered in this FAQ are the mailbox system for enabling/disabling the backlight, and rotating the screen, http://forums.pimoroni.com/t/official-7-raspberry-pi-touch-screen-faq/959

Here's the google search: https://www.google.com/#q=raspberry+pi+switch+between+touchscreen+and+hdmi

This thread contains some hints about using the "tvservice" function as I've seen in other forum answers, but as I've also seen on forum threads some users have reported that trying it trashed their OS installation. The OP for this forum thread ended up just living with fully removing power from his touch screen when he wanted to use the external monitor, which would be a desperation-only solution for my application: http://raspberrypi.stackexchange.com/questions/41417/how-can-i-switch-between-a-built-in-display-and-hdmi

Here is the thread with the answer, which is to add "ignore_lcd=1" to /boot/config.txt and rebooting when wanting to use HDMI rather than the touchscreen. To go back to the LCD, remove that line. The way I did this on the BeagleBone was to have two versions of the file, and a little shell script that copies the desired one over top of the last configuration file to set up for the next reboot. Interestingly, another commenter on this thread mentions that something called PINN appears to make hot-swapping screens work as I would want. I need to investigate this further: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=147962

Here's the same answer about "ignore_lcd=1" on a forum thread where somebody who tried something slightly different in config.txt was wrong: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=121591#p846271

Here's the same information in reverse, in some of Adafruit's documentation on a github page where the process for enabling the display with "ignore_lcd=0" in the config.txt file: https://github.com/raspberrypi/documentation/tree/master/hardware/display

Here's a crazy looking answer which apparently involves killing and restarting the xservice (and checking that tvservice is running? Not clear yet). This is another viewpoint of the answers that I saw concerning tvservice I think. http://raspberrypi.stackexchange.com/questions/39960/touchscreen-w-hdmi-output-only-when-a-display-is-attached

The suggestion above also points to the amazingly long and technically detailed online discussion of how to get both a TFT and HDMI working simultaneously, the thing some other forum threads claim is not possible. Lots of uses of tvservice. Here's the link from the thread above which links to page 2 of the thread at a photo proving that it has been done. It's not clear if any of this applies to the 7-inch touch screen but this is clearly the master class: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=91764&start=25#p661085

Another difference between the BeagleBone and the pi seems to be in how the /boot partition is mounted. It's still, oddly enough, an FAT partition on the SD card just like for BeagleBone, but for the Pi it has only root write permissions, making swapping the config.txt files around initially impossible either manually or by shell script. The solution was to edit the /etc/fstab file to change the permissions assigned to the entire partition at time of mounting by adding umask=0. The result is a little ungainly in that from experimenting with it I had to set the executable permission as well as the write permission for group and other, which oddly makes every file in the partition executable not just the directories. I can live with that though. Here are a bunch of links on how to do it:

Here's a very nice article that describes all the fstab parameters: http://www.omaroid.com/fstab-permission-masks-explained/

Half of the articles on the subject of fstab concern how to set it up to provide the desired user access to USB sticks, like this page: http://www.techjawab.com/2013/06/how-to-setup-mount-auto-mount-usb-hard.html

The other half of the articles are about setting up NAS, like this one. However, this also has, down in the comments, the solution to the all files executable problem in that instead of using umask, it's possible to use dmask and fmask to set permissions for directories and files separately! Another comment explains how FAT partitions are different and ideas on how to mount them differently. https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=40402

Having implemented the solution of having two versions of /boot/config.txt and swapping them as needed, I discovered that unlike on the BeagleBone, the backlight does not turn off on the touch screen when booting to the HDMI, leaving a pulsing random pattern on the screen. Not a bad reminder to switch back to the LCD when done, but not aesthetic looking. Is it possible to turn off the backlight when not configured to use the LCD? A whole lot of additional research ensued.

The problem comes from when setting ignore_lcd=1 in config.txt, the mailbox directories in /dev for the backlight controls aren't being set up during boot. Clearly the software module that reads the mailboxes and sets the appropriate control lines in the display is not being loaded.

I looked into what the i2c chip is that is being used to control the backlight and if it would be possible to directly access it. Here are some links:

I also did yet another review of how to load drivers in Device Tree, and was able to learn that the backlight has its own Device Tree driver, and get it to load such that it created the mailboxes on boot, but then writing to the mailboxes did nothing (maybe because the part that services the mailboxes is maybe in other drivers for the display or something).

Here are some links from people that want to use the i2c0 bus for HATs or other add-ons. The people writing these articles are pretty clear on how the i2c0 bus has been subordinated for use on the display connector, and just want to take it back. My thought was that there might be clues here for how to get the bus enabled so that I could get a successful scan of the ATTiny88 chip using i2cdetect as the first step to writing some kind of utility to directly program the output of the chip to turn the backlight off.

Here is a forum thread where the answer is to add "dtparam=i2c_vc=on" to config.txt. It didn't work for me, but that may be because I failed to do the other thing that I see also recommended, which is to add "bcm2708.vc_i2c_override=1" to cmdline.txt. In any case, the person who asked the question in this thread did both things and it didn't seem to work for him: http://stackoverflow.com/questions/32021924/raspberry-pi-2-cannot-enable-dev-i2c-0

Here is a thread from around 2016 specific to the previous release of Raspbian ("Wheezy", it is apparently now "Jessie") in which somebody is trying to enable the i2c0 bus. The hints of adding the kernel parm bcm2708.vc_i2c_override=1 to /boot/cmdline.txt and dtparam=i2c_vc=on to /boot/config.txt are discussed, plus the OP has added a few other interesting dtparam lines to his config.txt file. The OP is encouraged to open a ticket on the problem, and it seems like some discussion takes place on the ticket. Somebody else mentions how the i2c0 bus goes to two sets of pins simultaneously, although his description of why that would be a problem isn't in synch with what I've read elsewhere; he had some commands to execute that he says fixes it. Then the OP says that his problem is solved by a "firmware update" which doesn't exactly make sense. Somebody else joins the thread with a slightly similar problem, in that they want to use the i2c on GPIOs 28 and 29. Apparently the solution is to somehow disable the bus on GPIOs 1 & 0, and somebody proposes making a Device Tree overlay to do it. There is some other "Master Class" discussion further down:
https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=102130

The above forum thread has a link to this other forum thread where somebody is trying to get both i2c busses running. He has i2cdetect -y 0 working, but his devices on the bus are not detected. He's got all the modules loading, and has installed i2c-tools. He made sure that the bcm2708 drivers are not blacklisted and added some dtparam statements to his config.txt file. Somebody comments that there is a reason not to edit config.txt directly but I don't get it and in my previous edits for enabling or ignoring the LCD my edits seem to work. However apparently there is a configuration editor and it might produce live results without the need for rebooting. The forum thread dies without an answer apparently being found, but it is notable that the OP uses GPIOs 27 & 28 instead of 28 & 29, and the GPIOs don't have external pull-up resistors so some may need to be added. Again, it doesn't seem like this is going the right direction for me since I know that the ATTiny88 is being controlled fine by i2c0 already, but this thread still seems to have useful info.
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=115709&p=789932&hilit=i2c0#p789932

This thoughtful and measured article, entitled "How to get the second i2c bus to work" seems to describe the problems encountered by many others in forum threads, where they've gotten the bus to scan using i2cdetect but aren't reading any of their hardware that they know is connected. It starts off with a nice review of the history of i2c (in TVs in the 1970's!), goes into the history of how in the original Pi both buses were on the GPIO but when the Pi2 came out the bus 1 i2c got put on the bus 0 GPIO pins and bus 0 was sent to two other connectors. He even knows something about i2c0 being present on GPIO 28 and 29. Unfortunately, after that it becomes unclear to me; he describes his solution which is to use a C library to reprogram the BCM2835 processor to send the i2c0 signals to GPIO 28 and 29. Here is the link in hopes that this will become clearer with a little bit more research: https://martin-jones.com/2013/08/20/how-to-get-the-second-raspberry-pi-i2c-bus-to-work/

Here is an article which completely rewrites the above article in an easier to read how-to step-by-step format. It also discusses "WiringPi" which is mentioned in earlier links also:
https://xdevs.com/article/adding-i2c0-port-raspberry-pi-b-rev-20/

iPhone links:

awesome tutorial on enabling and using spi and both i2c busses. Goes over all of the same info but in tne easiest possible step-by-step format. Uses raspi-config to enable things, which is probably the best way. Goes over how to enable and use i2c0 as if it was easy:

https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial

Adafruit's tutorial on enabling the i2c. From the closest source possible and in the usual nice educational format except that it is only concerned with bus i2c1 and glosses over what happened to i2c0.

https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/configuring-i2c

how to download noobs onto sd card:

https://www.raspberrypi.org/documentation/installation/noobs.md


The google search for raspberry pi i2c install which seems to have a lot of good hits:
https://www.google.com/search?q=raspberry+pi+i2c+install&rlz=1CDGOYI_enUS705US706&oq=raspberry+pi+i2c+ins&aqs=chrome.1.69i57j0l3.17044j0j8&hl=en-US&sourceid=chrome-mobile&ie=UTF-8


The incredible link for the page published before the backlight driver had been added to Raspbian, where the driver chip gor the backlight is identified and traces are cut and wires added to the display board so that the backlight enable can be controlled from a gpio. All to hide the grub loader, apparently. I originally hoped that this link would aid me in figuring out how to send commands to the ATTiny88 once I got the ability to address it directly, but now I'm beginning to like this as a final solution to tbe difficulties in turning off the backlight when ignore_lcd=1.

www.raspberry-projects.com/pi/pi-hardware/raspberry-pi-touch-display/backlight-control


An interesting forum thread where somebody is trying to control what seems to be the rpi backlight and having trouble. This link needs to be further reread to find out if the OP is doing something I might be interested in trying, what the stuff mixed in for screen "blanking" is all about and whether it's useful to me, and also whether this is really all about the 7" touch screen or something wlse:

also why he is using 4 to write to the mailbox, and if the problem got solved in the kernel.

https://github.com/raspberrypi/linux/issues/1179


A github page with what might be source code for the backlight control! Also, one of the early clues that there was a self-contained overlay for the backlight:

https://github.com/raspberrypi/linux/pull/1173/files

Note that the conversation section seems to indicate that what this code is for is setting up the mailbox, and the GPU (Graphics Processor Unit?) firmware is needed to process the mailbox request. The conversation has lots of other potentially useful info in it too:

https://github.com/raspberrypi/linux/pull/1173


Here is the raspberry pi documentation for Device Tree overlays that gives the name of the rpi-backlight overlay! I added it as a dtparam in my config.txt file and it caused the pi to create the mailboxes at boot ti
e but writing to them had no effect if I also had ignore_lcd=1. In any case, this guide os probably the clearest that I have yet encountered on the subject of Device Tree.

https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README


The above couple of links were found due to the following Google search:

https://www.google.com/search?q=raspberry+pi+touchscreen+backlight+github&rlz=1CDGOYI_enUS705US706&oq=raspberry+pi+touchscreen+backlight+github&aqs=chrome..69i57.36459j0j9&hl=en-US&sourceid=chrome-mobile&ie=UTF-8

Also note that this search produces more info about i2c setup options from the perspective of Device Tree that might be useful:

https://www.google.com/search?rlz=1CDGOYI_enUS705US706&hl=en-US&ei=PaT3V5WOM8nZjwTYuZXQCA&q=dtoverlay+i2c0&oq=dtoverlay+i2c0&gs_l=mobile-gws-serp.3..33i160k1l2.29604.48539.0.49276.49.43.6.6.6.0.410.6204.10j27j3j2j1.43.0....0...1.1.64.mobile-gws-serp..19.25.2445.3..0j41j0i67k1j0i131k1j0i10k1j0i13k1.drZTiGGdGG0


Here is an online discussion with the developers at the time that the backlight control overlay got added. There is an explanation of why the GPU has to do the backlight controlling (I think because the same i2c bus is used for a camera also), and then some discussion where interested users are having trouble getting the update.

https://www.raspberrypi.org/forums/viewtopic.php?f=45&t=120296

Here is the datasheet for the ATTiny88. The chip has massive functionality so it is not clear why it is being wasted controlling a single on/off line for the backlight driver. It's also clear that I won't easily be able to figure out how to control just that one line over the i2c without some hints:

www.atmel.com/images/doc8008.pdf

raspberry pi 3 switch between touchscreen and hdmi

Research into running a touch screen and an external monitor either at the same time or switchable between them.

Bottom line: With Raspian you can't run two screens at once, and can't hot-switch screens. However, it is possible to tweak configuration files such that the Pi comes up using the desired screen after a reboot, basically the same solution that I used with the Beagle Bone. The configuration files to tweak are different though.

Links:

Here's the google search: https://www.google.com/#q=raspberry+pi+switch+between+touchscreen+and+hdmi

This thread contains some hints about using the "tvservice" function as I've seen in other forum answers, but as I've also seen on forum threads some users have reported that trying it trashed their OS installation. The OP for this forum thread ended up just living with fully removing power from his touch screen when he wanted to use the external monitor, which would be a desperation-only solution for my application: http://raspberrypi.stackexchange.com/questions/41417/how-can-i-switch-between-a-built-in-display-and-hdmi

Here is the thread with the answer, which is to add "ignore_lcd=1" to /boot/config.txt and rebooting when wanting to use HDMI rather than the touchscreen. To go back to the LCD, remove that line. The way I did this on the BeagleBone was to have two versions of the file, and a little shell script that copies the desired one over top of the last configuration file to set up for the next reboot. Interestingly, another commenter on this thread mentions that something called PINN appears to make hot-swapping screens work as I would want. I need to investigate this further: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=147962

Here's the same answer about "ignore_lcd=1" on a forum thread where somebody who tried something slightly different in config.txt was wrong: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=121591#p846271

Here's the same information in reverse, in some of Adafruit's documentation on a github page where the process for enabling the display with "ignore_lcd=0" in the config.txt file: https://github.com/raspberrypi/documentation/tree/master/hardware/display

Here's a crazy looking answer which apparently involves killing and restarting the xservice (and checking that tvservice is running? Not clear yet). This is another viewpoint of the answers that I saw concerning tvservice I think. http://raspberrypi.stackexchange.com/questions/39960/touchscreen-w-hdmi-output-only-when-a-display-is-attached

The suggestion above also points to the amazingly long and technically detailed online discussion of how to get both a TFT and HDMI working simultaneously, the thing some other forum threads claim is not possible. Lots of uses of tvservice. Here's the link from the thread above which links to page 2 of the thread at a photo proving that it has been done. It's not clear if any of this applies to the 7-inch touch screen but this is clearly the master class: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=91764&start=25#p661085

Another difference between the BeagleBone and the pi seems to be in how the /boot partition is mounted. It's still, oddly enough, an FAT partition on the SD card just like for BeagleBone, but for the Pi it has only root write permissions, making swapping the config.txt files around initially impossible either manually or by shell script. The solution was to edit the /etc/fstab file to change the permissions assigned to the entire partition at time of mounting by adding umask=0. The result is a little ungainly in that from experimenting with it I had to set the executable permission as well as the write permission for group and other, which oddly makes every file in the partition executable not just the directories. I can live with that though. Here are a bunch of links on how to do it:

Here's a very nice article that describes all the fstab parameters: http://www.omaroid.com/fstab-permission-masks-explained/

Half of the articles on the subject of fstab concern how to set it up to provide the desired user access to USB sticks, like this page: http://www.techjawab.com/2013/06/how-to-setup-mount-auto-mount-usb-hard.html

The other half of the articles are about setting up NAS, like this one. However, this also has, down in the comments, the solution to the all files executable problem in that instead of using umask, it's possible to use dmask and fmask to set permissions for directories and files separately! Another comment explains how FAT partitions are different and ideas on how to mount them differently. https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=40402

Having implemented the solution of having two versions of /boot/config.txt and swapping them as needed, I discovered that unlike on the BeagleBone, the backlight does not turn off on the touch screen when booting to the HDMI, leaving a pulsing random pattern on the screen. Not a bad reminder to switch back to the LCD when done, but not aesthetic looking. Is it possible to turn off the backlight when not configured to use the LCD? A whole lot of additional research ensued.

The problem comes from when setting ignore_lcd=1 in config.txt, the mailbox directories in /dev for the backlight controls aren't being set up during boot. Clearly the software module that reads the mailboxes and sets the appropriate control lines in the display is not being loaded.

I looked into what the i2c chip is that is being used to control the backlight and if it would be possible to directly access it. Here are some links:

I also did yet another review of how to load drivers in Device Tree, and was able to learn that the backlight has its own Device Tree driver, and get it to load such that it created the mailboxes on boot, but then writing to the mailboxes did nothing (maybe because the part that services the mailboxes is maybe in other drivers for the display or something).

Here are some links from people that want to use the i2c0 bus for HATs or other add-ons. The people writing these articles are pretty clear on how the i2c0 bus has been subordinated for use on the display connector, and just want to take it back. My thought was that there might be clues here for how to get the bus enabled so that I could get a successful scan of the ATTiny88 chip using i2cdetect as the first step to writing some kind of utility to directly program the output of the chip to turn the backlight off.

Here is a forum thread where the answer is to add "dtparam=i2c_vc=on" to config.txt. It didn't work for me, but that may be because I failed to do the other thing that I see also recommended, which is to add "bcm2708.vc_i2c_override=1" to cmdline.txt. In any case, the person who asked the question in this thread did both things and it didn't seem to work for him: http://stackoverflow.com/questions/32021924/raspberry-pi-2-cannot-enable-dev-i2c-0

Here is a thread from around 2016 specific to the previous release of Raspbian ("Wheezy", it is apparently now "Jessie") in which somebody is trying to enable the i2c0 bus. The hints of adding the kernel parm bcm2708.vc_i2c_override=1 to /boot/cmdline.txt and dtparam=i2c_vc=on to /boot/config.txt are discussed, plus the OP has added a few other interesting dtparam lines to his config.txt file. The OP is encouraged to open a ticket on the problem, and it seems like some discussion takes place on the ticket. Somebody else mentions how the i2c0 bus goes to two sets of pins simultaneously, although his description of why that would be a problem isn't in synch with what I've read elsewhere; he had some commands to execute that he says fixes it. Then the OP says that his problem is solved by a "firmware update" which doesn't exactly make sense. Somebody else joins the thread with a slightly similar problem, in that they want to use the i2c on GPIOs 28 and 29. Apparently the solution is to somehow disable the bus on GPIOs 1 & 0, and somebody proposes making a Device Tree overlay to do it. There is some other "Master Class" discussion further down:
https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=102130

The above forum thread has a link to this other forum thread where somebody is trying to get both i2c busses running. He has i2cdetect -y 0 working, but his devices on the bus are not detected. He's got all the modules loading, and has installed i2c-tools. He made sure that the bcm2708 drivers are not blacklisted and added some dtparam statements to his config.txt file. Somebody comments that there is a reason not to edit config.txt directly but I don't get it and in my previous edits for enabling or ignoring the LCD my edits seem to work. However apparently there is a configuration editor and it might produce live results without the need for rebooting. The forum thread dies without an answer apparently being found, but it is notable that the OP uses GPIOs 27 & 28 instead of 28 & 29, and the GPIOs don't have external pull-up resistors so some may need to be added. Again, it doesn't seem like this is going the right direction for me since I know that the ATTiny88 is being controlled fine by i2c0 already, but this thread still seems to have useful info.
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=115709&p=789932&hilit=i2c0#p789932

This thoughtful and measured article, entitled "How to get the second i2c bus to work" seems to describe the problems encountered by many others in forum threads, where they've gotten the bus to scan using i2cdetect but aren't reading any of their hardware that they know is connected. It starts off with a nice review of the history of i2c (in TVs in the 1970's!), goes into the history of how in the original Pi both buses were on the GPIO but when the Pi2 came out the bus 1 i2c got put on the bus 0 GPIO pins and bus 0 was sent to two other connectors. He even knows something about i2c0 being present on GPIO 28 and 29. Unfortunately, after that it becomes unclear to me; he describes his solution which is to use a C library to reprogram the BCM2835 processor to send the i2c0 signals to GPIO 28 and 29. Here is the link in hopes that this will become clearer with a little bit more research: https://martin-jones.com/2013/08/20/how-to-get-the-second-raspberry-pi-i2c-bus-to-work/

Here is an article which completely rewrites the above article in an easier to read how-to step-by-step format. It also discusses "WiringPi" which is mentioned in earlier links also:
https://xdevs.com/article/adding-i2c0-port-raspberry-pi-b-rev-20/

iPhone links:

awesome tutorial on enabling and using spi and both i2c busses. Goes over all of the same info but in tne easiest possible step-by-step format. Uses raspi-config to enable things, which is probably the best way. Goes over how to enable and use i2c0 as if it was easy:

https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial

Adafruit's tutorial on enabling the i2c. From the closest source possible and in the usual nice educational format except that it is only concerned with bus i2c1 and glosses over what happened to i2c0.

https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/configuring-i2c

how to download noobs onto sd card:

https://www.raspberrypi.org/documentation/installation/noobs.md


The google search for raspberry pi i2c install which seems to have a lot of good hits:
https://www.google.com/search?q=raspberry+pi+i2c+install&rlz=1CDGOYI_enUS705US706&oq=raspberry+pi+i2c+ins&aqs=chrome.1.69i57j0l3.17044j0j8&hl=en-US&sourceid=chrome-mobile&ie=UTF-8


The incredible link for the page published before the backlight driver had been added to Raspbian, where the driver chip gor the backlight is identified and traces are cut and wires added to the display board so that the backlight enable can be controlled from a gpio. All to hide the grub loader, apparently. I originally hoped that this link would aid me in figuring out how to send commands to the ATTiny88 once I got the ability to address it directly, but now I'm beginning to like this as a final solution to tbe difficulties in turning off the backlight when ignore_lcd=1.

www.raspberry-projects.com/pi/pi-hardware/raspberry-pi-touch-display/backlight-control


An interesting forum thread where somebody is trying to control what seems to be the rpi backlight and having trouble. This link needs to be further reread to find out if the OP is doing something I might be interested in trying, what the stuff mixed in for screen "blanking" is all about and whether it's useful to me, and also whether this is really all about the 7" touch screen or something wlse:

also why he is using 4 to write to the mailbox, and if the problem got solved in the kernel.

https://github.com/raspberrypi/linux/issues/1179


A github page with what might be source code for the backlight control! Also, one of the early clues that there was a self-contained overlay for the backlight:

https://github.com/raspberrypi/linux/pull/1173/files

Note that the conversation section seems to indicate that what this code is for is setting up the mailbox, and the GPU (Graphics Processor Unit?) firmware is needed to process the mailbox request. The conversation has lots of other potentially useful info in it too:

https://github.com/raspberrypi/linux/pull/1173


Here is the raspberry pi documentation for Device Tree overlays that gives the name of the rpi-backlight overlay! I added it as a dtparam in my config.txt file and it caused the pi to create the mailboxes at boot ti
e but writing to them had no effect if I also had ignore_lcd=1. In any case, this guide os probably the clearest that I have yet encountered on the subject of Device Tree.

https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README


The above couple of links were found due to the following Google search:

https://www.google.com/search?q=raspberry+pi+touchscreen+backlight+github&rlz=1CDGOYI_enUS705US706&oq=raspberry+pi+touchscreen+backlight+github&aqs=chrome..69i57.36459j0j9&hl=en-US&sourceid=chrome-mobile&ie=UTF-8

Also note that this search produces more info about i2c setup options from the perspective of Device Tree that might be useful:

https://www.google.com/search?rlz=1CDGOYI_enUS705US706&hl=en-US&ei=PaT3V5WOM8nZjwTYuZXQCA&q=dtoverlay+i2c0&oq=dtoverlay+i2c0&gs_l=mobile-gws-serp.3..33i160k1l2.29604.48539.0.49276.49.43.6.6.6.0.410.6204.10j27j3j2j1.43.0....0...1.1.64.mobile-gws-serp..19.25.2445.3..0j41j0i67k1j0i131k1j0i10k1j0i13k1.drZTiGGdGG0


Here is an online discussion with the developers at the time that the backlight control overlay got added. There is an explanation of why the GPU has to do the backlight controlling (I think because the same i2c bus is used for a camera also), and then some discussion where interested users are having trouble getting the update.

https://www.raspberrypi.org/forums/viewtopic.php?f=45&t=120296