Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Samsung A5 - Touchscreen only active when screen is off with some replacement screens #223

Open
JD9999 opened this issue Feb 25, 2022 · 31 comments

Comments

@JD9999
Copy link

JD9999 commented Feb 25, 2022

The device is an A500F. The device works normally as soon as it is restarted. However, as soon as the screen is turned off (with the power button), the touchscreen will only accept user input when the display is off.

I confirmed the issue on the Phosh GUI by SSHing into the device and using evtest. No SYN_REPORTs were recording when the screen was on, except on restart. I also had the same issue with Plasma Mobile, but I had issues with SSH and so I haven't ran evtest on it yet.

I am able to provide much more information if needed :)

@JD9999
Copy link
Author

JD9999 commented Feb 26, 2022

Some more information:

  • I have confirmed with SSH that this issue also exists with the Plasma GUI
  • On Plasma, I managed to get the screen to turn off without pressing the power button, and then I immediately pressed the power button so the screen was on, on home page not lock page, same issue exists. So it is not an issue with the lock screen interface, or the power button itself.

@wonderfulShrineMaidenOfParadise
	reg_vdd_tsp: regulator-vdd-tsp {
		compatible = "regulator-fixed";
		regulator-name = "vdd_tsp";
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;

-		gpio = <&msmgpio 73 GPIO_ACTIVE_HIGH>;
+		gpio = <&msmgpio 73 GPIO_ACTIVE_LOW>;
		enable-active-high;

		pinctrl-names = "default";
		pinctrl-0 = <&tsp_en_default>;
	};

I am not sure but changing this line could be interesting.
https://github.com/msm8916-mainline/linux/blob/master/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi#L83

@minlexx
Copy link

minlexx commented Mar 22, 2022

On my a5lte touchscreen works fine both when screen is off or on. In Phosh :)

@JD9999
Copy link
Author

JD9999 commented Mar 23, 2022

Sorry I realised I haven't replied!

I tested your code a while ago and no difference, I'll try updating to the latest service pack and see if that fixes anything.
If it doesn't I'll try installing Android (or maybe even Lineage OS) on it, see if it is maybe a hardware issue, not a software issue.

Thanks for your help :)

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

The screen works fine on Android (Android 6.0.1, based on linux 3.10.49) so it's not a hardware issue. The 2015 A5 is not compatible with any other OS, so I can't test any other OS.
While it was installing Android, it fixed a memory issue, so I'm going to try reinstalling pmOS again, and see if I have the same issue again.

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

Still have issues. I have tried image files and pmbootstrap with Phosh on v21.12, no success. Also tried Xfce4 and weston, the screen didn't even work on the first time! In v21.12 and in edge in Plasma, worked first time but once screen turned off screen is active when display is off, and deactivates when display is on. I have tried the fix above, as well as getting rid of enable-active-high (which stops the touchscreen from even appearing in evtest).

If there are any more suggestions I will gladly try them!

@TravMurav
Copy link
Member

Hi, is there any chance that you have an aftermarket replacement display on that device instead of original?

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

Yes, it is definitely aftermarket. It is not installed very well either (big gap between the display and the phone).
I bought it off someone else on Gumtree, the aftermarket display was already installed

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

lk2nd says it is a ss_dsi_panel_EA8061V_AMS497EE01_HD

@stephan-gh
Copy link
Member

Is it an AMOLED at least or does it have horrible viewing angle and backlight (lk2nd screen is more gray than black)?

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

It definitely has horrible viewing angles and backlight

@stephan-gh
Copy link
Member

