Samsung Galaxy S9 Accidental Touch Protection Not Working?

I recently had an experience with my Samsung Galaxy S9 phone, which was recently upgraded to Android 10, and which, in more recent days, received another update to its current Android 10 version. The experience was that, after a day at a sunny beach, while it was very hot, I came home and inspected my phone, and seemed to find that somebody had been having a party on its touch-screen. Normally, I’d say that not very much can go wrong, unless the accidental activation of the touch-screen also managed to enter the password that protects the phone. But, contrarily to that first approximation, even with the lock-screen locked, there are quite a few layers of widgets that a party-goer could go through, and leave the UI in a confused state.

And so, I started to ask myself what might be causing this. Was it me, perspiring under my shirt? Was it the excessive heat, somehow affecting that one chip in the phone that also controls the touch-screen? The conclusion that I came to, was:

  • Excessively bright sunlight, seeping through my lightly coloured shirt’s pocket.

I typically have a feature enabled, that’s called “Accidental Touch Protection”, and this screen-shot shows where it can be found on the S9 (Hint, this screen is reached through ‘Settings -> Display’…)

Screenshot_20200813-140351_Settings_e

The way this feature works, also explains why sometimes, it may not work. Most modern smart-phones have a photo-diode that acts as a light-level sensor. When the light-level is below some threshold, with this feature enabled, the screen is turned off. This low light-level indicates to the phone, that it’s either inside a pocket or a bag, and that capacitive contact with the screen should be ignored. The problem?

  • If the light-level is above this threshold, the phone has no AI to tell it, that the same light-level is due to extremely bright light to begin with, not being filtered below a sufficiently low level, just due to the cloth in a pocket. And thus, such a level is taken to mean, ‘The phone is in the open, and waiting to be used.’
  • With the upgrade to Android 10, for some reason, the threshold required was set to an even-darker threshold, than Android 9 had it set to.

Possible solutions?

  • Put the phone in an additional enclosure that blocks light, Or
  • Disable the Always-On Display during Summer months, Or
  • Wear a darker shirt? Or
  • Stay out of extremely bright sunlight…

I can’t think of much else that helps, on the assumption that indoors, the feature works as it should.

 

Dirk

 

Disabling upowerd on a Desktop Linux computer that never actually had a battery.

One of the facts which I’d like to make sure the reader knows, is what, exactly, the process ‘upowerd’ is responsible for on any Linux computer, lest the reader disable something that he or she may really need.

Many computers, including laptops, have batteries. ‘upowerd’ is the Linux process that monitors the battery, or the batteries, in case there is more than one to monitor. If the computer has batteries to monitor, then this process is essential and should not be disabled. But, in certain specific other cases, this process can become a problem, as it recently was on my desktop computer named ‘Phosphene’, which is running Debian 9 / Stretch, which has Plasma 5.8 as its desktop manager, and which will only ever run on A/C power, due to the very way in which its hardware is designed.

Several months ago, I noticed that the ‘North Bridge’ of this computer – an essential chip on its motherboard – was becoming rather hot. And the motherboard in question, the ‘Sabertooth X58′, manufactured in the year 2011, was already famous for the design flaw that causes its North Bridge to become 76.5⁰C hot when idle, which is actually hotter than the GPU on that computer will normally become, when pressed to work hard. Several Months ago, the North Bridge temperature when idle was 80⁰C or even 81⁰C! Whether it’s actually safe for a chip to be that hot is a subject open to opinion. This temperature will not cause an immediate failure, but if the chip is so hot continuously, then its lifespan will become shorter, than what the lifespan of chips is supposed to be, in general.

Therefore, months ago, when I first noticed this, I opened up the tower / desktop computer and examined it, to look for failed cooling fans, etc. There was no such cause for the elevated NB temperature. Not being able to remedy the problem, I just left it that way.

But only yesterday, I noticed that the process ‘upowerd’ was consuming an inordinate amount of CPU time. On the octa-core machine, that process was consuming maybe 1% of available CPU time, which was quite a lot, considering that there should have been nothing for it to do. And, never having noticed this before, it seemed possible to me that ‘upowerd’ may have been consuming 1% of available CPU time (unnoticed), since months ago.

