So with the recent 85-qhyccd.rules update, I can run my qhy5LLM under indilb successfully,
When I tried to connect to it directly in Phd2 to use your suggestion, it can't find the camera. I suppose I should do some reading to see how this camera needs to be installed to make Phd2 happy as well as Kstars.
120 MM Skywatcher Esprit on Celestron CGX
ZWO ASI 224MC or QHY-5L-II-M for guiding
Nikon Z7 8256 x 5504, 35.9 x 23.9mm 4.34 um pixel size
Triad Ultra Quad Band Narrow Filter
1) Odroid-N2 Ubuntu-mate 20.04
2) StellarMate on RPI4 8G
3) KStars on Astroberry RPI3.
PHD2 does support a number of cameras on Linux without INDI, but not all. A number of them also require INDI. It really depends. Note that I don't mean to diss using INDI as your camera driver. I love INDI and have contributed a lot to the project over the last couple of years. I think it works extremely well most of the time.
Probably the biggest limitation of INDI currently is the frame rate. You can do hundreds of frames per second with a zwo with direct support. With INDI, it is probably around 30ish max. To be fair, you probably don't need that sort of frame rate for guiding, so this probably doesn't matter so much. It's more of a factor for planetary imaging. So I don't think its that relevant here.
One possible issue for guiding with an INDI driver that I was alluding to in a previous post would be how long it might take to download images to any clients before taking the next image. I don't think there is a huge difference, but I do believe that I have observed that there is a bit of a lag between frames when guiding with an INDI driver vs. directly connecting with PHD2. I think it is caused by downloading to all clients. This slows down guiding just a little, making it less responsive. I haven't done a scientific test, and I probably should do so, but I think it is the case, and it would make sense. Has anybody tried a side by side test where they recorded data? If not I could certainly try it.
The other issue is what I think was giving you trouble. If INDI is running the guide camera as well as everything else on the same remote computer, when you connect remotely from Ekos, it will pick up the guide camera also, even though you don't really want it to do so (at least I don't). Right now the best option for this (if you don't have the option of native support for your camera in PHD2) is just to not check "receive external guide frames." That way it won't try to download those frames and might speed things up a little.
To bring back an early discussion in this thread, I mentioned that KStars should be getting data from PHD2 no matter what. I just ran a test configuring my system in a different way, using PHD2 with an INDI driver. For some reason using this configuration, the star profile image is coming in fine, but some of the other data seems to be missing. When I connect it directly to PHD2 and don't use the INDI driver as I have been advocating in this thread, the data still comes in just fine as it always has for me. I will look into this. Something must have changed because last time I checked this worked perfectly in both configurations. But I didn't know about any change because I never use it that way. It is probably something simple.
Ok I just ran some tests to determine why this configuration that I just tried using an INDI driver failed to produce graphs in Ekos. Apparently it was because PHD2 didn't have the focal length information for my setup and was reporting the error in pixels instead of arc seconds. So Ekos didn't like that. I don't know if this is similar to anyone's issue who posted in this forum, as there were several folks who were stating that they didn't have graphs when using PHD2 as an external guider in this forum. But the solution is very simple. Just enter your focal length into PHD2. It is in the "Brain" under "Guiding."
Give it a shot. You should certainly have all graphs and the star profile image if you are using PHD2 whether it uses an INDI driver or if it is directly connected as I have been recommending.
I will investigate to see if we could fix this so that in the future, we could report the error in pixels like PHD2 does for this sort of situation, or if maybe we could get the information from the INDI connected equipment to convert the reported error from PHD2 to arc seconds in Ekos.