Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eyetoy Support #30

Open
seta-san opened this issue May 3, 2020 · 106 comments
Open

Eyetoy Support #30

seta-san opened this issue May 3, 2020 · 106 comments

Comments

@seta-san
Copy link

seta-san commented May 3, 2020

i see there is at least some preliminary support for eyetoy in the code even if it isn't active. is there plans to make that available?

@SlyCooperReloadCoded
Copy link

Yes, please. No one seems to have attempted to get into EyeToy emulation, but all EyeToy titles would most likely jump directly to the Playable category if there was full EyeToy emulation. It's just a camera, it can't be that hard, right? Heck, the EyeToy can be used as a PC webcam.

@Florin9doi
Copy link
Contributor

Florin9doi commented May 27, 2020

Notes:

  1. The develop branch (and others?) has a issue: it reorders the endpoints and descriptors:
    wheelErr

Patch 1: try to resolve it but SuperSpeed endpoints are disabled: usb_desc1.txt. Untested
Patch 2: avoid the issue only for EyeToy: eyetoy.txt. This patch also clears a reserved bit from bmAttributes which is not present in a hardware device.

  1. The Windows and linux (a windows clone) drivers are configuring the camera to transfer jpeg pictures.
    PS2, or at least EyeToyPlay(1), is using a different format/compression. Immediately after OV header, partially documented by the linux driver, it sends an additional constant header: 69 70 75 6D 00 00 00 00 40 01 F0 00 01 00 00 00 and then compressed(?) data.

  2. EyeToyPlay(1)(SCES_515.13) and his OV driver are unstripped.

@jackun
Copy link
Owner

jackun commented May 27, 2020

it reorders the endpoints and descriptors:

Is there any difference? Seemed to "work" anyway.

@Florin9doi
Copy link
Contributor

Is there any difference? Seemed to "work" anyway.

I haven't seen any difference. It is getting stuck the same

@Florin9doi
Copy link
Contributor

Florin9doi commented May 28, 2020

  1. At the bytes [5:8] from header: ff ff ff 50 00 [ef bb ba bc] 00 01 00 00 00 14 00
    is present an little-endian increasing counter. Between SOP (ff ff ff 50) and EOP (ff ff ff 51) it increases with ~320k, and between EOP (ff ff ff 51) and SOP (ff ff ff 50) it increases with ~10k: counter.txt

@Florin9doi
Copy link
Contributor

Florin9doi commented May 31, 2020

  1. I modified the plugin to send a few frames captured from a hardware camera. The frames are received and then sent to the image processing unit (IPU) to decode them: ipu_decompressYCrCb(void *, void *, sceImage *, sceImage *, sceImage *), but the decoding fails and this message is observed in console: IPU1 running when IPU1 DMA disabled! CHCR 1 QWC 126. It seems that the PCSX2 decoding is bugged too.
  2. [69 70 75 6D](magic number) 00 00 00 00 [40 01](width) [F0 00](height) 01 00 00 00

@Florin9doi
Copy link
Contributor

EyeToy Kinetic Combat works with pre-recorded data 😛
Untitled

@jackun
Copy link
Owner

jackun commented May 31, 2020

So the data was still MJPG, just different header or some huffman compressed raw?

@Florin9doi
Copy link
Contributor

Florin9doi commented May 31, 2020

I have no idea yet. I saved the usb isoc packets using a linux test program. But because the decoder is already implemented in PCSX2 and not in game's driver, I think that it cannot be something very custom.
//LE: something MPEG with these tables:
snap3

@seta-san
Copy link
Author

seta-san commented May 31, 2020

Thank you guys for working g so hard on this. I think peripheral emulation is going to be one of the last biggest compatibility boosters!

I also have an eyetoy and singstar. If doing some sort of straight passthrough would help figure out what's the plugin issue and what's a core issue I'm here to test

@SlyCooperReloadCoded
Copy link

