Advent Vega kernel source code now available!

[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.

After some reading, yes... using OpenMax IL seems not to be a problem (there are lots of quirks to take into consideration...) ... But, the problem is the way NVidia did the passing of the video data frames to the h264 encoder. Usually, when using OpenMax, you open 2 ports... the input port that receives the raw unencoded video frames, and the output port that outputs the encoded video.

Nvidia implemented an extension called "OMX.google.android.index.storeMetaDataInBuffers" that is used to tell OpenMax to force the video encoder to reinterpret the data sent to the input port as a sort of metadata. There is no documentation on that extension and the exact format of the metadata, or at least, i was unable to find it... Id really like to be proven that i am wrong on this.. So, if some of you know where to find info on this extension, id really like to hear about that ! :D

That metadata tells the way to find, and where to find the actual video frame data... being the idea behind this to avoid copying video data... But, the problem is that there is absolutely no documentation on that extension... There are 2 places where that metadata is created (the closed source original libcamera) and the closed source implementation of OpenMax ... The OpenMax encoder itself should be able to use the data we are already providing, but libstagefright (the library handling the video recording) is forcing OpenMax to use that custom "OMX.google.android.index.storeMetaDataInBuffers" extension, without verifying if the libcamera component accepted or not to create metadata instead of regular captured video frames... That is the cause of the Openmax hard crash,,,

So, there are 2 possibilities here:

1) Patch libstagefright to skip that call so the OpenMax encoder is open in the regular way, without expecting metadata we can-t produce...

2) Reverse engineer the original libcamera to find out the format of the metadata, and where the captured video frames must be placed so the openMax encoder finds them ... This last option will be very hard to do...

Well, any other ideas besides those?

Eduardo

PD: Attached my latest versions of the libcamera library, I disabled support for the YV16 colorspace, that seems to be crashing Gtalk... (it is not a big deal, as Nvidia hw does not support YV16) .. Hope it will improve Gtalk support, but no promises. Regarding the video recording bug, i will address it by patching the libstagefright.so lib...

Trust me, it is hard to get Gtalk working and avoid losing compatibility with all the other programs at same time ;)

uvc4.rar

uvc4-compiled.rar

Edited September 14, 2011 by ejtagle

[Guest dima_tr]

Nvidia implemented an extension called "OMX.google.android.index.storeMetaDataInBuffers" that is used to tell OpenMax to force the video encoder to reinterpret the data sent to the input port as a sort of metadata. There is no documentation on that extension and the exact format of the metadata, or at least, i was unable to find it... Id really like to be proven that i am wrong on this.. So, if some of you know where to find info on this extension, id really like to hear about that ! :D

Hopefully this helps. At least not everything is in virtual methods, there's an implementation :)

Edit: wait! there's a method in Camera.h ; if we call it with "false" we do not need this metadata, do we?

   	// tell camera hal to store meta data or real YUV in video buffers.

   	status_t	storeMetaDataInBuffers(bool enabled);

This is called in libstagefright/CameraSource.cpp with "true", so hacking the libstagefright.so seems to be the right direction :)

(void)mCamera->storeMetaDataInBuffers(true);

Edited September 14, 2011 by dima_tr

[Guest CoWPlagued]

PD: Attached my latest versions of the libcamera library, I disabled support for the YV16 colorspace, that seems to be crashing Gtalk... (it is not a big deal, as Nvidia hw does not support YV16) .. Hope it will improve Gtalk support, but no promises. Regarding the video recording bug, i will address it by patching the libstagefright.so lib...

Trust me, it is hard to get Gtalk working and avoid losing compatibility with all the other programs at same time ;)

Still no go on Gtalk I'm afraid.

http://pastebin.com/zAZasBV6

Cheers.

[Guest ejtagle]

Hopefully this helps. At least not everything is in virtual methods, there's an implementation :)

Edit: wait! there's a method in Camera.h ; if we call it with "false" we do not need this metadata, do we?

   	// tell camera hal to store meta data or real YUV in video buffers.

   	status_t	storeMetaDataInBuffers(bool enabled);

This is called in libstagefright/CameraSource.cpp with "true", so hacking the libstagefright.so seems to be the right direction :)

(void)mCamera->storeMetaDataInBuffers(true);

You are right, but it wouldn't be enough... This fn call is calling the libcamera. We could easily ignore the storeMetaDataInBuffers() call.. If you check OMXCodec.cpp, part of the libstagefright library (even the froyo version.. the HC is not the same, but preliminary disassembly shows that the HC version is heavily based on it, check methods

status_t OMXCodec::allocateBuffersOnPort(OMX_U32 portIndex) ; ... There is avoids allocating buffers if using metadata, based on the flag mIsMetaDataStoredInVideoBuffers . And that flag is set in

status_t OMXCodec::configureCodec(const sp<MetaData> &meta, uint32_t flags);

using the "OMX.Nvidia.h264.encoder" as the key. So, everytime libstagefright uses h264 OMX encoder from Nvidia, it tries to use metadata. This can only happen with the camera, i guess. So, the most important function to patch is status_t OMXCodec::configureCodec(const sp<MetaData> &meta, uint32_t flags); . Preliminary disassembly of that fn shows that the HC version has nearly exactly the same code. And also shows that the string "OMX.Nvidia.h264.encoder" is used by that lonely function.. So, perhaps modifying that string could be an easy way to prove it... The other way is just to patch the status_t OMXCodec::configureCodec(const sp<MetaData> &meta, uint32_t flags); function not to set that flag ;) (As you see, the HC components have some hardcoded defaults ... That leads me into thinking this code has still to mature quite a bit before we can see an AOSP version of HC3.x ;) )

[Guest mrz_hun]

Hi Everyone!

Several people (including me) are experience touch screen issues. I'm pretty confident that it is not a hardware issue since for me, reflashing moddedstock v2, and running moduleap.apk app fixes this.

There's a topic on TabletRoms.com on the touch screen problem

I have read that Vegacomb recalibrates the screen upon each startup, but this appears to be ineffective, since I could not get my touchscreen working after fiddling around for around an hour (tried many-many reboots with and without the power attached, tried removing sd, rotating screen etc.etc. ;) )

I tried looking around many places before bringing this up here, and I also read that running moduleap.apk-s screen calibration has no effect in Vegacomb, since the corresponding functionality has been removed from the driver:

From Eduardo (ejtagle):

The IT7260 calibration app is a lost case. The interfaces that app was using to communicate with the ts were, not only dangerous, but very unstable and not standard at all. They were removed from the driver and i don't plan to port them,as they constitute a huge security hole. To recalibrate the TS, all that is needed is to write any value to the /sysfs/platform/devices// ... well, i promise to tell latel. I cant remember the exact location right now.

Is it possible that there is a bug in the recalibration functionality? Would it be possible to include he removed functions from the touchscreen driver so we wouldn't have to revert back to another ROM to recalibrate it with the app?

I'm not an android / linux expert, but I would be happy to help debug this problem.

[Guest ejtagle]

Hi Everyone!

Several people (including me) are experience touch screen issues. I'm pretty confident that it is not a hardware issue since for me, reflashing moddedstock v2, and running moduleap.apk app fixes this.

There's a topic on TabletRoms.com on the touch screen problem

I have read that Vegacomb recalibrates the screen upon each startup, but this appears to be ineffective, since I could not get my touchscreen working after fiddling around for around an hour (tried many-many reboots with and without the power attached, tried removing sd, rotating screen etc.etc. ;) )

I tried looking around many places before bringing this up here, and I also read that running moduleap.apk-s screen calibration has no effect in Vegacomb, since the corresponding functionality has been removed from the driver:

From Eduardo (ejtagle):

Is it possible that there is a bug in the recalibration functionality? Would it be possible to include he removed functions from the touchscreen driver so we wouldn't have to revert back to another ROM to recalibrate it with the app?

I'm not an android / linux expert, but I would be happy to help debug this problem.

In fact, the new IT7620 driver implements a new interface to recalibrate the touchscreen... It should be just an easy task to write an app to trigger a recalibration in a running kernel... But.. i will state an obviuos thing -- did you clean the touchscreen surface ? A window cleaner is all that should be needed.. The touchscreen controller of the IT is not the best one, and it is very susceptible to dust, dirt, and grease, that causes dead areas on the screen. If one of those agents is on the screen, or ANYTHING is near or over the screen, the selfcalibration WILL fail. This is something that is stated by the touchscreen manufacturer, not me... So, the first rule here is to clean the screen surface with some detergent, then wait until the surface dryes completely. And then turn the tablet on. Recalibration will only happen when rebooting. and it required an unobstruded, very clean surface ;)

[Guest mrz_hun]

What do you mean by the "new TI7260 driver"? Is it the one already in build 8.1 or is there a new one on the way?

So, the first rule here is to clean the screen surface with some detergent, then wait until the surface dryes completely. And then turn the tablet on. Recalibration will only happen when rebooting. and it required an unobstruded, very clean surface ;)

I tried cleaning it with a soft cloth many times when I had the issue, but I didn't try using a detergent. The screen 'looked' clean to me (ie. no fingerprints, dust, particles visible to the naked eye).

I didn't clean it thoroughly before recalibrating though, but the recalibration app still fixed it instantly.

Does recalibrating run only when rebooting, or from a cold start too?

Edited September 15, 2011 by mrz_hun

[Guest a_appleby]

In fact, the new IT7620 driver implements a new interface to recalibrate the touchscreen... It should be just an easy task to write an app to trigger a recalibration in a running kernel... But.. i will state an obviuos thing -- did you clean the touchscreen surface ? A window cleaner is all that should be needed.. The touchscreen controller of the IT is not the best one, and it is very susceptible to dust, dirt, and grease, that causes dead areas on the screen. If one of those agents is on the screen, or ANYTHING is near or over the screen, the selfcalibration WILL fail. This is something that is stated by the touchscreen manufacturer, not me... So, the first rule here is to clean the screen surface with some detergent, then wait until the surface dryes completely. And then turn the tablet on. Recalibration will only happen when rebooting. and it required an unobstruded, very clean surface ;)

It's not true, it still has dead areas. I just cleaned it with a window cleaner & grease removal and that was it. It's as clean as it can ever be, but it still has dead areas in the left side, in the middle top area.

The wavy lines in drawing apps are still there.

This was happening while running Vegacomb 3.2 build 8.1.

What do you mean by the "new TI7260 driver"? Is it the one already in build 8.1 or is there a new one on the way?

I tried cleaning it with a soft cloth many times when I had the issue, but I didn't try using a detergent. The screen 'looked' clean to me (ie. no fingerprints, dust, particles visible to the naked eye).

I didn't clean it thoroughly before recalibrating though, but the recalibration app still fixed it instantly.

Does recalibrating run only when rebooting, or from a cold start too?

It runs on every reboot by default, from what I understood.

Edited September 15, 2011 by a_appleby

[Guest ejtagle]

It's not true, it still has dead areas. I just cleaned it with a window cleaner & grease removal and that was it. It's as clean as it can ever be, but it still has dead areas in the left side, in the middle top area.

The wavy lines in drawing apps are still there.

This was happening while running Vegacomb 3.2 build 8.1.

It runs on every reboot by default, from what I understood.

The original .32 kernel triggered a recalibration everytime you pressed the "back" button... But it seems overkill to me... The new .36 kernel does not implement that. I even wonder why the .32 calibration app did anythng at all... For me this is becoming more and more a meta science.. There are no explanations on the causes of the problem... and there is no justification if something would ever fix it...

Edited September 15, 2011 by ejtagle

[Guest mrz_hun]

Maybe there was a reason for recalibrating on each back button press :huh: (like suddenly losing calibration...)

If the current recalibration procedure would work, then we would get our touchscreens back after a reboot, but unfortunately this is not the case. The only currently known way to get it working is by using moduleap in ModdedStock. Would it be possible to enable/implement the functionality triggered by that app in VC? It definitely works some magic to get our touchscreen back to working order, which is not happening during a reboot.

As I said before, I would be glad to help with testing.

