(samsung-kylessopen) Xorg output distorted and nearly looks like the output of cat /dev/urandom > /dev/fb0

As the title describes. The image is static, not changing. I've luckily been able to pull the Xorg log as well as the output of logread. This issue is so far over my head that I unfortunately can't seem to go any further with it. I'm hoping you guys can help.

I modified the xinitrc file from within /etc/postmarketos-ui and commented out exec hildon-desktop and then killed X. Interestingly, the noisy image appears for a split second but then disappears when Xorg restarts itself. This leads me to believe that hildon isn't the culprit and it's more likely to be something very involved with the way Xorg works. I then edited /etc/profile and removed the for loop so I could startx manually. I still notice the image. After messing with various configurations, I can't figure out what causes this.

logread.log Xorg.0.log

changed the description

By Ghost User on 2018-07-17T02:05:39

changed the description

By Ghost User on 2018-07-17T02:07:11

changed the description

By Ghost User on 2018-07-17T02:50:02

changed the description

By Ghost User on 2018-07-17T03:23:21

changed the description

By Ghost User on 2018-07-17T04:58:06

Thanks for opening the detailed issue!

From your log, this stands out to me:

FBDEV(0): FBIOPUTCMAP: Invalid argument

After some research, I found this thread with the same issue, and the unconfirmed, but proposed fix being:

Turns out that after every write to the memory mapped area, you have to submit the image for display using ioctl(fbfd, FBIOPUT_VSCREENINFO, &vinfo).

...which is exactly what msm-fb-refresher is doing. You can enable it by adding msm-fb-refresher to the depends of your device.

I'm not sure if this is the real fix to your problem though, but you could try it out if you have not already. See also Troubleshooting:display with various patches to try out.

By Oliver Smith on 2018-07-18T20:02:42

mentioned in commit wiki@7f91cd6f

By Martijn Braam on 2018-07-18T20:42:36

It seems msm-fb-refresher is already in the depends of the device, by looking at pmbootstrap/aports/device/device-samsung-kylessopen/APKBUILD. I'll try playing around with other patches, since I don't know what else to do. Just to let you know, all Wayland interfaces work. This is only an issue with X11. I personally haven't dealt with an issue this technical before. I was curious, what resources or tools do you guys use to troubleshoot, patch and port a new device? I feel like knowing this kind of stuff would greatly help me understand and properly troubleshoot this phone. At the moment, I'm basically treating my phone as if it were a faulty computer rather than a phone.

By Ghost User on 2018-07-18T21:17:23

@lofenyy this looks exactly the same error of the Huawei-y530 (see !1602 (comment 85282453)).

That device had a lot of driver issues, look in aports/device/linux-huawei-y530 how many patches to get something to work.

If you have some time to spend on this I suggest trying to add some additional logs directly in the kernel driver. At least this is what I did to debug some issues.

For example in https://github.com/pavlepiramida/FrankenKernel/blob/master/drivers/video/fbmem.c#L1098 add some lines like:

...
	case FBIOPUTCMAP:
                printk(KERN_ERR "PMOS DEBUG: calling copy_from_user...\n");
		if (copy_from_user(&cmap, argp, sizeof(cmap))) {
                        printk(KERN_ERR "PMOS DEBUG: copy_from_user failed!\n");
			return -EFAULT;
                }
                printk(KERN_ERR "PMOS DEBUG: copy_from_user ok!\n");
                printk(KERN_ERR "PMOS DEBUG: calling fb_set_user_cmap...\n");
		ret = fb_set_user_cmap(&cmap, info);
                printk(KERN_ERR "PMOS DEBUG: fb_set_user_cmap returned %d\n", ret);
		break;
...

rebuild the kernel, flash and check the dmesg output when starting the X11.

And keep adding log lines inside the various functions, also printing out the values of the variables is very useful.

By Daniele Debernardi on 2018-07-18T21:53:07

I feel like I don't know enough about the hardware and the kernel to know what drivers and functions I should be adding debug lines to. I've never touched kernel source code before. I'm going to try my best to really look into this, but any tips or resources that I could use to figure this out would be greatly appreciated.

By Ghost User on 2018-07-18T22:54:35

@lofenyy: I've looked into linux-samsung-kylessopen to get a suitable example with the actual kernel sources. But then I realized @drebrez already did this, the example he posted directly shows which file to patch and what to add to gain more debug information. For the kernel sources that the kylessopen is using.

This wiki page may be helpful about the actual patching process: https://wiki.postmarketos.org/wiki/How_to_create_a_patch_when_packaging_software

I recommend to use the --src method, that should make it a lot easier. You might get real time help in the IRC/matrix channel if you get stuck with patching - otherwise feel free to ask further questions here

By Oliver Smith on 2018-07-19T23:35:08

I've created the patch file but I'm not sure how to actually implement it. Also, I've found something interesting in the output of dmesg. Look at the output from 212.124921 to 215.465578. It seems to print this whenever I start Xorg.I don't know how to interpret it though.

debug.patch dmesg.log

By Ghost User on 2018-07-24T09:48:16

I've created the patch file but I'm not sure how to actually implement it.

I'm not sure if you mean "how to apply the patch" with that, but in case you do:

• Copy the patch file toaports/device/linux-samsung-kylessopen/
• Edit aports/device/linux-samsung-kylessopen/APKBUILD
  • add the patch to source= (e.g right below "0001-fix-video-argb-setting.patch")
• Compile the kernel with force, so it doesn't use the existing binary package: pmbootstrap build --force linux-samsung-kylessopen

Also, I've found something interesting in the output of dmesg. Look at the output from 212.124921 to 215.465578. It seems to print this whenever I start Xorg.I don't know how to interpret it though.

The lines start with NT35510, which probably indicates the kernel driver name that is printing the messages (it should be easy to figure out the source files in your kernel when searching for that string).

What happens when you start weston, do you get the same or similar output?

By Oliver Smith on 2019-03-22T19:39:53

I'm sorry for the late reply, I somehow missed your question and rediscovered it when reviewing this issue. Weston runs perfectly, but I'll have to do some digging to see what dmesg says. I'd just like to make it known that I'm still interested in this, I just don't have as much free time as I did before.

By Ghost User on 2019-03-22T19:41:04

moved to pmaports#39 (closed)

By Bart Ribbers on 2018-09-17T21:46:50

After looking into everything after quite an amount of time has passed, it seems like a lot of issues have fixed themselves, including this one! Most DE's actually run now except hildon. As for the the contents of dmenu and Xorg's log, I'll have to look and compare, but it seems this issue is mostly fixed.

By Ghost User on 2019-03-23T07:10:16

mentioned in issue pmaports#39 (closed)

By Oliver Smith on 2019-03-25T08:37:13