Yes, thank you. I'm looking forward to this, this is most likely the only thing keeping all the EyeToy games from immediately jumping to the Playable category.

@Florin9doi
Copy link
Contributor

Florin9doi commented Jun 9, 2020

@Florin9doi
Copy link
Contributor

Frames conversion works now: Florin9doi@85ffc3c
example: https://i.imgur.com/2MZJcEM.mp4

@seta-san
Copy link
Author

seta-san commented Jun 9, 2020

You guys are amazing

@jackun
Copy link
Owner

jackun commented Jun 9, 2020

Play 2 is still just green background and keeps spamming reg 0x71 which i don't remember what it was for

[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x01 (1)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)
[USBqemu] [eyetoy_handle_control]:360	*** WRITE reg 0x71 = 0x00 (0)

@Florin9doi
Copy link
Contributor

Florin9doi commented Jun 9, 2020

I know and I made a ticket @PCSX2/pcsx2#3432 but no reply so far.
The game receives the usb packets and send them to IPU for decoding, but the IPU fails.

@seta-san
Copy link
Author

The eye toy has a couple led lights on the front of it that it controls. Might it be trying to access those?

@jackun
Copy link
Owner

jackun commented Jun 10, 2020

Doh, it's the led.

@SlyCooperReloadCoded
Copy link

In this case, it's the misLED.

@seta-san
Copy link
Author

Play 2 is still just green background and keeps spamming reg 0x71 which i don't remember what it was for

so it's basically bitching at you for a brighter room

@Florin9doi
Copy link
Contributor

I pushed a new commit to capture video from a real webcam (v4l) but is noisy with many corrupted frames:
Screenshot_2020-06-13_18-23-22

https://github.com/Florin9doi/USBqemu-wheel/commits/eyetoy
Works only if the webcam supports native: 320x240/YUYV. No resize/format conversion.

@jackun
Copy link
Owner

jackun commented Jun 13, 2020

Extend/modify the API in videodev.h as needed as if this actually starts to work then the plan is to hide platform specific stuff in VideoDevice-inheriting classes.

Eyetoy v4l driver itself support YUYV? Keeps sending JPEG :D
I guess not

ioctl: VIDIOC_ENUM_FMT
	Type: Video Capture

	[0]: 'JPEG' (JFIF JPEG, compressed)

@Florin9doi
Copy link
Contributor

It doesn't. The frames should be decompressed.

@Florin9doi
Copy link
Contributor

Florin9doi commented Jun 17, 2020

I fixed the frames corruption and I added jpeg support for EyeToy cams:
Screenshot_2020-06-17_19-19-49

@Florin9doi
Copy link
Contributor

Florin9doi commented Jun 17, 2020

What's left :

  • check if the image should be mirrored ?
  • support for windows
  • speed and quality optimizations ?

@seta-san
Copy link
Author

What's left :

  • check if the image should be mirrored ?
  • support for windows
  • speed and quality optimizations ?

I can test on hardware to see if it needs to be mirrored. It might also be nice to have a working driver for the actual eyetoy on windows 10.

@Florin9doi
Copy link
Contributor

It might also be nice to have a working driver for the actual eyetoy on windows 10.

it works disabling testsigning, installing the old driver and enabling testsigning again

@seta-san
Copy link
Author

It might also be nice to have a working driver for the actual eyetoy on windows 10.

it works disabling testsigning, installing the old driver and enabling testsigning again

You mean driver signing?

@Florin9doi
Copy link
Contributor

yes

@seta-san
Copy link
Author

yes

Tried that

@SlyCooperReloadCoded
Copy link

Any progress on this? Still waiting for a fix for Antigrav. I also don't see the eyetoy branch anywhere.

@seta-san
Copy link
Author

Any progress on this? Still waiting for a fix for Antigrav. I also don't see the eyetoy branch anywhere.

