mrworf / photoframe

Software to pull random photos from Google Photos and show them, like a photo frame
GNU General Public License v3.0
221 stars 38 forks source link

Does scope include other platforms? #173

Closed dadr closed 3 years ago

dadr commented 3 years ago

Hi Henric,

First, thank you for sharing this software. It has brought a lot of joy to my family's life.

At this point I have 3 implementations: on RPi Zero W, RPi 3-B, and now ASUS CN60.

I'm writing this issue to explore your desire to support other platforms. My question arises because I am still working on extending the software to work with a low-end PC, an ASUS Chromebox CN60. This all came from a desire to use an old monitor I had lying around as a photoframe. The monitor is an HP LP3065. This is a very nice 30" IPS monitor, with 2560x1600 resolution. Unfortunately, it only has Dual-link DVI as inputs. Try as I might, I could not find a reasonable solution to connect a Raspberry Pi to a DL-DVI monitor. In fact, I could find no low end boards or computers that would support Dual Link DVI at all. Nor am I certain that anything less than a Pi 4 would support that resolution. The Chromebox I bought was just about the cheapest way I could go. It cost less than $40, and it has a DisplayPort for which I was able to find an adapter to connect to DL-DVI. (It also has a HDMI port that will do 4K UHD.)

So I blew away chrome OS (which was no longer supported on that box anyway) and I installed the Raspberry Pi Desktop: an x86 port of the Raspberry Pi OS. (Actually tried Lubuntu first, but I had too may problems getting photoframe to work with that OS) In any case - using your manual install instructions - I was able to get the photoframe service working in short order. Except it did not display any output.

It turns out that this was an incredibly easy hack^H^H^H fix. I changed line 304 in display.py from display = None to display = '/dev/fb0' Now photoframe believes I have an internal display and is happy to show pictures.

Then I started thinking about a "more proper" way to fix that code for my application. And this is why I'm writing. I'd prefer to keep getting the automatic updates and improvements to photoframe. As a first question, do you think it's reasonable for me to contribute back the changes I'm making, or do you think that this project is just for Raspberry Pi? If it's the latter, then I will probably just leave my PC version as a simple one-time hack.

I was wondering why you turn off the display when there is no monitor connected? (the line i changed) As far as I can tell, there is no hot plug code. I have tried plugging and unplugging HDMI on a Raspberry Pi, and it makes no difference to the software. Maybe my hack is not all that bad? I probably just don't understand your intent there.

If you were interested in accepting changes for other computers, then I would remove the hack and add a _pcdisplay method based largely on _internaldisplay. I've been poking around in the /sys/class/drm kernel interfaces and have found monitor mode, possible monitor modes, and enabled graphics ports. I could see how to add logic to allow selecting fb resolutions from this information, but it also seems logical to just pick the native resolution that the kernel chooses and go with that. I wonder how often users select other resolutions from that drop-down list?

I'm still looking for a good way to get the monitor to sleep and wake. I have trouble finding much documentation on the drm interface, but I suspect strongly that it's there somewhere. I've also considered just using rtcwake. it works great on the ASUS, but also sleeps the web interface.

I hope I can draw out your opinions on my many comments and questions. But most importantly, Thanks Again for sharing your work as FOSS.

Best Regards, Tom

mrworf commented 3 years ago

Hi Tom,

I'd love support for other platforms/systems. I haven't had a reason to explore this since I have too many RPis 🤣 . But already today it supports running in a desktop environment on Linux as headless in emulation mode (speeds up development).

So if you'd like to contribute to the project, I'd be more than happy to accept. Just do a PR and I'll have a look.

As for the behavior you mentioned, the software only scans for display on start, there's no run-time detection of displays (especially the internal one which is connected via the PINOUT and not hotpluggable). The code that detects and does proper handling of attached display via HDMI can probably stand a refactoring since it's very RPi specific.

The resolution selection is important though, since some displays (older and/or cheaper) may sometimes lie about their capability and trick the linux kernel to use a higher resolution than what the native panel supports (causing HW scaling in the panel). There's also been cases where the opposite happens or where it defaults to a VESA resolution instead of a HD resolution. Initially it wasn't possibly to change resolution but this was added since people ran into this issue.

For sleep, the current solution is very RPi specific, so I'd look at vbetool, specifically vbetool dpms on/off and see if you can utilize the VESA standard for power control of the attached display.

dadr commented 3 years ago

Thank you - that's good news. Also thanks for the suggestions and explanations.