weston produces a black screen with fkms mode but not kms

[Gerharddc]

For reasons described in #72 I am trying to eventually get OpenGL ES 2 running on fkms. In said issue I was working with self compiled kernels etc but I have now tested with stock Raspbian everything just to make sure this was not my distro's fault.

When configuring Raspbian to use VC4 and then changing the overlay to fkms everything seems to work fine at first. In other words, the framebuffer console comes up and works just fine. In my previous issue I tested with a DRM OpenGL application but in this case it did not want to compile and instead of wasting my time I instead tried to see if Weston would launch. To little surprise after launching Weston on fkms the screen just went black while on normal kms it worked just fine. I therefore believe that fimwarekms is broken on either EGL or DRM level. Am I missing something or is this a known problem?

[ktb83]

Hi Gerharddc,

I've been trying to get the Anholt driver working with the RPF touchscreen.

I did an ARM64 Debian Sid build with the 4.10 64-bit kernel which is running great in general:
Linux version 4.10.0-rc3-v8+ (ktb@KTBMacMini) (gcc version 6.2.1 20161124 (Ubuntu/Linaro 6.2.1-5ubuntu1) ) #2 SMP PREEMPT Wed Jan 18 11:34:51 CST 2017

I've been able to use vc4-kms-v3d with an HDMI connected TV. Works OK. Unfortunately, I haven't gotten the RPF touchscreen to work with it. I'll keep trying.

Using vc4-fkms-v3d, I'm able to get the RPF touchscreen to sort of work. The desktop/display seems to basically freeze up after logging in via LightDM (EDIT: actually, it locks up after I try to launch an application). However, if I SSH in from another machine, then it unfreezes. Strange? Permissions issue?

EDIT: Upon second review, perhaps applications are just launching very slowly, hanging up on something? Whatever it is, the the hangs tend to go away if I SSH in to the Pi while it's locked up (cursor spinning, but not movable).

Did you build the 64-bit userland? I did.

The onboard WiFi works, but I haven't worked out the bluetooth error I'm seeing. Somehow the driver feels slower than it did last year when I was testing/playing Open Arena with cma=512M. Unfortunately, it no longer boots with cma=512M.

[Gerharddc]

@ktb83 Yes I have built a 64 bit a userpace, but not "userland" as that is actually the package for the proprietary GPU driver which I cannot build. I have also been able to get 64bit OpenGL applications running in normal KMS on the RPF touchscreen even though the console framebuffer doesn’t show until I exit one of these applications after running it. I have no idea what causes that.

Relating to this question though I cannot get OpenGL + DRM stuff to work with FKMS even though I can get it to boot and show a framebuffer.

I have not tested WiFi yet.

[Electron752]

@ktb83 - I was able to track the weird locks to GPU Reset/Hangs. I have no idea what is causing it though. If anybody has any ideas...

I also noticed cma=512M doesn't work anymore either. I haven't been able to determine why yet. The RPI 3 doesn't make it very far into the boot process at all. I guess one thing to try is the good old fashioned serial console to see if any error messages are being printed.

The cma=512M is too bad, because my monitor likes to run at 1920x1080 and running at that resolution is a bit memory intensive.

[ktb83]

I think Eric mentioned somewhere in a GitHub comment that it is limited to 256 for some reason. I don't know why.

I found some of my notes from 2015:
gohai/vc4-buildbot#3
gohai/vc4-buildbot#4

[Electron752]

OK, I remember reading now the 256 is a hardware limitation of the GPU. I remember reading it from this topic:

raspberrypi#1707

I have no idea how cma=512M every worked.

[anholt]

Testing the 4.9 backport PR with HDMI-only, fkms came up with lightdm autologin into XFCE just fine and GL apps are fine.

weston produces a black screen with fkms, but not with proper kms. Renaming this issue and focusing it on that bug.

[anholt]

Things I've learned so far:

• Sometimes weston will go from black to displaying once I move the cursor.
• Sometimes it doesn't.
• Weston, weridly, doesn't display the cursor at first startup.
• Our display is being scanned out as ARGB, with HVS looking at the alpha channel. That's no good. DRM (fbdev, at least) requires that we support XRGB. Unfortunately, the alpha_mode=0 property channel message to set xrgb mode will get smashed back to 0 when we do our MBOX message. OTOH, given that below our primary plane is just black, I guess this is fine.
• Got a pageflipping failure under X, will investigate that first since it doesn't require screwing around on the console like weston does.

[anholt]

Got it. Failed to attach pageflip completion events to the CRTC. Fixed in my 4.9 PR now, and I'm working on a 4.4.

[anholt]

4.4 PR is merged. 4.9 is still stalled, but I'm going to mark this fixed since we've got the patch in the current stable branch.