The two active branches are master and develop. Eye toy support is there. The problem seems to be in pcsx2's ipu code around certain color spaces and no one seems terribly anxious to fix it.

@SlyCooperReloadCoded
Copy link

Dang, that's the only reason I wanted EyeToy support honestly. If knew anything about programming I'd look into it, but I couldn't script or program to save my life.

@Florin9doi
Copy link
Contributor

The problem seems to be in pcsx2's ipu code around certain color spaces

You have more information ?

@seta-san
Copy link
Author

The problem seems to be in pcsx2's ipu code around certain color spaces

You have more information ?

I made a patch that got eyetoy play to show a picture by activating the rgb functions. The picture is fucked up and because of that the game isn't playable.

@Florin9doi
Copy link
Contributor

where is the patch ?

@seta-san
Copy link
Author

I'll send it to you when I get home

@seta-san
Copy link
Author

Basically I sent the emulator from the ypbpr function to the rgb function

@seta-san
Copy link
Author

where is the patch ?

Again. This is the video of it "working"
https://www.youtube.com/watch?v=oW4YexlmuCM

@seta-san
Copy link
Author

i can't find the patch anymore. it's just a straight jump from 0015DE80 to 0015EB30 in Eyetoy Play NTSC.

All i'm doing is moving the game from this function.
ipu_decompressYCrCb__FPvPvP8sceImageP8sceImageP8sceImage

to this one.
ipu_decompressRGB__FPvPvP8sceImageP8sceImageP8sceImage
Untitled

@Florin9doi
Copy link
Contributor

Ok, I made a patch as you said for PAL :

Serial = SCES-51513
[patches = C0FCD1CE]
	// replace decompressYCrCb with decompressRGB
	patch=0,EE,0015cc80,word,16620033
[/patches]

The color issue is expected considering that it uses an incorrect function to decode the frames.
My observations are that:

  1. "IPU1 running when IPU1 DMA disabled" isn't observed while the patch is applied.
  2. ipu_decompressRGB function is 3 times shorter than ipu_decompressYCrCb : 0x1A8 bytes vs 0x4F4 bytes
  3. ipu_decompressRGB contains a single sceIpuSync call, but ipu_decompressYCrCb contains 6 sceIpuSync calls
  4. GameIndex.dbf contains a few sceIpuSync patches; sceIpuSync isn't properly emulated??

@seta-san
Copy link
Author

there's something there. the plugin IS sending the data. I have no idea why the emulator isn't doing anything with it.

@seta-san
Copy link
Author

i also found an eyetoy game that currently works and has debug symbols. it's Boboboubo Boubobo: Shuumare! Taikan Boubobo

https://wiki.pcsx2.net/Boboboubo_Boubobo:_Shuumare!_Taikan_Boubobo

@SlyCooperReloadCoded
Copy link

For some reason this no longer works on the latest PCSX2 builds, specifically the 1.7.0 dev builds. It detects my webcam like the 1.5.0 builds, but just gives this weird static color image instead of using the webcam:
https://imgur.com/a/p8gGeeS

@jackun
Copy link
Owner

jackun commented Oct 31, 2020

@SlyCooperReloadCoded just try opening/closing config dialog or pausing/resuming PCSX2. There's some weirdness with DShow currently.

@SlyCooperReloadCoded
Copy link

SlyCooperReloadCoded commented Oct 31, 2020

Also, where's the latest plugin in the develop branch? I tried downloading an artifact, but it wasn't detected as a plugin in PCSX2.

Edit: tried pausing, resuming, and messing with the config menu. Still getting that weird screen.

@jackun
Copy link
Owner

jackun commented Oct 31, 2020

FFS why can't you still trigger a branch build from appveyor ui, gaaah

@SlyCooperReloadCoded try these https://github.com/jackun/USBqemu-wheel/releases/tag/0.10.0-10

@SlyCooperReloadCoded
Copy link

