Debugging HDMI output problem

[ffxx68]

Hi,

I've started integrating the HDMI driver into our JB code, but I haven't managed to make the display show onto HDMI. It's still going to the tablet LCD.

I've collected a few debug notes with hat I've noticed so far, here:

  https://github.com/Renesas-EMEV2/Documentation/blob/emev-4.1/devnotes/HDMI.txt

Is anyone willing to get into this issue a bit deeper and carry work on from where I left?

thanks
Fabio

[ffxx68]

Note how latest build (uploaded Jul 9) already includes the HDMI drivers I'm referring above.

[ffxx68]

Under the usual JB beta location I've saved a debug version of the kernel image:

 https://www.dropbox.com/s/s99vd3uw5x5fazm/uImage4_HDMIdebug

for testing purposes. The image can be installed downloading it somewhere and pushing it to device with:

adb push arch/arm/boot/uImage4 /tmp/uImage4
adb shell dd if=/tmp/uImage4 of=/dev/block/mmcblk0p2

If anyone has a chance to plug the device to an HDMI display, that might help me debug why HDMI isn't working yet. I tested on my TV and it doesn't work yet, but I'm not sure if it depends on TV, or the kernel...

Procedure is:

- install image on device as said above
- plug device (turned off) to an hdmi display (turned off as well)
- plug a usb mouse to device, through the mini-USB adapter
- turn on display
- turn on device and wait
- once done, unplug mouse and plug USB cable to a PC to collect dmesg output with:

adb shell dmesg > dmesg.out
adb logcat > logcat.out

Thanks to anyone helping with this...
Fabio

[shield.liu]

Sorry for quite long time not visited here. I have some patches that seems can drive HDMI output on the HDMI dongle, let me past here as a reference.

Hope it can help you.

B.R

在 2013年3日星期四UTC+8下午11时27分07秒，ffxx68写道：

Hi,

I've started integrating the HDMI driver into our JB code, but I haven't managed to make the display show onto HDMI. It's still going to the tablet LCD. hel

[ffxx68]

Thanks a lot Liu - very helpful!
Glad to hear from you again...

On Thursday, 3 October 2013 08:27:07 UTC-7, ffxx68 wrote:

[ffxx68]

Hi Liu,

thanks again for these patches.
I'm reviewing them and noticed some of them (e.g. commit-ab53d57) introduced changes to select 100%, 95%, 90%, 85% resolution in 720P HDMI mode.
Issue is that I don't have any HDMI option in userland (Android settings).
Is it possible there's some associated change to the AOSP code tool? Or how to enable that setting option?

Unfortunately, I'm still not able to view HDMI output on my TV, with JB, in spite I think I have all patch changes in place.
I'm still double checking patches, but it seems to me like default resolution is wrong (I can see the screen flashing on TV), and tablet LCD is kept on...
Note that on GB firmware TV shows HDMI output...

[shield.liu]

EMEV hardware can not support dynamic switching from LCD to HDMI, so when you configure HDMI output, there should nothing displayed from LCD.

If you can see somthing out from LCD, that means the driver or kernel configure wrong

When debugging, you can modify init.rc to disable Android display to startup by remove surfaceflinger service.

Then you can use adb shell to test framebuffer directlly, such as 

cat /bin/sh > /dev/fb/0

在 2013年12月11日星期三UTC+8上午12时37分20秒，ffxx68写道：

Hi Liu,

thanks again for these patches.

I'm reviewing them and notic.

[ffxx68]

Hi Liu,

I'm still struggling to try to use my tablet on my TV through HDMI... Indeed, yes I still can see LCD ebung on, but I wonder how the switch from LCD to HDMI happens.

Tuning on device plugged to TV, I can see from dmesg that the hdmi is detected:

<4>===== HDMI inserted =====
<6>emxx_fb: hdmi_output_setup - dev 0 - mode 2

(mode 2 meaning "HDMI 720P")

but later in the same I can see LCD hw being turned on, for example:

<7>emxx_lcdhw: lcd_module_hw_wakeup: 
<7>emxx_lcdhw: lcd_module_hw_spiw: ->cmd(0x02) ->param(0x00)
<7>emxx_lcdhw: lcd_hw_backlight_on:

So, looks like both HDMI and LCD are working a the same time, but my TV probably doesn't support the 800x480 and I can see an instable flashing picture on TV. Unusable.

I compared with the dongle kernel code and I'm suspecting that (since the kernel driver structure is EXTREMELY similar) some user-level action is performed on the Smallart dongle, to switch to HDMI mode through ioctl functions (emxx_fb) and call change_output() with the hdmi mode.

Is that possible?

thanks
Fabio

[ffxx68]

A switch using ioctl is found in the gralloc lib: device/renesas/emev/libgralloc/framebuffer.cpp:

int mapFrameBufferLocked(struct private_module_t* module)
{
 ...
    struct fb_fix_screeninfo finfo;
    if (ioctl(fd, FBIOGET_FSCREENINFO, &finfo) == -1) {
        LOGE("mapFrameBufferLocked - FBIOGET_FSCREENINFO error");
        return -errno;
    }
    /* Switch to the HDMI output mode */
    if(finfo.reserved[0] == 1){
    LOGI("Calling checkandsetHDMI...");
    checkandsetHDMI(fd);
    }
 ...

Then, checkandsetHDMI() sets the output mode to EMXX_FB_OUTPUT_MODE_HDMI_720P.

All depending on the value found in reserved[0], which seems like using the info passed by kernel here:

     for (i = 0; i < EMXX_FB_DEVICES; i++) {
                printk_info("hdmi_output_setup - dev %d - mode %d", i, event);
        struct fb_info *info = drvdata.info[i];
        info->var.reserved[0] = event;
    }

but from dmesg I can see that event = 2 (which is EMXX_FB_OUTPUT_MODE_HDMI_720P), while check above is expecting 1 !!!!

I tried fixing framebuffer.cpp, replacing if(finfo.reserved[0] == 1) with if(finfo.reserved[0] != 0), but issue is that rebuilding this lib and pushing it on device

 adb push out/target/product/emev/symbols/system/lib/hw/gralloc.emxx.so system/vendor/lib/hw/gralloc.emxx.so

it crashes on boot (/system/bin/surfaceflinger).

In fact, this code makes the grallox.emxx.so, which I had it prebuilt too (device/renesas/emev/sgx/um/system/vendor/lib/hw/gralloc.emxx.so) and I miss the original code of.

So, I have to guess a fix on kernel side, maybe trying to pass 1 into finfo.reserved[0], assuming that's the value being checked in the pre-built lib.

Liu, any suggestion?

[ffxx68]

Going forward with my debugging, let me report what I've found so far.

I have modified SGX driver code, so to switch to HDMI mode through ioctl (I have modified framebuffer_device_open(), after the call to ioctl FBIOGET_VSCREENINFO). This is what I get in logcat enabling debug logging:

I/IMGSRV  (  253): hal.c:550: hal_init: Graphics HAL loaded (err=0)
I/IMGSRV  (  253): framebuffer.c:1138: framebuffer_setup: entered function
I/IMGSRV  (  253): framebuffer.c:659: framebuffer_device_open: Checking output mode: 2
I/IMGSRV  (  253): framebuffer.c:661: framebuffer_device_open: Calling checkandsetHDMI
I/IMGSRV  (  253): framebuffer.c:532: checkandsetHDMI: entered function
I/IMGSRV  (  253): framebuffer.c:568: checkandsetHDMI: **TPfb: ioctl EMXX_FB_UPDATE_SCRN...
I/IMGSRV  (  253): framebuffer.c:568: checkandsetHDMI: **TPfb: ioctl EMXX_FB_UPDATE_SCRN...
I/IMGSRV  (  253): framebuffer.c:568: checkandsetHDMI: **TPfb: ioctl EMXX_FB_UPDATE_SCRN...
I/IMGSRV  (  253): framebuffer.c:577: checkandsetHDMI: left function
I/IMGSRV  (  253): framebuffer.c:930: framebuffer_device_open: left function
I/IMGSRV  (  253): framebuffer.c:1168: framebuffer_setup: left function
I/IMGSRV  (  253): gralloc.c:2105: gralloc_setup: entered function
I/IMGSRV  (  253): gralloc.c:2137: gralloc_setup: left function
I/IMGSRV  (  253): gralloc.c:660: gralloc_device_alloc: entered function
E/IMGSRV  (  253): gralloc.c:694: gralloc_device_alloc: Invalid color format (0)

I don't like the final error ... but I don't quite understand yet the origin of it.

From kernel logging, I can see first the emxxlfb init, and later later the switch to HDMI through change_output():

...

<4>===== HDMI inserted =====
<6>emxx_fb: hdmi_output_setup

...
<4>HDMISetCSCScale:Input mode is RGB444
<4>HDMISetCSCScale:Output mode is YUV444
<4>HDMISetCSCScale:CSC = RGB2YUV 2 HDMISetCSCScale:ITU709 0-255 HDMISetupAFE:SetupAFE()
<4>HDMIFireAFE:reg[61] = 00HDMIFireAFE:reg[62] = 19 HDMIFireAFE:reg[63] = 01 HDMIFireAFE:reg[64] = 1E HDMIFireAFE:reg[65] = 00
<4>HDMISetAVIInfoFrame:SetAVIInfo(): HDMISetAVIInfoFrame:
<4>HDMIHDCP_Authenticate:HDCP_Authenticate():
...
<4>HDMISetNCTS:SetNCTS(74250000,48000): Fs*128 = 6144000
<4>HDMISetAudioFormat:SetAudioFormat(2 channel,01,SampleFreq 48000Hz,AudSWL 24,00)
<4>HDMIConfigAudioInfoFrm:ConfigAudioInfoFrm(2)
...
<4>HDMICheckHDMITX:interrupt Authenticate Done.
...
<6>PVR: PVRCore_Init
<6>PVR_K:(Warning): _SetDispatchTableEntry: 0 PVRSRV_BRIDGE_ENUM_DEVICES PVRSRVEnumerateDevicesBW [3824, services4/srvkm/bridged/bridged_pvr_bridge.c]
...
<6>PVR_K:(Warning): _SetDispatchTableEntry: 115 PVRSRV_BRIDGE_SGX_SET_TRANSFER_CONTEXT_PRIORITY SGXSetTransferContextPriorityBW [3824, services4/srvkm/bridged/bridged_pvr_bridge.c]
<6>PVR: PVRSRVDriverProbe(pDevice=bf06ee50)
<6>PVR: EnableSystemClocks: Enabling System Clocks
<6>PVR: PVRCore_Init: major device 249
<7>emxx_lcdhw: init_lcdhw:
<7>emxx_lcdhw: lcd_module_hw_power_on:
<7>emxx_lcdhw: lcd_module_hw_spiw: ->cmd(0x03) ->param(0x01)
...
<7>emxx_lcdhw: lcd_module_hw_spiw: ->cmd(0x9d) ->param(0x00)
<7>emxx_lcdhw: lcd_hw_init:
...
<7>emxx_lcdhw: lcd_hw_start:

<7>emxx_lcdhw: lcd_module_hw_wakeup:
<7>emxx_lcdhw: lcd_module_hw_spiw: ->cmd(0x02) ->param(0x00)
<7>emxx_lcdhw: lcd_hw_backlight_on:

<4>==>>hdmi irq 0
<6>emxxlfb: Device 0: Framebuffer physical address: 0x4ab00000
<6>emxxlfb: Device 0: Framebuffer virtual address: 0xe1000000
<6>emxxlfb: Device 0: Framebuffer size: 16588800
<6>emxxlfb: Device 0: Framebuffer virtual width: 800
<6>emxxlfb: Device 0: Framebuffer virtual height: 5184
<6>emxxlfb: Device 0: Framebuffer width: 800
<6>emxxlfb: Device 0: Framebuffer height: 480
<6>emxxlfb: Device 0: Framebuffer stride: 3200
<6>emxxlfb: Device 0: LCM of stride and page size: 102400
<6>emxxlfb: Device 0: rounded buffer size: 8294400
<6>emxxlfb: Device 0: pixel format: 20
<6>emxxlfb: Device 0: Maximum number of swap chain buffers: 2
<6>emxxlfb: Device 0: PVR Device ID: 1
<6>PVR: Installing MISR with cookie bf07200c
<6>PVR: Installing device LISR SGX ISR on IRQ 62 with cookie c949f2c0
<6>PVR: OSUnMapPhysToLin: unmapping 16384 bytes from e2378000
<6>PVR_K:(Warning): SysFinalise: Version string: SGX revision = 1.2.0 [442, services4/system/emev/sysconfig.c]
...
<6>emxx_lcdhw: change_output: change_output old_mode: 0, new_mode: 2
<7>emxx_lcdhw: lcd_hw_backlight_off:
...
<7>emxx_lcdhw: lcd_module_hw_wakeup:
<4>HDMI output mode, lcd backlight off.
<4>==>>hdmi irq 0
<7>emxx_lcdhw: lcd_module_hw_power_off:

I'm not sure now where the "0" of the "invalid color format" comes from. Shouldn't it be "20", as "pixel format" above?

emxxlfb gets loaded only after kernel init has been completed, as it's loaded within init.emev.sh.

Should the emxxlfb be re-loaded, after switching to HDMI?

On Thursday, 3 October 2013 08:27:07 UTC-7, ffxx68 wrote:

[ffxx68]

Forget latest post. It wsa a coding error!

Issue now is that I get a wrong resolution, i.e. first emxxlfb is loaded with 800x480 resolution, then SET_OUTPUT switches to HDMI-720P mode:

<6>emxxlfb: Framebuffer Screen mode: 2

<6>emxxlfb: Device 0: Framebuffer physical address: 0x4ab00000
<6>emxxlfb: Device 0: Framebuffer virtual address: 0xe1000000
<6>emxxlfb: Device 0: Framebuffer size: 16588800
<6>emxxlfb: Device 0: Framebuffer virtual width: 800
<6>emxxlfb: Device 0: Framebuffer virtual height: 5184
<6>emxxlfb: Device 0: Framebuffer width: 800
<6>emxxlfb: Device 0: Framebuffer height: 480
<6>emxxlfb: Device 0: Framebuffer stride: 3200
<6>emxxlfb: Device 0: LCM of stride and page size: 102400
<6>emxxlfb: Device 0: rounded buffer size: 8294400
<6>emxxlfb: Device 0: pixel format: 20

<7>emxx_fb: emxx_fb_callback: fb(0) status(0) from(0)

<6>emxxlfb: Device 0: Maximum number of swap chain buffers: 2
<6>emxxlfb: Device 0: PVR Device ID: 1
<6>PVR: Installing MISR with cookie bf07200c

<6>PVR: Installing device LISR SGX ISR on IRQ 62 with cookie c94a22c0

<6>PVR: OSUnMapPhysToLin: unmapping 16384 bytes from e2378000
<6>PVR_K:(Warning): SysFinalise: Version string: SGX revision = 1.2.0 [442, services4/system/emev/sysconfig.c]

<4>emxx-mixer: codec_power_on
<4>HDMICheckHDMITX:INT_Handler: reg06 = 00
<4>HDMICheckHDMITX:INT_Handler: reg07 = 00

<4>HDMIFireAFE:reg[61] = 00HDMIFireAFE:reg[62] = 19 HDMIFireAFE:reg[63] = 01 HDMIFireAFE:reg[64] = 1E HDMIFireAFE:reg[65] = 00

<7>emxx_fb: emxx_fb_ioc_set_output: <start>
<7>emxx_fb: emxx_fb_ioc_set_output: set_output to 2
<7>emxx_fb: set_lcd_var: <start>
<7>emxx_fb: set_lcd_var: setting OUTPUT_MODE_HDMI_720P
<7>emxx_fb: set_lcd_var: < end >
<7>emxx_fb: set_lcd_size: <start>
<7>emxx_fb: set_lcd_size: setting OUTPUT_MODE_HDMI_720P
<7>emxx_fb: set_lcd_size: < end >

but it's too late, as the one set by emxxlfb.ko is the one used for display, which doesn't match the actual HDMI TV resolution.

I should find a way to ivert the order of these two calls:

1) emxxlfb.ko, which is loaded by init.rc, through the call to "pvrsrvctl -init" in init.emev.sh
2) emxx_fb_ioc_set_output, which is called within the Android HAL init stages.

