-
Notifications
You must be signed in to change notification settings - Fork 122
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
Comments
Some more information:
|
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. |
On my a5lte touchscreen works fine both when screen is off or on. In Phosh :) |
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. Thanks for your help :) |
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. |
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! |
Hi, is there any chance that you have an aftermarket replacement display on that device instead of original? |
Yes, it is definitely aftermarket. It is not installed very well either (big gap between the display and the phone). |
lk2nd says it is a ss_dsi_panel_EA8061V_AMS497EE01_HD |
Is it an AMOLED at least or does it have horrible viewing angle and backlight (lk2nd screen is more gray than black)? |
It definitely has horrible viewing angles and backlight |
Alright, I have some of these trashy displays and will try to reproduce the problem myself. :) 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. :/ |
@stephan-gh Thanks heaps! 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. :) |
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? |
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. |
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)) |
@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! |
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. |
@stephan-gh Tried what you did, screen does not respond after first screen lock |
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;
};
};
|
@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! |
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? |
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 {
};
};
+®_vdd_tsp {
+ vin-supply = <®_vlcd_vci>;
+};
+
&touchkey {
vcc-supply = <®_touch_key>;
vdd-supply = <®_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) |
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. |
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 |
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. |
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? |
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. |
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/20221117091159.31533-2-guozihua@huawei.com Link: https://lkml.kernel.org/r/20221117091159.31533-3-guozihua@huawei.com Reported-by: syzbot+0f89bd13eaceccc0e126@syzkaller.appspotmail.com Fixes: 60ece08 ("net/9p: allocate appropriate reduced message buffers") Signed-off-by: GUO Zihua <guozihua@huawei.com> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> [Dominique: squash patches 1 & 2 and fix size including header part] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
(If someone else is affected by this please comment here so we could decide to make the workaround the default for everyone) |
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: stable@vger.kernel.org # v5.12+ Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20230130014707.541110-1-mpe@ellerman.id.au
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 :)
The text was updated successfully, but these errors were encountered: