Closed argosphil closed 1 year ago
Here's the very hacky script which will produce a solid white bright screen without flickering (at least, sometimes) on today's asteroidos image. It requires installing msm-fb-refresher
first, but that's just to pan the frame buffer:
killall -STOP asteroid-launcher
killall -STOP mce
for i in $(seq 1 $((500 * 476))); do echo -ne '\xff\xff\xff\xff'; done > /dev/fb0
msm-fb-refresher
echo 255 > /sys/class/leds/lcd-backlight/brightness
echo 1 > /sys/class/graphics/fb0/mdss_hbm_enable
echo 1ac8000.qcom,mdss_dsi_ctrl0 > /sys/bus/platform/drivers/mdss_dsi_ctrl/unbind
echo 1a00000.qcom,mdss_mdp:qcom,mdss_fb_primary > /sys/bus/platform/drivers/mdss_fb/unbind
echo 1a00000.qcom,mdss_mdp > /sys/bus/platform/drivers/mdp3/unbind
echo soc:qcom,mdss_dsi@0 > /sys/bus/platform/drivers/mdss_dsi/unbind
Some of the things I've tried without success:
asteroid-launcher
(which I understand uses libhybris) but not psplash
(which doesn't)psplash
but not asteroid-launcher
/sys/class/graphics/fb0
(mdss_hbm_enable
increases screen brightness, mdss_fb_disp_en_gpio
disables the display and is necessary to apply other sysctls)/sys/kernel/debug/mdp
/sys/kernel/debug/mdss_panel_fb0
(note: after modifying those, you need to write 1
to /sys/kernel/debug/mdss_panel_fb0/override_flag
, then 0
to mdss_fb_disp_en_gpio
, then 1
to mdss_fb_disp_en_gpio
, then restore framebuffer contents)/sys/kernel/debug/clk
/dev/fb0
, particularly LPM mode and vsync settingsasteroid-launcher
at various points to try to work out when the flickering startsSome progress:
If I modify mce
to lie about the display state to the dbus (and whoever's listening), the flickering goes away, but the display still works and brightness seems okay. In particular, I'm making mce
send
signal time=1691185489.798890 sender=:1.78 -> destination=(null destination) serial=107 path=/com/nokia/mce/signal; interface=com.nokia.mce.signal; member=display_status_ind
string "off"
even though the display is on and working. So my guess is someone's listening on the system dbus and putting the display in some sort of power-saving mode that I cannot distinguish from normal intended operation. However, it's possible it's blurry or the color representation is off and I just haven't noticed.
As this test was done on a somewhat hacked system, it needs further verification. Grepping suggests mcewatcher.c
might be what listens to the signal and somehow forwards it to the hybris layer...
Wow thanks for the research thus-far!
I'll follow this thread closely, it seems you're making great progress.
It might also fix the display issue introduced in https://github.com/AsteroidOS/meta-smartwatch/pull/149.
@MagneFire Thank you! That's really encouraging. I'll have a look at #149 (but don't have affected hardware).
Any suggestions or ideas would be very welcome, of course :-)
I finally traced it down to the component that was literally my last desperate "just in case" entry on the list: nfcd
.
Does anyone have a beluga
with stock firmware to test whether it happens there when NFC is in use or enabled? I feel rather silly for not thinking of the possibility before...
Anyway, is it possible this is a hardware issue and that NFC just isn't sufficiently isolated from the display electronics?
Fixed via https://github.com/AsteroidOS/meta-asteroid/pull/178 thanks for the great work you've put into figuring this one out!
The screen on
beluga
watches flickers slightly; the problem appears to be pixels not lighting up all the time, so it's particularly visible with bright backgrounds and high "backlight" brightness, and appears to happen (mostly?) near the left and right edges of the screen.So far, the only way I've found to stop the flickering is to unbind devices from the kernel drivers in the right order, causing an oops in the process and preventing further modification of the screen contents.