Or, trigger a re-load of emxxlfb.ko after emxx_fb_ioc_set_output has changed output type to HDMI.

Or, anticipate emxx_fb_ioc_set_output to switch to HDMI mode within emxxlfb init stages.

On Thursday, 3 October 2013 08:27:07 UTC-7, ffxx68 wrote:

[ffxx68]

I moved the set_output into kernel code, early within the emxx_fb_open function:

static int emxx_fb_open(struct fb_info *info, int user)
{
      ...
        /* If in HDMI mode, first set paramaters accordingly */
        printk(KERN_INFO "emxx_fb_open: output mode is %u\n", info->var.reserved[0]);
        if (info->var.reserved[0] != 0) {
            ret = emxx_fb_set_output(info, info->var.reserved[0]);
            if (ret) return ret;
        }

This at least allowed to get the proper resolution to the emxxlfb module:

...
emxxlfb: Framebuffer screen mode: 2
emxx_fb_open: output mode is 2
emxx_fb_set_output to 2
==>>hdmi irq 0

emxxlfb: Device 0: Framebuffer physical address: 0x4ab00000

emxx_lcdhw: change_output: change_output old_mode: 0, new_mode: 2

emxxlfb: Device 0: Framebuffer virtual address: 0xe1000000

emxxlfb: Device 0: Framebuffer size: 16588800

emxxlfb: Device 0: Framebuffer virtual width: 1280
emxxlfb: Device 0: Framebuffer virtual height: 3240
emxxlfb: Device 0: Framebuffer width: 1280
emxxlfb: Device 0: Framebuffer height: 720
emxxlfb: Device 0: Framebuffer stride: 5120
emxxlfb: Device 0: LCM of stride and page size: 20480

emxxlfb: Device 0: rounded buffer size: 8294400

emxxlfb: Device 0: pixel format: 20

HDMI output mode, lcd backlight off.

...

Issue is that visualization is not correct, at least on my TV screen.

Android home overflows the screen borders and colors are wrong (black is green, white is pink). Image is also sometimes unstable. BUt at least I can see something and using an external mouse I can use it... somehow.

I have pushed this latest build on the usual DropBox folder. That doesn't impact in any way the LCD use, so it's no harm in trying it.

Is there anyone who could test the HDMI output on their monitor, to see if it depends on my TV or not?

On Thursday, 3 October 2013 08:27:07 UTC-7, ffxx68 wrote:

[marshel]

I have to reflash the ROM because of one error on startup that I cant surpass the lock screen, so i will test it on my panasonic LED TV 2012 asap,

But 1st I need to remember how to reflash.
It´s just vol.down+power than select the ZIP on SD, is this right?

Where I can find a ZIP with the last build?

Best regards,
Marshel

[ffxx68]

Hi Marshel ... good to hear someone is still using this old tablet :)

The latest build is found at https://www.dropbox.com/sh/r6tv8e5okrd9epo/lp0rqPeSIt (as usual - I don't keep the build history, just sources on github).
You should copy the content of this dir into the root of an SD card (2Gb max, FAT or FAT32 formatted).
Then on Pwr & Vol+ with SD card in (wait a few secs) a yellow menu would appear.
Select system update using Vol+/Vol- then press Pwr, to start flashing ROM.
That won't clean up user data (e.g. installed apps). There's a dedicate option for that. Use it before flashing if you want to wipe up your device completely.
Let me know...

Fabio

[ffxx68]

EUREKA! There was a critical difference (with respect to Smallart dongle kernel), that I had to backport.

Within lcd_hw_init() and change_output(), a call to change_pinsel_hdmi() had to be replaced with a call to change_pinsel_wvga(), even in case of the HDMI output types.

Probably the change_pinsel_hdmi() applies to boards with a different HDMI chipset, not the IT6610 (e.g. the ADV7523, used in the evaluation board).

Now I get a proper image on my TV (though my TV screen - a relatively old Samsung - doesn't fit all 720 pixels, looks like is missing some, so the screen borders crop a bit...).

I've pushed the new kernel image on the usual fw update folder.

  https://www.dropbox.com/sh/r6tv8e5okrd9epo/lp0rqPeSIt

Before pushing the source code onto github I'd like to make some other changes.

On Thursday, 3 October 2013 08:27:07 UTC-7, ffxx68 wrote:

[ffxx68]

I've posted both the kernel image ( uImage4 ) on Dropbox and the latest source code version on github.

Looks like HDMI output is working now, at 720P resolution.

On Thursday, 3 October 2013 08:27:07 UTC-7, ffxx68 wrote:

[Dmitriy B.]

Looks like HDMI output is working now, at 720P resolution.

Nice to see such progress, Fabio! Time to bring my RENA3 out since I dont have an LCD connected (broke it long ago).

Best Regards,

Dmitriy Beykun

[marshel]

I am really glad as well.

Great Job.

As you can see in the attached photos, it worked with 720p 60htz, I did not had the time to search for how to change to 1080i (but it seems to me that 1080i would be the same quality as 720p stretched on my screen).

I almost Thought the HDMI did not work because my mini hdmi cable is kinda tricky, but finally after some stretch ups here and there in the cable it worked.

I had to turn on the tablet with the cable plugged to make it work but that's OK. (see the photo with display errors ´cause of the cable)

The touch screen worked as well and the the UI mode changed to Tablet mode with the virtual buttons on the left lower side.

I did not test video/streaming video though, or even if audio was coming out nicely by the hdmi cable, but I believe if you can test it and it´s functional, the same would be for me.

Best regards!

Marcel

[ffxx68]

No way to change output resolution from Android. It would need a kernel hack and rebuild, as of now. I haven't tried going this way either, but I'm not sure having an interlaced 1080 would be much better than a progressive 720. And how much 1080-ready content do we have actually?

Yes, hardware is such that you need to boot it with HDMI plugged to an active display, to enable HDMI output. That's expected. Hot-switching the output mode would require a complex modification of both kernel and android (if ever possible - I'm not sure) ... and, once again, who does really need it?

Audio through HDMI is ok, except I haven't found a way to switch the internal speakers off. So, you have "double" output. Some debugging would be needed here... When I have time :)

I haven't noticed big issues with the video playback. One thing is when the CPU is very heavy loaded (e.g. displaying very rich web pages on browsers) display can black-flash briefly, sometimes. This is a HW bug of the chip release we have (I'm told from Liu), which is almost completely, though not 100%, worked around by a kernel hack.

About the Google error, I guess it's because the package includes a stripped off, "lightweight" version of Google Apps. Voice Search doesn't work either, for the same reason. I think I'm going to raise a new thread about that...

On Thursday, 3 October 2013 17:27:07 UTC+2, ffxx68 wrote: