Jump to content
PaulOBrien

Advent Vega kernel source code now available!

Recommended Posts

Audio seems to work but the receiving end seems to get a lot of static.

If you mean the audio is very noisy this may be due to the gain in the mic being too high. I'm fairly sure it's holding things open that would normally clip. Real simple example is if I ... I mean my son ... uses talking tom, it constantly thinks you're talking. The same would happen with video conferencing apps where they'd want to cut the audio to reserve bandwidth.

Share this post


Link to post
Share on other sites

Well, a new version... This one:

> Should fix the video recording problems

> Implemented several new "virtual" video sizes (handled by cropping from the next available larger size capture frame) - This includes 320x200, as needed by gTalk

> Implemented several extra video capture colorspaces. Hopefully, they will make compatible the camera with gTalk, etc,etc

> Several minor fixes...

Still pending to do:

>Power management. When USB resume problem is fixed, i will also implement the camera powerdown

Please try it, i didnt test gTalk myself yet. As always, compatibility reports with other camera programs are welcome!

Eduardo

uvc3.rar

uvc3-compiled.rar

Share this post


Link to post
Share on other sites

Please try it, i didnt test gTalk myself yet. As always, compatibility reports with other camera programs are welcome!

Eduardo

Just tested a couple of camera apps and they all seem to work just fine: ecamera, RetroCamera, Paper Camera (wow!) and of course the default camera app.

Only small thing is, eCamera didn't show the preview at first, but it looked like a bug within the app itself, cause after a FC (I tried to change a setting in the app) I reopened it and it worked straight away...

Magnificent job, all of you! :D

Share this post


Link to post
Share on other sites

[...]

Please try it, i didnt test gTalk myself yet. As always, compatibility reports with other camera programs are welcome!

Eduardo

Hi Eduardo, again great work from you and Kamil off course!

I've tried Google Goggles and it has worked once and took a picture successfully to analyze it. Most of the times it gives a FC. But it did work once here so I think you are on the right path to a working cam in gtalk... Sorry I'm not able to get logs but I wanted to suggest that goggles may have the same approach to the camera and could be handy in testing your libraries.

Thanks again!

edit:

I've just tested Fring and it does work. There are some minor things though because Fring works in portrait mode while videocalling. This results in a upside down video feed. Also the colors are very strange, sort of black and white feel with a lot of blue and some green tints.

But than again: Great work!!

Edited by lometje

Share this post


Link to post
Share on other sites

Excellent progress.

We now have fring working, so we at least have one video chat application available to us.

Gtalk has the same issue as before when receiving a video request, where it will connect with audio but no sound.

When placing a video call it FC's with the following log -

http://pastebin.com/ZQ4xhnNE

Apologies if this is a double post, I had already sent this post but it didn't appear to make it through, so I'm posting it again.

Cheers

Share this post


Link to post
Share on other sites

Excellent progress.

We now have fring working, so we at least have one video chat application available to us.

Gtalk has the same issue as before when receiving a video request, where it will connect with audio but no sound.

When placing a video call it FC's with the following log -

http://pastebin.com/ZQ4xhnNE

Apologies if this is a double post, I had already sent this post but it didn't appear to make it through, so I'm posting it again.

Cheers

Gtalk has a bug when try to make a call it crashes because of a resource location problem of out ringing tone. But when recives calls, it works. But camera is still not working while receiving video calls. Only black screen and on both sides. Probably bug in gtalk. Our talk.apk is for 3.1, we must try gtalk for 3.2.

Share this post


Link to post
Share on other sites

Done a little testing too.

Found that OOVOO current version 1.2 for cross platform video calling is very nearly there in that picture is working in good quality at both ends but the rotation is off and the same fault with a whistling sound is also happening. But this could be a very good alternative to gtalk if that is being a git to get going.

Tested Yahoo messenger video downloadable using below linksas no longer in market (one for messenger and the other for video plugin), Also worked quite well but video sent from the vega is rotated 90 degrees to the right. and whistling noise there too.

http://forum.xda-developers.com/attachment.php?attachmentid=580250&d=1303951606

http://forum.xda-developers.com/attachment.php?attachmentid=580251&d=1303951606

also tested Fring and gtalk with same results as posted by others.

Edited by rus52

Share this post


Link to post
Share on other sites

Gtalk has a bug when try to make a call it crashes because of a resource location problem of out ringing tone. But when recives calls, it works. But camera is still not working while receiving video calls. Only black screen and on both sides. Probably bug in gtalk. Our talk.apk is for 3.1, we must try gtalk for 3.2.

The problem with that is gtalk for 3.2 has a libtalk_jni.so file that's over 30MB big ??? (or it has in the builds I've looked at). We'd end up having to shift the partitions round again, or insist on a repartitioned SD card, which wouldn't be too popular. I had a go at trying it but I couldn't get it any further.

Using the updated Talk.apk and the original libtalk_jni.so file does seem to address the crashing on sending a vid request, but you just get a white screen when sending video and a black screen when receiving video.

Logcat shows the same -

E/CameraHardware( 96):Unable to lock the NativeWindow - Assuming NativeWindow became invalid

Edited by CoWPlagued

Share this post


Link to post
Share on other sites

Well, another version... We are now in the trial and error realm... There are no apparent bugs in the code, but still sometimes seems to fail due to the applications expecting special kirks on the libcamera... So i am trying to guess them...

1) Added some checks to avoid reconfiguring capture sizes if no changes detected... Some programs stop working otherwise... Reason is not clear at all, but the implemented behaviour seems to cure them..

2) Swapped U and V colorspace components. There is no documentation on the order of colorplanes in YUV mode in Android. So, as some of you told people were blue, i swapped them... At least, seems to cure google goggles...

Please, test it with all the apps you can. I have tried myself with several ones, and seems to be working.. But, we are in the trial and error mode, and there is no other way to be sure if we are improving or not

Regards,

Eduardo

uvc3.rar

uvc3-compiled.rar

Share this post


Link to post
Share on other sites

The problem with that is gtalk for 3.2 has a libtalk_jni.so file that's over 30MB big ??? (or it has in the builds I've looked at). We'd end up having to shift the partitions round again, or insist on a repartitioned SD card, which wouldn't be too popular. I had a go at trying it but I couldn't get it any further.

Using the updated Talk.apk and the original libtalk_jni.so file does seem to address the crashing on sending a vid request, but you just get a white screen when sending video and a black screen when receiving video.

Logcat shows the same -

E/CameraHardware( 96):Unable to lock the NativeWindow - Assuming NativeWindow became invalid

Regarding the 30mb lib, seems it was compiled with debug and rtti information, both useless under Android... That is the cause... The library itself is less than 3MB...

Share this post


Link to post
Share on other sites

It's working pretty well! Colors don't seem off anymore and google goggles is working perfect!. The only thing is when I use fring, the video feed is still mirrored.

edit: @BTatHome,

The thing is, Fring is used in portrait, so the video receiver gets an upside down stream. It is easy to see it yourself by installing fring and doing a test video call. You'll receive your own recorded message back from the fring test call service.

Edited by lometje

Share this post


Link to post
Share on other sites
The only thing is when I use fring, the video feed is still mirrored.
Mirroring of video feed from 2nd cameras for video call is pretty standard on phones. Supposed to be easier for the user to move the camera around to get image centered if the feed is mirrored :)

Share this post


Link to post
Share on other sites

Mirroring of video feed from 2nd cameras for video call is pretty standard on phones. Supposed to be easier for the user to move the camera around to get image centered if the feed is mirrored :)

Indeed, most apps have a flip camera button that seems to work fine, but I didn't notice one in fring, the image quality has always been poor in fring anyway and is only made worse by the larger screen.

Although I'd love to see the camera working fully and personally want Gtalk, I'm wondering if we're taking up too much of Eduardos time on this, and now we have it at a mostly stable point we should release some of his talent to look at the other kernel bugs like the USB removal issue and host/slave mode, and then come back to it later. Unless it'd be interrupting the flow so to speak :)

Share this post


Link to post
Share on other sites

One small symptom to add to the Fring story, Fring does have a flip camera button and it flips the small preview video box in the lower left corner. It does not however flips the stream that is 'recorded'. Hopefully this is info that helps, but off course there are more things like the USB issue.

Totally humble and in no way trying to say what needs to be done. Just sharing the things I'm encountering which may lead to an overall improvement.

I had the feeling that gtalk may not work with video because it can't flip the stream like fring can't (with exception of the preview).

Share this post


Link to post
Share on other sites

looking good, fring seems fine to me now, and other apps also seem to work well.

Still no go on Gtalk, a lot of

E/CameraHardware( 96): Unable to lock the NativeWindow - Assuming NativeWindow became invalid

Full log -

http://pastebin.com/f22iuBs9

Cheers

Well.. There is something very strange here.. Lets lokk at your log file..

> line55: libjingle is querying for the camera descriptions... Everything ok

> lines 56-117: The camera initialization stuff.. nothing strange here... This is the libcamera querying the USB cam to find the supported resolutions... also choosing the best preview and picture sizes based on framerate and resolution...

> line 118: libjingle is calling the libcamera to register video capture callbacks. Pretty standard. Until now, no problems

> line 119: libjingle enabling processing of frames in libcamera. No problems here

> line 130: libjingle querying for the camera orientation.

> line 131: libjingle setting the display orientation to match the camera orientation

> line 132: libjingle checking if the libcamera is streaming video. It is not and thats OK

> line 133: libjingle querying for the actual format being used to deliver the video frames by the libcamera to the app

> line 134: libjingle checking if the libcamera is streaming video. It is not and thats OK

> line 135: libjingle checking if the libcamera is streaming video. It is not and thats OK

> line 136: libjingle sets the window that must be used to display preview video.. no probs here

> line 137: libjingle is enabling the preview video! - From now on, we should get preview video on the screen :)

> line 138-200: All the internal stuff libcamera has to do to enable the video preview (enumerating formats, looking for the best match to the user requested one, reserving memory for the captured frames, etc,etc) ... It completed successfully

> line 201: Libjingle disabling video capture (but preview is kept enabled) -- Nothing strange here

> line 202,203,216-219,: The libcamera capture and preview thread.. a video fram was grabbed from the camera, but at line 219 , when trying to display the video preview, finds out that the window that has to be used to display preview (set at line 136) became invalid.. This is meaning a crash in the gtalk app .. This is the only possible explanation, as the window to be used for preview has been destroyed...

Lines 204-214 are key to finding out what is happening here... I am not sure ,as they are very criptic ...line 204 seems to be 2 lines in one.. perhaps an unrelated message from a weather widget... The 2nd fused line (starting at "ServiceThread" (it is a communication timeout!) i am not sure if it is related to gtalk or to the weather widget... Lines 205-215 seems to be gtalk processing some sort of response (either it could be ahandshake to the calling party, or a message from the window composer... not clear the exact meaning) ... lines 208-209 are also crytic, but "unregistering" sounds bad to me.. Specially if associated with the RemoteVideoChatAccessor... So, to me, seems gtalk itself is refusing to do the video chat ... It is actually very weird... The causes of this refusal are not clear at all.. It could be something missing from the libcamera side (perhaps the gtalk app needs an special video capture resolution, but the gtalk app could set any resolution it needs... seems to be using 640x480, but that is the default size the libcamera uses. libjingle never tried to set a capture resolution.. ) .. or perhaps, it is just gtalk that tried to negotiate a video chat with the calling party, and it failed , so it refused to do a video chat...

I have read that gtalk is very picky on the devices that it allows to do videochat... Hummm.. any ideas ? - Perhaps changing the default video capture/preview settings? - To what values? -- It would be nice to extract those settings from a device actually supporting video chat on gtalk ...

Any ideas?

Eduardo

Share this post


Link to post
Share on other sites

Lines 204-214 are key to finding out what is happening here... I am not sure ,as they are very criptic ...line 204 seems to be 2 lines in one.. perhaps an unrelated message from a weather widget... The 2nd fused line (starting at "ServiceThread" (it is a communication timeout!) i am not sure if it is related to gtalk or to the weather widget... Lines 205-215 seems to be gtalk processing some sort of response (either it could be ahandshake to the calling party, or a message from the window composer... not clear the exact meaning) ... lines 208-209 are also crytic, but "unregistering" sounds bad to me.. Specially if associated with the RemoteVideoChatAccessor... So, to me, seems gtalk itself is refusing to do the video chat ... It is actually very weird... The causes of this refusal are not clear at all.. It could be something missing from the libcamera side (perhaps the gtalk app needs an special video capture resolution, but the gtalk app could set any resolution it needs... seems to be using 640x480, but that is the default size the libcamera uses. libjingle never tried to set a capture resolution.. ) .. or perhaps, it is just gtalk that tried to negotiate a video chat with the calling party, and it failed , so it refused to do a video chat...

I have read that gtalk is very picky on the devices that it allows to do videochat... Hummm.. any ideas ? - Perhaps changing the default video capture/preview settings? - To what values? -- It would be nice to extract those settings from a device actually supporting video chat on gtalk ...

Any ideas?

Eduardo

I review smail of gtalk today. I think the problem is about ANativeWindow and SurfaceTexture compability. Gtalk does not use on screen preview instead it uses offdispay SurfaceTexure. The preview thread in the driver cannot lock SurfaceTexture and copy image on to it.

Share this post


Link to post
Share on other sites

I review smail of gtalk today. I think the problem is about ANativeWindow and SurfaceTexture compability. Gtalk does not use on screen preview instead it uses offdispay SurfaceTexure. The preview thread in the driver cannot lock SurfaceTexture and copy image on to it.

Looks interesting.

While I have them infront of me, I might as well post some bits from logs I have just incase they're usefull. I had a go at comparing with my phone, but it's also not working too well and they logs dont seem to be comparable.

We get a different set of errors when making a call -

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame: frameBuffer:0x40003000, len:153600

W/libjingle( 6373): Warning(lmimediaengine.cc:759): LmiTimer: Timer execution took 402.972000 ms: ptb=0x9f85a8, ptb->timer=0x680e58, callback=0x8116b230, data=0x67b6a0, debug=0x0

W/libjingle( 6373): Warning(lmimediaengine.cc:759): LmiSocketEngine: About to wait for sockets; 403.764000 ms elapsed since previous return from socket wait (403.762000 ms since previous socket engine execution completed).

E/NvAudioALSAStreamOut( 96): write: failed to snd_pcm_writei, -32, Broken pipe

D/CameraHardware( 96): CameraHardware::disableMsgType: 16

W/AudioFlinger( 96): RecordThread: buffer overflow

E/NvAudioALSAStreamOut( 96): write: failed to snd_pcm_writei, -32, Broken pipe

W/AudioFlinger( 96): write blocked for 216 msecs, 15 delayed writes, thread 0x35310

W/libjingle( 6373): Warning(lmimediaengine.cc:759): LmiSocketEngine: About to wait for sockets; 72.424000 ms elapsed since previous return from socket wait (72.420000 ms since previous socket engine execution completed).

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Got Raw frame (320x240) (buf:[email protected], len:153600)

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Copied frame to destination 0x0x40003000

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Queued buffer

E/CameraHardware( 96): Unable to lock the NativeWindow - Assuming NativeWindow became invalid

I also did a quick check with the older gtalk.apk when making a call just in case any of the errors were due to me still running that apart from it selecting a lower resolution here's the log in question

  1. D/V4L2Camera( 96): Selected format: (320 x 240), Fps: 15
  2. D/dalvikvm( 979): GC_CONCURRENT freed 3K, 8% free 6900K/7495K, paused 1ms+2ms
  3. I/V4L2Camera( 96): Cropping from origin: 0x0 - size: 320x240 (offset:0)
  4. I/V4L2Camera( 96): Actual format: (320 x 240), Fps: 15, pixfmt: 'YUYV', bytesperline: 640
  5. D/CameraHardware( 96): CameraHardware::startPreviewLocked: effective size: 320x240
  6. D/CameraHardware( 96): CameraHardware::initHeapLocked
  7. D/CameraHardware( 96): CameraHardware::initHeapLocked: preview size=320x240
  8. D/CameraHardware( 96): CameraHardware::initHeapLocked: picture size=1280x1024
  9. D/CameraHardware( 96): CameraHardware::initHeapLocked: video size=640x480
  10. D/CameraHardware( 96): CameraHardware::initHeapLocked: OK
  11. D/CameraHardware( 96): CameraHardware::startPreviewLocked: StartStreaming
  12. D/CameraHardware( 96): CameraHardware::startPreviewLocked - Setting preview window geometry of 0x4c9b0 to 320x240
  13. D/CameraHardware( 96): CameraHardware::startPreviewLocked: starting PreviewThread
  14. D/CameraHardware( 96): CameraHardware::startPreviewLocked: O - this:0x0x3ff90
  15. D/CameraHardware( 96): CameraHardware::previewThread: this=0x3ff90
  16. D/V4L2Camera( 96): V4L2Camera::GrabRawFrame: frameBuffer:0x400a3000, len:153600
  17. D/CameraHardware( 96): CameraHardware::disableMsgType: 16
  18. D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Got Raw frame (320x240) (buf:[email protected], len:153600)
  19. D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Copied frame to destination 0x0x400a3000
  20. D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Queued buffer
  21. E/CameraHardware( 96): Unable to lock the NativeWindow - Assuming NativeWindow became invalid

Share this post


Link to post
Share on other sites

I review smail of gtalk today. I think the problem is about ANativeWindow and SurfaceTexture compability. Gtalk does not use on screen preview instead it uses offdispay SurfaceTexure. The preview thread in the driver cannot lock SurfaceTexture and copy image on to it.

I think you could be right here.... GTalk is using , as you say, SurfaceTexture to get the preview frames (using dex2jar, convert the Talk.apk into Talk,jar, and then, using jd-gui you can get the "source" of the application)... The problem is that in the libcamera , we always get a NativeWindow. Probably, this nativewindow can both represent a window, or a texture... And, if it represents a texture, then we would need some function to be able to fill the data on it, but that function is not the ANativeWindow_lock() call we are using... it is probably another, not yet documented function introduced with HC... If this is the case, i think we won[t be able to fix it, not at least without a lot of effort and a huge amount of RE... I;d really prefer to fix the USB host mode instead, as there are sustitutes to the GTalk app, for example, Vtok allows to do GTalk video conferences without trouble...

Well, if anyone has a better idea, just tell!

Eduardo

Share this post


Link to post
Share on other sites

The problem is that in the libcamera , we always get a NativeWindow. Probably, this nativewindow can both represent a window, or a texture... And, if it represents a texture, then we would need some function to be able to fill the data on it, but that function is not the ANativeWindow_lock() call we are using... it is probably another, not yet documented function introduced with HC... If this is the case, i think we won[t be able to fix it, not at least without a lot of effort and a huge amount of RE...

....

Eduardo

There is only a header file SurfaceTexture and it seems it has not JNI part. (I think its pure java can be RE )SurfaceTexture costructor accepts textureid. It's a gl oes texture an only way to copy is to use glTexSubImage2D. Updating Surface texture is not with calling updateTexImage function so preview thread in native carema useless.

There is 2 problem that must me solved.

1. finding Textureid

2. how the updateTexImage function interacts with the native camera.(What is send to to camera as a displaysurface?)

Any way, as you say it not time to solve this. But i wrote as guide for future intentions.

And about usb host: I wonder why you prefer manuel switch to host mode by usin /sys/usb/host_mode . But otg driver must switch to hostmode during otg interrupt as saw it on

drivers/usb/otg.cpp.

Share this post


Link to post
Share on other sites

There is only a header file SurfaceTexture and it seems it has not JNI part. (I think its pure java can be RE )SurfaceTexture costructor accepts textureid. It's a gl oes texture an only way to copy is to use glTexSubImage2D. Updating Surface texture is not with calling updateTexImage function so preview thread in native carema useless.

There is 2 problem that must me solved.

1. finding Textureid

2. how the updateTexImage function interacts with the native camera.(What is send to to camera as a displaysurface?)

Any way, as you say it not time to solve this. But i wrote as guide for future intentions.

And about usb host: I wonder why you prefer manuel switch to host mode by usin /sys/usb/host_mode . But otg driver must switch to hostmode during otg interrupt as saw it on

drivers/usb/otg.cpp.

Regarding the SurfaceTexture.. I´ll try another approach... I guess that if the libcamera is receiving a NativeWindow representation of the texture (as it is), maybe the problem is that that special NativeWindow does not support an standard setBufferGeometry() operation (as we do right now to be sure preview fills the preview window), or it does not support the pixel format we are using. I have seen , in previous experiments, that usually setting unsupported sizes/pixelformats does not fail until we try to lock the surface.. So, perhaps, adding more severe checks at the time of preview format "negociation" between the NativeWindow and the libcamera preview thread will make sure we try to use a format/size that actually allows to lock the preview buffer... That's the idea, uill try it and report if it seemed to work...

Regarding USB OTG.. Unfortunately, Shuttle lacks the special OTG connector.. it uses a normal USB connector. OTG requires an extra signal (called CableID), and an special cable.. That extra signal is used to detect if the USB interface is in host or slave mode, based on the cable being plugged into the OTG connector). And the Tegra hardware uses that signal to switch between modes...As Shuttle decided not to use that OTG connector, we have no means to detect if we need to be in Host or slave mode... Host mode requires shuttle to provide power to the USB port, while USB slave does not. And that is a very big difference... So, the only way we can handle this situation is with a manual selection of the mode.

Tegra implements ways to override the Cable ID signals, that is why i modified the OTG driver .. so there is a way to use that override to force tegra into either host or slave mode... But if overriding the signal, Tegra does not trigger the mode change interrupt... If not using the OTG driver, (at least, until now), Tegra can't be switched between modes at runtime. Either Host or USB can be selected at startup, but no dynamic switching... But i could be wrong here .. But, at least, on my experiments, OTG was the only working way to do that dynamic switching thing...

Eduardo

Edited by ejtagle

Share this post


Link to post
Share on other sites

Lets try the last mod to the camera lib ... This time i have implemented a more aggresive format negociation for preview surfaces... Hopefully, this will make Gtalk work (not tested!) - Feedback on this last library version is welcome. Also, very welcome, the associated logs ... id really like to see the format negotiation (it is in the log) so we will know if there is any hope on making Gtalk work or not...

Feedback welcome !

Eduardo

PS: From now on, i will try to make USB host work... Camera library seems to be stable :D

uvc3.rar

uvc3-compiled.rar

Share this post


Link to post
Share on other sites

Lets try the last mod to the camera lib ... This time i have implemented a more aggresive format negociation for preview surfaces... Hopefully, this will make Gtalk work (not tested!) - Feedback on this last library version is welcome. Also, very welcome, the associated logs ... id really like to see the format negotiation (it is in the log) so we will know if there is any hope on making Gtalk work or not...

Feedback welcome !

Eduardo

PS: From now on, i will try to make USB host work... Camera library seems to be stable :D

Video screen on gTalk still black ... logs below of the session ..

http://pastebin.com/FALK7ArV

Many thanks

Cass

Share this post


Link to post
Share on other sites

Yes, I get the same issue.

D/CameraHardware( 96): CameraHardware::startPreviewLocked: StartStreaming

D/CameraHardware( 96): CameraHardware::setPreviewWindow - Negotiating preview format

D/CameraHardware( 96): CameraHardware::NegotiatePreviewFormat

D/CameraHardware( 96): Original geometry: 0x0, fmt:1

D/CameraHardware( 96): Trying to set preview window geometry to 320x240

D/CameraHardware( 96): TryPreviewWindowFormat: surface of (320 x 240) - fmt:0x1

D/CameraHardware( 96): Initially, surface changed geometry. Check if it is really usable

D/CameraHardware( 96): Able to adjust the preview geometry to match the preview size

I/CameraHardware( 96): Got surface params (0 x 0, fmt:1)

D/CameraHardware( 96): CameraHardware::startPreviewLocked: starting PreviewThread

D/CameraHardware( 96): CameraHardware::startPreviewLocked: O - this:0x0x49438

D/CameraHardware( 96): CameraHardware::previewThread: this=0x49438

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame: frameBuffer:0x40000000, len:153600

D/CameraHardware( 96): CameraHardware::disableMsgType: 16

I/ActivityManager( 134): Displayed com.google.android.talk/.videochat.VideoChatActivity: +673ms

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Got Raw frame (320x240) (buf:[email protected], len:153600)

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Copied frame to destination 0x0x40000000

D/V4L2Camera( 96): V4L2Camera::GrabRawFrame - Queued buffer

E/CameraHardware( 96): Unable to lock the NativeWindow - Assuming NativeWindow became invalid

D/CameraHardware( 96): previewThread OK

Other than the above issue with gtalk, everything else seems much the same. the main issues other than gtalk seem to be

Apps like oovoo although the preview colours are ok, the colours sent through the chat are off - orange appears blue.

Apps that take into account the orientation like oovoo and also Vtok have the orientation off, so even if you disable the auto rotate it still flips you on your side however you try and hold the tablet.

Edited by CoWPlagued

Share this post


Link to post
Share on other sites

Regarding the SurfaceTexture.. I´ll try another approach... I guess that if the libcamera is receiving a NativeWindow representation of the texture (as it is), maybe the problem is that that special NativeWindow does not support an standard setBufferGeometry() operation (as we do right now to be sure preview fills the preview window), or it does not support the pixel format we are using. I have seen , in previous experiments, that usually setting unsupported sizes/pixelformats does not fail until we try to lock the surface.. So, perhaps, adding more severe checks at the time of preview format "negociation" between the NativeWindow and the libcamera preview thread will make sure we try to use a format/size that actually allows to lock the preview buffer... That's the idea, uill try it and report if it seemed to work...

SurfaceTexture is en opengles texture not onscreen surface use in surfacefilinger so Nativewindow is useless. gltexsubimage2d ony way to fill it.

Regarding USB OTG.. Unfortunately, Shuttle lacks the special OTG connector.. it uses a normal USB connector. OTG requires an extra signal (called CableID), and an special cable.. That extra signal is used to detect if the USB interface is in host or slave mode, based on the cable being plugged into the OTG connector). And the Tegra hardware uses that signal to switch between modes...As Shuttle decided not to use that OTG connector, we have no means to detect if we need to be in Host or slave mode... Host mode requires shuttle to provide power to the USB port, while USB slave does not. And that is a very big difference... So, the only way we can handle this situation is with a manual selection of the mode.

Tegra implements ways to override the Cable ID signals, that is why i modified the OTG driver .. so there is a way to use that override to force tegra into either host or slave mode... But if overriding the signal, Tegra does not trigger the mode change interrupt... If not using the OTG driver, (at least, until now), Tegra can't be switched between modes at runtime. Either Host or USB can be selected at startup, but no dynamic switching... But i could be wrong here .. But, at least, on my experiments, OTG was the only working way to do that dynamic switching thing...

Eduardo

Thans for the info. I made a search for it. Ony microusb connectior can support otg. Anyway... I Notice something i the code while chaging to host mode you just chage the direction off Vbus register with

gpio_direction_input(SHUTTLE_USB0_VBUS );

I think the Vbus Gpio must be set 1 to enable Vbus(Voltage of bus)pin in usb socket. Like.

gpio_direction_output(SHUTTLE_USB0_VBUS, 1 );

I am wrong?

Or seting gpio pin input, sets pin low on a an active low input?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.