Alright, I have some of these trashy displays and will try to reproduce the problem myself. :)
Not sure how much we can do though, trashy displays are trash. :(

The Samsung Android might accidentally work around it with some weird changes to e.g. the touchscreen code. A similar problem exists e.g. for harpia (#190) with "fake" replacement screens that we were never really able to solve. :/

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

@stephan-gh Thanks heaps!

I'll try the same thing iyzsong tried, see if I have any improvement.

@stephan-gh
Copy link
Member

I'll try the same thing iyzsong tried, see if I have any improvement.

The A5 uses a different touchscreen driver than motorola-harpia, it won't help. :)
I just listed this as an example that "aftermarket displays" tend to cause problems with touchscreens.

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

You're right, it didn't help. That makes sense :)

It's a strange problem, because the issue only happens when the Plasma/Phosh screen comes up. If there's a delay between the backlight coming on, and the Plasma screen coming on, and I touch the screen then, then I can use it until I turn off the display again (and hope for another delay).

So it's definitely software related, but I am absolutely clueless what change needs to be made.

Is there a way to automate a "touch" on the screen while backlight is on but display is off? Or am I just going too far now?

@stephan-gh
Copy link
Member

Have you tried disabling suspend like described in https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_410/412_(MSM8916)#Suspend? It's not very well tested at the moment and provides little benefits so far.

@minlexx
Copy link

minlexx commented Mar 25, 2022

I can add unrelated info, that I have weird replacement screen (not amoled, gray bg and horrible view angles) on my second samsung-klte (Galaxy S5) - and it does not work in mainline either, same as on harpia I guess (synaptics rmi4-i2c: device was reset during probe)

Aand of course it works fine in Android.

I can also add that LCD panel itself reports slightly different panel ID than expected (using samsung's custom "read panel ID" DSI commands (DA/DB/DC))

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

@stephan-gh I just tried disabling suspend, still had problems

@minlexx Since this is happening on lots of different chipsets and devices, maybe I should just give up on my screen working :(

Dang!

@stephan-gh
Copy link
Member

stephan-gh commented Mar 25, 2022

I can't seem to reproduce this with my trash screen. I installed the latest prebuilt image: https://images.postmarketos.org/bpo/edge/samsung-a5/phosh/20220323-2153/20220323-2153-postmarketOS-edge-phosh-18-samsung-a5.img.xz

Then I pressed the power button a couple of times, waited a bit while the display was off and pressed the power button again. The lock screen showed up again and touch input works (the lock screen is a bit slow to react sometimes though).

Could you try exactly the same setup and see if it happens? If it does, I guess your fake screen is either different from mine or it's because I have SM-A500FU and not SM-A500F.

@JD9999
Copy link
Author

JD9999 commented Mar 25, 2022

@stephan-gh Tried what you did, screen does not respond after first screen lock

@stephan-gh
Copy link
Member

I'm pretty clueless here at this point. It might just be some dumb property of the replacement screen. If you want you can try if keeping the power supplies on helps somehow:

diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
index 5f5880874cf3..4afb55f88112 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
@@ -85,6 +85,8 @@ reg_vdd_tsp: regulator-vdd-tsp {
 
 		pinctrl-names = "default";
 		pinctrl-0 = <&tsp_en_default>;
+
+		regulator-always-on;
 	};
 
 	i2c-muic {
@@ -353,6 +355,7 @@ l5 {
 	l6 {
 		regulator-min-microvolt = <1800000>;
 		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
 	};
 
 	l7 {
@@ -410,6 +413,7 @@ l16 {
 	l17 {
 		regulator-min-microvolt = <2850000>;
 		regulator-max-microvolt = <2850000>;
+		regulator-always-on;
 	};
 
 	l18 {
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts b/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
index f29937f8dbf7..70af82a782d5 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
@@ -21,6 +21,8 @@ reg_vlcd_vdd3: regulator-vlcd-vdd3 {
 
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_on_default>;
+
+		regulator-always-on;
 	};
 
 	reg_vlcd_vci: regulator-vlcd-vci {
@@ -31,6 +33,8 @@ reg_vlcd_vci: regulator-vlcd-vci {
 
 		gpio = <&msmgpio 87 GPIO_ACTIVE_HIGH>;
 		enable-active-high;
+
+		regulator-always-on;
 	};
 
 	reg_touch_key: regulator-touch-key {
@@ -44,6 +48,8 @@ reg_touch_key: regulator-touch-key {
 
 		pinctrl-names = "default";
 		pinctrl-0 = <&tkey_en_default>;
+
+		regulator-always-on;
 	};
 };
 

@JD9999
Copy link
Author

JD9999 commented Mar 26, 2022

@stephan-gh my device works now! :)

Now time to find out which regulators needs to stay on, and which ones I can turn off :)

Thanks heaps!

@JD9999
Copy link
Author

JD9999 commented Mar 27, 2022

So adding the regulator-always-on to the regulator-vlcd-vci code fixes this issue. None of the other changes are required. Should I submit a merge request to add this in or just make the change on my device each time I update it?

@stephan-gh
Copy link
Member

stephan-gh commented Mar 27, 2022

Can you try the following instead of the regulator-always-on:

diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts b/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
index f29937f8dbf7..d9b2852de358 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
@@ -102,6 +102,10 @@ iris {
 	};
 };
 
+&reg_vdd_tsp {
+	vin-supply = <&reg_vlcd_vci>;
+};
+
 &touchkey {
 	vcc-supply = <&reg_touch_key>;
 	vdd-supply = <&reg_touch_key>;

It's a bit dumb (does not represent the actual hardware state), but should ensure vdd3/vci are turned on together with the touchscreen supply.

@JD9999
Copy link
Author

JD9999 commented Mar 30, 2022

Can you try the following instead of the regulator-always-on:

diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts b/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
index f29937f8dbf7..d9b2852de358 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
@@ -102,6 +102,10 @@ iris {
 	};
 };
 
+&reg_vdd_tsp {
+	vin-supply = <&reg_vlcd_vci>;
+};
+
 &touchkey {
 	vcc-supply = <&reg_touch_key>;
 	vdd-supply = <&reg_touch_key>;

It's a bit dumb (does not represent the actual hardware state), but should ensure vdd3/vci are turned on together with the touchscreen supply.

Yes this also works - out of interest, do you prefer this one to the other one, and if so, why so? (I have no understanding of any of this)

@stephan-gh
Copy link
Member

Yes this also works - out of interest, do you prefer this one to the other one, and if so, why so? (I have no understanding of any of this)

The regulators control the power supply to the components connected to them. There should be two for the display and one for the touchscreen. Normally they are independent, so if you want the touchscreen you just need the touchscreen regulator. This does not work in your case for some reason, it seems like the display regulator also supplies part of the touchscreen somehow.

This might cause the following problem: If the touchscreen is started before the display gets enabled (this depends on the timing), then one of its power supplies is still missing and it will fail to start.

With this change, the touchscreen regulator is marked as being supplied by the display regulator. This means that Linux will always turn on the display regulator before the touchscreen regulator is enabled. The advantage is that the display regulator does not stay always on, when the display and touchscreen are both disabled the display regulator still gets turned off to save some minor power.

@JD9999
Copy link
Author

JD9999 commented Apr 9, 2022

Sorry Stephen, would you like me to submit a pull request to fix this issue, or do something downstream, or not at all? I have never submitted a pull request before and don't know whether to do it or not since this seems very device specific

@stephan-gh
Copy link
Member

I'm still undecided if we should make this change since it only seems to affect your device, and it does potentially increase power consumption a bit in some edge cases.

@JD9999
Copy link
Author

JD9999 commented Apr 9, 2022

It sounds like you are hesitant - I won't submit a request then, but if we hear of another device with this issue, then I can learn how to do a pull request.

In that case, should I close the issue?

@stephan-gh stephan-gh changed the title Samsung A5 - Touchscreen only active when screen is off Samsung A5 - Touchscreen only active when screen is off with some replacement screens Apr 9, 2022
@stephan-gh
Copy link
Member

Let's keep it open for now I guess, it doesn't hurt and might make it easier for others to find the workaround we came up with.

stephan-gh pushed a commit that referenced this issue Nov 28, 2022
This error was reported while fuzzing:

BUG: KASAN: slab-out-of-bounds in _copy_to_iter+0xd35/0x1190
Write of size 4043 at addr ffff888008724eb1 by task kworker/1:1/24

CPU: 1 PID: 24 Comm: kworker/1:1 Not tainted 6.1.0-rc5-00002-g1adf73218daa-dirty #223
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
Workqueue: events p9_read_work
Call Trace:
 <TASK>
 dump_stack_lvl+0x4c/0x64
 print_report+0x178/0x4b0
 kasan_report+0xae/0x130
 kasan_check_range+0x179/0x1e0
 memcpy+0x38/0x60
 _copy_to_iter+0xd35/0x1190
 copy_page_to_iter+0x1d5/0xb00
 pipe_read+0x3a1/0xd90
 __kernel_read+0x2a5/0x760
 kernel_read+0x47/0x60
 p9_read_work+0x463/0x780
 process_one_work+0x91d/0x1300
 worker_thread+0x8c/0x1210
 kthread+0x280/0x330
 ret_from_fork+0x22/0x30
 </TASK>

Allocated by task 457:
 kasan_save_stack+0x1c/0x40
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0x7e/0x90
 __kmalloc+0x59/0x140
 p9_fcall_init.isra.11+0x5d/0x1c0
 p9_tag_alloc+0x251/0x550
 p9_client_prepare_req+0x162/0x350
 p9_client_rpc+0x18d/0xa90
 p9_client_create+0x670/0x14e0
 v9fs_session_init+0x1fd/0x14f0
 v9fs_mount+0xd7/0xaf0
 legacy_get_tree+0xf3/0x1f0
 vfs_get_tree+0x86/0x2c0
 path_mount+0x885/0x1940
 do_mount+0xec/0x100
 __x64_sys_mount+0x1a0/0x1e0
 do_syscall_64+0x3a/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

This BUG pops up when trying to reproduce
https://syzkaller.appspot.com/bug?id=6c7cd46c7bdd0e86f95d26ec3153208ad186f9fa
The callstack is different but the issue is valid and re-producable with
the same re-producer in the link.

The root cause of this issue is that we check the size of the message
received against the msize of the client in p9_read_work. However, it
turns out that capacity is no longer consistent with msize. Thus,
the message size should be checked against sdata capacity.

As the msize is non-consistant with the capacity of the tag and as we
are now checking message size against capacity directly, there is no
point checking message size against msize. So remove it.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Reported-by: [email protected]
Fixes: 60ece08 ("net/9p: allocate appropriate reduced message buffers")
Signed-off-by: GUO Zihua <[email protected]>
Reviewed-by: Christian Schoenebeck <[email protected]>
[Dominique: squash patches 1 & 2 and fix size including header part]
Signed-off-by: Dominique Martinet <[email protected]>
@stephan-gh
Copy link
Member

(If someone else is affected by this please comment here so we could decide to make the workaround the default for everyone)

stephan-gh pushed a commit that referenced this issue Feb 7, 2023
In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
extra space will be needed in the device tree for some memory related
properties.

That logic uses the size of RAM divided by drmem_lmb_size() to do the
estimation. However drmem_lmb_size() can be zero if the machine has no
hotpluggable memory configured, which is the case when booting with qemu
and no maxmem=x parameter is passed (the default).

The division by zero is reported by UBSAN, and can also lead to an
overflow and a warning from kvmalloc, and kdump kernel loading fails:

  WARNING: CPU: 0 PID: 133 at mm/util.c:596 kvmalloc_node+0x15c/0x160
  Modules linked in:
  CPU: 0 PID: 133 Comm: kexec Not tainted 6.2.0-rc5-03455-g07358bd97810 #223
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,git-dd0dca pSeries
  NIP:  c00000000041ff4c LR: c00000000041fe58 CTR: 0000000000000000
  REGS: c0000000096ef750 TRAP: 0700   Not tainted  (6.2.0-rc5-03455-g07358bd97810)
  MSR:  800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24248242  XER: 2004011e
  CFAR: c00000000041fed0 IRQMASK: 0
  ...
  NIP kvmalloc_node+0x15c/0x160
  LR  kvmalloc_node+0x68/0x160
  Call Trace:
    kvmalloc_node+0x68/0x160 (unreliable)
    of_kexec_alloc_and_setup_fdt+0xb8/0x7d0
    elf64_load+0x25c/0x4a0
    kexec_image_load_default+0x58/0x80
    sys_kexec_file_load+0x5c0/0x920
    system_call_exception+0x128/0x330
    system_call_vectored_common+0x15c/0x2ec

To fix it, skip the calculation if drmem_lmb_size() is zero.

Fixes: 2377c92 ("powerpc/kexec_file: fix FDT size estimation for kdump kernel")
Cc: [email protected] # v5.12+
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants