getting vblank timestamps sometimes fails or results in invalid timestamps #38
Comments
ekuusi
changed the title
ekuusi
changed the title
|
Is there a way to choose a different DRM mode? Wondering if the other available mode would work ... For reference, here is what I get when having the exact same setup, only this time my HDMI cable is connected to HP's 27er monitor: https://support.hp.com/us-en/product/hp-value-27-inch-displays/3989902/document/c05078501/ |
|
Further testing: If I change the resolution in the HP monitor to anything other than 1920x1080 in raspi-config -> advanced -> resolution, I get the same issue as with the WaveShare display: The screen goes dark, then the screen comes back on (you see the backlight going off and then on), but the screen remains black until I stop flutter-pi with ctrl+c. After that the command line appears back again. In this kind of a case the log I get from flutter-pi is exactly the same as above, for example here's the one when I have resolution set to 640x480 with the HP monitor. It seems like it is still trying to display 1920x1080 even though the resolution in raspi-config is different, as there's this bit below the modes: |
|
Tried with a Samsung 4K monitor, that works as well. So far the WaveShare panel is the only one not working. But even with the 4K monitor if I change the resolution to anything than the monitor default, it stops working. With this monitor I tried changing the resolution to 1920x1080, the same resolution the HP monitor worked with, and it failed again. So it doesn't seem like an issue of incompatible resolution values, rather that there's a problem when the resolution is not the default one. And perhaps there's a problem with WaveShare's firmware where the "default" resolution is wrong, or something like that? Just speculating possibilities ... |
|
Just tested it, I got the same problem with my monitor, albeit with the default 1080p60 resolution of my monitor, so it seems it's not only when configuring a non-default HDMI mode. It definitely worked before, so there's probably a regression somewhere in Actually the resolution configuration using I think it's unrelated to #16 though, that issue was (or still is) caused by a raspbian kernel / firmware bug. See here. He couldn't even boot into Raspbian Desktop without modifications. |
|
Okay the error seems to happen in this line, which is part of the vsync mechanism. Normally, I think for now I can build a workaround that disables vsync if |
- disable vsync if kernel doesnt supply valid vblank timestamps - print a warning when vsync is disabled for this reason
|
Pushed the workaround. Will have to do some investigation to see whether this is a kernel/firmware bug or some misconfiguration |
|
The screen works now, but there's a nasty side effect. I get this crash pretty soon after scrolling views in flutter: Doesn't happen always when scrolling, only when there's a hiccup for any reason (which happens pretty quick when using the UIKit demo I'm using for testing: https://github.com/iampawan/Flutter-UI-Kit ). Doesn't happen on the monitors that worked before, only on the problematic one. |
|
An error similar to |
my bad, some parts of the vsync mechanism mistakenly weren't disabled by the workaround. Should work now.
Wow Can you tell me what error code it prints in your case? So whats the text after EDIT: Would be even better if you could include the a log of the full output of |
|
Can confirm that it works now, no crashes. Your work is super impressive. Sorry to go a bit off-topic, but since we're discussing displays and as I've banged my head against this all day, quick question: is there a way to flip the HDMI screen 90 degrees somehow for flutter-pi? Since we have to use Fake-KMS, /boot/config.txt -> display_hdmi_rotate=1 doesn't work (it flips the screen but doesn't adjust resolution), and as we're not using X can't use xrandr, which is how it can be done in Desktop. |
Thank you!
This is actually integrated into flutter, just use The default await SystemChrome.setPreferredOrientations(const {DeviceOrientation.portraitUp});somewhere in your code. |
|
You're my hero. I love you. |
You're welcome 😄 EDIT: Now that there's a workaround in place and blanking doesn't occur anymore, I'm gonna change now to more accurately describe the underlying problem |
ardera
changed the title
drmCrtcGetSequence sometimes fails or returns invalid timestamps
ardera
changed the title
drmCrtcGetSequence sometimes fails or returns invalid timestamps
This is how my error log looks like. The screen goes dark/blank after this until ctrl+C is pressed. I'm not working on a Raspbian Image but on a Pi image of another embedded linux project. (Will check if I'm getting the same error when I use a Raspbian Image). Also could you include the flutter_assets of any very basic flutter application. Just to ensure that this isn't an error caused by any version mismatches. |
Clone this: https://github.com/iampawan/Flutter-UI-Kit Alternatively here's a direct link of the assets I've used, built with 1.12.3: |
These are not the cause of your problem though, but they may cause problems later on.
This is the actual problem. Two possible causes:
Yeah, @ekuusi's asset bundle will work. Btw you can create a minimal flutter app with the |
|
How did you create the flutter engine( Will your engine version 1.9.1 still work? The build I'm using doesn't support the latest version of flutter engine(1.12.3) Some GLIBC errors. |
|
@ardera Just to verify (even though it's pretty obvious), there indeed is some tearing happening without vsync. It's not horrible, and mostly only noticeable when you scroll up / down, but def something that would be worth looking into if there's a solution that "fixes" these problematic monitors. I tested various apps with both the HP monitor and the problematic one. Other than that, the performance on a RPi4 is really impressive, very smooth even on a 4k monitor. I did notice that for example in this demo app: https://github.com/scitbiz/flutter_pokedex the pokemon don't load (they did when building for my phone) and some background color animations didn't trigger (the color just instantly changes), even though I didn't notice any platform specific plugins. Not a big deal really, just curious why the difference, as other demo apps I tried seemed to work 1:1. EDIT: Also, am I missing something, because I'm building assets with --precompiled and --release: I guess the overflow errors are supposed to always be there, just annoying when doing quick demos with layouts not optimized for all monitors. Quick googling didn't turn out any oneliner solutions of hiding the overflow errors. |
Compiling the engine is a complicated topic. There are so many things that can go wrong doing it, many things that are platform-dependant, so I'm sorry but you're on your own. I support everyone that has problems with I can give you my cross compilation script though, link here. I compile in WSL because compiling on-target takes ages. This needs a cloned repo of GNU binutils, LLVM 9 and LLVM 10. Use at your own risk, I'm not gonna provide any support for it either. .
I agree. Actually I think the
Yeah I think so too, it's really great.
While the App doesn't depend on any plugins directly, it does indirectly. i.e. it depends on
Did you try the |
|
Ok, cool. The debug indeed doesn't seem to be an issue at the moment. Though eventually would be useful to be able to squeeze that extra performance out. I also tested https://rive.app/ demos (https://github.com/2d-inc/Flare-Flutter/tree/stable/example), the animations work and are smooth as butter. Using htop it was really neat seeing that when there's nothing going on in the app the Pi has one core at under 2% and everything else at 0, and while playing Rive / Flare animations just a couple of cores under 30% So, decided to go with flutter-pi for embedded so I can live that code (and animate) once deploy everywhere dream for real .. (if they hopefully get flutter for web production ready this year) |
I agree.
Nice! I've got to say though that flutter-pi is not really production ready. Could be that there are bugs or security risks, I don't provide any guarantees for that, it's more like an experiment right now. I'm not sure |
I am having the same issue as in #16
That is, flutter-pi shows a blank screen when I try to start the app when the Pi is connected to this display: https://www.waveshare.com/10.1inch-HDMI-LCD-B-with-case.htm
Connecting the Raspberry Pi to an hp 1080p monitor, everything works fine, including the touch screen panel from the above Waveshare display, so I can control the app fine by touching the display when I pipe the image to the HP monitor.
I'm running flutter-pi on Raspberry Pi 4 with the latest version of Raspbian Buster Desktop. I've modified it to boot to command line and then running flutter-pi there. The Waveshare display works otherwise fine, I'm able to for example boot to chromium in kiosk-mode and run a Flutter for Web app on it fine.
Any ideas how to get the display to work on flutter-pi? My expertise on such hardware issues is limited so it's a bit challenging to troubleshoot this one.
Here's the log when starting the app from SSH:
The text was updated successfully, but these errors were encountered: