stacksmashing / tamarin-firmware

GNU General Public License v3.0
432 stars 51 forks source link

DisplayPort mode ? *Not so much an issue #18

Open serbyxp opened 8 months ago

serbyxp commented 8 months ago

Kind of a different use case for this , but this project might work with something im researching to start developing, (I’m trying to get the screen mirroring via lightning to usb to work… but by tricking the tristar into thinking it’s a DisplayPort device)

Is there a CRC to toggle the tristar to display mode ? (I Didn’t see it in the code … first glance). If not I assume I can just add it to the CRC section and assign it a command to invoke it?

Note* I know that the lightning to USB adapter “Haywire” is a hardware device that I assume is converting some lightning pins to HDMI, I plan to deal with that in software… or combo hardware software.

(Trying to get opencv to connect to the iOS screen stream )

nezza commented 7 months ago

Hey, there's nothing yet in regards to any of the vide modes or so in the code, so feel free to add!

serbyxp commented 7 months ago

Hmm I sidetracked trying to do some stuff with The usbmuxd and I was looking at the iOS-go video streamer / qtime hack … still trying to wrap my head around what this is doing different then usbmuxd , ( clearly it’s a hardware implementation using a pico , I have a couple and some esp32s stm32s etc … but since I was going video I was going with an orangePi zero 2w I had laying around, which I guess I can implement this the same way on Linux and use its OTG port…

but initially what caught my attention was the fact that your emulating the cable itself, which had me thinking ( as my previous post mentioned).

From the usbmuxd it seems like it’s doing something similar by sending specific “CRC” (for lack of better term) codes, that tell the iOS device what “mode” to be in.

But then I started looking at the Airplay protocols and how it can establish the screen sharing over TCP I guess port 7100 (really seems I’m going out of scope from this project) Ref https://nto.github.io/AirPlay.html#screenmirroring-httprequests

But still the USBmuxd (atleast I haven’t stumbled on it yet) and where this keeps bringing me back to this repo is since this is working on the hardware level ( that your actually able to split the usb connections like a lightning to usb “hub”, even if it’s not physically broken out to 2 seperate ports, and were to handle this internally (for USB-HID controlled through software emulation) or even the way it is now… ?? Can you plug a keyboard and mouse into the USB port and the iOS device receiver auto detect it, or would a “CRC” need to be passed? … Either way what I figure even if the raw video isn’t established by “tricking” it to think it’s connected to a lightning to HDMI adapter, the lightning / usb connection could still establish the airplay protocol ( which does all the h264 encoding decoding and “serving” on the iOS device itself. then throughthe Lightning USB their is a means to establish “tethering” for the “eth” connection but all through the one cable or device , I’m pretty sure the Pico has an eth/lan controller build in to gpios that might be useful…

i think I got ahead of myself here lol… but if any information available, I don’t have one of those nice debugger middleman signal processor tools so i find all this type of data useful

thanks

** Im not familiar so much with the Pico as I am with the ESP32 … but if someone knows how to turn this into micropython … by mixing the C to Cpython then you could get a python terminal to play around with this…

serbyxp commented 7 months ago

I found this interesting… depending on how many of the PIO cores your using currently might have enough left over to modify this repo ( has up to 24 channels, using all the PIO cores) to just have enough channels for this use case… And would eliminate the need for external analyzer , if it can sample fast enough for this…

https://github.com/gusmanb/logicanalyzer/tree/master