Making newer GPU drivers work

Search This thread
By:
Advanced…
Shidell

Shidell

Senior Member
Jan 21, 2009
563
85
@musical_chairs Ah, I see. Well, if you can test Navigation while charging, I would expect that either phone should stop charging within five minutes. It would be a good test to compare, seeing are running two completely different kernels and ROMs.

If you or @Ziyan post updated DDK kernels, I will certainly try those, too. I'd like to see the GNex working to it's fullest potential; especially with the improvements in L, if we can resolve these graphical bugs, I don't see any reason or need to upgrade.
 
musical_chairs

musical_chairs

Senior Member
Mar 6, 2012
1,072
1,226
Shidell said:
@musical_chairs Ah, I see. Well, if you can test Navigation while charging, I would expect that either phone should stop charging within five minutes. It would be a good test to compare, seeing are running two completely different kernels and ROMs.

If you or @Ziyan post updated DDK kernels, I will certainly try those, too. I'd like to see the GNex working to it's fullest potential; especially with the improvements in L, if we can resolve these graphical bugs, I don't see any reason or need to upgrade.
Click to expand...
Click to collapse

The updated DDK kernel (if you mean DDK 1.9, the one with GPU governor and temperature limit throttling) requires ROM-side changes in addition to the kernel changes. You can't just flash a kernel and get DDK 1.9 running. Ziyan's stable OMAP kernel branch has updates to a whole bunch of other stuff but keeps DDK at 1.8 so camera and OMX still work. FreshKernel and NukedTrinity both have a bunch of stuff from Ziyan's stable OMAP kernel, maybe one of those would help your overheating issues. If you would like to try the DDK 1.9 driver on toroplus, I can re-upload the ROM I had posted.

As far as navigation goes, I only use offline maps (my cell phone plan comes with a whopping 10Mb/month), so I'll have far less heating while navigating. Also, I'm usually not using Google Maps , I bought a download of US and Canada maps for another app and it behaves fine while charging AFAIK. So my test results won't necessarily help you.
 
Shidell

Shidell

Senior Member
Jan 21, 2009
563
85
Thanks @musical_chairs. In another thread here, according to freshgiammi, the overheating problem is tied to 4.4.

It's possible that @Ziyan's commits might fix it, but I honestly don't know enough about the kernel to know for sure.
 
markitosd

markitosd

Senior Member
Jul 14, 2012
167
31
Reconquista
Nexus 7 (2013)
OnePlus 5T
When listening to music there seems to be a stutter seconds after locking the screen. Is that due to drivers, kernel, rom? I've tried several combinations of roms and kernels and the problem is still there. Any idea? I'm using Apollo and Play Music, and I'm having the issue with both.
 
ScardracS

ScardracS

Recognized Developer
May 6, 2012
1,969
821
Huawei P40
markitosd said:
When listening to music there seems to be a stutter seconds after locking the screen. Is that due to drivers, kernel, rom? I've tried several combinations of roms and kernels and the problem is still there. Any idea? I'm using Apollo and Play Music, and I'm having the issue with both.
Click to expand...
Click to collapse

The problem appears on android 4.4.x like overheat and lags..

Sent from my Galaxy Nexus using XDA Free mobile app
 
  • Like
Reactions: markitosd
musical_chairs

musical_chairs

Senior Member
Mar 6, 2012
1,072
1,226
markitosd said:
When listening to music there seems to be a stutter seconds after locking the screen. Is that due to drivers, kernel, rom? I've tried several combinations of roms and kernels and the problem is still there. Any idea? I'm using Apollo and Play Music, and I'm having the issue with both.
Click to expand...
Click to collapse

Actually, stock OmniROM is one of the few 4.4 ROMs I've tried that does not have this problem. DOn't remember if the modified Omni with the new GPU drivers did, but I don't think so. Sometimes with custom kernels (and lower minimum clock frequencies), Omni will cut out the music when the screen goes off, but with the stock kernel or a custom kernel with the minimum frequency at 350 MHz it is fine. CyanogenMod definitely cuts out when the screen locks.
 
  • Like
Reactions: markitosd
S

Sdobron

Senior Member
Sep 5, 2010
2,346
418
musical_chairs said:
Actually, stock OmniROM is one of the few 4.4 ROMs I've tried that does not have this problem. DOn't remember if the modified Omni with the new GPU drivers did, but I don't think so. Sometimes with custom kernels (and lower minimum clock frequencies), Omni will cut out the music when the screen goes off, but with the stock kernel or a custom kernel with the minimum frequency at 350 MHz it is fine. CyanogenMod definitely cuts out when the screen locks.
Click to expand...
Click to collapse
Omnirom does.. I used it for 6 months
 
freshgiammi

freshgiammi

Senior Member
Dec 2, 2012
513
2,029
Pesaro
OnePlus 6
I actually submitted the fix for this, but no one did it. Since i have no ROM Knowledge, i can't fix it. I believe FML has it fixed, by the way.

The problem is that Audio Buffer is too low. It should be set to 48000 instead of 44100. Try PowerAmp, you should be able to set the Audio Buffer to MAX, and that should fix your issue.

EDIT: Forgot to say, it's ROM related, so custom kernels won't help.
 
Last edited:
  • Like
Reactions: rajputrajat, matoushybl and Punkiderma
S

Sdobron

Senior Member
Sep 5, 2010
2,346
418
freshgiammi said:
I actually submitted the fix for this, but no one did it. Since i have no ROM Knowledge, i can't fix it. I believe FML has it fixed, by the way.

The problem is that Audio Buffer is too low. It should be set to 48000 instead of 44100. Try PowerAmp, you should be able to set the Audio Buffer to MAX, and that should fix your issue.

EDIT: Forgot to say, it's ROM related, so custom kernels won't help.
Click to expand...
Click to collapse
That's the sample rate not the audio buffer...
 
mirhl

mirhl

Senior Member
Oct 15, 2012
3,129
1,171
Imagination released today their PowerVR SDK, and they claim the entire instruction set is public now

Can you confirm?
 
ScardracS

ScardracS

Recognized Developer
May 6, 2012
1,969
821
Huawei P40
Android 5.0 will be released on 3rh november via ota and in the next few days will be released AOSP version :)

Sent from my Galaxy Nexus using XDA Free mobile app
 
M

MWisBest

Inactive Recognized Developer
Dec 26, 2010
934
5,817
Green Bay, WI
github.com
markitosd said:
When listening to music there seems to be a stutter seconds after locking the screen. Is that due to drivers, kernel, rom? I've tried several combinations of roms and kernels and the problem is still there. Any idea? I'm using Apollo and Play Music, and I'm having the issue with both.
Click to expand...
Click to collapse

The issue is, at least mostly, audio HAL related. The deep buffer path behaves differently for screen on and screen off. Screen off is... more relaxed, and basically says "we don't give a **** about latency if the screen is off, let the CPU take its time to save power". Which makes perfect sense, a delay is only going to be noticeable if you're interacting with something on the screen.
This might be fixable by making the difference between screen on and screen off smaller. I'll look into it.
 
  • Like
Reactions: 7175, thomstrack, markitosd and 3 others
santi1993

santi1993

Senior Member
Mar 24, 2012
789
135
Buenos Aires
i've readed there and here and see that the galaxy nexus just "slow" their vital signs to save power, if anyone could include and exception for audio processor maybe the problem will be gone, im not joking anyone, i know here are too much intelligent ppl but maybe focusing in this way make the audio works better with screen off, making an exception to slow everything except audio DSP
 
n1kolaa

n1kolaa

Inactive Recognized Developer
Oct 21, 2011
3,367
4,062
Zrenjanin
OnePlus Nord
santi1993 said:
i've readed there and here and see that the galaxy nexus just "slow" their vital signs to save power, if anyone could include and exception for audio processor maybe the problem will be gone, im not joking anyone, i know here are too much intelligent ppl but maybe focusing in this way make the audio works better with screen off, making an exception to slow everything except audio DSP
Click to expand...
Click to collapse

IT have some Tesla DSP-s for omap , but we think our board dont have it :)
 
theBlackEnd

theBlackEnd

Senior Member
Mar 14, 2014
102
262
Hey guys,
I've been trying to switch to Hashcode's OMAP4-next repo.
Build finishes successfully, but I can't get one booting.
First builds were stuck at google's logo since pvrsinit bin was missing, now surfaceflinger can't locate composer file, so there's no video output.
Here's an extract from the logcat:

Code: 
[...]
I/SurfaceFlinger(  669): SurfaceFlinger is starting
I/SurfaceFlinger(  669): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
D/libEGL  (  669): loaded /vendor/lib/egl/libEGL_POWERVR_SGX540_120.so
D/libEGL  (  669): loaded /vendor/lib/egl/libGLESv1_CM_POWERVR_SGX540_120.so
D/libEGL  (  669): loaded /vendor/lib/egl/libGLESv2_POWERVR_SGX540_120.so
I/ti_hwc  (  669): Expecting h/w vsync for tuna
E/ti_hwc  (  669): failed to open hdmi fb (2)
[B]E/SurfaceFlinger(  669): composer device failed to initialize (No such file or directory)[/B]
I/SurfaceFlinger(  669): Using composer version 0.0
W/SurfaceFlinger(  669): no suitable EGLConfig found, trying a simpler query
I/SurfaceFlinger(  669): EGL information:
I/SurfaceFlinger(  669): vendor    : Android
I/SurfaceFlinger(  669): version   : 1.4 Android META-EGL
I/SurfaceFlinger(  669): extensions: EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer EGL_ANDROID_recordable 
I/SurfaceFlinger(  669): Client API: OpenGL_ES
I/SurfaceFlinger(  669): EGLSurface: 8-8-8-8, config=0x2
I/SurfaceFlinger(  669): OpenGL ES informations:
I/SurfaceFlinger(  669): vendor    : Imagination Technologies
I/SurfaceFlinger(  669): renderer  : PowerVR SGX 540
I/SurfaceFlinger(  669): version   : OpenGL ES-CM 1.1
I/SurfaceFlinger(  669): extensions: GL_EXT_debug_marker GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_matrix_get GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_point_sprite GL_OES_point_size_array GL_OES_matrix_palette GL_OES_draw_texture GL_OES_query_matrix GL_OES_texture_env_crossbar GL_OES_texture_mirrored_repeat GL_OES_texture_cube_map GL_OES_blend_subtract GL_OES_blend_func_separate GL_OES_blend_equation_separate GL_OES_stencil_wrap GL_OES_extended_matrix_palette GL_OES_framebuffer_object GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_stencil8 GL_OES_compressed_ETC1_RGB8_texture GL_OES_mapbuffer GL_OES_EGL_image GL_OES_EGL_image_external GL_EXT_multi_draw_arrays GL_OES_required_internalformat GL_IMG_read_format GL_IMG_texture_compression_pvrtc GL_IMG_texture_format_BGRA8888 GL_EXT_texture_format_BGRA8888 GL_OES_egl_sync GL_IMG_vertex_array_object GL_APPLE_texture_2D_limited_npot
I/SurfaceFlinger(  669): GL_MAX_TEXTURE_SIZE = 2048
I/SurfaceFlinger(  669): GL_MAX_VIEWPORT_DIMS = 2048
I/dex2oat (  253): Explicit concurrent mark sweep GC freed 43706(6MB) AllocSpace objects, 0(0B) LOS objects, 14% free, 23MB/27MB, paused 457us total 1.158s
E/cutils-trace(  669): Error opening trace file: Permission denied (13)
D/SurfaceFlinger(  669): Set power mode=2, type=0 flinger=0x40662000
[B]F/libc    (  669): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 669 (surfaceflinger)[/B]

A\B comparison shows no missing files in /system dir (no more, lol).
The only difference from builds made with MWisBest and Ziyan's Franken-domx is that hwcomposer.*.so and camera.*.so libs have different names (omap4 instead of tuna), but this looks legit to me. (*)
Any hint?

Thank you in advance.


EDIT: Ok, after some digging in hardware/libhardware/hardware.c I think I found what's wrong. I'll let you know.
EDIT2: Meh, I made a few more attempts and set SELinux policy to permissive. (*) ro.board.platform is set to omap4, so hwc_open_1() should be able to load these modules.
I'm out of ideas now.

EDIT 3: Another final is gone and I've got a few hours to spend on this. I think I need do start to try easy solutions first. It's working fine now, I'm going to make a new clean build and test what's working (camera, sensors...).
 
Last edited:
  • Like
Reactions: siddardha21
theBlackEnd

theBlackEnd

Senior Member
Mar 14, 2014
102
262
zzpianoman said:
Ah but using CyanogenMod's LegacyCamera app, I am able to take perfect snapshots while recording video!! Actually, the LegacyCamera app works pretty flawlessly with Lollipop on Tuna - the Camera NEVER crashes, and I never have to reboot like I do with the stock Camera app or Google Camera. That's where the story gets even more complex and weird. The snapshots I take using that Camera app WHILE recording 1080p video are all high resolution (2592 x 1458) and NOT 1920x1080 like they SHOULD be.

Which is actually how I came to the conclusion that perhaps the camera is stuck in snapshot mode. It looks like OMX makes several calls to the CameraHAL, and maybe one of them is not setting recordingHint to true? I really have no idea. I have been rattling my brain over this as well trying to understand how all of this works. It's pretty complicated.

EDIT: I wish there was some kind of flowchart available to see exactly how the camera interfaces with the software.
Click to expand...
Click to collapse
I'm sorry for the late answer, I've been busy with an exam. Better move this here, at least we can keep track of posts.
I'm going to re-enable snapshot capability during video recording in DOMX just to verify if it happens here too. I had to disable a few features as Ducati crashed on capability\compatibilty request for some of them. EDIT: This has been disabled by MWisBest for some reason, I'm re-enabling it and check if it works.

While updating domx and camera, before realizing that Ducati was crashing, I wrote down a flowchart to try to understand what was causing capabilities arrays to have all NULL entries.
In short, there are more than 10 functions calling each other just to get camera properties, set them visible to camera apps and then display them in logs. I don't think there could be any usable flowchart for the whole camera/domx software interface.

All we can do to check your theory is to log camera status for each call, I guess. Anyway, 2592 x 1458 is still 16:9 multiple, this doesn't explain green bands in just a part of the video IMHO. Also, if I recall correctly, you're still using old pvr, domx and camera on your ROM and still get green lines, right? If so, why the same source is working fine on KK? What's changed in encoding and camera handling since then?

EDIT: Just built and installed LegacyCamera. WHAT A BAD LOOKING UI D: Yeah, this looks really stable. However, I'm not experiencing other cameras FCs (during usage, I mean) lately.
Meh, these lines seem to be camera dependent (?). I mean, in video recorded with Google Camera there's a green line on the left, same with Camera2 but that is gray most of the time, in LegacyCamera there's just a small pink band on the bottom, so small that I didn't notice it at first, but it's there even during preview. The more I try to locate the problem and the more I get confused. No good.

EDIT 2:
Code: 
D/CameraHal(  137): (40f438a8)     hardware/ti/omap4/camera/CameraParameters.cpp:227 dump - prop-video-snapshot-supported = false
Code: 
W/CAM_VideoModule( 2249): Cannot take a video snapshot - not supported by hardware
... I have no words.

This looks interesting:
Code: 
D/CAM_VideoModule( 2249): Video snapshot size is Size: (1920 x 1080)
But then, loads of lines bellow (I guess I launched Legacy Camera by then)
Code: 
V/videocamera( 3754): Video snapshot size is 2592x1458

EDIT 3: Googling for an error I just found out there's a camera_test bin from TI, I'm going to give it a try. I think this could help to find what's wrong.

EDIT 4: OUCH. I have to figure out why OpenGL compatibility is stuck at 1.1 version on my builds instead of 2.0 as CM 12. Any hint? I don't have any valid idea to be honest.
 
Last edited:
  • Like
Reactions: mirhl
Z

zzpianoman

Senior Member
Jun 25, 2008
854
1,623
New York
theBlackEnd said:
I'm sorry for the late answer, I've been busy with an exam. Better move this here, at least we can keep track of posts.
I'm going to re-enable snapshot capability during video recording in DOMX just to verify if it happens here too. I had to disable a few features as Ducati crashed on capability\compatibilty request for some of them. EDIT: This has been disabled by MWisBest for some reason, I'm re-enabling it and check if it works.

While updating domx and camera, before realizing that Ducati was crashing, I wrote down a flowchart to try to understand what was causing capabilities arrays to have all NULL entries.
In short, there are more than 10 functions calling each other just to get camera properties, set them visible to camera apps and then display them in logs. I don't think there could be any usable flowchart for the whole camera/domx software interface.

All we can do to check your theory is to log camera status for each call, I guess. Anyway, 2592 x 1458 is still 16:9 multiple, this doesn't explain green bands in just a part of the video IMHO. Also, if I recall correctly, you're still using old pvr, domx and camera on your ROM and still get green lines, right? If so, why the same source is working fine on KK? What's changed in encoding and camera handling since then?

EDIT: Just built and installed LegacyCamera. WHAT A BAD LOOKING UI D: Yeah, this looks really stable. However, I'm not experiencing other cameras FCs (during usage, I mean) lately.
Meh, these lines seem to be camera dependent (?). I mean, in video recorded with Google Camera there's a green line on the left, same with Camera2 but that is gray most of the time, in LegacyCamera there's just a small pink band on the bottom, so small that I didn't notice it at first, but it's there even during preview. The more I try to locate the problem and the more I get confused. No good.

EDIT 2:
Code: 
D/CameraHal(  137): (40f438a8)     hardware/ti/omap4/camera/CameraParameters.cpp:227 dump - prop-video-snapshot-supported = false
Code: 
W/CAM_VideoModule( 2249): Cannot take a video snapshot - not supported by hardware
... I have no words.

This looks interesting:
Code: 
D/CAM_VideoModule( 2249): Video snapshot size is Size: (1920 x 1080)
But then, loads of lines bellow (I guess I launched Legacy Camera by then)
Code: 
V/videocamera( 3754): Video snapshot size is 2592x1458

EDIT 3: Googling for an error I just found out there's a camera_test bin from TI, I'm going to give it a try. I think this could help to find what's wrong.

EDIT 4: OUCH. I have to figure out why OpenGL compatibility is stuck at 1.1 version on my builds instead of 2.0 as CM 12. Any hint? I don't have any valid idea to be honest.
Click to expand...
Click to collapse

This is what I get when I try to record video @ 720p:

Code: 
D/OMXCodec(  137): Successfully allocated OMX node 'OMX.TI.DUCATI1.VIDEO.DECODER'
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] AVC profile = 100 (High), level = 41
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 1280 x 720
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 1280 x 720 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 2 buffers of size 921600 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a301a0 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30100 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 3 buffers of size 1723392 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a300b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x4210d6a0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 1408 x 816
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 1280 x 720 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 7 buffers of size 1723392 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x4210d6a0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x4210d920 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30240 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30290 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a302e0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30330 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 1408 x 816
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 1280 x 720 @ (32, 24)

And now for 480p:

Code: 
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] AVC profile = 100 (High), level = 41
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 720 x 480
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 720 x 480 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 2 buffers of size 345600 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a301a0 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30100 on input port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 3 buffers of size 774144 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a300b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x423115b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 896 x 576
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 720 x 480 @ (0, 0)
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocating 7 buffers of size 774144 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x423115b0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x42311560 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30150 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30290 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a302e0 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30330 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] allocated buffer 0x41a30380 on output port
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] video dimensions are 896 x 576
I/OMXCodec(  137): [OMX.TI.DUCATI1.VIDEO.DECODER] Crop rect is 720 x 480 @ (32, 24)

It looks like the first call made to video decoder passes the correct video dimension but then two subsequent calls pass dimensions that are larger than the target video size. Also, it seems as if one dimension from each of these larger dimensions, is from the list of supported jpeg sizes - i.e. one of the supported still image capture resolutions from getsupportpicturesizes.

I've also tried forcing the video dimensions at several locations in the source code with no success. All that happens is that the software codec thinks I'm requesting that particular size, and merely sets the crop dimensions to the forced values. Perhaps the cameraHAL is stuck in preview mode and never actually goes into recording mode, and the logic that determines the video dimensions "thinks" it is in recording mode and therefore sets the video size based on the preview size, which is actually one of the still-capture dimensions?

I even tried adding some of the supported jpeg sizes to the supported preview resolutions in OMXCapabilities, and the decoder is still choosing video size dimensions that are larger than the requested video dimensions.

I am using old pvr, so it looks like whatever is causing this issue is something in frameworks_av that changed from KitKat to Lollipop - which is actually quite a bit. I've been meticulously going through the code trying to pinpoint what has been changed and how it could be affecting this particular issue, but with no success.

Just to add some more confusion to the mix, apps that stream video such as Skype actually work perfectly so it appears that it's just encoding and saving video that is the problem.
 
  • Like
Reactions: mirhl
You must log in or register to reply here.

Similar threads

franciscofranco
[KERNEL] [GPL] [GN] franco.Kernel r398
Replies
45K
Views
8M
C
Ctzokas
mskip
[GNEX TOOLKIT V11.1.0] Drivers, Backup, Unlock, Root, Recovery, Flash + MORE [GSM]
Replies
4K
Views
2M
mskip
mskip
L
Post your Galaxy Nexus home screens
Replies
14K
Views
4M
O
ohussain
mskip
[TOOLKIT] SKIPSOFT ANDROID TOOLKIT -GNEX SPR- Drivers, Root, Recovery + MORE
Replies
729
Views
619K
lambdaman
lambdaman
mskip
[GNEX TOOLKIT V11.1] Drivers, Backup, Unlock, Root, Recovery, Flash + MORE [VERIZON]
Replies
1K
Views
610K
ا
ابو اواب

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 26
    Ziyan
    Ziyan
    samcortez said:
    I am really newbie on it and I readed the whole thread but I wanted to know: you're just putting new GPU drivers on 3.0 kernel, right? Not 3.4 kernel for now, am I right?
    Click to expand...
    Click to collapse

    From that 1000 commits, only a small portion are for the GPU drivers - the rest are OMAP updates. Kernels have two separate parts: the general kernel code, and the platform specific code (OMAP code in this case). Well, it was like the OMAP code was still on 2.6 for us.

    We've got proximity fixed, and if everything goes right, camera will be working soon :good:
    View
    23
    Ziyan
    Ziyan
    I've updated most of our kernel to 4AJ.2.2. Our kernel was really outdated, but with these changes, it should be easier to make the newer binaries work, as there are many, many kernel side dependencies for them.
    Currently, I reverted everything that broke functionality with the current binaries (that includes remoteproc stuff which broke the camera, some sound and usb commits, not that much...), so everything still works.
    As far as I see, we can compile the binaries ourselves: Building SGX driver (or just borrow them from another device?). As I have a little side project that I want to do now, I don't intend to get into ROMs too much, but I may as well join the party soon :)

    The best starting point to make the kernel side changes is... well, my simple, but effective method is to compare the kernel dirs, like this. With this method, one can easily find & cherry-pick the changes from github, or I can create a separate branch that includes them (should I do it?), as it's not hard, I actually got them merged at a time with it's dependencies, but I reverted everything to get back the display.

    Here's the kernel: https://github.com/Ziyann/omap
    and the source: https://github.com/icepeda/omap/tree/icepeda-panda-4aj22

    Also, it would be nice to know which binaries should we use, as there may be different versions for 3.0 and 3.4. Which binaries work with this panda kernel? @isrcepeda, we don't want to disturb you as you work on the 3.4 kernel, but it'd be great if you could give us some hints :highfive:
    View
    21
    Ziyan
    Ziyan
    Well, today was a good day - remember, this is stock kernel, no mods or whatsoever, only about 1k official commits from TI. I let you guys figure out what's new :good:

    It's still not ready, but soon it will be. ;)
    View
    11
    Ziyan
    Ziyan
    Here's a test version: http://xdaforums.com/galaxy-nexus/development/ddk-1-9-omnirom-ddk-1-9-test-version-t2814977
    View
    6
    ILA
    ILA
    samcortez said:
    I am really newbie on it and I readed the whole thread but I wanted to know: you're just putting new GPU drivers on 3.0 kernel, right? Not 3.4 kernel for now, am I right?
    Click to expand...
    Click to collapse

    Yes, he "just" updated the GPU drivers for the 3.0 kernel... The man added over a 1000!!! commits to the kernel. My eyes would pop out if I did that... Huge respect for the dev and also everyone that helped him out!
    View

New posts