pwmsensitive See also: the display module repository. These do not function in isolation as they just expose certain display parameters in sysfs.
Certainly I believe a solution for integration into GrapheneOS requires additional work.
EElephant
- Joined Jul 27, 2023
For me it's like erasing flash memory with zeros for privacy - it would also affect the chip's lifespan and failure rate, and I believe it's up to the user to accept the risk, if any.
I do not think using flawed analogies is productive towards this cause either. Wear leveling going to get ya ;-)
https://github.com/GrapheneOS/os-issue-tracker/issues/3850
Came across this ticket on the GrapheneOS issue tracker. Extremely disappointed by the response. It is ok to stare at a screen with aggressive flickering even when it triggers a physical manifestation of medical symptoms? And it can not be solved by any current medical treatment!
The display industry is rather secretive. As far as I am aware no one from Samsung or other company has joined in to either justify the decision or work towards a solution.
- Edited
aw22 The fact this solution is described as "a single line of code" is a misnomer. The single line of code in the article is writing values to a parameter of the modified kernel driver of the display panel controller that is implemented in this commit. Presumably it is signaled to the display panel controller and otherwise opaque to the host.
Accessing the kernel module parameter as described in the article involves root access but an implementation integrated into the operating system could be written. For integration it is a question of the project how such "tunables" should be exposed to the user without needing root.
I assume the values in question were derived through knowledge of the existing values and experimentation. As far as I know no data-sheets for the display panel controller of this detail have ever surfaced publicly.
- Edited
Not ignoring recent developments but something also to note. A phone repair store in Europe has listings for Pixel phone display assemblies that are labled as non OEM LCD/TFT and not OLED. Assuming its not simply mislabeled it also could be of interest. Unfortunately the most recent device they support is the 6a.
Third-party LCD/TFT displays do exist for several models of iPhone but I was under the impression such a solution only existed because of the economy of scale.
While I have been unable to authenticate its validity if it is real it could be a step towards a solution for this issue.
If it actually works and merely requires kernel modification it should not be hard to integrate it into GrapheneOS.
This is an unfortunate and unsurprising development.
The only way I see this being solved involves either an independent researcher investigating the functionality of the display controller to conclude if the PWM parameters can be adjusted or someone with sympathetic engineering contacts inside Google or Samsung can do something about this. :-(
Something that may be of interest is for some models of iPhone that come from the factory with OLED displays there exists third-party replacement displays that are LCD. Unfortunately other than anecdotal feedback on 'comfort' no one with equpment has attempted to measure to which degree they may flicker.
Guessing the reason they exist is in part due to the economy of scale of iPhone and engineering such a solution is not viable for Pixel devices.
nice seeing another kind soul bring this up!
judging review it appears that measurements of some that have DC-dimming function appear much more stable compared to oled as used by Samsung however unsure how stable the waveform of an oled display can be in contrast to LCD.
as for implementing it for gOS on pixel devices, not sure if the chipset or display controller support DC-dimming or PWM at 100 brightness can be avoided.