(Since going back to Moddedstock and fixing my touchscreen this morning, then reflashing VC 8.1, the issue is back after a couple of hours of use... It's quite frustrating :()

[Guest ejtagle]

Maybe there was a reason for recalibrating on each back button press :huh: (like suddenly losing calibration...)

If the current recalibration procedure would work, then we would get our touchscreens back after a reboot, but unfortunately this is not the case. The only currently known way to get it working is by using moduleap in ModdedStock. Would it be possible to enable/implement the functionality triggered by that app in VC? It definitely works some magic to get our touchscreen back to working order, which is not happening during a reboot.

As I said before, I would be glad to help with testing.

(Since going back to Moddedstock and fixing my touchscreen this morning, then reflashing VC 8.1, the issue is back after a couple of hours of use... It's quite frustrating :()

The problem is that if we force recalibration at some point in time, and the user is touching the screen at that time, touchscreen fails to calibrate properly... Recalibration should not depend on the touchscreen to be launched... ;)

I even have doubts if it is good or not to recalibrate so often... For example, if calibration data is stored in an eeprom in the touchscreen controller, then we could run out of eeprom write cycles ... Manufacturer recommends NOT to calibrate the touchscreen, except for a first time in the manufacturing line... I don't know... Maybe write an android app to launch recalibration :S

And, thinking about it a bit more... Are we sure this is related to the touchscreen driver at all? -- I never had any of such issues with any of the HC versions... Before concluding it is a touchscreen driver issue, what about trying one of the Android touchscreen tests apps available from the market? -- If the app shows the touchscreen working on all the screen, they it could be something related with the android config itself...

Edited September 16, 2011 by ejtagle

[Guest mrz_hun]

Recalibration should not depend on the touchscreen to be launched... ;)

I could live with an app that has no UI but could be launched from adb :) (adb am -n ....).

So far I have been lucky, since the calibration app's button as wide as the screen, and I always had some touch functionality on the right 2-3cm of the screen, so I was always able to press it. (Launching the app was a bit of a challenge though ;) )

And, thinking about it a bit more... Are we sure this is related to the touchscreen driver at all? -- I never had any of such issues with any of the HC versions... Before concluding it is a touchscreen driver issue, what about trying one of the Android touchscreen tests apps available from the market? -- If the app shows the touchscreen working on all the screen, they it could be something related with the android config itself...

I understand this concern, and I agree that the root cause should be addressed not the symptoms. But until then, this workaround (which I hope is feasible) could be used at least until the underlying problem is discovered and solved.

[Guest richardmlea]

The problem is that if we force recalibration at some point in time, and the user is touching the screen at that time, touchscreen fails to calibrate properly... Recalibration should not depend on the touchscreen to be launched... ;)

Is this not the reason why the back button was used to recalibrate in previous kernal versions. If you are pressing the back button you can't be touching the screen.

maybe the eerom in some of the touch screen controllers is faulty or something is corrupting the stored information.

Maybe if someone intheknow has time to have a look at the screen calibration app and have a look if its doing anything different that the current one isn't doing.

I am convinced it must be a hardware issue because I, like you have never had any issue with my touch screen . I do have a plastic screen not a glass screen so thats maybe why I have never had any issue but I am not the only one that has not had any issues with the touchscreen.

[Guest ejtagle]

Is this not the reason why the back button was used to recalibrate in previous kernal versions. If you are pressing the back button you can't be touching the screen.

maybe the eerom in some of the touch screen controllers is faulty or something is corrupting the stored information.

Maybe if someone intheknow has time to have a look at the screen calibration app and have a look if its doing anything different that the current one isn't doing.

I am convinced it must be a hardware issue because I, like you have never had any issue with my touch screen . I do have a plastic screen not a glass screen so thats maybe why I have never had any issue but I am not the only one that has not had any issues with the touchscreen.

This is easy to test.. just try with one of the multitouch screen android test apps... I have myself some problems in the upper top of the screen.. but the touchscreen test app shows perfect touchscreen response. And there is another itneresting test to do: Rotate the device, and, if the nonworking touchscreen areas move, then it is Android, not the touchscreen linux kernel driver... To the linux kernel touchscreen , there is absolutely no change if using the device in portrait or landscape mode...

[Guest mrz_hun]

Rotate the device, and, if the nonworking touchscreen areas move, then it is Android, not the touchscreen linux kernel driver... To the linux kernel touchscreen , there is absolutely no change if using the device in portrait or landscape mode...

I tried the app call "Touch Test" it showed the problem irrespective of the screen orientation.

