2855 replies to this topic

[ejtagle]

Scanno, on 04 March 2013 - 08:26 AM, said:

Great I will have a go at this. The old Bluetooth stuff is that still needed or can in remove that?
I mean the hciattach. Is that now included?

The hciattach functionality is now included in libbt-vendor, We should need no part of bluez...

[Scanno]

ejtagle, on 04 March 2013 - 12:01 PM, said:

The hciattach functionality is now included in libbt-vendor, We should need no part of bluez...

OK i will remove all the old stuff and implement lbbt-vendor and put the files you posted in /etc/bluetooth

Lets see how far we can get. Do not know when i have time for this hopefully i can get some stuff done tonight.

[ejtagle]

fosser2, on 04 March 2013 - 03:06 AM, said:

Does this crash happen on the vega too like I posted?


I don't actually try to resume my tablet when this crash happens. As soon as I put it to sleep while on hdmi is when everything errors. It never makes it into LP1 while on hdmi.

fosser2: Could you please try the attached hwc to see if the hdmi crashes continue ? - What i did was to disable the hwc when the screen is turned off. This seems to cure the crashes. At the same time, i get a "Cannot lock buffer" error on gralloc, but, it does not crash, and, as soon as screen is turned on again, it resumes working without issues... or at least, that is what i believe...

To all the other people... Please do not integrate this hwc to any rom.. not yet... It still does not work properly. The problem i see is that when the system is turning off the screen, it still tries to render to a turned off video subsystem. When there is no hdmi connection, besides getting some flip errors, no other strange or harmful thing happens.

But, when HDMI is plugged in, there is an extra thing causing trouble... The mirroring operation that copies framebuffer to HDMI bombs gralloc. I still have to figure out if the problem is that we are turning off the screen (something that was not implemented in the original hwc), our interrupt emulation, or just the something that was changed by Google at the framework level.

I think it can be fixed, though. The attached hwc simply rejects calls when the screen is turned off (that is the difference to the previous hwc... This provents the crashes, but causes other issues... One of them is polluting logcat with hwc errors... But, at least, no more crashes... Really would appreciate testing of this hwc with and without hdmi plugged in...

Edit2: the new hwc seems to be working pretty well, at least, it does not crash gralloc when the tablet suspends and HDMI is plugged in.. I am testing it right now... Prper HDMI output, proper video decoding, no crashes and tablet continues resuming from deep sleep without issues.. If today tablet kees waking without issues, i think we could integrate it...

Attached Files

•  hwc_v2.rar   11.58K   15 downloads

Edited by ejtagle, 06 March 2013 - 11:55 AM.

[fosser2]

ejtagle,

Sorry, I should get around to testing this soon. I am mid-move as I just got a new job. Thanks for the work and I'm looking forward to testing it!

fosser2

[ejtagle]

fosser2, on 06 March 2013 - 06:00 PM, said:

ejtagle,

Sorry, I should get around to testing this soon. I am mid-move as I just got a new job. Thanks for the work and I'm looking forward to testing it!

fosser2

No problems... I am testing it myself, but i thought it could also solve the problems you have with your port ..

[fosser2]

ejtagle, on 06 March 2013 - 06:31 PM, said:

No problems... I am testing it myself, but i thought it could also solve the problems you have with your port ..

Well from my tests the "crash" seems to have been cured. Great job with that! I'm not sure if all the i2c issues are lib related or kernel related, my guess is the latter. I guess I'll have to mess w/ my i2c even more... I was able to get display and it slept fine though as you can see from the logs.

ADB: http://pastebin.com/deXcMUA6
SERIAL: http://pastebin.com/ZWNEM4k5

[fosser2]

Scanno,

Just wondering if you have built CM10.1 recently, and if so has your system ui crashed? It seems like CM pushed something new that has broken Xoom and similar tegra2 tablets.

fosser2

EDIT: nvm I got the issue fixed. You will have to patch your CM10.1 build if you did not already do so.
https://github.com/r...74aacdd49b739f8

Edited by fosser2, 13 March 2013 - 12:49 AM.

[ejtagle]

fosser2, on 11 March 2013 - 02:47 AM, said:

Well from my tests the "crash" seems to have been cured. Great job with that! I'm not sure if all the i2c issues are lib related or kernel related, my guess is the latter. I guess I'll have to mess w/ my i2c even more... I was able to get display and it slept fine though as you can see from the logs.

ADB: http://pastebin.com/deXcMUA6
SERIAL: http://pastebin.com/ZWNEM4k5

What i don't like about your SERIAL log is the unbalanced enable IRQ ... That means something is pretty wrong. I don't have them. It is something related to the screen blanking. I seem to remember that it could be caused by something trying to blank the HDMI output, or perhaps you have enabled console autoblanking at the same time as android managed autoblanking... Disable console autoblanking, just let android manage it.

Also, check platform_pwm_backlight_data, specifically the .check_fb function. You MUST ONLY blank the default framebuffer, NOT the HDMI framebuffer.... As it can cause this thing related to unbalanced irqs...

Also check your earlysuspend routines for the framebuffers. You dont want to power down the hdmi panel...

Edited by ejtagle, 13 March 2013 - 12:15 AM.

[fosser2]

ejtagle, on 13 March 2013 - 12:14 AM, said:

What i don't like about your SERIAL log is the unbalanced enable IRQ ... That means something is pretty wrong. I don't have them. It is something related to the screen blanking. I seem to remember that it could be caused by something trying to blank the HDMI output, or perhaps you have enabled console autoblanking at the same time as android managed autoblanking... Disable console autoblanking, just let android manage it.

Also, check platform_pwm_backlight_data, specifically the .check_fb function. You MUST ONLY blank the default framebuffer, NOT the HDMI framebuffer.... As it can cause this thing related to unbalanced irqs...

Also check your earlysuspend routines for the framebuffers. You dont want to power down the hdmi panel...

I'm pretty sure I am only blanking FB1 not FB2 which is hdmi. Our panel file is here. I am hoping you can point me to the "console autoblanking." I would like to make sure I do not have that enabled. I will dig into the pwm backlight data also and report back if that fixes anything. Thanks for the help.

fosser2

EDIT: from the looks of it my ".check_fb" function is the same as yours.

Edited by fosser2, 13 March 2013 - 12:58 AM.

[Scanno]

fosser2, on 12 March 2013 - 11:42 PM, said:

Scanno,

Just wondering if you have built CM10.1 recently, and if so has your system ui crashed? It seems like CM pushed something new that has broken Xoom and similar tegra2 tablets.

fosser2

EDIT: nvm I got the issue fixed. You will have to patch your CM10.1 build if you did not already do so.
https://github.com/r...74aacdd49b739f8

I have build it and i had the same problem. I have not had time to investigate the issue. But thanks a lot for the signal and the solution.

[ejtagle]

fosser2, on 13 March 2013 - 12:55 AM, said:

I'm pretty sure I am only blanking FB1 not FB2 which is hdmi. Our panel file is here. I am hoping you can point me to the "console autoblanking." I would like to make sure I do not have that enabled. I will dig into the pwm backlight data also and report back if that fixes anything. Thanks for the help.

fosser2

EDIT: from the looks of it my ".check_fb" function is the same as yours.

Yes,your check_fb is ok. On our kernel, we have an early_suspend callback that does the blanking and also switches to conservative governor...


#ifdef CONFIG_HAS_EARLYSUSPEND
n10_panel_early_suspender.suspend = n10_panel_early_suspend;
n10_panel_early_suspender.resume = n10_panel_late_resume;
n10_panel_early_suspender.level = EARLY_SUSPEND_LEVEL_DISABLE_FB;
register_early_suspend(&n10_panel_early_suspender);
#endif  

I failed to find that code on your smba related files. That piece of code is the one that must be carefully checked...

[vasudevan]

Scanno, on 20 September 2012 - 07:13 PM, said:

Here is the compiled RIL

Just downloading and pasting this compiled RIL in /system/lib folder is enough or we have t follow some other procedures?. please help me
Vasu

[Scanno]

vasudevan, on 29 May 2013 - 02:34 PM, said:

Just downloading and pasting this compiled RIL in /system/lib folder is enough or we have t follow some other procedures?. please help me
Vasu

What are you trying to do?
That RIL is already included in the vegabean and cm10.1 ROMs ???

[Scanno]

Eduardo,

In have not had much time to experiment with BT.. Did you have any luck getting BT working on 4.2.2?

[DerArtem]

ejtagle, on 04 March 2013 - 01:21 AM, said:

I will also post here my latest bluetooth attempts. On the ui, everything seems to work, but, i was unable to make a bt connection, so guessing something is still missing... Nevertheless, it will be interesting to know if someone is able to actually use the bluetooth...

I am attaching 2 archives:
>The first one contains my latest libbt-vendor, that is required so bluedroid knows how to talk to the hci layer of the linux kernel
>The 2nd one is the required files that must be installed in /etc/bluetooth so the the libbtvendor is able to properly configure the bluetooth chipset

I was also experimenting with BT:

In order to make the UI work I had to add the folowing code to src/userial_vendor.c:

		/* Set the socket to UP */
		if (ioctl(vnd_netlink.fd, HCIDEVUP, vnd_netlink.dev_id) < 0) {
				ALOGE("Can't bring up device");
		}

Has somebody any progress with BT?

[DerArtem]

I have found the following:

http://review.cyanog....org/#/c/30629/

"TTY emulation for user-space Bluetooth stacks over HCI-H4"

"tty_hci driver exposes a /dev/hci_tty character device node, that intends to
emulate a generic /dev/ttyX device that would be used by the user-space
Bluetooth stacks to send/receive data to/from the WL combo-connectivity
chipsets."

Maybe this can be adapted to our devices?

Edited by DerArtem, 02 June 2013 - 04:50 PM.