• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [DEV] Continuing Triumph ICS Development

OK, looks like the problem with hdmid refusing to start isn't because of the compile flag (it must be getting set as expected), but because we're using the old proprietary one from the phone originally. The hdmid daemon compiled from the frameworks runs, even on an unmodified alpha build 0.6.8.9. It still doesn't display anything though, so no point in bringing it into the build yet.

Hopefully I'll get some time this weekend to look into what the daemon is doing.

You sure that is what it is? I pushed the hdmid from the andro-id rom to Tickerguys CM7 and it ran fine, but when I pushed it to CM9, I still got that same error that you get when you run the proprietary one.

What exactly did you change to get it to compile in the one from frameworks?
 
Yeah, we shouldn't have to hack cyanogenmod's vendor repo; that's why i set it back to upstream. However, I think I see the problem. I'll have to test it out when I get the chance later.

Ok, so I was wrong. The cm7 repo did require that either we hack the cyanogenmod vendor repo or hack the system/build repo. I opted to go with what Isaac did and just forked his repo. The cm7 repo is back up and running. I just completed a cm7 build and it works fine now.
 
You sure that is what it is? I pushed the hdmid from the andro-id rom to Tickerguys CM7 and it ran fine, but when I pushed it to CM9, I still got that same error that you get when you run the proprietary one.

What exactly did you change to get it to compile in the one from frameworks?
All I did was do a find for hdmid on the build directory since I saw there's source for hdmid. It gets compiled by the makefiles we have already, but the build is configured to select the one from proprietary since it exists.

I pushed android/out/target/product/triumph/obj/EXECUTABLES/hdmid_intermediates/hdmid to the phone and it executes. Rebooted and ps shows hdmid gets started automatically and stays running as well. The executable built from source is very slightly larger than the one in proprietary--15396 vs 15418 bytes.

I imagine the proprietary hdmid and the one from the andro-id ROM are the same and built from the same source as the one in the CM9 tree, but something changed in the GB->ICS transition that makes the binary prebuilt for GB not work on ICS. The function those binaries were looking for exists in our GUI lib.

My first attempt was to add "COMMON_GLOBAL_CFLAGS += -DQCOM_HDMI_OUT" to the BoardConfig since the surface compositor's enable HDMI output is wrapped around that and use the proprietary hdmid but got the same error. That's when I did the find and noticed that we are building hdmid from source, so I pushed that on and it runs.

Do you want to give that a try and see if hdmid runs for you?

EDIT: Got a chance to look at a logcat with hdmid starting finally. It's strange, it looks like android_get_control_socket is failing without setting errno -

Code:
E/HDMIDaemon(10509): Obtaining file descriptor socket 'hdmid' failed: Success

if ((mFrameworkSock = android_get_control_socket(HDMI_SOCKET_NAME)) < 0) {
        LOGE("Obtaining file descriptor socket '%s' failed: %s",
             HDMI_SOCKET_NAME, strerror(errno));
        return -1;
    }

EDIT2: That error goes away if I invoke hdmid with "start hdmid" instead of "/system/bin/hdmid".

D/HDMIDaemon(10870): readyToRun: success
 
I've hit a wall with my limited programming knowledge trying to get HW OMX video decoding working (ie. Netflix and LQ Youtube). So here is what I've been trying and if anyone has any suggestions let me know.

I've been basing my work off that of LorDClockaN's IceColdSandwich and existz's aospX ROMs for the HTC Desire HD. Both of those ROMs have working video decoding using the same Adreno 205 chip we have in the Triumph.

I started with Mantera's ICS repo (obviously) and merged in this commit from the cyanogenmod gerrit (credit for that commit goes to Dalingrin and the Touchpad team).

I then created a directory at vendor/qcom-opensource/omx and cloned the mm-core and mm-video repos from existz (here and here)

At this point, the build will fail without this and this and this

Here's where things start to get confusing for me

This commit adds some omx realated things to the product packages in the 7x30 common mk file. Since we don't use the common 7x30 repo, I added those packages to our device_triumph.mk.

This one looked important so I added it to our ueventd.triumph.rc

This one looked important so I threw it in also.


So from that point I started making builds. The first couple had no sound whatsoever, so I threw in this and this. After that sound worked again, but video decoding still didn't. At this point I poked around and started trying some other things. I don't remember all the changes I made after that point, but now when I build it bootloops trying to start audio_policy.

So at this point, I'm about ready to take a break for a few days then start from scratch with Mantera's repo so I figured I would try to document as many of my steps as possible to help anyone else who wants to take a shot at it.

While typing this up, I noticed that there is a difference between this and this. Maybe that is part of my problem...
 
At this point, the build will fail without this and this and this

Regarding the middle commit in your sentence above, don't do that one again. It's already in our repo. See this commit:

https://github.com/mantera/android_system_core/commit/9b5169b0cdf50b2fa0dad3f7931bd654c17bb738

Of course, that breaks our mic again unless you do this:

https://github.com/mantera/android_system_core/commit/1ac4af3405f4de26af8032f0ecf58f2d038af641

I just realized that I forgot to push it up. Sorry. repo sync and you should have them.

Regarding your bootloop. Did you change the media_profiles.xml file by chance? When I was messing with the media_profiles.xml file, I also experienced bootloops when loading the audio_policy.
 
I have to say I've thoroughly enjoyed poking around with HDMI the last couple days. I hardly get a chance to do this kind of thing anymore.

Right now I've got the adv7520 driver kind-of communicating with hdmid, and the communication path between hdmid and the Android frameworks is OK. It threw me off for a couple hours that because of the way the communication is structured between hdmid and the framework, simply pushing a new hdmid to the phone and starting it wont allow the daemon to work as expected. You have to restart the phone so the framework sends out the "start" event again, otherwise hdmid will not work correctly.

hdmid appears that it is designed to work with a newer interface to the hdmi driver support, so right now I don't believe HDCP or HPD (isn't necessary) will work. I don't think it will detect powering up with the HDMI cable connected will utilize the display either. It's only triggering off the interrupt of cable detected right now. I also hard-coded in 720p@60Hz for now. The resolution detection can be changed in hdmid if we don't want to touch the driver level, but I believe to get HDCP to work we'd need to get the interface created in the driver.

I've got a blank screen coming up reliably on my TV--it no longer complains there's no signal present. The signal is killed when the phone's screen turns off and comes back when the phone's screen turns on as well. I don't have a picture up yet though.

This is the first time I've used HDMI on an Android device. Does anyone know if stock ROMs only output over the HDMI if a video app, etc. is playing? Or do they mirror the launcher and everything as well?

There's a couple changes upstream related to HDMI which are hung up in Gerrit which might help with getting it working 100%: 11978 and 12735. I also wonder if the problems we're seeing in other areas with getting some video to work is related.

For the curious, here's what my logcat looks like without klogd running at this point -

HDMI insertion:
Code:
D/HDMIDaemon(  153): checking uevent buffer (online@/kernel/hdmi_kset/hdmi_kobj)
D/HDMIDaemon(  153): checking uevent s (online@/kernel/hdmi_kset/hdmi_kobj)
D/HDMIDaemon(  153): attempting to handle  uevent (online@/kernel/hdmi_kset/hdmi_kobj)
D/HDMIDaemon(  153): processUevent: event.action == 3
D/HDMIDaemon(  153): readResolution: read resolution U:1280x720p-0 (HACK expected U:1280x720p-0)
D/HDMIDaemon(  153): readResolution: resolution match, overwriting with 4
D/HDMIDaemon(  153): readResolution: new res: 4
D/HDMIDaemon(  153): sendCommandToFramework: 'hdmi_connected: 4' successful
E/HDMIListener(  233): handleEvent 'hdmi_connected: 4'
E/HDMIService(  233): Broadcasting ... HDMI_CABLE_CONNECTED
E/HDMIListener(  233): writeCommand: 'change_mode: 4'
D/HDMIDaemon(  153): change_mode:
E/HDMIListener(  233): writeCommand: 'enable_hdmi'
D/HDMIService(  233): Broadcast HDMI connected
E/HDMIService(  233): Broadcasting ... HDMI_CONNECTED, modes: 1
D/HDMIDaemon(  153): enable_hdmi
D/HDMIDaemon(  153): processFrameworkCommand: setResolution with =4
HDMI removal:
Code:
D/HDMIDaemon(  153): checking uevent buffer (offline@/kernel/hdmi_kset/hdmi_kobj)
D/HDMIDaemon(  153): checking uevent s (offline@/kernel/hdmi_kset/hdmi_kobj)
D/HDMIDaemon(  153): attempting to handle  uevent (offline@/kernel/hdmi_kset/hdmi_kobj)
D/HDMIDaemon(  153): processUevent: event.action == 4
D/HDMIDaemon(  153): sendCommandToFramework: 'hdmi_disconnected' successful
E/HDMIListener(  233): handleEvent 'hdmi_disconnected'
E/HDMIService(  233): Broadcasting ... HDMI_CABLE_DISCONNECTED
E/HDMIService(  233): Broadcasting ... HDMI_DISCONNECTED
D/HDMIDaemon(  153): disable_hdmi
E/HDMIListener(  233): writeCommand: 'disable_hdmi'
E/HDMIListener(  233): writeCommand: 'hdmi_hpd: 1'
D/HDMIDaemon(  153): hdmi_hpd: : 1
E/HDMIDaemon(  153): writeHPDOption: state file '/sys/class/graphics/fb1/hpd' not found
 
Below is a snippet of a logcat I posted at https://gist.github.com/1970405
Maybe someone can help me resolve this bug.

03-02 15:59:07.564: I/DEBUG(3533): debuggerd: Feb 11 2012 16:34:54
03-02 15:59:09.334: D/Camera(3487): hardware/Camera.java getParameters()
03-02 15:59:09.334: D/Camera-JNI(3487): getParameters in android_hardware_Camera.cpp
03-02 15:59:09.334: D/Camera(3487): getParameters in Camera.cpp
03-02 15:59:09.334: D/ICamera(3487): getParameters in ICamera.cpp
03-02 15:59:09.334: D/CameraService(2338): CameraService::Client::getParameters
03-02 15:59:09.334: D/CameraService(2338): getParameters in CameraHardwareInterface.h in libcameraservice
03-02 15:59:09.334: D/CameraHAL(2338): camera_get_parameters
03-02 15:59:09.334: D/CameraHAL(2338): camera_get_parameters dev->cameraid: 0
03-02 15:59:09.334: V/QualcommCameraHardware(2338): sendCommand: EX
03-02 15:59:09.334: A/libc(2338): Fatal signal 11 (SIGSEGV) at 0xfffffff0 (code=1)
03-02 15:59:09.739: I/DEBUG(3533): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-02 15:59:09.739: I/DEBUG(3533): Build fingerprint: 'motorola/motorola_triumph/triumph:4.0.3/IML74K/223971:user/release-keys'
03-02 15:59:09.739: I/DEBUG(3533): pid: 2338, tid: 2343 >>> /system/bin/mediaserver <<<
03-02 15:59:09.739: I/DEBUG(3533): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr fffffff0
03-02 15:59:09.739: I/DEBUG(3533): r0 00000001 r1 fffffff0 r2 00000001 r3 00000000
03-02 15:59:09.739: I/DEBUG(3533): r4 00000001 r5 fffffff0 r6 2bd40cf8 r7 2bd40cfc
03-02 15:59:09.739: I/DEBUG(3533): r8 2b056d1c r9 00000922 10 000003f5 fp 00000000
03-02 15:59:09.739: I/DEBUG(3533): ip 2abab07c sp 2bd40ca0 lr 2ab63338 pc 2ab63338 cpsr 800f0010
03-02 15:59:09.739: I/DEBUG(3533): d0 643a64696f72646e d1 6472656767756265
03-02 15:59:09.739: I/DEBUG(3533): d2 7265746e49657263 d3 6920682e6563616f
03-02 15:59:09.739: I/DEBUG(3533): d4 745f3233746e6975 d5 3233746e6975202c
03-02 15:59:09.739: I/DEBUG(3533): d6 4220000041300000 d7 3f8000003debc8c1
03-02 15:59:09.739: I/DEBUG(3533): d8 0000000000000000 d9 0000000000000000
03-02 15:59:09.739: I/DEBUG(3533): d10 0000000000000000 d11 0000000000000000
03-02 15:59:09.739: I/DEBUG(3533): d12 0000000000000000 d13 0000000000000000
03-02 15:59:09.739: I/DEBUG(3533): d14 0000000000000000 d15 0000000000000000
03-02 15:59:09.739: I/DEBUG(3533): d16 3ff0000000000000 d17 3ff0000000000000
03-02 15:59:09.739: I/DEBUG(3533): d18 7e37e43c8800759c d19 3fcce748f8ed8687
03-02 15:59:09.739: I/DEBUG(3533): d20 3f11504c209ef562 d21 bebbb370fb6f0b05
03-02 15:59:09.739: I/DEBUG(3533): d22 3ff0000000000000 d23 3ff43d16aee00482
03-02 15:59:09.739: I/DEBUG(3533): d24 3e66376972bea4d0 d25 0000000000000000
03-02 15:59:09.739: I/DEBUG(3533): d26 0000000000000000 d27 0000000000000000
03-02 15:59:09.739: I/DEBUG(3533): d28 0000000000000000 d29 0000000000000000
03-02 15:59:09.744: I/DEBUG(3533): d30 0000000000000000 d31 0000000000000000
03-02 15:59:09.744: I/DEBUG(3533): scr 60000010
03-02 15:59:09.844: I/DEBUG(3533): #00 pc 00005338 /system/lib/libcutils.so (android_atomic_add)
03-02 15:59:09.844: I/DEBUG(3533): #01 pc 0001f378 /system/lib/libutils.so (_ZNK7android12SharedBuffer7acquireEv)
03-02 15:59:09.854: I/DEBUG(3533): #02 pc 000200ba /system/lib/libutils.so (_ZN7android8String165setToERKS0_)
03-02 15:59:09.854: I/DEBUG(3533): #03 pc 00001f4e /system/lib/hw/camera.msm7x30.so (_Z21camera_get_parametersP13camera_device)
03-02 15:59:09.854: I/DEBUG(3533): #04 pc 00008e3a /system/lib/libcameraservice.so (_ZNK7android13CameraService6Client13getParametersEv)
03-02 15:59:09.854: I/DEBUG(3533): #05 pc 00014ed2 /system/lib/libcamera_client.so (_ZN7android8BnCamera10onTransactEjRKNS_6ParcelEPS1_j)
03-02 15:59:09.854: I/DEBUG(3533): #06 pc 00017d4c /system/lib/libbinder.so (_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j)
03-02 15:59:09.854: I/DEBUG(3533): #07 pc 0001b04a /system/lib/libbinder.so (_ZN7android14IPCThreadState14executeCommandEi)
03-02 15:59:09.854: I/DEBUG(3533): #08 pc 0001b226 /system/lib/libbinder.so (_ZN7android14IPCThreadState14joinThreadPoolEb)
03-02 15:59:09.854: I/DEBUG(3533): #09 pc 000204d8 /system/lib/libbinder.so
03-02 15:59:09.854: I/DEBUG(3533): #10 pc 00021176 /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv)
03-02 15:59:09.854: I/DEBUG(3533): #11 pc 000217bc /system/lib/libutils.so
03-02 15:59:09.854: I/DEBUG(3533): #12 pc 00012c74 /system/lib/libc.so (__thread_entry)
03-02 15:59:09.854: I/DEBUG(3533): #13 pc 000127a4 /system/lib/libc.so (pthread_create)
03-02 15:59:09.854: I/DEBUG(3533): code around pc:
03-02 15:59:09.854: I/DEBUG(3533): 2ab63318 e1853f92 e3530000 1afffffa e8bd8070 .?....S.....p...
03-02 15:59:09.854: I/DEBUG(3533): 2ab63328 e92d4070 e1a04000 e1a05001 ebffffd4 p@-..@...P......
03-02 15:59:09.854: I/DEBUG(3533): 2ab63338 e1950f9f e0802004 e1853f92 e3530000 ..... ...?....S.
03-02 15:59:09.854: I/DEBUG(3533): 2ab63348 1afffffa e8bd8070 e1a01000 e3e00000 ....p...........
03-02 15:59:09.854: I/DEBUG(3533): 2ab63358 eafffff2 e1a01000 e3a00001 eaffffef ................
03-02 15:59:09.854: I/DEBUG(3533): memory map around addr fffffff0:
03-02 15:59:09.854: I/DEBUG(3533): 7ee38000-7ee4d000 [stack]
03-02 15:59:09.854: I/DEBUG(3533): (no map for address)
03-02 15:59:09.854: I/DEBUG(3533): (no map above)
03-02 15:59:09.854: I/DEBUG(3533): stack:
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c60 00018340 [heap]
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c64 004d0090
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c68 2b0535b9 /system/lib/libcameraservice.so
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c6c 2ab36474
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c70 000003f5
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c74 2ab02a81 /system/lib/libc.so
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c78 00018340 [heap]
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c7c 0000000c
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c80 00000010
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c84 00000000
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c88 0000a008 [heap]
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c8c 00000000
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c90 2bd40cb4
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c94 2ab9c349 /system/lib/libutils.so
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c98 df0027ad
03-02 15:59:09.854: I/DEBUG(3533): 2bd40c9c 00000000
03-02 15:59:09.854: I/DEBUG(3533): #00 2bd40ca0 2bd40cf4
03-02 15:59:09.854: I/DEBUG(3533): 2bd40ca4 2bd40cdc
03-02 15:59:09.854: I/DEBUG(3533): 2bd40ca8 2bd40cf8
03-02 15:59:09.854: I/DEBUG(3533): 2bd40cac 2ab9c37b /system/lib/libutils.so
03-02 15:59:09.854: I/DEBUG(3533): #01 2bd40cb0 2bd40cf4
03-02 15:59:09.854: I/DEBUG(3533): 2bd40cb4 2ab9d0bf /system/lib/libutils.so
03-02 15:59:10.854: D/Camera(3487): Parameters getParameters() from native_getParameters():

img, #cubbies-overlay{ -moz-transition-property: margin, box-shadow, z-index; -moz-transition-duration: 0.1s; -webkit-transition-property: margin, box-shadow, z-index; -webkit-transition-duration: 0.1s; } .cubbies-selected{ z-index: 9999; box-shadow: 3px 3px 8px -1px blue !important; cursor: pointer !important; margin: -3px 3px 3px -3px; } .cubbies-selected:active{ box-shadow: 2px 2px 5px -1px darkblue !important; margin: -1px 1px 1px -1px; } #cubbies-overlay{ position: fixed; z-index: 9999; bottom: 30px; left: 30px; box-shadow: 0 2px 3px rgba(0,0,0,0.8); border: none; } #cubbies-overlay:hover{ box-shadow: 0 2px 3px rgb(0,0,0); }
 
Regarding the middle commit in your sentence above, don't do that one again. It's already in our repo. See this commit:

https://github.com/mantera/android_system_core/commit/9b5169b0cdf50b2fa0dad3f7931bd654c17bb738

Of course, that breaks our mic again unless you do this:

https://github.com/mantera/android_system_core/commit/1ac4af3405f4de26af8032f0ecf58f2d038af641

I just realized that I forgot to push it up. Sorry. repo sync and you should have them.

Regarding your bootloop. Did you change the media_profiles.xml file by chance? When I was messing with the media_profiles.xml file, I also experienced bootloops when loading the audio_policy.

Ok, so I reset my entire build directory back to your repo, synced down the latest changes and started over. I followed my own steps carefully and was able to build. This one boots, and has audio working, but the video decoding still isn't playing nice.

Logcat is showing me the same error as on Mantera's builds.

I've combed through both LC's and Existz's githubs multiple times, and I don't think I missed anything. I feel like I'm missing something simple somewhere, maybe a flag in a mk file or something that's causing the stagefright and omx changes not to be built or something, but at this point I'm pretty much out of ideas.

The only other difference I can think of between the Desire HD and our Triumph is the fact that the DHD has a GB .35 kernel and we don't. Maybe the kernel is somehow involved in this.
 
I have to say I've thoroughly enjoyed poking around with HDMI the last couple days. I hardly get a chance to do this kind of thing anymore.

Right now I've got the adv7520 driver kind-of communicating with hdmid, and the communication path between hdmid and the Android frameworks is OK. It threw me off for a couple hours that because of the way the communication is structured between hdmid and the framework, simply pushing a new hdmid to the phone and starting it wont allow the daemon to work as expected. You have to restart the phone so the framework sends out the "start" event again, otherwise hdmid will not work correctly.

hdmid appears that it is designed to work with a newer interface to the hdmi driver support, so right now I don't believe HDCP or HPD (isn't necessary) will work. I don't think it will detect powering up with the HDMI cable connected will utilize the display either. It's only triggering off the interrupt of cable detected right now. I also hard-coded in 720p@60Hz for now. The resolution detection can be changed in hdmid if we don't want to touch the driver level, but I believe to get HDCP to work we'd need to get the interface created in the driver.

I've got a blank screen coming up reliably on my TV--it no longer complains there's no signal present. The signal is killed when the phone's screen turns off and comes back when the phone's screen turns on as well. I don't have a picture up yet though.

This is the first time I've used HDMI on an Android device. Does anyone know if stock ROMs only output over the HDMI if a video app, etc. is playing? Or do they mirror the launcher and everything as well?

There's a couple changes upstream related to HDMI which are hung up in Gerrit which might help with getting it working 100%: 11978 and 12735. I also wonder if the problems we're seeing in other areas with getting some video to work is related.


on the stock Triumph ROM. HDMI output mirrors absolutely everything. when you flip from vertical to horizontal, the image on the TV does the same. most TVs can make the vertical image the right aspect ratio, but PC monitors ive found try to stretch it edge to edge, so you get a super wide view.

back on point, yes it mirrors everything android does. and at 480p (even videos at a hd resolution are scaled to the 480p before being sent out, since its a 1:1 pixel mirror of the device screen.

i assume/hope thats a software problem and I really hope ICS is capable of resizing interface elements to tru 720p output. instead of 480p upscaled to a 720 output ( similar image quality to playing a DVD full screen on a hdtv)


if you cant tell, thats a huge problem I have with the triumph :P
 
I have to say I've thoroughly enjoyed poking around with HDMI the last couple days. I hardly get a chance to do this kind of thing anymore.

Right now I've got the adv7520 driver kind-of communicating with hdmid, and the communication path between hdmid and the Android frameworks is OK. It threw me off for a couple hours that because of the way the communication is structured between hdmid and the framework, simply pushing a new hdmid to the phone and starting it wont allow the daemon to work as expected. You have to restart the phone so the framework sends out the "start" event again, otherwise hdmid will not work correctly.

hdmid appears that it is designed to work with a newer interface to the hdmi driver support, so right now I don't believe HDCP or HPD (isn't necessary) will work. I don't think it will detect powering up with the HDMI cable connected will utilize the display either. It's only triggering off the interrupt of cable detected right now. I also hard-coded in 720p@60Hz for now. The resolution detection can be changed in hdmid if we don't want to touch the driver level, but I believe to get HDCP to work we'd need to get the interface created in the driver.

I've got a blank screen coming up reliably on my TV--it no longer complains there's no signal present. The signal is killed when the phone's screen turns off and comes back when the phone's screen turns on as well. I don't have a picture up yet though.

This is the first time I've used HDMI on an Android device. Does anyone know if stock ROMs only output over the HDMI if a video app, etc. is playing? Or do they mirror the launcher and everything as well?

There's a couple changes upstream related to HDMI which are hung up in Gerrit which might help with getting it working 100%: 11978 and 12735. I also wonder if the problems we're seeing in other areas with getting some video to work is related.

For the curious, here's what my logcat looks like without klogd running at this point -

Hmm so I have 3 different versions of hdmid (3 different sizes). The one built with CM9, the andro-id one and the proprietary one.

None of the 3 versions will run on CM7 built from Mantera's repo. The proprietary and andro-id one run on TG's CM7 (haven't tried the CM9 one). And as you know only the one built with CM9 runs on CM9.

I was thinking getting this working with CM7 first would be easier, but maybe not especially with these problems getting the daemon running and for the possible HDMI support upstream on CM9.

Also not sure if you already know this but back in the day, Isaac had made progress on HDMI and he put those changes into an experimental branch. For example see https://github.com/ikarosdev/android_hardware_libhardware/commits/gingerbread-experimental and https://github.com/ikarosdev/android_device_motorola_triumph/commits/gingerbread-experimental. I'm not sure how applicable those libhardware changes will be to CM9 as it looks like much of that area (such as the gralloc.h file) has changed.

Also is restarting the phone necessary after you push it or is it equivalent to just do start hdmid from the shell (after it is running)? What more did you change to get the blank screen come up? I think that is the point that Isaac got to but then got stuck after that- I think those libhardware changes got him to that point.
 
Below is a snippet of a logcat I posted at https://gist.github.com/1970405
Maybe someone can help me resolve this bug.

Sorry progmanos, atm, I'm out of ideas. Does cm7 have the same camera call?

Also, I can't really tell for sure from your logcat, but does the camera HAL module actually load? Or are you still getting that "can't connect to camera HAL" error message? It doesn't look like you are, but just wanted to be sure.

Also, I wonder what the cm7 call is to get the camera parameters? Have you tried changing the function to the same one that cm7 uses to call the parameters?
 

Yeah, I've been looking at that. Still trying to get a build to complete though so we'll see if it even works. Will have to try again later when I get the time. Also, it may not work with our wifi modules. We may need to find new wifi modules that will work with our phone in order to have the new kernel work properly with wifi.

With our 2.6.32.x kernel, whenever I changed the kernel version number, wifi would break; it seemed that the wifi module was hard-coded to specifically look for a 2.6.32.9 version of the kernel or it wouldn't load. However, I've tried the libra modules from a bunch of different ROMs on xda and haven't found one that will work yet with the Triumph.

On a side note, did anyone happen to get a chance to download that HUAWEI ICS beta that they put out in December temporarily for the Ideos phones? I wonder if the modules from that will work for us.
 
Progmanos any update on the camera?

I'm just going to go out on a limb here and say no. I'm sure he will give an update when there is one to give. This is complicated stuff and it takes A LOT of time to grasp even for experienced developers. If only there were more hours in a day....


Anyway... I finally got some more time to look at HDMI again. I figured out the source of the error when starting the daemon and I figured I should document it for anyone else who comes across it. The error that says:
reloc_library[1311]: 770 cannot locate '_ZN7android21SurfaceComposerClient16enableHDMIOutputEi'...
CANNOT LINK EXECUTABLE

The source of that problem is from libsurfaceflinger_client.so so swapping that with andro-ids version fixed it.


@aaronfitz
Not sure if you are still working on this but I grabbed the logs of a successful hdmi connection/disconnect while running andro-id. Hopefully comparing it against what we are getting may point us in the right direction.

On disconnect:
Code:
D/HDMIDaemon(  137): processUevent: event.action == offline
D/HDMIDaemon(  137): sendCommandToFramework:'hdmi_disconnected' successful
E/HDMIListener(  187): handleEvent 'hdmi_disconnected'
E/HDMIService(  187): Broadcasting ... HDMI_CABLE_DISCONNECTED
V/AudioService(  187): HDMI disconnected
E/HDMIService(  187): Broadcasting ... HDMI_DISCONNECTED
E/HDMIListener(  187): writeCommand: 'disable_hdmi'
On connect:
Code:
D/HDMIDaemon(  137): processUevent: event.action == online
D/HDMIDaemon(  137): bool android::HDMIDaemon::readResolution(): edid_modes file empty buf== '4' mode== '4'
D/HDMIDaemon(  137): sendCommandToFramework:'hdmi_connected: 4' successful
E/HDMIListener(  187): handleEvent 'hdmi_connected: 4'
D/HDMIService(  187): notifyHDMIConnected ... Broadcasting On
D/LightsService(  187): Incoming Notification: ID(17302346), Title(Video out connected (HDMI)), Show Light(false), Default(false), Color(0x0), onMS(0), offMS(0)
V/AudioService(  187): HDMI connected
E/HDMIService(  187): Broadcasting ... HDMI_CONNECTED, modes: 1
E/HDMIService(  187): Broadcasting ... HDMI_CABLE_CONNECTED
D/HDMIDaemon(  137): bool android::HDMIDaemon::readResolution(): edid_modes file empty buf== '4' mode== '4'
D/HDMIDaemon(  137): GET Info<ID=4 1280x720 (110,40,220), (5,5,20) 74MHz>
D/HDMIDaemon(  137): SET Info<ID=4 => Info<ID=4 1280x720 (110,40,220), (5,5,20) 74MHz>
E/HDMIListener(  187): writeCommand: 'enable_hdmi'
I am going to keep trying to get this on CM7 for now. I haven't gotten any communication going with the daemon yet even though it seems to be running and started. Any ideas?
I'm hoping I'll have more time next week to work on this more.
 
BTW: An update on what I'm working on currently. I got the 2.6.35.14 kernel "mostly" working. It boots up but something's not right just yet. So I've been spending time trying to figure out wtf that is causing the fc's. If anyone has suggestions on this particular error message in logcat, it would be helpful:

E/rmt_storage( 164): rmt_storage shared memory ioctl failed

And here's the full dmesg:

Motorola Triumph 2.6.35.14 kernel dmesg - Pastebin.com
 
I do this as user, not root, (I really don't see a reason to do this as root) on my computer
Code:
mkdir ~/bin

PATH=~/bin:$PATH

curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo

chmod a+x ~/bin/repo

mkdir android

cd ~/android

repo init -u https://github.com/mantera/android.git -b ics

repo sync

cd ~/android/vendor/cm/

./get-prebuilts

cd ~/android

repo sync

. build/envsetup.sh && brunch triumph
You will now be prompted to provide your name and email address. Please give it real details; that way you can use the gerrit code review tool if your email is connected with a Google account."

Any direction would be appreciated. (no prompt for google account info)
Delete both the android and bin folders and try again from scratch
 
Back
Top Bottom