Hm, that one doesn't have EyeToy. Isn't develop the branch with EyeToy?

@jackun
Copy link
Owner

jackun commented Oct 31, 2020

Uh? I have only 32bit version installed and that works fine so check that you actually selected USBqemu-wheel-0.10.0-Win32 or USBqemu-wheel-0.10.0-x64

@seta-san
Copy link
Author

0.10.0 release version has eyetoy in it but so do the master and develop branches. develop has the most up to date code in it and it works on 32 bit but crashes on 64bit

@SlyCooperReloadCoded
Copy link

I downloaded that develop version and EyeToy wasn't an option.

@seta-san
Copy link
Author

here's the latest develop builds for 32 and 64bit
USBqemu-wheel-0.10.0- OCT 31 2020.zip

@SlyCooperReloadCoded
Copy link

Not only did that work, but it also fixed the static color image and it now works fine.

Also, I found another game that doesn't work with it yet. The PS2 version of Harry Potter and the Prisoner of Azkaban has EyeToy minigames. Similar to AntiGrav, it doesn't detect input. However, it also doesn't detect that an EyeToy is even plugged in, probably for that reason.

@SlyCooperReloadCoded
Copy link

Kinda unrelated, but PCSX2 is slowly working on integrating its plugins into itself, meaning no plugin selector. They're working with the devs of another plugin that adds network and HDD support, but I hope this is getting integrated too.

@Florin9doi
Copy link
Contributor

OV519, register 0xA0 is setting the output format : 0x33=JPEG, 0x42=MPEG. Needed if we will support different formats.

			case VendorDeviceOutRequest | 0x1: //Write register
				switch (index)
				{
+					case 0xA0:
+						if (data[0] == 0x42)
+							Console.WriteLn("EyeToy : configured for MPEG format");
+						else if (data[0] == 0x33)
+							Console.WriteLn("EyeToy : configured for JPEG format; Unimplemented");
+						else
+							Console.WriteLn("EyeToy : configured for unknown format");
+						break;
					case R518_I2C_CTL:

OV7648, register 0x12, b6 (0x40) is setting the image mirroring. Now we always send a mirrored image, but some games ask for a straight image.

@@ -376,6 +403,14 @@ namespace usb_eyetoy
                                                        {
                                                                s->i2c_regs[reg] = val;
                                                        }
+                                                       if (reg == 0x12 && (val & 0x40))
+                                                               Console.WriteLn("EyeToy : mirroring ON");
+                                                       else if (reg == 0x12 && (val & 0x40) == 0)
+                                                               Console.WriteLn("EyeToy : mirroring OFF");
                                                }
                                                else if (s->regs[R518_I2C_CTL] == 0x03 && data[0] == 0x05)
                                                {

@jackun
Copy link
Owner

jackun commented Feb 20, 2021

Of course datasheet skips 0xA0 👹

@mirh
Copy link

mirh commented Sep 22, 2023

I'm going to assume MPEG might have been added after/while partnering with sony?
It is not mentioned whatsoever in the annoucement or datasheet of the bridge (only JPEG is ever highlighted), conversely you *can* find it in the press release and presentation of the eyetoy.

@Florin9doi
Copy link
Contributor

Florin9doi commented Sep 22, 2023

Omnivision have had webcam controllers with some kind of JPEG support previously: ov511 and ov518. I assume ov519 was developed together with Sony from the beginning (they also made PS3 and PS4 webcams together), but the MPEG support wasn't advertised because the format is customised to take advantage of the PS2's IPU hardware: it adds some special headers intended for decoder, unrelated to Mpeg. Additionally, it wouldn't make sense to reuse the same name for a different product.

I don't have any other ov519 webcam but it's something which may be tested on one of many other products with the same controller. It was used even by Microsoft for its Xbox Webcam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants
@Florin9doi @jackun @seta-san @mirh @prafullpcsx2 @SlyCooperReloadCoded @luke5416 and others