When ‘upowerd’ misbehaves in this way, sometimes this happens, because of hardware signals, such as perhaps, a battery which continuously disconnects and reconnects, etc… Therefore, before a software kludge is attempted, all possibilities need to be followed, to find hardware causes for this behaviour, to which ‘upowerd’ would simply be responding in a normal fashion. Yet, even given hardware reasons to be active, ‘upowerd’ should not be consuming much more than 1% of available CPU time, in case the reader has some situation where this process is consuming, say, 10% of the CPU.

Continue reading Disabling upowerd on a Desktop Linux computer that never actually had a battery.

Observations, on how to insert Unicode and Emojis into text, using a KDE 4 / Plasma 5.8 -based Linux computer.

One of the earliest ‘inventions’ on the Internet, were ‘Smilies’, which were just typed in to emails, and which, when viewed as text, evoked the perception of whichever face they represented. But, graphical user interfaces – GUIs – replaced simple text even in the 1990s, and the first, natural thing which developers coded-in to email clients was, the ability to convert typed, text-based smilies, into actual images, flowed with the text. Also, simple colon-parenthesis sequences were replaced with other, more varied sequences, which could be converted by some email clients into fancier images, than simply, smiling faces.

Actually, the evolution of the early Internet was slightly more complex than that, and I have even forgotten some of the real terms that were used to describe that History.

But there is an even more recent shift in the language of the Internet, which creates a distinction between Smilies, and ‘Emojis’. In this context, even many ‘Emoticons’ were really just smilies. Emojis distinguish themselves, in that these pictograms are represented as part of text in the form of Unicode values, of which there is such a large supply, that some Unicode values represent these pictograms, instead of always representing characters of the Earth’s many languages, including Chinese, Korean, Cyrillic, etc. What some readers might ask next could be, ‘Traditionally, text was encoded as 7-bit or 8-bit ASCII, how can 16-bit or 32-bit Unicode characters simply be inserted into that?’ And the short answer is, through either UTF-8 or UTF-16 Encoding. Hence, in a body of text that mainly consists of 8-bit codes, half of which are not normally used, sequences of bytes can be encoded, which can be recognized as special, because their 8-bit values do not correspond to valid ASCII characters, and their sequences complete a Unicode character.

One fact which is good to know about these Emojis is, that they are often proprietary, which means that they are often either the intellectual property of an IT company, or part of an Open-Source project. But the actual aspect of that which can be proprietary is, the way in which Unicode values are rendered to images.

What that means is that, for example, I can put the following code into my blog: 🤐 . That is also referred to as Unicode character ‘U+1F910′. Its length extends beyond 16 bits by 1 bit, and the next 4, most-significant bits are all 1’s, as expressed by the hexadecimal digit ‘F’. It’s supposed to be a pictogram of a deceased entity, as if that were stated correctly by a head which has had certain features crossed out. But for my blog, the use of such a code can be a hazard, because it will not display equally on Android devices, as it displays on iOS devices. And, on certain Linux computers, it might not be rendered at all, instead just resulting in a famous rectangle that seems to have dots or numbers inside it. This latter result will form, when the client-program could not find the correct Font, to convert this code into an image. (:3)

Those fonts are what’s proprietary. And, they also provide some consistency in style, between Android devices, OR between iOS devices, OR between Windows devices, etc.

Well, I began this posting by musing about the early days of the Internet. During those days, some users – myself included 😊  – did some things which were truly foolish, and which included, to put background images into our HTML-composed emails, and, to decorate documents with (8-bit) dingbat fonts, just because it was fun to pass certain fancier documents around, than POT. I don’t think there is really anything wrong with potential readers, who still put background images into their emails. What I mean is that many of my contacts today, prefer emails which are not even HTML.

This earlier practice, of using dingbat fonts etc., tended to play favourably into the hands of the tech giants, because the resulting documents could only be viewed by certain applications. And so today, I needed to ask myself the question, of how often the use of Emojis can actually result in a document, which the recipient cannot read. And my conclusion is that today, such an indecipherable outcome is actually rare. So, how I would put a long story short is to say, that Commercialism is back, riding on the desire of younger people to put more-interesting content into their messages, and perhaps, without some of the younger people being aware that when they put Emojis, they are including themselves as the software-disciples of one larger group or another. But that larger group mainly seems to be drawing its profits, from the ability of certain software to insert the images, rather than, the ability of only certain software to render them at the receiving end (at all). Everybody knows that, even though the input methods on our smart-phones don’t lead to massively good prose, they almost always offer a rich supply of Smilies, plus Emojis, all displayed to the sender using his or her own font, but later displayed to the recipient, using a potentially different font.

The way Linux computers can be given such fonts, is through the installation of packages such as ‘fonts-symbola’ and ‘ttf-ancient-fonts’, or of ‘fonts-noto‘… The main drawback of the open-source ‘Symbola’ font, for example, is simply, that it often gives a more boring depiction of the same Unicode character, than the depiction which the true Colour Noto Font from Google would give.

One interesting way in which Linux users are already in on the party is, in the fact that actual Web-browsers are usually set to download fonts as they are needed, even under Linux, for the display of Web-pages. Yet, email clients do not fall into that category of applications, and whether they render Emojis depends on whether these font packages are installed.

Hence, if the ability to send Emojis from a Linux computer is where it’s at, then this is going to be the subject of the rest of my posting. I can put two and two together, you know…

(Updated 7/31/2020, 15h10… )

Continue reading Observations, on how to insert Unicode and Emojis into text, using a KDE 4 / Plasma 5.8 -based Linux computer.

A 3rd-party, Android email client, still worth using: FairEmail.

One of the observations which I’ve made about the Android platform is, that many of the 3rd-party email apps that once used to run well, no longer do so under Android 10, and that, additionally, their devs have often abandoned them.

For that reason, I’m happy to find that such an app still exists, or newly exists, and its name is FairEmail. This is an app, the free version of which can actually be used in the long term, but which I paid for, just to get the extra features.

One of the observations which I can make about this app is, that it has a plethora of settings, some of which I haven’t learned the meaning of yet. But, by default, the way to use it is to follow what is located in its first settings tab, which displays wizards to set up email accounts according to a database of recognized providers, and then, to leave the settings at their defaults. Additional wizards help the user give the app special settings under Android. The app directs the user to the required or optional settings, but it’s up to the user actually ‘to throw the switch’ each time. (:2)

Multiple email accounts can all be set up, using the same wizard.

The app runs in phone-optimized as well as tablet-optimized formats.

Screenshot_20200723-121436_FairEmail_1_e

Screenshot_20200723-121814_FairEmail_2_f

One of the features that were highly important to me was, support for both ‘S/MIME’ and ‘OpenPGP’. When using OpenGPG, this app will always encode it using the trendy ‘PGP/MIME’ format, and no longer, using ‘Clearsigning’, which was also referred to as ‘Inline Format’. The use of OpenPGP requires that an additional key-management app be installed, and on my devices, Open Keychain was already so, and was recognized immediately by FairEmail.

The app displays many widgets inside displayed emails, most of which give explicit commands to do things, that might impact the privacy of the user, such as, to display images, to display tracking images, etc. The app tries to distinguish between these two types of images because additionally, being an IMAP Client, downloading even plain images will consume additional data, when many emails can Humanly be understood, without the need actually to see the images. This is especially true for actual Spam.

The app leaves Spam filtering up to the IMAP Server, but displays the Spam Folder as fully accessible.

And many configuration details show me, that it assumes trendy preferences, even though I can’t say that either I, or most of my email contacts, qualify as trendy Internet users. One trendy feature is that this app mainly supports IMAP, and that any support of POP3 which the user may find, will be incomplete at best.

Another trendy setting in this app has to do with “Flowed Text”. This is a term which refers to ‘Pure Text Emails’, in which one paragraph is essentially written on one line. Traditionally, this lack of formatting was reserved for HTML-composed emails, and the receiving email client would always display those flowed. By contrast, traditionally, Pure Text had fixed line-lengths, determined by the sender, and the receiving client would break lines where line-breaks were sent, even if doing so, or not doing so, tended to wreck the appearance of the email…

(Updated 8/13/2020, 10h10… )

Continue reading A 3rd-party, Android email client, still worth using: FairEmail.