Jump to content
PaulOBrien

Advent Vega kernel source code now available!

Recommended Posts

You'd think so eh .. but for some reason this repo is not recognising itself as a git one ... no git commands work ;)

No matter .. new AOSP compiling now .. see in a couple of hours what happens ...

EDIT :- HQ video now works .. many a wasted hour on a dirty AOSP build ... picture looks very nice ... also just noticed transparency effect in the notification popups .. very swish .. we never had that before ... Just testing sleep right now ... on the inital tests it appears to work ... just needs longer rest and a check for wakelocks before i can say all is well ... but on the upshot right now im very happy ... a little more work to the build after this and ill release it .. Its nearly there .... :)

There is an small secret here, Cass... Most kernels 2.6.39 out there were based on my initial port of drivers from the 2.6.36 kernel... Initially. and the 2.6.36 kernel was configured this way, the framework buffer was configured to run at 16bits per pixel (65k colors)... But, as we were trying with you to sort out the video acceleration issues, at some time i upped the bits per pixel to 32 and enabled error difussion dithering. The kernel you are using is configured in that way, but most other kernel (Adam included) are still using 16bits ... If you think about it, 32bits sounds too much, for an LCD that is just able to use 18 bits per pixel... But, i found out that the Tegra2 does not work that way.

Tegra2 emulates the missing bits by using dynamic error diffusion dithering, effectively reaching at least 24 bit color on the 18bit LCD. But, if i reduce the framebuffer bpp to 16 bits, then there are no extra bits to perform dithering... So, our current 32bit bpp gives us way better picture quality that Adam or the others... And i am perfectly able to tell the difference.. You will also notice it when there are alpha channel based transitions, colors seem to fade very nicely... And also all the color interpolations look really nice... Not to mention video playback ;)

Share this post


Link to post
Share on other sites

There is an small secret here, Cass... Most kernels 2.6.39 out there were based on my initial port of drivers from the 2.6.36 kernel... Initially. and the 2.6.36 kernel was configured this way, the framework buffer was configured to run at 16bits per pixel (65k colors)... But, as we were trying with you to sort out the video acceleration issues, at some time i upped the bits per pixel to 32 and enabled error difussion dithering. The kernel you are using is configured in that way, but most other kernel (Adam included) are still using 16bits ... If you think about it, 32bits sounds too much, for an LCD that is just able to use 18 bits per pixel... But, i found out that the Tegra2 does not work that way.

Tegra2 emulates the missing bits by using dynamic error diffusion dithering, effectively reaching at least 24 bit color on the 18bit LCD. But, if i reduce the framebuffer bpp to 16 bits, then there are no extra bits to perform dithering... So, our current 32bit bpp gives us way better picture quality that Adam or the others... And i am perfectly able to tell the difference.. You will also notice it when there are alpha channel based transitions, colors seem to fade very nicely... And also all the color interpolations look really nice... Not to mention video playback ;)

Ohh yeah :) ... The HQ video is nothing short of stunning on the YouTube stream so Amen to that ... Though is it limitation of the Adam screen that limits the PQ? Those chaps have 32bpp enabled also ...

Cheers

Cass

Share this post


Link to post
Share on other sites

Ohh yeah :) ... The HQ video is nothing short of stunning on the YouTube stream so Amen to that ... Though is it limitation of the Adam screen that limits the PQ? Those chaps have 32bpp enabled also ...

Cheers

Cass

Cass,

Ha Ha guess instead of posting boot image and links should have just said do a clean build and problems would have been solved ;) Glad you got everything solved.

Re. Adam looking at adam gpu and fb_data still says 16-bit per pixel so I don't think they are using 32-bit.

edit:- forget adam comment looking at DHD branch they changed fb_data to 32- originally looking at different branch

Edited by brucelee666

Share this post


Link to post
Share on other sites

Ohh yeah :) ... The HQ video is nothing short of stunning on the YouTube stream so Amen to that ... Though is it limitation of the Adam screen that limits the PQ? Those chaps have 32bpp enabled also ...

Cheers

Cass

No , they could also use it... They never merged the patch (at least, EnJens github does not have it... Even HDMI seems to be in 16bit in their ROM) ... In some way, could be my fault... As i don't use git in my own development cycle, i don't tag commits, so no change history... It is very common for me to be developing without inet access, so git is not as useful ... Besides, sometimes i have to do several tests to find working fixes, and git commits/reverts would just slow down them.. I find git more useful when following a development/review plan, or when working in groups... ;)

edit1: on the rel14-merge they use 16bit for HDMI, 32bit for fb, and ordered dithering (TEGRA_DC_ORDERED_DITHER () .. But tegra supports error diffusion ... There was an error in the comments ;) ...

Edited by ejtagle

Share this post


Link to post
Share on other sites

Cass, is the internal GPS and 3g modem in my PoV Mobii supposed to work in the alpha 2 build?

You guys are doing an amazing job by the way, making these great devices even greater!

Share this post


Link to post
Share on other sites

Cass, is the internal GPS and 3g modem in my PoV Mobii supposed to work in the alpha 2 build?

Don't think it does, i don't have one to test with it but chaps over on TR were working on it .. i think the last i noticed it failed to work ... Alpha 3 / Beta1 whatever i call it will have the files to support it but the Vega has no means to allow me to test ... ill leave that fun up to the likes of you ;)

Cheers

Cass

Share this post


Link to post
Share on other sites

Don't think it does, i don't have one to test with it but chaps over on TR were working on it .. i think the last i noticed it failed to work ... Alpha 3 / Beta1 whatever i call it will have the files to support it but the Vega has no means to allow me to test ... ill leave that fun up to the likes of you ;)

Cheers

Cass

I do have a PoV mobii with 3G and GPS... I think that applying the same patches that the Adam guys did, but using the huawei-ril lib with the appropiate entry in the init.rc script should be enough. Regarding the GPS, the lib i posted for ICS should be enough ;)

Share this post


Link to post
Share on other sites

No , they could also use it... They never merged the patch (at least, EnJens github does not have it... Even HDMI seems to be in 16bit in their ROM) ... In some way, could be my fault... As i don't use git in my own development cycle, i don't tag commits, so no change history... It is very common for me to be developing without inet access, so git is not as useful ... Besides, sometimes i have to do several tests to find working fixes, and git commits/reverts would just slow down them.. I find git more useful when following a development/review plan, or when working in groups... ;)

edit1: on the rel14-merge they use 16bit for HDMI, 32bit for fb, and ordered dithering (TEGRA_DC_ORDERED_DITHER () .. But tegra supports error diffusion ... There was an error in the comments ;) ...

I have been experimenting with the 32bit depth for a while now on the .36 kernel and this is the only way to stabilise the stock browser on honeycomb obviously as you have already mentioned this significantly increase the video/image quality however you must also increase the amount of gpu ram. I have currently got it set at 184mb with 5mb fb1 and 8mb hdmi 720p fb which is stable I think we may be able to reduce it a little more yet. regarding gpu ram I looked at the xoom, tf and streak 7 kernels to see how they have done it. the xoom kernel goes about gpu ram by using the low memory for main system ram and the himem for gpu ram giving it 512mb for main ram and 512mb for gpu ram it also has 8mb for fb1 and 16mb for 1080p hdmi fb. the tf kernel has 768mb for main ram and 256mb for gpu ram and the same as the xoom for both the framebuffers. both the tf kernel and xoom kernel have 32bit depth on internal and hdmi fb's. This is ok if you have 1gb of ram which we do NOT so I looked to the dell streak 7 kernel which is a ventanna tablet with 512mb ram and an official honeycomb update. the way dell have achieved this is by cheating in my opinion ;) they have reduced the screen resolution to 800x480 used 16bit depth for internal fb and 24bit depth for hdmi. All this allows the streak to have 128mb gpu ram leaving 384mb for system ram 2mb for fb1 and strangely only 2mb for hdmi even though at 24bit depth and 720p it should need a bigger fb than this. With this tied together with the android low memory killer settings allows honeycomb to run very well if a little sluggish at times on the streak.

now comes the problem I cannot get the initlogo.rle to display correctly with the 32bit depth enabled the image is displayed with garbled colours and it is display twice in the top half of the screen and the bottom half is just black and white lines. I have tried using a black image and an image produced at 32bit depth to no avail. Any pointers here would be helpful.

