Advent Vega kernel source code now available!

[Guest ejtagle]

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

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?

Regarding NativeWindow, i was just trying. We have no function to convert NativeWindows to textures... At least, we have no informationn on such function (even, we don't know if it exists...) ..

Regarding USB, That is the way the .32 kernel worked. I have checked that. It is properly enabling and disabling VBUS as it is... probably they are using a fet driver with a pullup, so they dont need to explicitly set it to 1 (it wouldnt cause any harm if yopu do, but, as the .32 was doing this in this way...

[Guest ejtagle]

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:0@0x0x4025d000, 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.

If there are any programs where oranges are displayed as blues, or encoded as blues, i'd really appreciate the program name and the preview/ format that is using.. You can easily find them in the logs.. As PREVIEW: Size .... format... Fixing those is extremely easy, and it would help , as Android documentation is very lacking regarding the correct definition of color formats...

[Guest CoWPlagued]

If there are any programs where oranges are displayed as blues, or encoded as blues, i'd really appreciate the program name and the preview/ format that is using.. You can easily find them in the logs.. As PREVIEW: Size .... format... Fixing those is extremely easy, and it would help , as Android documentation is very lacking regarding the correct definition of color formats...

It looks like oovoo is using -

PREVIEW: Size 176x144, 10 fps, format: yuv420sp

[Guest d3rs7]

@Eduardo

Did you try to enable Vbus regulator. regulator_get(NULL, "avdd_usb"). and enable it. Its used by Vbus irq. And also some clock must be enable. There is redudant code in tegra_otg driver and usb_phy device i m not sure which one is but both otg and phy enable disable clock during switching.. Otg device has no clk defined( currently disable with define # 0)

And also noticed .vbus_irq is not set on tegra_usb_phy_pdata [0] if you set it regulator will be activated by irq. Only otg clock remains but which one?

But again tegra Otg dirver cannot switch to hostmode during irq because of ID pin. But in the gpio_vbus.c driver switches B(host) mode with a Vbus detection. You can try to add a device for it.

[Guest redscorpion]

Hi All,

I have some news about the camera and Gtalk...

It works!!! :-)

Not at 100%, because the captured video is "super green" and the Gtalk is still crashing at the outgoing call... but it's a progress... :-)

Have a nice day!

Kamil

precompiled libcamera:

libcamera.zip

and patched camera sources:

uvc3.zip

[Guest d3rs7]

Here's talk.akp outgoig call crash fixed.There is resource problem locating outgoing ring.ogg. Probably something about namespace but did find it. So i point resource to system nnotification sound. Out going call ring as system notification sound but no crash. i also set gtalk log level to a verbose so log cat will get more info. soon I 'll get to normal level.

Talk.zip

[Guest ejtagle]

Hi All,

I have some news about the camera and Gtalk...

It works!!! :-)

Not at 100%, because the captured video is "super green" and the Gtalk is still crashing at the outgoing call... but it's a progress... :-)

Have a nice day!

Kamil

precompiled libcamera:

libcamera.zip

and patched camera sources:

uvc3.zip

Superb, kamil, really excellent work! :D

[Guest redscorpion]

Superb, kamil, really excellent work! :D

Hi Eduardo,

thanks, but this is probably a hack...

look at this lines:

	GraphicBufferMapper& mapper = GraphicBufferMapper::get();

	status_t status = mapper.lock(buf->handle, GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN,  bounds, &vaddr);

but it should be:

  GraphicBufferMapper& mapper = ...

  status_t status = mapper.lock(buf->handle, buf->usage,  bounds,  &vaddr);

But if the buffer usage flags contains the GRALLOC_USAGE_HW_* flags then the returned vaddr is always NULL... :-( I'm not 100% sure but it can be because in this case the buffer is allocated in video memory and mapper is not able to map it to the virtual memory... :-( If it is true then I'm de facto reallocating buffer from video memory to the virtual memory.. and this is a hack, it works but there can be some side effects, like this "green video" in gtalk... We need to figure out how to write to the buffer which is allocated in video memory. We have access to the file descriptor which represents the buffer:

int fd = buf->handle->data[0];

buf I dont' know how to use it... I've tried the mmap but it doesn't work...

You are more skilled with this, so maybe you will find some way... :-)

Regards,

Kamil

[Guest CoWPlagued]

awesome work guys.

d3rs7 - the newer gtalk from 3.2 doesnt have the outgoing fc issue. ive been running it for a while without issue. im using our older libtalk_jni.so file as the newer one has been compuled with debug and is 30MB big rather than 3.

the colours are definately fun, techno cam. changes from purple to green.

keep up the good work.

Talk.zip

[Guest redscorpion]

Hi,

forget what I wrote... it seems that it's not so big hack... ;-)

I've found FGLWindowSurface implementation source code (http://gles6410.goog.../libsgl/egl.cpp) and they are working with the buffers in the same way...

Kamil

Edit: we are writing wrong data to the preview surface! we need to set the format for the native window according to the selected preview format in camera parameters (if it is supported, of course...) and then we can directly write this data to the buffer! additional conversion is not needed and gtalk works perfectly - green color is gone.. :-) I'll post modified camera sources tomorrow...

