đŸ Archived View for gemini.ctrl-c.club âș ~ssb22 âș projector.gmi captured on 2024-07-09 at 04:35:04. Gemini links have been rewritten to link to archived content
âŹ ïž Previous capture (2023-03-20)
-=-=-=-=-=-=-
These notes are from 2017 and have not been tested more recently.âChanges to video websites, Raspberry Pi OS versions or projector models might mean they no longer work.
In 2017 I was asked to set up a mini projector to be controlled from an iPhone; Iâm posting these notes on how I did it in case they are useful (but usual disclaimers apply).
The iPhoneâs âscreen mirroringâ function worked only with an âApple TVâ not anybody elseâs.â(Update: since writing this, it has come to my attention that the product called âApple TVâ is not actually a television, but a set-top box, although it costs nearly as much as a new 32-inch television in UK 2020 prices.âApple have now also licensed their âAirPlayâ protocol for some high-end television manufacturers to support natively.)
The mini projector did not support AirPlay, only Miracast and its own wireless protocol, and physical HDMI.âIt was bought on offer from Maplin mail-order before they went into administration, for a user who needed a large âhands-freeâ display for physiotherapy instructional videos and wanted the option of putting them on the roomâs walls or ceiling as appropriate to the position.âIt was a Miroir MP50 DLP LED 854x480 (tripod mount is a ÂŒâ-20 UNC hole; power supply is 12V 2A 3.5mm OD 1.3mm ID +ve tip).âIn time the projector failed because the soldering between the power socket and its circuit board above is weak, but by this time the physiotherapy videos were no longer needed.
The MP50 projector *did* supply iOS software for its own wireless protocol, but this could play only videos that had already been downloaded to the âcamera rollâ, and Apple didnât make it particularly easy to do that without buying a computer that can run the latest version of iTunes.â(Telegram Messenger has an option to save video to camera roll, but youâll have to upload the video to the Telegram âcloudâ yourselfââbotsâ that download videos *for* you were blocked on iOS due to Appleâs worry that theyâll be used to infringe copyright.)âSome manufacturersâ Android-based devices (e.g. Xperia) could send any screen to the projector via Miracast, but that user wanted to control it from a stock iOS device (which couldnât send Miracast), so I had to do a rather more complex workaround.
The basic idea was to use Web Adjuster to assist the user as they browsed video sites, inserting extra links to play the videos on the projector.âI didnât have a spare wildcard domain for this Adjuster, so I went into the iPhoneâs Wi-Fi settings and told it to use a proxy when connected to the home access point.âBut I still needed a separate computer to run that proxy and control the projector.
We bought a Raspberry Pi Zero W with case, Raspbian 9 MicroSD, HDMI to Mini HDMI adaptor, and USB OTG adaptor for initial setup (I suggest finding an OTG adaptor that has a little cable between the USB and the MicroUSB end; I made the mistake of ordering the adaptors before the Zero W had arrived and not realising how cramped its two MicroUSB ports areâit took me some time to plug in both a power lead and the bulky non-cabled OTG adaptor Iâd bought).âIt was not necessary to buy GPIO headers and such.âThe mini projector had an auxiliary USB power output which was adequate for powering the Zero W (although there was no way of turning off the power without unplugging itâleaving it in would result in the Zero W continuing to be powered from the projectorâs internal battery).
To ensure the SD card would not be harmed by loss of power without proper shutdown, I made it run read-only.âI thinned down the Raspbian distribution by removing all the X11-related packages to leave a console-only setup (but had to keep dbus for omxplayer), and then disabled all swap space, replaced rsyslog with busybox-syslogd, put ,ro after the defaults in /etc/fstab, symlinked various directories in /var to /tmp (which I symlinked to /dev/shm), and set /boot/cmdline.txt to ro noswap fastboot.âI even removed DHCP and had systemd run my own script to set up the Wi-Fi with a static IP address using wpa_supplicant and ifconfig, but I found I had to temporarily remount / read-write or wpa_supplicant wouldnât run.â(I could remount it read-only half a second after wpa_supplicant started; I hope nobody cuts the power in that particular startup half-second.)âI also had to restore resolv.conf from the script, as in this configuration wpa_supplicant tended to symlink it to a non-existent file on startup.âWhile I was at writing a script, I removed fake-hwclock and added a simple date --set "$(nc -w 1 192.168.0.3 13)" where 192.168.0.3 is a machine I knew would be on and serving daytime on port 13 from openbsd-inetd.â(The Zero W had to know the date in case it did any SSL-certificate validity checks while fetching video streams.)
In order to have half a chance of playing Internet videos smoothly, we needed as much RAM as possible to be assigned to the GPU, so I set gpu_mem in config.txt to 384.â(I did try the maximum of 448, leaving only 64M for the system, but that made Raspbian 9 boot considerably slower because it had insufficient room for buffers.âYouâd have to use a Raspberry Pi 3 instead of a Zero W if you need much more GPU RAM.)âI used an existing Raspberry Pi 1 B+ (with a wired connection that was always on and running public services) for the Web Adjuster part, setting up an SSH key for it to be able to log in to the Zero W without password and run omxplayer -o hdmi with a video URL (I used tvservice --explicit='CEA 3 HDMI' for a 16:9 screen of 720x480, which was as near as the Pi could get to the projectorâs actual resolution of 854x480, and I used a simple killall omxplayer.bin for the stop control).âPerforming the Web handling on the other Pi meant we didnât have to take up RAM on the Zero W for proxying and adjusting instead of for graphics (the B+ on the other hand was configured with almost all RAM for the system and hardly any for graphicsâyou donât need much for fbterm and tmux); it also meant the phoneâs proxy settings didnât have to change when the Zero W was powered down, and a third advantage was that packets sent from the wired B+ somehow seemed to reach the reconfigured Zero W more reliably than did packets sent from other Wi-Fi clients on the network.
The proxy itself was a home-compiled version of nginx with ngx_http_proxy_connect_module, by default set to pass through all CONNECT and non-SSL traffic to the specified remote sites (and without logging), but with an exception for an imaginary new wildcard domain (non-SSL) which it passed to my Adjuster instead.âThis was faster than passing *all* traffic through the adjuster in real_proxy mode, and it saved worrying about intercepting SSL sites and having the phone accept fake certificates (and/or complications due to its having already seen Strict-Transport-Security headers for the sites); the user simply browsed an alternate version of the site at my imaginary domain if they wanted the extra links to play videos on the projector, or browsed the site at its original domain if they didnât.
To add the links for playing videos on the projector, I used Adjusterâs prominentNotice="htmlFilter" option with an htmlFilter set to a Python function that scanned the original site for certain regular expressions to identify final video URLs (these regexps will probably have to change from time to time at the whim of the video sites).âI also had to add some Javascript to headAppend for some sites, and had to use htmlUrl so the function could use youtube-dl --proxy="" -f best -g where appropriate.
The links to play and stop the videos pointed to URLs which I handled using an Adjuster extensions module that simply started an ssh process to run the above-mentioned commands on the Zero W (with careful shell quoting of video URLs); when the Zero W was switched off, these links simply did nothing.â(The extensions module was set to back-convert adjusted domains before sending them to the Zero W, because the Zero W wasnât using the proxy.)
I also set a normal GNU/Linux laptop to mirror its screen to the projector if plugged in via HDMI; this was simply a matter of using arandr to find a suitable xrandr command that overlays both screens, and putting this in an infinite loop (with sleep 5) in a script which I called .screenlayout/projector.sh and placed in .config/lxsession/LXDE/autostart (as the laptop was running LXDE), so that the xrandr command would be executed shortly after any HDMI cable is plugged in.âIdeally I should have used MiracleCast but, besides requiring a systemd upgrade, it would also be complex on that hardware to enable WiDi and WiFiâs wpa_supplicant simultaneously, and as the user primarily wanted to use the iPhone rather than the laptop I thought this was unlikely to be worth the extra effort.
All material © Silas S. Brown unless otherwise stated. AirPlay is a registered trademark of Apple Inc. Android is a trademark of Google LLC. Apple is a trademark of Apple Inc. Apple TV is a registered trademark owned by Apple Inc. HDMI is a trademark or registered trademark of HDMI Licensing LLC in the United States and other countries. iPhone is a trademark of Apple in some countries. Javascript is a trademark of Oracle Corporation in the US. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Miracast is a trademark of the Wi-Fi Alliance. Python is a trademark of the Python Software Foundation. Raspberry Pi is a trademark of the Raspberry Pi Foundation. Telegram is a trademark of Telegram Messenger LLP. Wi-Fi is a trademark of the Wi-Fi Alliance. Xperia is a trademark of Sony Ericsson Mobile Communications AB. Any other trademarks I mentioned without realising are trademarks of their respective holders.