I assume the frameworks in android are optimized for either 16bit depth or 32bit depth that is why when 32bit depth is enabled alot of problems go away and considering we are essentially emulating a xoom as both the ICS build and honeycomb are based on xoom/tf targets.

Also I did notice that before nvidia introduced the seperate dc/fb driver they allowed the lcd resolution to be different from the framebuffer resolution and the driver would stretch it to fill the screen, I did try to get this working in the new driver but I do not think they have fully implemented the functionality. again any pointers on the is would be great.

great work cass and eduardo I really cant wait to have ago with your latest efforts for both the .39 kernel and ICS.

please correct me if I am wrong on any of the above.

ok this has been a long post but just one more thing.

Cass will you be publishing the device profile for ICS so anyone can build from aosp when you have got it working I would like to give it ago but my build keeps failing in libmedia cant remember the error for now but was just wondering?

thanks again guys/gals your work is much appreciated.

rolleyes.gif

Share this post


Link to post
Share on other sites

Cass will you be publishing the device profile for ICS so anyone can build from aosp when you have got it working I would like to give it ago but my build keeps failing in libmedia cant remember the error for now but was just wondering?

rolleyes.gif

Hi Wooshy ..

Yes ill publish it as soon as i have a build im happy with and make it shuttle'centric ... currently i build it as moto/wingray with customizations to suit us then after the system folder is created i move stuff over that we need, libs, apks etc ... im too lazy right now to update the profile to suit every time i make a change, its not stable enough right now ;) Shouldnt be long .. The build is looking quite good right now .. just trying to sort out a lingering wifi issue where it stops scanning and you cant add a new AP .. had many a complaint about it in earlier alphas but now im seeing it for myself for some reason ..

If you like i can tar up what i have and mail it to you ? PM your mail addy if you'd like this meanwhile...

Cheers

Cass

Share this post


Link to post
Share on other sites

I do have a PoV mobii with 3G and GPS... I think that applying the same patches that the Adam guys did, but using the huawei-ril lib with the appropiate entry in the init.rc script should be enough. Regarding the GPS, the lib i posted for ICS should be enough ;)

In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :)

edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ?

edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it ..

http://pastebin.com/Y5jCN6Pt

