Posts by witokondoria

Pelican: there was a typo. Just an output is active at a moment

lrusak: a GUI configurable behaviour would be priceless. At the bluetooth screen, it could be chosen if this autoswitch would run, thus, the MAC address will be known, addressing chewitt idea

Maybe just a myself-reminder. but I have saved a gist with the udev rules needed for letting my LE box to autoswitch the output audio device on bluetooth connected device.

The outcome is:
BT connected -> pulse active (A2DP output)
BT disconnected -> alsa active (HDMI output)

Feel free to comment or suggest improvements.

Unbelievable.
I feel ashamed as a totally noob.

I am using a microSD within a full-SD adapter. Dont ask me why, but the times I had written the 007 image, everything worked, but with devel builds wasnt (just merely coincidental). I have changed the SD adapter for another one and VOILA! LE booted within seconds and Im right now testing the output_rgb fix (currently works neat as pin)

Thanks @kszak for the tip and @and_thomas for the tryout idea

dtbs are supposed to be recompiled due kernel changes, so previous ones should not be valid. Anyway, I will try them (because you never know...)

Im a MXQ Quickplay owner with a Philips PFL9664 tv. After seeing how issues related with RGB mode have been fixed at another thread, I have been unable to boot devel builds after 007 version.

My sd has been prepared with Win32DiskImager, LibreELEC-S905.aarch64-7.0-devel-20161003204518-r23361-gb5788b7.img.gz (after being uncompressed) and gxbb_p200_1G_1Gbit.dtb as dtb.img

Toothpick method just shows the start boot screen, but with recovery method (take 2nd variant) ("android update" -> "choose any zip" -> "update"), I have ended at android recovery, with a "No command" message. Luckily, from this recovery menu there are options to dump /cache/recovery/last_kmsg and /cache/recovery/last_log

I will look for a way to save those dumps to a file, as taking pictures doesnt seem nice, but the interesting points could be:

from /cache/recovery/last_kmsg

device-tree: Duplicate name in /efusekey, renamed to "key0#1"
device-tree: Duplicate name in /efusekey, renamed to "key1#1"
device-tree: Duplicate name in /efusekey, renamed to "key2#1"
device-tree: Duplicate name in /efusekey, renamed to "key3#1"
...
mcblk0boot1: unknown partition table
mcblk0boot0: unknown partition table

from /cache/recovery/last_log

E: ubootenc init failed (-2)
E: bad bootloader arguments
"(null)"
...
E: failed to mount /dev/nlock/mmcblk0 on /sdcard (Invalid argument). try read-only
E: failed to mount /dev/nlock/mmcblk0 on /sdcard by read-only (Invalid argument)
...
  
On previous versions:
LE 006 booted with gxbb_p200_mxq_pro_quick_play.dtb
LE 007 booted with gxbb_p200_1G_wetek_hub.dtb

Thanks, will try again this night.

Triple checked the dtb and it wont boot. Will open a new thread to not pollute this one

Duh, my soldering skills are far below the acceptable thresold: would probably drill the motherboard.

Has any other MXQ quickplay owner manage to use any devel dtb?

Well, Im unable of booting any devel build, with none of its respective dtbs. kszaq, is there any way to debug the boot process (such as editing aml_autoscript or s905_autoscript)?

PS: as this issue seems solved, I would set again the proper title tag

Yep, I tested with those dtb files, as Im aware that eack kernel change (or at least some of them) require to rebuild the dtbs. will go on testin gwith previous devel builds to see if I can guess something else.

Tested with default dtb and gxbb_p200_1G_1Gbit.dtb, with the same result: wont pass the inistial splash.

I have been trying to test this build, but I seem to be unable to boot into LE. For 006 builds I could use gxbb_p200_mxq_pro_quick_play.dtb. For 007 builds, theres no such named dtb, but after testing each dtb file, gxbb_p200_1G_wetek_hub.dtb did it, ending with LE booted, wifi and ethernet.

For both devel builds at 2016-09-28-devel, trying with each 1G dtb wont go pass the first splash screen

kszaq, could you give me any advise.

Thanks in advance

PS: If this issue has been finally erased, time for a install to nand will come for me
PS2: My box is a MXQ quick play, almost a clone from Beelink MiniMX (apart for a different wifi & BT chipset)

Its also still happening on my TV. What I have seen is that whilst the screen is wrecked, echoing the same 1 to /sys/class/amhdmitx/amhdmitx0/output_rgb, as it recalls hdmitx_set_display, the colors go back to normal.

Could make any sense that the first time hdmitx_set_display is called, as hdmi_output_rgb is 0, the tvs gets to an "unstable hdmi mode" where even resetting the display mode wont fix it?

What about trying to replace

if(hdmi_output_rgb){  param->color = COLOR_SPACE_RGB444;
}

with something as

if(readFromAttr(output_rgb == 1)){
param->color = COLOR_SPACE_RGB444;
}

at linux/hdmi_tx_video.c at 67f076b4c76fe508457d5c4eccfe08ce6885ae41 · kszaq/linux · GitHub?

PS: I thing the post title should not contain the [SOLVED] tag.

I have been unable to test this build, but I can assure my patches solved the problem 100% on a Philips PFL9664. Could be that hdmi_tx_14/hdmi_tx_video.c also needs the changes from hdmi_tx_20/hdmi_tx_video.c commited on drivers/amlogic/hdmi: make output_rgb a device parameter · kszaq/linux@67f076b · GitHub ?

At least my TV doesnt have HDMI 2.0, so the naming could make sense.

@kszaq, wdyt? hdmi_tx_14 is used under hdmi 1.4?

Quote from MrMagic

Do you know what influence that patch would have on non-RGB capable displays?

Quote from MrMagic

it's selectable in CONFIG.TXT

Being selectable would be the simplest and fairest solution. A default value of forced RGB would ensure compatibility.

That was it, just forcing two vars: simplest patch for forcing RGB mode · witokondoria/LibreELEC.tv@7a3e4f9 · GitHub

If I recall correctly, its even simpler. Just defaulting hdmi_output_rgb to 1 @ linux/hdmi_tx_video.c at amlogic-3.10.y · witokondoria/linux · GitHub

I have a patch for amlogic hdmi driver, applied over a LE self built installation.

Unfortunatelly, there are several issues with it:

It forces RGB444 mode always so its probably not the better thing to apply to each installation. EDID parsing or reading from a config file an applying some logic to the patch would be leaner, but I haven't spent time on it.
Its a patch over 3.10 kernel. 006 version seems to be working over 3.14, so amlogic drivers could have changed (and some commits have been added to them)
My hackish patch is on my work computer and hasnt been versioned, so until monday I wont be able to commit them.

Other than these, the patch is working 100% and no colors have been changed again