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