/dev/input/* has proper permissions and should be able to open the device ok ....

Cheers

Cass

Edited by Cass67

Share this post


Link to post
Share on other sites

With regards to the PCM audio issues you gentlemen were having before, did you ever sovlve them with that patch?

I dived a little deeper into the dma system and found we are quite short of channels.

There are 16 for Tegra 2, 4/5 of which seemed to be reserved for the AVP, 4 SPI devices using 2 channels each, 1 uart device using 2 channels which leaves 1 channel left, which we usually use for playing back sound.

However, trying to record often involves pressing a button which in itself plays a sound, hence the "Out of memory" errors we're encountering.

I guess the important question here is - do we need all 4 SPI devices?

Edited by DrMon

Share this post


Link to post
Share on other sites

In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :)

edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ?

edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it ..

http://pastebin.com/Y5jCN6Pt

/dev/input/* has proper permissions and should be able to open the device ok ....

Cheers

Cass

Hi boys...

Be carefull with 3G, in ICS there is some changes that needs to modify huaweigeneric.c, I cant get it to work in wetab, but i'm almost here.

Can you point me to the sources of Adams ril?

Thanks

Corvus.

Share this post


Link to post
Share on other sites

In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :)

edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ?

edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it ..

http://pastebin.com/Y5jCN6Pt

/dev/input/* has proper permissions and should be able to open the device ok ....

Cheers

Cass

In our previous kernels interface for 3G was usb0, but now we have usb0 and it chooses wwan0 for interface name. About the new ril lib we using the difference from the old one made for GB and HC is that there is implementation for GW and DNS handling. To make 3G working I need also to make proper permissions to the serials of the modem (other way is to give correct permissions to rild).

Share this post


Link to post
Share on other sites

Hi boys...

Be carefull with 3G, in ICS there is some changes that needs to modify huaweigeneric.c, I cant get it to work in wetab, but i'm almost here.

Can you point me to the sources of Adams ril?

Thanks

Corvus.

Cant be 100%, but it looks to be this one... Borkata can advice if this is not the case...

https://github.com/rrathi/adamICS/commit/72953f13ef0a3eccd03d772045789dd0e1e9d090

I only noticed they had one while sifting through the overlay stuff to see what changed ...

:)

Cass

Share this post


Link to post
Share on other sites

With regards to the PCM audio issues you gentlemen were having before, did you ever sovlve them with that patch?

I dived a little deeper into the dma system and found we are quite short of channels.

There are 16 for Tegra 2, 4/5 of which seemed to be reserved for the AVP, 4 SPI devices using 2 channels each, 1 uart device using 2 channels which leaves 1 channel left, which we usually use for playing back sound.

However, trying to record often involves pressing a button which in itself plays a sound, hence the "Out of memory" errors we're encountering.

I guess the important question here is - do we need all 4 SPI devices?

We use i2c devices .. SPI is not used ... at least on shuttle. I think there is no need to enable all SPI channels... ;)

The out of memory errors were caused, at least with shuttle, because we were using a wrong block size ... We do get audio recordings, but they seem to be garbled... sometimes... :o .. We didn't get Out of memory errors with the latest audio_hw_primary i posted here. The Adam version is based on my previous version of audio_hw_primary that did not had those fixes... Unifying the sampling rate between capture and playback is needed (even the codec does not suport different sampling rates between play and record channels) ... I'd suggest to compare them and port the changes, as they are minimal ... ;)

Edited by ejtagle

Share this post


Link to post
Share on other sites

In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :)

edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ?

edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it ..

http://pastebin.com/Y5jCN6Pt

/dev/input/* has proper permissions and should be able to open the device ok ....

Cheers

Cass

I see:

E/CameraHardware( 103): Unable to power camera

E/V4L2Camera( 103): ERROR opening V4L interface: Permission denied

E/CameraHardware( 103): cannot open device.

I think we have permission problems on the Camera power control ;) - The /sys/shuttle-pm-camera/power_on entry.. It is 0666 , but perhaps the /sys is forbidding writes ...

edit1: Ok, we have no permission problems on the Camera power control, the problem is we can't open /dev/video0 . Perhaps a permission problem, or perhaps a rule is missing..

D/EventHub( 153): No input device configuration file found for device 'USB 2.0 Camera'.

I/EventHub( 153): New device: id=6, fd=260, path='/dev/input/event5', name='USB 2.0 Camera', classes=0x80000001, configuration='', keyLayout='/system/usr/keylayout/Generic.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false

I/InputReader( 153): Device added: id=6, name='USB 2.0 Camera', sources=0x00000101

Seems to be recognizing the camera as a keyboard ;), instead of creating the /dev/video0 entry ;) -- If you do echo "1" >/sys/shuttle-pm-camera/power_on , the camera should power on and the /dev/video0 should appear

Edited by ejtagle

Share this post


Link to post
Share on other sites

I have been experimenting with the 32bit depth for a while now on the .36 kernel and this is the only way to stabilise the stock browser on honeycomb obviously as you have already mentioned this significantly increase the video/image quality however you must also increase the amount of gpu ram. I have currently got it set at 184mb with 5mb fb1 and 8mb hdmi 720p fb which is stable I think we may be able to reduce it a little more yet. regarding gpu ram I looked at the xoom, tf and streak 7 kernels to see how they have done it. the xoom kernel goes about gpu ram by using the low memory for main system ram and the himem for gpu ram giving it 512mb for main ram and 512mb for gpu ram it also has 8mb for fb1 and 16mb for 1080p hdmi fb. the tf kernel has 768mb for main ram and 256mb for gpu ram and the same as the xoom for both the framebuffers. both the tf kernel and xoom kernel have 32bit depth on internal and hdmi fb's. This is ok if you have 1gb of ram which we do NOT so I looked to the dell streak 7 kernel which is a ventanna tablet with 512mb ram and an official honeycomb update. the way dell have achieved this is by cheating in my opinion ;) they have reduced the screen resolution to 800x480 used 16bit depth for internal fb and 24bit depth for hdmi. All this allows the streak to have 128mb gpu ram leaving 384mb for system ram 2mb for fb1 and strangely only 2mb for hdmi even though at 24bit depth and 720p it should need a bigger fb than this. With this tied together with the android low memory killer settings allows honeycomb to run very well if a little sluggish at times on the streak.

now comes the problem I cannot get the initlogo.rle to display correctly with the 32bit depth enabled the image is displayed with garbled colours and it is display twice in the top half of the screen and the bottom half is just black and white lines. I have tried using a black image and an image produced at 32bit depth to no avail. Any pointers here would be helpful.

I assume the frameworks in android are optimized for either 16bit depth or 32bit depth that is why when 32bit depth is enabled alot of problems go away and considering we are essentially emulating a xoom as both the ICS build and honeycomb are based on xoom/tf targets.

Also I did notice that before nvidia introduced the seperate dc/fb driver they allowed the lcd resolution to be different from the framebuffer resolution and the driver would stretch it to fill the screen, I did try to get this working in the new driver but I do not think they have fully implemented the functionality. again any pointers on the is would be great.

great work cass and eduardo I really cant wait to have ago with your latest efforts for both the .39 kernel and ICS.

please correct me if I am wrong on any of the above.

ok this has been a long post but just one more thing.

Cass will you be publishing the device profile for ICS so anyone can build from aosp when you have got it working I would like to give it ago but my build keeps failing in libmedia cant remember the error for now but was just wondering?

thanks again guys/gals your work is much appreciated.

rolleyes.gif

Tegra2 hw only supports 16 and 32bit per pixel framebuffers. HDMI is always 32bit: The tegra2 driver ignores the bitdepth specified for that framebuffer. But, it must be taken info account when computing the hdmi framebuffer memory... the main framebuffer requires 2 video pages to work reliably under Android, the HDMI i am not sure... Probably with some apps (full screen vieo playback), 2 HDMI pages would also be required...

Probably, the initlogo.rle requires a 16bit framebuffer... Or it assumes so... Did you try to compress a 32bit logo ? ... If you are unable to make it work, tell me, i will write an small logo display utility... or you could do something along the lines : zcat logo.gz > /dev/fb0 ;)

You don't need such huge amount of gpu memory... mount debugfs. then cat /dbgfs/nvmap/ ... To check exactly how much vide memory a given program is using ;) --

Share this post


Link to post
Share on other sites

Whaty about HDMI audio ? -- Did it work ? -- Seems that if it does not, the required mods to make it work are trivial... I will try to test it, but feel free to also test it and tell me if it does not work ;), so we can fix it

Share this post


Link to post
Share on other sites

I see:

E/CameraHardware( 103): Unable to power camera

E/V4L2Camera( 103): ERROR opening V4L interface: Permission denied

E/CameraHardware( 103): cannot open device.

I think we have permission problems on the Camera power control ;) - The /sys/shuttle-pm-camera/power_on entry.. It is 0666 , but perhaps the /sys is forbidding writes ...

edit1: Ok, we have no permission problems on the Camera power control, the problem is we can't open /dev/video0 . Perhaps a permission problem, or perhaps a rule is missing..

D/EventHub( 153): No input device configuration file found for device 'USB 2.0 Camera'.

I/EventHub( 153): New device: id=6, fd=260, path='/dev/input/event5', name='USB 2.0 Camera', classes=0x80000001, configuration='', keyLayout='/system/usr/keylayout/Generic.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false

I/InputReader( 153): Device added: id=6, name='USB 2.0 Camera', sources=0x00000101

Seems to be recognizing the camera as a keyboard ;), instead of creating the /dev/video0 entry ;) -- If you do echo "1" >/sys/shuttle-pm-camera/power_on , the camera should power on and the /dev/video0 should appear

Yes, perfect thanks a lot, never dawned on me to check the power... one more thing off the list ;)

echo 1 > /sys/devices/platform/shuttle-pm-camera/power_on

chmod 666 /dev/video0

did the trick ... cant remember having that in previous releases, for camera at least ...

Cheers

Cass

Share this post


Link to post
Share on other sites

Yes, perfect thanks a lot, never dawned on me to check the power... one more thing off the list ;)

echo 1 > /sys/devices/platform/shuttle-pm-camera/power_on

chmod 666 /dev/video0

did the trick ... cant remember having that in previous releases, for camera at least ...

Cheers

Cass

of course you don't want to put

echo 1 > /sys/devices/platform/shuttle-pm-camera/power_on

everytime the device boots, or the camera will be kept powered on .. I think when the /dev/video0 entry is created, the right permissions should be set ;)

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.