I might create a video of this if it happens again and upload it somewhere...

[Guest Alexzandro]

Hello everybody !

Wouldn' never want to hack this thread, but.... have two major questions to bring to attention:

1) In wifi advanced settings on VEGACOMB 8.1 we find frequencies range, i.e. 2.4 or 5 GHZ (or even automatic choice), do they really work or their choice is ineffective ? Moreover, is 5GHZ functionality as a N standard?

2) When ( I hope this will come true soon ) we will have USB fully working, what are your thoughts about giving Android world the first working program for DVB-T USB Stick ( and drivers ?).

Telling YOU ROCK really and my POV MOBII has only episodic browser crashes, nothing more than that and I am really very very happy with my choice, thanks to your efforts.

Regards

Alessandro

[Guest ejtagle]

Just an update on what i am working on:

-Accelerometer: Fixes so it is as responsive as in the .32 kernel: Done

-Dynamic USB host/device switching: Done

-USB cutting communication when device enters sleep: Done

I am not posting the patches, just because i have to do some extra tests to make sure they do work as expected in HC3.2 .... Right now i am testing with a busybox linux shell

Well, regarding camera, i am out of ideas... Seems that if we make the camera compatible with Gtalk, we lose compatibility with all the other apps. Or at least, that is what i can infer by using redscorpions libcamera. That is a trade i dont want to go into... Any ideas? (Yes, i am a bit tired of the camera lib right now... Too much work just for one program)

Touchscreen: Still thinking about that. But, if it is a hw problem, then reinstalling the ROM should not fix it ... hummm...

DTV and other goodies... Hummm... if linux does not support the device, you won-t be able to do it... Quite frankly, it is VERY HARD just to make the default shuttle hw to properly work... I am sorry about this, but, i am running out of time regarding this project. I do intend to try to fix what it is not working as it should, but i wont implement new features... I have tons ot other projects waiting to be done ;) -- But you have all the tools required to do what you want yourself

Regards,

Eduardo

[Guest rebel1]

Just an update on what i am working on:

-Accelerometer: Fixes so it is as responsive as in the .32 kernel: Done

-Dynamic USB host/device switching: Done

-USB cutting communication when device enters sleep: Done

I am not posting the patches, just because i have to do some extra tests to make sure they do work as expected in HC3.2 .... Right now i am testing with a busybox linux shell

Well, regarding camera, i am out of ideas... Seems that if we make the camera compatible with Gtalk, we lose compatibility with all the other apps. Or at least, that is what i can infer by using redscorpions libcamera. That is a trade i dont want to go into... Any ideas? (Yes, i am a bit tired of the camera lib right now... Too much work just for one program)

Touchscreen: Still thinking about that. But, if it is a hw problem, then reinstalling the ROM should not fix it ... hummm...

DTV and other goodies... Hummm... if linux does not support the device, you won-t be able to do it... Quite frankly, it is VERY HARD just to make the default shuttle hw to properly work... I am sorry about this, but, i am running out of time regarding this project. I do intend to try to fix what it is not working as it should, but i wont implement new features... I have tons ot other projects waiting to be done ;) -- But you have all the tools required to do what you want yourself

Regards,

Eduardo

:wub: Great!

[Guest CoWPlagued]

Just an update on what i am working on:

-Accelerometer: Fixes so it is as responsive as in the .32 kernel: Done

-Dynamic USB host/device switching: Done

-USB cutting communication when device enters sleep: Done

I am not posting the patches, just because i have to do some extra tests to make sure they do work as expected in HC3.2 .... Right now i am testing with a busybox linux shell

Well, regarding camera, i am out of ideas... Seems that if we make the camera compatible with Gtalk, we lose compatibility with all the other apps. Or at least, that is what i can infer by using redscorpions libcamera. That is a trade i dont want to go into... Any ideas? (Yes, i am a bit tired of the camera lib right now... Too much work just for one program

awesome work, i think with regards to the camera you are absolutely right about the effort for a single app. We can simply provide an update zip that swaps the libcamera.so so that people can choose themselfs between better compatability or gtalk.

cheers

[Guest WWEpsp]

Just an update on what i am working on:

-Accelerometer: Fixes so it is as responsive as in the .32 kernel: Done

-Dynamic USB host/device switching: Done

-USB cutting communication when device enters sleep: Done

I am not posting the patches, just because i have to do some extra tests to make sure they do work as expected in HC3.2 .... Right now i am testing with a busybox linux shell

Well, regarding camera, i am out of ideas... Seems that if we make the camera compatible with Gtalk, we lose compatibility with all the other apps. Or at least, that is what i can infer by using redscorpions libcamera. That is a trade i dont want to go into... Any ideas? (Yes, i am a bit tired of the camera lib right now... Too much work just for one program)

Touchscreen: Still thinking about that. But, if it is a hw problem, then reinstalling the ROM should not fix it ... hummm...

DTV and other goodies... Hummm... if linux does not support the device, you won-t be able to do it... Quite frankly, it is VERY HARD just to make the default shuttle hw to properly work... I am sorry about this, but, i am running out of time regarding this project. I do intend to try to fix what it is not working as it should, but i wont implement new features... I have tons ot other projects waiting to be done ;) -- But you have all the tools required to do what you want yourself

Regards,

Eduardo

WOW!, i really dont like the idea of posting here, because i see this post like a private one just for devs :P

but seriously i just wanted to reply after this just to say thanks!, awesome job you people are doing!

anyway i just want you to know, about the EAP wifi(enterprise) bug, its seems like its just a problem of authentification. If you could only check it quickly please...

P.D: If you cant really test the bug, i could test it, so i can bring you a little bit of feedback, just in case you want to fix it...

[Guest mrz_hun]

Just an update on what i am working on:

...

Touchscreen: Still thinking about that. But, if it is a hw problem, then reinstalling the ROM should not fix it ... hummm...

...

I'm happy to see that there is a chance this will be addressed.

If there is anything I can do to test any changes, I'll be glad to help. Just send me a PM.

Thanks.

[Guest ejtagle]

I'm happy to see that there is a chance this will be addressed.

If there is anything I can do to test any changes, I'll be glad to help. Just send me a PM.

Thanks.

Regarding the IT7260 touchscreen controller, I found this today: http://www.docin.com/p-165227169.html ... If someone has a local copy of this PDF, or is able to download it, and it could be posted here, it would help.. I have a text version of this PDF, but the original contains much more information... Not all the info i wished for, , but a bit more...

[Guest WWEpsp]

Regarding the IT7260 touchscreen controller, I found this today: http://www.docin.com/p-165227169.html ... If someone has a local copy of this PDF, or is able to download it, and it could be posted here, it would help.. I have a text version of this PDF, but the original contains much more information... Not all the info i wished for, , but a bit more...

i tried to download it from the page and you have to pay in order to download stuff :(...

anyway i found this but didnt work for me: http://pptown.com/archives/395

its a dicon downloader but it just throws me an error, i cant actually understand because i dont know chinese :P

[Guest pizzaboy75]

Regarding the IT7260 touchscreen controller, I found this today: http://www.docin.com/p-165227169.html ... If someone has a local copy of this PDF, or is able to download it, and it could be posted here, it would help.. I have a text version of this PDF, but the original contains much more information... Not all the info i wished for, , but a bit more...

Here you go!

IT7260.zip

BTW: Could you guys implement the updated CM7 cacerts.bks file or at least just remove the DIGINOTAR cert in the next Vegacomb Release?

Edited September 19, 2011 by pizzaboy75

[Guest redscorpion]

Hi Eduardo,

sorry, I've been on holidays, but now I'm back.

According to my investigation, the problem with Gtalk is that Gtalk is very "sensitive" to operations with native window, so:

- do not iterate through all color formats, just set the YV12 format, otherwise the Gtalk will not be working correctly (preview will be empty or with messy colors...)

- do not use the win.get()->perform(...) call to set the windows geometry, it causes that Gtalk will crash.. use the ANativeWindow_setBuffersGeometry(), it works fine...

- do not use the win.get()->perform(...) call to set the cropping area, buffers count, transform, etc.. otherwise the GTalk will crash...

Here are my camera sources, please look at them (especially at the setPreviewWindow method)...

Regards,

Kamil

camera_src.zip

libcamera.so.zip

Edited September 19, 2011 by redscorpion