Edited September 11, 2011 by redscorpion

[Guest ejtagle]

-Attached my latest version... Compared to previous ones, i fixed a race condition in the stopping of the preview thread, that was causing lockups on the camera.

I also have observed. after upgrading to Vegacomb 8.1 from 7.0 that the video recording feature of the default camera application is causing a hard crash on the system. After lots of investigation, the problem seems to be that they are programming the libcamera to output instead of YUV data, metadata in the video buffers. Metadata is a way to, instead of copying video data, bypassing the video buffers and the camera should directly send the data to the OpenMAX video encoder. The main problem is that our libcamera is not supporting that, and the default camera application requires that feature... at some point, while using Vegacomb 7 , the video recording was working, but now, even with the same libcamera libraries that used to work, it doesnt work.. any ideas?

All the other apps should be working, except Gtalk.. Kamil seems to have found the solution for it... :D

Regards,

Eduardo

uvc3.rar

uvc3-compiled.rar

[Guest redscorpion]

Hi,

as I've promised, here is the version of the camera which should work perfectly with the Gtalk... :-)

Please test it and let me know if it works... currently I don't have access to the wifi... :-(

Regards,

Kamil

precompiled libcamera.so:

uvc3.zip

and source codes:

libcamera.zip

BWT: Eduardo, please check the conversion routine from the yuyv to yvu420, it produces weird result so I'm using different routine from my old sources... It's probably not possible to calculate U or V values as a average of values from current line and the next line...

Edit: Are you sure that the native color format from our camera is the YCrYCb and not the YCbYCr??? ;-)

Edited September 12, 2011 by redscorpion

[Guest lometje]

Hey Redscorpion,

Again great work!

I've just tested this with Fring and it works, although the colors aren't what they supposed to be. (It's black/white and greenish..)

Hopefully it's a useful comment,

Thnx!

edit: I believe with the last version from eduardo it worked, but it's no biggie :)

Edited September 12, 2011 by lometje

[Guest redscorpion]

Hey Redscorpion,

Again great work!

I've just tested this with Fring and it works, although the colors aren't what they supposed to be. (It's black/white and greenish..)

Hopefully it's a useful comment,

Thnx!

Hi lometje,

thanks for the testing :-)

Has it worked before? With the older camera? and with normal colors?

I'm asking because I've changed the default preview format from the yuv422sp to the yuv420p (which is used by Gtalk) to test the OpenGL accelerated conversion from the YUV to RGB :-) But this change can be easily reverted...

Regards,

Kamil

[Guest redscorpion]

Hi,

finally I've got an access to the wifi... :-)

And it seems that the Gtalk is crashing... :( but it is not related to my changes, because Gtalk is crashing also with the original libcamera from Eduardo... :-(

Kamil

[Guest redscorpion]

Hi,

I've build special GTalk camera version from my old sources... It's not supporting so much formats like Eduardo camera but the GTalk works! tested!!!

Kamil

libcamera.zip

[Guest CoWPlagued]

Hi,

I've build special GTalk camera version from my old sources... It's not supporting so much formats like Eduardo camera but the GTalk works! tested!!!

Kamil

you are a star.

Here's my log from Eduardo's camera to see if it shows anything useful.

http://pastebin.com/2Y3mThBz

[Guest ejtagle]

Well, i merged all the wonderful improvements Kamil made, including using YV12 as the default colorspace, also fixed several bugs in the colorspace conversion routines, and also added proper stride alignements for the new YV12 mode, that made retrocamera preview work as before.. All apps should be working, except the video recorder (requires to implement metadata storage in video capture buffers, and sending the captured video frames directly to the OpenMax encoder) - Anyone with enough experience with OpenMax ?

Attached the latest version of the lib. Very special thanks to Kamil, as the latest findings are all of his own investigations - Thanks, Kamil!! :D

As always, please test and report results..

Eduardo

uvc4.rar

uvc4-compiled.rar

[Guest CoWPlagued]

Well, i merged all the wonderful improvements Kamil made, including using YV12 as the default colorspace, also fixed several bugs in the colorspace conversion routines, and also added proper stride alignements for the new YV12 mode, that made retrocamera preview work as before.. All apps should be working, except the video recorder (requires to implement metadata storage in video capture buffers, and sending the captured video frames directly to the OpenMax encoder) - Anyone with enough experience with OpenMax ?

Attached the latest version of the lib. Very special thanks to Kamil, as the latest findings are all of his own investigations - Thanks, Kamil!! :D

As always, please test and report results..

Eduardo

Unfortunately still no go with Gtalk for me. Same error as before -

http://pastebin.com/sd8wLpQ9

oovoo is working fine (as with your previous camera) it just has the image 90 degree out, in landscape it's 90 degree out counter clockwise and in portrait it's 90 degree out clockwise

Also as a side note I noticed that we get

E/NvAudioALSAControl( 96): Control 'Mic Mute Switch' cannot get element info: -2

in gtalk (but not oovoo) so as expected you cannot mute the microphone.

Cheers

Just thought I'd add something quickly while I mentioned Microphone. The gain on the mic seems too high, there's a lot of background noise and it effects not just video conferencing but also voice commands and other apps (*cough ... talking tom .. *cough).

Is this a simple case of adjusting the values in the alc5624.c file?

Edited September 13, 2011 by CoWPlagued

[Guest dima_tr]

the video recorder (requires to implement metadata storage in video capture buffers, and sending the captured video frames directly to the OpenMax encoder) - Anyone with enough experience with OpenMax ?

Does not look to be too hard, although I had problems with NV OMX being stuck (H.264 decoding, hopefully not related to recording). Take https://github.com/m...r/demo_decode.c as the base, change all decoders to encoders and most probably swap loops (buffer_out_nb) (buffer_in_nb) in decode().

You can take a look at the EncodeVideo and Init logic in http://www.videolan....c/omxil/omxil.c . If you need an explicit library load - it is libnvomx.so. Here's another encoder example.

[Guest ejtagle]

Unfortunately still no go with Gtalk for me. Same error as before -

http://pastebin.com/sd8wLpQ9

oovoo is working fine (as with your previous camera) it just has the image 90 degree out, in landscape it's 90 degree out counter clockwise and in portrait it's 90 degree out clockwise

Also as a side note I noticed that we get

E/NvAudioALSAControl( 96): Control 'Mic Mute Switch' cannot get element info: -2

in gtalk (but not oovoo) so as expected you cannot mute the microphone.

Cheers

Just thought I'd add something quickly while I mentioned Microphone. The gain on the mic seems too high, there's a lot of background noise and it effects not just video conferencing but also voice commands and other apps (*cough ... talking tom .. *cough).

Is this a simple case of adjusting the values in the alc5624.c file?

... E/NvAudioALSAControl( 96): Control 'Mic Mute Switch' cannot get element info: -2 ...

In the ALC5624 codec driver, there are 2 mics... One of them is called MIC!, and the other MIC2. The Shuttle desgin uses Mic2 as the source. The control is called "Mic2 Mute Switch"... Seems the component NvAudioALSAControl took some shortcuts.. They HARCODED the control names instead of enumerating them (as it is expected from a normal application/library). Either we patch the NvAudioALSAControl, or we modify the ALC5624 codec, but, we would be polluting the alc codec source code...

.. The gain on the mic seems too high ...

I am not sure about this. It is very easy to reduce the mic gain but, if we reduce it, perhaps the mic will become "deaf" and won't have the required sensitivity.. With the ALSA tools, you can switch the mic gain from userspace... We can also reduce the default gain... But i am not sure ... mic , as it is , seems not to be sensitive enough...

... GTalk ...

Kamil is the person to ask.. He made it work in his library version... ;)

Thanks a lot,

Eduardo

[Guest ejtagle]

Does not look to be too hard, although I had problems with NV OMX being stuck (H.264 decoding, hopefully not related to recording). Take https://github.com/m...r/demo_decode.c as the base, change all decoders to encoders and most probably swap loops (buffer_out_nb) (buffer_in_nb) in decode().

You can take a look at the EncodeVideo and Init logic in http://www.videolan....c/omxil/omxil.c . If you need an explicit library load - it is libnvomx.so. Here's another encoder example.

Thanks a lot, of course i'll check them! ;)

[Guest CoWPlagued]

I am not sure about this. It is very easy to reduce the mic gain but, if we reduce it, perhaps the mic will become "deaf" and won't have the required sensitivity.. With the ALSA tools, you can switch the mic gain from userspace... We can also reduce the default gain... But i am not sure ... mic , as it is , seems not to be sensitive enough...

There's definitely something set a little high, whether it's some form of mic boost or record volume/gain or not I have no idea. I'll happily have a play about with settings, especially if there were some way of doing that without requiring a kernel recompile or something to that effect, as that's quite a way out of my comfort zone ;)

Looking at a few other threads, there does seem to be a fine balance between excessive background noise and mic volume, it would be nice to find the point where google voice commands doesn't just display a fully clipped wave, or apps like talking tom or video conferencing apps don't hold the mic open assuming someone is talking.

If there's already a way of playing with levels via ALSA would it be possible to implement something like the HD2 fix http://forum.xda-developers.com/showthread.php?t=1162224

thanks again.

[Guest ejtagle]

There's definitely something set a little high, whether it's some form of mic boost or record volume/gain or not I have no idea. I'll happily have a play about with settings, especially if there were some way of doing that without requiring a kernel recompile or something to that effect, as that's quite a way out of my comfort zone ;)

Looking at a few other threads, there does seem to be a fine balance between excessive background noise and mic volume, it would be nice to find the point where google voice commands doesn't just display a fully clipped wave, or apps like talking tom or video conferencing apps don't hold the mic open assuming someone is talking.

If there's already a way of playing with levels via ALSA would it be possible to implement something like the HD2 fix http://forum.xda-dev...d.php?t=1162224

thanks again.

Of course there is a way to control mic boost without recompiling.. The ALC codec driver exposes those settings as ALSA mixer controls to the user... Any ALSA mixer application could be used to change mixer settings, including mic boost settings ;)

<div><br></div><div>And, as a last resort, we could enable automatic mic level control ... The ALC supports it, but it tends to interfere with the ALSA mixer mic level settings...</div>

Edited September 13, 2011 by ejtagle

[Guest CoWPlagued]

Of course there is a way to control mic boost without recompiling.. The ALC codec driver exposes those settings as ALSA mixer controls to the user... Any ALSA mixer application could be used to change mixer settings, including mic boost settings ;)

cheers for your patience ;)

I had a quick look for a simple app, but the only one was Mixget and that didn't detect ALSA until a patch was applied and then it did nothing :) I might have another go later.

However what I noticed and I'd seen this before is that there's a rather large negative offset on the mic recordings. If you try making a recording with an app that shows the wave form such as TapeMachine lite, you will see a negative offset with the recording that I believe maybe part of the issue, as you need to be quite loud just to get the peak to hit the neutral line. A large offset like this is probably tripping the clip points in apps, so even if it levelling it didn't reduce the background noise, it might allow apps to clip it out and ignore it when you're not speaking.

There is of course a possibility I have a fault with my vega ;) I've got another one in a box I bought to mess about with and look into the yaffs bad sector issue, maybe I'll dig it out.