Screen dying already?

[fxc]

The glass is glued on the screen using a UV-cured bond. These are typically rated for 350°F / 176°C. I highly doubt such temperatures have been reached, to be quite frank. Temperature as definite cause is simply unconfirmed and the fact that both of you don't have a big squared stain on top of the SoC but instead stains on the colder corners points towards other directions.

[dsimic]

I've started by setting the thermal trip points on my PinePhone (Manjaro Phosh, stable branch) to 45°C, 60°C and 75°C respectively.

Reason for the upper limit being so low is that I did once accidentally reach it by stupidly putting some clothes on top my phone, which was on the charger and had a compile job running; needless to say, the whole phone was searing-hot at only 75°C, which couldn't have been healthy for it. I must add that this was around Christmas time and the delamination didn't start until April.

Having such a low value for the "critical" trip point cannot hurt the phone; when it comes to the safety of the phone, it's only important not to go over the default value of 110 °C for the "critical" trip point.  Also, with the lowered values for the "passive" and "hot" trip points, the "critical" temperature shouldn't be easily reached, at least in theory, so it should be fine to have around 100 °C configured as the value for the "critical" trip point.

The only adjustment I felt like I had to make was bumping up the "passive" point up to 50°C because I experienced stutters when watching 720p videos YouTube videos using FreeTube that weren't present before and (seem to) have gone again after the bump. Even at 50°C the phone still doesn't feel too hot, so I think it's okay.

Thank you for doing the testing!  Did you also monitor the CPU temperature while watching YouTube videos, etc.?  There are more "knobs" for the thermal governor inside the Linux kernel, so it would be good to know how close was the CPU temperature to the configured "passive" trip point value.

Has anyone gotten a word on whether it's a defect and whether they'd be willing to ship a replacement screen to those affected? I ask this because I already have quite the shopping list for the PINE store and they're all currently in stock (doesn't happen often) and I wouldn't want to order a replacement screen just to find out afterwards that they would've given me a one.

Unfortunately, I have no idea.  You may want to create an official support ticket, asking the same questions.  Due to unknown reasons, Pine64 has remained silent to quite a few recent questions and bug reports.

Expanding the guide above by adding a more "modern" (read: "systemd-centric") way of doing the same thing using systemd's tmpfiles, something that Arch and Manjaro users need to do due to the lack of a sysfsutils init script or service unit. I'm sure there's also a way to do this using udev rules, but I'm not that familiar with those (yet ).

Please note that the "traditional" sysctl mechanism is actually available on Arch Linux and, consequently, on Manjaro.  Thus, creating a simple /etc/sysctl.d/90-throttling.conf file, for example, would be all that's needed.  More information can be found in the Arch Linux wiki.

[marcih]

Thank you for doing the testing!  Did you also monitor the CPU temperature while watching YouTube videos, etc.?  There are more "knobs" for the thermal governor inside the Linux kernel, so it would be good to know how close was the CPU temperature to the configured "passive" trip point value.

I didn't explicitly look out for that, that's a good idea, will do. I did find that the temperature was often at the "passive" trip point when I randomly checked though. I know there are the "performance", "powersave", "ondemand" and "conservative" ACPI governors; does the A64 have its own similar ones, or use that same ones?

Please note that the "traditional" sysctl mechanism is actually available on Arch Linux and, consequently, on Manjaro.  Thus, creating a simple /etc/sysctl.d/90-throttling.conf file, for example, would be all that's needed.  More information can be found in the Arch Linux wiki.

If I understood the documentation correctly, sysctl is related to /proc/sys, not sysfs (/sys). I did try using "sysctl -a" to list all the available variables, but none of them were related to temperature or trip points. Oh and of course, sysctl and sysfsutils are two different things, although the folder names "/etc/sysfs.d" and "/etc/sysctl.d" are inconveniently similar.

[dsimic]

I didn't explicitly look out for that, that's a good idea, will do. I did find that the temperature was often at the "passive" trip point when I randomly checked though. I know there are the "performance", "powersave", "ondemand" and "conservative" ACPI governors; does the A64 have its own similar ones, or use that same ones?

You can check the list of available thermal governors using the following command:

Code:

cat /sys/class/thermal/thermal_zone0/available_policies

Similarly, you can check which thermal governor is currently used with this command:

Code:

cat /sys/class/thermal/thermal_zone0/policy

Expectedly, the desired thermal governor can be configured using the following command, for example:

Code:

echo "step_wise" > /sys/class/thermal/thermal_zone0/policy   # default

More information about the available thermal governors can be found on page 15 in this document.  I haven't researched the available thermal governors (yet), so I cannot provide any suggestions about using any governors other than the default one.  Some of the available thermal governors obviously cannot even be used.

If I understood the documentation correctly, sysctl is related to /proc/sys, not sysfs (/sys). I did try using "sysctl -a" to list all the available variables, but none of them were related to temperature or trip points. Oh and of course, sysctl and sysfsutils are two different things, although the folder names "/etc/sysfs.d" and "/etc/sysctl.d" are inconveniently similar.

You're totally right; I was wrong.  Thank you for pointing it out!

The approach you described, using a tmpfiles.d configuration file, is the most appropriate way to apply the configuration on Arch Linux and Manjaro.  Another approach could be to create a separate systemd service unit, but it would be less clean.

[dsimic]

Sorry, forgot to mention in my previous post that configuring the usual cpufreq governors is also available, which affect how the CPU frequency scaling is applied according to the system load.  In this case, they should mostly affect the speed and responsiveness of the phone.

You can check the list of available cpufreq governors and "CPU blocks" using the following command:

Code:

grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_available_governors
grep . /sys/devices/system/cpu/cpu?/cpufreq/related_cpus

Similarly, you can check which cpufreq governor is currently used with this command:

Code:

grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor

Expectedly, the desired cpufreq governor can be configured using the following command, for example:

Code:

echo "schedutil" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   # default

Interesting cpufreq governors to test out would be the "conservative" and "ondemand" governors, with an emphasis on the "powersave_bias" parameter of the latter.  More information about the cpufreq governors can be found in this document.

[marcih]

Just wanted to update in here that as of this morning, the screen no longer registers touch input.

EDIT: A reset (had to hold down the power button for 5s since I couldn't do it from the OS with no input) thankfully resorted it, but this has never happened to me before, not a good sign.

[dsimic]

I'm sorry to hear that.  If the issue doesn't persist, it could be that the cause was a software bug.

However, there are some very good signs that a userspace daemon could do a lot when it comes to regulating the thermals of the phone, or better said, balancing the performance and the thermals.  I did some "semi-scientific" testing to assess the room for improvements before starting the actual work on the daemon, and the preliminary results look very promising.  I've managed to keep the phone barely warm to the touch without having noticeable negative effects to the user experience. 

[RudderDuck]

I'm afraid I'm having the same problem. Mine is the batch with the Manjaro logo on the back. Delamination around all borders, roughly 1 to 2 mm wide. I will order a spare screen but think you guys need to be aware of the issue.    

[dsimic]

I'm afraid I'm having the same problem. Mine is the batch with the Manjaro logo on the back. Delamination around all borders, roughly 1 to 2 mm wide. I will order a spare screen but think you guys need to be aware of the issue.

I'm sorry to see that.  Just checking, has your PinePhone ever suffered some water damage?  Are you using it as your daily driver?

[RudderDuck]

I'm afraid I'm having the same problem. Mine is the batch with the Manjaro logo on the back. Delamination around all borders, roughly 1 to 2 mm wide. I will order a spare screen but think you guys need to be aware of the issue.

I'm sorry to see that.  Just checking, has your PinePhone ever suffered some water damage?  Are you using it as your daily driver?

It never suffered water damage but sometimes use it when having bath . I do think it started after that, so it may be humidity related. Almost switching to it as daily driver, I would say using it 5 out of 7 days as main phone. I'm happy that it is fairly affordable to replace, hoping it isn't too much of a job to replace screen.