Forgive me if I get some of the terminology wrong. I can't seem to get this driver to work without a running X server. Is that how it is supposed to be? Is there support for running applications using EGL without having an X server running?

If so, how would one go about doing things like setting the resolution?

Want to put the correct DT in config.txt (device_tree=)
But not sure whether there is a specific one for the Raspberry Pi 3 (a specific bcm2837 doesn't seem exist so unsure whether using bcm2836-rpi-2-b.dtb is the right thing to do here)
cheers, JD.

It seems that when i enable open gl on my pi3 it gives me a blank display every time, after some googling i found this forum post: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=140865&p=936901

so it seems that pi3 crashes / blanks display on some monitors, i do not have another monitor to check on so i am relying on what the forum post says.

Also no UART output so i can't interact with the pi at all.

PS my display model: ViewSonic VX2270 smh

The Adafruit DPI kippah looks like it ought to be pretty straightforward to support, but no serial for debugging will be a pain.

In /boot/config.txt with dtoverlay=vc4-kms-v3d & display_rotate=1 system does not boot. Black screen, no "rainbow" test screen. Nothing. dtoverlay=vc4-kms-v3d & display_rotate=0 works as expected.

display_rotate=1
gpu_mem=256
dtoverlay=vc4-kms-v3d

Raspberry Pi 3.

$ uname -a
Linux rpi 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux

Varad has been working on taking my anholt/vc4-kms-v3d-rpi2-binrendersubmit-2 branch and fixing it. Hopefully done soon.

This shouldn't be terribly hard.

We need this for zero-copy display of video.

Hi,

Using the old graphics mode, there's no problem, but booting with the VC4 driver shows a pink column of pixels on the console, on the left border of the HDMI TV.
My Pi and TV are running at the recommended mode of 1360x768 pixels.

This is the problem:
https://www.dropbox.com/s/wdf64hb0b26p8ha/20160724_221438.jpg

Any ideas on this issue?

Firstly it looks like vc4 doesn't work with DRI3 yet. To do anything I had to manually disable it by setting: LIBGL_DRI3_DISABLE=1

When I start X session manually and I try to run glxgears I get:

env LIBGL_DEBUG=verbose LIBGL_DRI3_DISABLE=1 glxgears
libGL: OpenDriver: trying /usr/lib/dri/tls/vc4_dri.so
libGL: OpenDriver: trying /usr/lib/dri/vc4_dri.so
libGL: Can't open configuration file /home/sandersr/.drirc: No such file or directory.
libGL: Can't open configuration file /home/sandersr/.drirc: No such file or directory.
libGL: Using DRI2 for screen 0
Attempting to import 300x300 b8g8r8x8_unorm with unsupported stride 1200 instead of 76
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
231 frames in 5.0 seconds = 46.066 FPS
233 frames in 5.0 seconds = 46.522 FPS
233 frames in 5.0 seconds = 46.527 FPS
233 frames in 5.0 seconds = 46.528 FPS

but the content of the window displayed on the LCD is completely blank.

env LIBGL_DEBUG=verbose LIBGL_DRI3_DISABLE=1 glxinfo | grep OpenGL
libGL: OpenDriver: trying /usr/lib/dri/tls/vc4_dri.so
libGL: OpenDriver: trying /usr/lib/dri/vc4_dri.so
libGL: Can't open configuration file /home/sandersr/.drirc: No such file or directory.
libGL: Can't open configuration file /home/sandersr/.drirc: No such file or directory.
libGL: Using DRI2 for screen 0
Attempting to import 100x100 b8g8r8x8_unorm with unsupported stride 400 instead of 28
OpenGL vendor string: Broadcom
OpenGL renderer string: Gallium 0.4 on VC4
OpenGL version string: 2.1 Mesa 12.0.1
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 12.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

rpm -qa | grep libdrm
libdrm-2.4.70-1.fc24.armv7hl

uname -a
Linux Celica 4.4.16-v7+ raspberrypi#900 SMP Wed Aug 10 18:02:31 BST 2016 armv7l armv7l armv7l GNU/Linux

Hola,

Thank you for the awesome work to date. I followed your instructions to get Linux 4.7 compiled and running on the Pi. This works awesome on the Raspberry Pi 2, but the same sd-card blanks on my Raspberry Pi 3 following the:

"Switching to vc4drmfb from simplefb"

My kernel sources have b3a15f6, which looks like it should address exactly this issue. (The associated description is perfect.)

Please let me know how I can help resolving this

Hello,

While using the render node, I found that the current implementation in raspberrypi 4.4 kernel lacks some flags allowing the IOCTLs to be used with a render mode.
Contrary to other flags, which are restricters, the flag for render node is an enabler (the IOCTL can't be used from render node if it's not present).
So it seems you need to add DRM_RENDER_ALLOW to all the flags that were previously to 0.
The attached patch is - hopefully - doing that.

Herve
0002-vc4-ioctl-rendering-allow.patch.txt

My Pi2 B v1.1 fails to boot when I have dtoverlay=vc4-kms-v3d in my config.txt unless an HDMI display is plugged in. This is not solved even when I have the official display connected. This bug seems to be present both in the latest released rasbian and in a kernel I built just now from the rpi-4.1.y branch here.

The DSI1 connector isn't enabled yet. drm-vc4-dsi-boot is the WIP for it, but currently writes to the device don't appear to take effect.

Sorry for my ignorance, but it seems that the VC4 drivers doesn't work quite properly together with pluggable USB display devices, or maybe this is an issue with Xorg.
I used a Raspberry PI2 + Lenovo LT1412 , but I guess it should do any other USB display. Without the option "experimental GL driver for desktop" it works quite well, but no OpenGL output on X.

Right now the DRM core is helping us out by polling the HPD periodically, but we should be able to just register for an interrupt, saving CPU wakeups.

Possibly related to a note about washed out colors in openarena.

Hi,

When I start RPI3 with DSI LCD screen, the framebuffer seems to be bigger than the screen. Once the cursor reaches the bottom of the screen it disappears but I can still type the commands.
dmesg for reference

These are going to be tricker than the other panels: We need to use the transposer to write back into memory, then when the transposer is done we need to use the DMA engine to stream the new frame over SPI to the device. I hope.

Sorry I know this isn't exactly the right place for questions... But can I use libgles2-mesa with this VC4 driver? I read all these things saying that this driver "disables" GLES2, but I assume they mean the Broadcom closed-source implementation of GLES2.

There are some GLES extensions (OES_depth_texture for instance) that are not implemented in the closed-source driver, so I was hoping to be able to use libgles2-mesa and this driver.

Also, is that crazy to do? Is there any downside to doing this? I don't want to use full OpenGL because some applications assume that if you have OpenGL, you must be able to handle all kinds of fancy stuff, whereas I just want to run the application in "GLES" mode.

Hi,

I'm trying to get Xorg and/or wayland (kwin_wayland to be precise) working under vc4. I do not have HDMI screen connected, just the 7" official DSI LCD.

I'm using the following kernel:
Linux 4.4.16-v7+ raspberrypi#900 SMP Wed Aug 10 18:02:31 BST 2016 armv7l armv7l armv7l GNU/Linux

and the system boots fine: dmesg

When I start sddm, it starts an Xorg server instance. Xorg.0.log

Looking at ps output, I can see Xorg running:

ps ax | grep X
718 tty1 Ss+ 0:01 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{da410aef-9a1d-4af9-be98-075308f677df} -background none -noreset -displayfd 17 vt1
728 ? S 0:00 /bin/bash /etc/X11/xinit/Xsession /usr/bin/startkde
738 ? S 0:00 /bin/bash /etc/X11/xinit/Xsession /usr/bin/startkde

At this point the screen goes all black. At the same time, this line is added to the dmesg:
[Fri Aug 12 09:24:14 2016] disable

switching to another VT works fine and LCD panel greets you with a VT login prompt. Switching back to the X brings back the blank black screen.

I also manually logged in to the console and started X with just startx
The X server starts ok:
grep X
683 tty2 S+ 0:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 vt2 -keeptty -nolisten tcp -auth /home/sandersr/.serverauth.661
684 tty2 S 0:01 /usr/libexec/Xorg :0 vt2 -keeptty -nolisten tcp -auth /home/sandersr/.serverauth.661
686 ? Ss 0:00 /bin/sh /etc/X11/xinit/xinitrc

but I cannot talk to it:
$ export DISPALY=:0
$ xrandr
Can't open display

Please let me know if you need any more information.

The GPIO line for the HDMI hotplug detect reports inverted results, so the kernel thinks it's not connected. TODO: see if this is true on pi1 as well.

Hello from Hamburg!

Thank you very much for your awesome work!

I am currently trying to get the Raspberry PI 3 to boot in 64bit mode with activated VideoCore device, but am still failing.

After some booting using simplefb, the console blanks out.

I have retrieved the dmesg from the failed boot and found these entries:

grep -i -P "(vc4|drm|console)" dmesg_not_working2.txt
[ 0.000000] Kernel command line: console=tty0 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes cma=256M@512M rootwait
[ 0.004791] Console: colour dummy device 80x25
[ 0.025957] console [tty0] enabled
[ 2.380990] Console: switching to colour frame buffer device 210x65
[ 28.405139] [drm] Initialized drm 1.1.0 20060810
[ 32.569560] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
[ 32.684805] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
[ 32.908000] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
[ 33.023165] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
[ 33.131309] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
[ 33.240326] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
[ 33.347174] fb: switching to vc4drmfb from simple
[ 33.457027] Console: switching to colour dummy device 80x25
[ 33.514638] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 33.515617] [drm] No driver support for vblank timestamp query.
[ 33.520274] vc4-drm soc:gpu: No connectors reported connected with modes
[ 33.521854] [drm] Cannot find any crtc or sizes - going 1024x768
[ 34.070008] Console: switching to colour frame buffer device 128x48
[ 34.506082] vc4-drm soc:gpu: fb0: frame buffer device

There are other issues (like USB not working), which might have to be fixed, first, but maybe you have an idea why the gpu can not find the display?

What information can I provide to help analyzing the problem?

Thank you very much in advance

Sven

latest firmware as of 8/21, display connected via cheap HDMI->VGA adapter

when not using 3D, it works out of the box:
tvservice -s shows:
state 0x12000a [HDMI DMT (18) RGB full 4:3], 1024x768 @ 75.00Hz, progressive
0x12000a = VC_SDTV_ATTACHED, VC_SDTV_CP_INACTIVE, VC_HDMI_ATTACHED, VC_HDMI_HDMI
explicitly setting the mode also works:

/opt/vc/bin/tvservice -e "DMT 18 HDMI"
Powering on HDMI with explicit settings (DMT mode 18)

with dtoverlay=vc4-kms-v3d, it shows the rainbow, but then shows blank screen during boot and also blank when X is started.
tvservice -s shows HDMI unplugged:
state 0x120009 [HDMI DMT (18) RGB full 4:3], 1024x768 @ 75.00Hz, progressive
0x120009 = VC_SDTV_ATTACHED, VC_SDTV_CP_INACTIVE, VC_HDMI_UNPLUGGED, VC_HDMI_HDMI
explicitly setting the mode fails:

/opt/vc/bin/tvservice -e "DMT 18 HDMI"
Powering on HDMI with explicit settings (DMT mode 18)
[E] Failed to power on HDMI with explicit settings (DMT mode 18)

So for I have added to the /boot/config.txt
avoid_warnings=2
hdmi_drive=2
hdmi_group=2 #1=CEA 2=DMT
hdmi_mode=18
gpu_mem=128
hdmi_force_hotplug=1 # Use HDMI mode even if no HDMI monitor is detected

Anything else I can try, or should report?

Dirk

Thanks to your recent work on support for the DPI interface, I've been able to use the VGA666 adapter with the open-source vc4 driver. It's a very simplified D/A converter which turns the DPI signal into VGA-like analog video. I'm using it with an arcade CRT monitor that's rather different from the normal VGA monitor - it only supports video modes with 15 or 25kHz horizontal scan rate, i.e. 240p/384p/480i/768i. I had to make what feels like a bit of a hack to get this working and I'm really looking for pointers on how to do it "properly".

There is already a device tree overlay for the VGA666 adapter but I found it needed some additions to enable the vc4 driver to work with it: raspberrypi/linux@rpi-4.4.y...sigmaris:vga666-dpi
I also added a panel_desc into the kernel code with some supported video modes for my particular monitor. Now I can switch between custom modes on the monitor without a reboot, which I couldn't do with the closed-source VC4 firmware.

But having to add custom modes to the kernel source and recompile seems awkward, since all kinds of monitors could be connected to the VGA666 adapter but my changes are very specific to the non-standard arcade monitor I'm using. Is there a better way to tell the driver what modes are supported without recompiling (device tree parameters?) or a way to set up custom modes after boot (i.e. set the pixel clock, h-sync and v-sync timings, etc)?

By visiting the following page using Chromium (Version 48.0.2564.82 Built on Ubuntu 15.04, running on Raspbian 8.0, with hardware acceleration for WebGL), and setting the renderer option to "WebGL", my entire system completely froze 2 out of 3 times:
http://brm.io/matter-js/demo/

Unfortunately, there's nothing in /var/log/kern.log from the crash itself, although it's full of messages like the following:

Mar 12 10:28:17 pi3 kernel: [ 1157.017293] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 3956736
Mar 12 10:28:17 pi3 kernel: [ 1157.017346] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 3956736
Mar 12 10:28:17 pi3 kernel: [ 1157.018377] [drm] Resetting GPU.
Mar 12 10:28:17 pi3 kernel: [ 1157.022468] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 3956736
Mar 12 10:28:17 pi3 kernel: [ 1157.022817] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 3956736
Mar 12 10:28:17 pi3 kernel: [ 1157.027353] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 3956736
<snip>
Mar 12 11:04:34 pi3 kernel: [  183.699052] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 4857856
Mar 12 11:04:34 pi3 kernel: [  183.699676] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 4857856
Mar 12 11:04:34 pi3 kernel: [  183.699840] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 4857856
Mar 12 11:04:34 pi3 kernel: [  183.699901] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 4857856
Mar 12 11:04:34 pi3 kernel: [  183.699924] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
Mar 12 11:04:34 pi3 kernel: [  183.699928] [drm] num bos allocated: 322
Mar 12 11:04:34 pi3 kernel: [  183.699933] [drm] size bos allocated: 197112kb
Mar 12 11:04:34 pi3 kernel: [  183.699937] [drm] num bos used: 320
Mar 12 11:04:34 pi3 kernel: [  183.699941] [drm] size bos used: 187624kb
Mar 12 11:04:34 pi3 kernel: [  183.699945] [drm] num bos cached: 2
Mar 12 11:04:34 pi3 kernel: [  183.699948] [drm] size bos cached: 9488kb

I have looked all over for the answer to this, as it seems others have encountered this problem as well, but I could never find a clear answer. Putting "avoid_warnings=2" in my /boot/config.txt did not do anything at all, and using another screen did not work either. I did switch out PSU from a 5V 2.1A to a 5V 2.3A but I still received the red-blue-green-yellow square on bootup, which indicates a brownout, or not enough voltage being supplied. When I had a Raspberry Pi 1, this sign would appear quite frequently and it still worked perfectly, so I don't believe that voltage has anything to do with it. Anyway, on to the problem. I have a Sandisk 8GB SD Card, which is compatible with the Raspberry Pi 2, according to the website. I flashed the latest Raspbian version (March 2016) onto the SD card using the command "sudo dd bs=4M if=~/Downloads/March2016/raspbian-jessie-March2016.img of=/dev/sdb" and successfully flash Raspbian. I then remove the SD card from the computer, take it out of the adapter, and insert it into my Raspberry Pi 2. It boots up fine, and I reboot it once out-of-the-box to make sure there is no corruption or problems, and after a reboot, I realize everything is working fine. The first things I do is go to my terminal and issue "sudo apt-get update && sudo apt-get -y upgrade" and patiently wait for that to finish. Afterwards, I go to the Raspbian Preferences and click Expand Filesystem, and I reboot. Upon entering Desktop again, I issue "sudo apt-get -y install xcompmgr libgl1-mesa-dri && sudo apt-get -y install libalut0 libalut-dev"
and receive the latest drivers. I issued "sudo raspi-config" and enabled the new OpenGL driver located in Advanced Options. I then reboot my Raspberry Pi 2 in high hopes, and my hopes are dashed by after reboot, a low voltage / brownout symbol covering the whole screen, after that, a flash of NO SIGNAL and then suddenly, just blackness. A pure black screen.

I have tried this on two different screens, one 1020x600 Touchscreen 7" which I mainly use for my Raspberry Pi's and another a large screen television to which I don't exactly know the resolution, but I would guess between 1080p and 1700p.

Any fix to this?

( I have not tried SSH yet to retrieve the logs, but if you absolutely require the logs, I will do good to enable and get them to you. However, it seems this problem has been answered before, so, I don't really expect to need to give you the logs. If you need them, just ask. )

Hello from Hamburg!

Thank you very much for your awesome work!

I am currently trying to get my Raspberry Pi 3 to boot in 64bit mode using your bcm2837-64-next branch.

While USB works fine using the kernel from https://github.com/Electron752/linux/tree/rpi-4.5.y+rpi364 , it does not work using the most current 4.7 kernel from bcm2837-64-next.

What I get in dmesg is:

grep -i -P "usb" dmesg_not_working.txt
[ 1.779777] usbcore: registered new interface driver usbfs
[ 1.783796] usbcore: registered new interface driver hub
[ 1.788265] usbcore: registered new device driver usb
[ 29.960789] usbcore: registered new interface driver cdc_ether
[ 30.077724] usbcore: registered new interface driver smsc95xx
[ 30.337978] 3f980000.usb supply vusb_d not found, using dummy regulator
[ 30.452091] 3f980000.usb supply vusb_a not found, using dummy regulator
[ 30.696159] dwc2 3f980000.usb: 256 invalid for host_nperio_tx_fifo_size. Check HW configuration.
[ 30.809321] dwc2 3f980000.usb: 512 invalid for host_perio_tx_fifo_size. Check HW configuration.
[ 31.000247] dwc2 3f980000.usb: Specified GNPTXFDEP=1024 > 32
[ 31.116064] dwc2 3f980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[ 31.253264] dwc2 3f980000.usb: DWC OTG Controller
[ 31.366900] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1
[ 31.481353] dwc2 3f980000.usb: irq 41, io mem 0x00000000
[ 31.633936] hub 1-0:1.0: USB hub found
[ 31.909958] usbcore: registered new interface driver usb-storage
[ 32.028306] usbcore: registered new interface driver usbled
[ 33.181042] usbcore: registered new interface driver usbhid
[ 33.288221] usbhid: USB HID core driver

Unfortunately no other USB events show up, so I have neither ethernet, nor keyboard or mouse.

Do you have any idea, what I am missing? I am using the same configuration as with the Electron752 kernel, updated with your current defconfig.

What information can I provide to help analyzing the problem?

Thank you very much

Sven

Hi,

I have been adapting other people's pupular programs (RetroArch, Scummvm, and a long etc) to use the dispmanx API for years now.
However, dispmanx should, sooner or later, be superseeded by KMS/DRM, so I am adapting RetroArch to it.

With dispmanx, things were easy for blitting. Let's say I want to copy a 256x256 rect for a 298x256 buffer to a dismanx "resource" (buffer). Well, I have this GREAT dispmanx function for that:

vc_dispmanx_resource_write_data( DISPMANX_RESOURCE_HANDLE_T res, VC_IMAGE_TYPE_T src_type, int src_pitch, void * src_address, const VC_RECT_T * rect );

You see, I can pass a pitch, let's say 256*4 if I am blitting a pixel array with 4 bytes per pixel, and then it will be uploaded to the GPU without using the CPU for the transfer. Very fast and good solution!

But in KMS, using a dumb buffer, without an specific function to do it, I would have to copy a pitch of pixels each line, so in 256 lines I would be calling memcpy() 256 times to archieve the same. And that's for small rect...

So, I have seen that /usr/include/drm contains some hardware-specific implementations of blitting functions. Is there something similar on the Pi? I don't mind using IOCTLs or whatever is needed...

Hi Eric,

Amazed at the progress you're making.
I have an issue that the screen is black at the default 1920x1080 resolution. infrequently i get a picture for about a second and then it disappears again, setting the raspberry pi to output a resolution of 1280x720 does work.

by the way, probably a separate bug (and can file separately if you like) changing the screen resolution via /opt/vc/bin/tvservice causes a purple line(s) to appear at the screen edge(s).

I would like to post any relevant info you need to catch what's going on but I don't know what it is you need.

I'm running on a raspberry pi 3 with arch:
Linux alarmpi 4.4.8-1-ARCH #1 SMP Fri Apr 22 18:47:51 MDT 2016 armv7l GNU/Linux

config.txt:

hdmi_group=1

hdmi_mode=4

disable_overscan=1

framebuffer_depth=32

gpu_mem=256

dtoverlay=hifiberry-dacplus

dtoverlay=vc4-kms-v3d
avoid_warnings=2

The monitor i'm using works fine with other devices at 1920x1080 60/59mhz.

So grateful for your work, pretty soon I'll enjoy my raspberry pi almost as much as I do cookies.

We'll definitely want this for DSI. There are bits for X and Y flips per plane, and we need to reduce rotations to those.

After enabling the new opengl driver on my Raspberry PI 2, I receive a black screen on my TV after the rainbow. When I SSH in see what's in the logs, I see a bunch of errors about EDID information being goofed up. I've included these logs below for reference.

Xorg.0.log:
http://pastebin.com/3SbXUdkb

dmesg:
http://pastebin.com/RHALEPYj

config.txt:
http://pastebin.com/Pz8bUj7c

Thanks everyone, looking forward to goofing around with the accelerated graphics! Also, I’m going to try this on my other monitor to make sure it's the display.

• I've verified I'm using a 5v 2A power adapter and am running a Raspberry PI 2 with a fresh Raspian image.
• I've tried forcing 1080p using the config.txt file
• I've tried changing the GPU memory
• I've tried ignoring EDID in the config.txt file
• I've tried enabling HDMI boost (4)
• I tried suggestions at #24 with no luck

I'm using 5bc0a41 with a DVI monitor (K212HQL)
Here is dmesg.
https://gist.github.com/173210/d6e287bd3c45307a37c081218e6a6c09

(snip)
[ 0.000000] Kernel command line: cma=128M@128M dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2708.boardrev=0x10 bcm2708.serial=0xa2ce3e8c st...
(snip)
[    0.879274] [drm] Initialized drm 1.1.0 20060810
[    0.886191] [drm:vc4_hdmi_bind] *ERROR* Failed to get pixel clock
[    0.892419] vc4-drm soc:gpu: failed to bind 20902000.hdmi (ops vc4_hdmi_ops): -517
[    0.900297] vc4-drm soc:gpu: master bind failed: -517
(snip)
[    1.549134] bcm2708_i2c 20805000.i2c: BSC2 Controller at 0x20805000 (irq 77) (baudrate 100000)
(snip)
[    1.765351] vc4-drm soc:gpu: bound 20902000.hdmi (ops vc4_hdmi_ops)
[    1.771939] vc4-drm soc:gpu: bound 20206000.pixelvalve (ops vc4_crtc_ops)
(snip)
[    1.794617] vc4-drm soc:gpu: bound 20207000.pixelvalve (ops vc4_crtc_ops)
[    1.801694] vc4-drm soc:gpu: bound 20807000.pixelvalve (ops vc4_crtc_ops)
[    1.823146] vc4-drm soc:gpu: bound 20400000.hvs (ops vc4_hvs_ops)
[    1.843225] vc4-drm soc:gpu: bound 20c00000.v3d (ops vc4_v3d_ops)
[    1.850835] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    1.873077] [drm] No driver support for vblank timestamp query.
[    1.879278] vc4-drm soc:gpu: No connectors reported connected with modes
[    1.888631] [drm] Cannot find any crtc or sizes - going 1024x768
[    1.925583] Console: switching to colour frame buffer device 128x48
[    1.955738] vc4-drm soc:gpu: fb0:  frame buffer device

So it's failing to detect the monitor?

When trying to play 0ad, the game load fine but I start a game, at the middle of the loading screen the screen gets garbled and goes to black.
The following messages are found in dmesg

80710.527173] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 5595136
[80710.527467] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 5595136
[80710.527607] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 5595136
[80710.527737] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 5595136
[80710.527782] [drm:vc4_bo_create [vc4]] ERROR Failed to allocate from CMA:
[80710.527796] [drm] num bos allocated: 694
[80710.527809] [drm] size bos allocated: 245204kb
[80710.527821] [drm] num bos used: 692
[80710.527833] [drm] size bos used: 234276kb
[80710.527845] [drm] num bos cached: 2
[80710.527859] [drm] size bos cached: 10928kb

80715.107110] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 1056768
[80715.107256] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 1056768
[80715.107306] [drm:vc4_bo_create [vc4]] ERROR Failed to allocate from CMA:
[80715.107322] [drm] num bos allocated: 707
[80715.107335] [drm] size bos allocated: 239508kb
[80715.107350] [drm] num bos used: 701
[80715.107362] [drm] size bos used: 236148kb
[80715.107374] [drm] num bos cached: 6
[80715.107385] [drm] size bos cached: 3360kb
[80715.107425] [drm:vc4_validate_bin_cl [vc4]] ERROR 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate
[80715.112874] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 1060864
[80715.113139] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 1060864
[80717.076550] [drm] Resetting GPU.
[80717.077174] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 1060864
[80717.077312] vc4-drm soc:gpu@7e4c0000: failed to allocate buffer with size 1060864
[80717.077357] [drm:vc4_bo_create [vc4]] ERROR Failed to allocate from CMA:
[80717.077371] [drm] num bos allocated: 703
[80717.077384] [drm] size bos allocated: 237968kb
[80717.077397] [drm] num bos used: 701
[80717.077409] [drm] size bos used: 235896kb
[80717.077420] [drm] num bos cached: 2
[80717.077432] [drm] size bos cached: 2072kb
[80717.077470] [drm:vc4_validate_bin_cl [vc4]] ERROR 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate

I managed to attach a serial cable to the gpio of an rpi2 (I've also got an rpi3 handy)
and captured some logs from the serial console, not sure if these might be handy

I've tried 2 different kernels so far

• Latest rpi sources now based on full 4.5 release / latest commit - rpi-4.5.y
• The kernel from the drm-vc4-4.5 branch (it was only updated a few hours ago, so I wasn't expecting anything to work)

The strange thing is, I'm still getting the same error as before about the pixel clock, but since it's the latest commit it should be included in the kernel, I have a feeling it's currently not being linked into the kernel binary, so I'm going to try and look at that next.

• rpi-sources No Monitor attached
• rpi-sources Packard Bell Monitor via DVI
• rpi-sources Samsung Monitor direct HDMI
• rpi-sources Samsung Monitor via hdmi switch box
• rpi-sources LG TV hdmi input
• drm-vc4-4.5 dmesg log
• kernel .config
• cmdline.txt
• config.txt

Made progress on this on 2016-02-15, but not quite there yet.

Hi
I hope this is the correct place to report this, I have done some searching and not found anything relating to this issue.

When running Raspbian without the OpenGL driver to my Full HD TV (via HDMI) we can see the entire screen, both at bootup and when running X.
When we swap over to the OpenGL driver the image extends past the edge of the TV on all sides, both on the console at bootup and when running X.

Changing the overscan options from raspi-config has no effect.
Changing the overscan_{left|right|top|bottom} and the disable_overscan in config.txt, has no effect.

Am I just missing the obvious, configured wrong, or is this a bug?
Let me know what information you require and I will get it for you.

Thank you for all your hard work getting this driver working :-)

Hi,

Trying to do:
drmModeAtomicCommit(drm.fd, req, DRM_MODE_PAGE_FLIP_EVENT|DRM_MODE_PAGE_FLIP_ASYNC, &pipe);

results on synchronous drmModeAtomicCommit() call: it returns when pageflip is done, instead of returning immediately as it is supposed to do.
So I was wondering if asynchronous atomic pageflipping is supposed to be working already with this KMS/DRM driver or not.
If it's not, I could implement my own thread, but having this block in the main thread is not desired at all for CPU-intensive emulation: we don't have CPU time to waste waiting for vsync.
But I would like to know if it's supposed to be working already.

Thanks!

Hi,
I am using an hdmi to vga converter on my rpi 2. If using the downstream kernel and binary blob, I can get the display's EDID by the command 'tvservice -d xxx'. But if using the upstream kernel, I get black screen because the driver cannot get display's EDID. I tried to use the command like 'i2cdump 2 0x50' and it still got nothing (kernel dumps: "i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100"). I have also tried the same converter and the display on the PC to exclude the device issue. It can get the EDID by using the command 'i2cdump 2 0x50'.
Any suggenstion for debugging?
config.txt
dmesg.txt

After the upgrade to (a self-built) 4.4.11, I noticed that the colors on my HDMI TV look brighter and light colors become white. I guess this has something to do with the VC4 update and "drm/vc4: Add support for gamma ramps". Hence, I wanted to ask if this is intended? I don't run a DE but just a fullscreen QML-based slideshow with Xorg.

Although xrandr shows me that the brightness is set to 1, setting it again to 1 seems to fix the colors. I noticed though that the gamma also gets changed from 0.46:0.46:0.46 to 1:1:1 although I only set the brightness.

Followed https://dri.freedesktop.org/wiki/VC4/, and used vc4_kms_v3d branch (5e0242f), but I had no luck.
I wrote cmdline.txt as the following but it has no UART output.

cma=256M@512M console=ttyAMA0,115200 kgdboc=ttyAMA0,115200

config.txt only contains avoid_warnings=2\n.
The firmware is up-to-date (e0fedf15518eef8a56f41113abd5ec8171e3981c), and has no additional bootloader such as Das U-Boot.

I also confirmed rpi-4.4.y(5bc0a41) works with the above configuration, but doesn't have DRM.
Any idea?

I am a developer with an application that runs into strangeness when ran on a rasberryPi3 with a stock rasbian install once hardware acceleration is enabled. The software renderer however performs as expected which leads me to believe this is a bug with the driver and not my code.

I have a mouse selection algorithm which reads the Z value of the pixel under the mouse and if closer than zFar it calls gluUnproject and checks whether the Z value is between -1.0 and 1.0. As far as I'm aware this is quite standard practice yet I'm now getting odd values as soon as I turn on hardware rendering which breaks mouse handling. Turn it off and values are correct again. Normally I'd consider my code but the application runs on multiple architectures and other systems without issues.

In C++ the minimal use case is basically...

//Scene setup in projection mode then glFrustum with aspect boilerplate, zNear 0.1f  zFar 100000.0f
//Before this Render some pixels with Z set to -2000.0f.
//Transform it however you please, then mouse over it.

GLint rendered_viewport[4];
GLdouble  rendered_modelview[16];
GLdouble  rendered_projection[16]; 
GLfloat winX, winY, winZ;
//Read in the rendered_ variables from glGet calls... [not listing these]
glGetIntegerv( GL_VIEWPORT, viewport );
winX = event.xmotion.x; //X11 mouse event
winY = (float)viewport[3] - event.xmotion.y; //Proper Z invert here found in opengl manuals. 
glReadPixels( winX, winY, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &winZ);
gluUnProject( winX, winY, winZ, rendered_modelview, rendered_projection, rendered_viewport, &posX, &posY, &posZ);
if (posZ >= -1 && posZ <= 1.0) {
    //When mousing over the drawn pixels, we should land here once unprojecting
    //(Normally from here you'd then run whatever picking algorithm if multiple objects)
} else {
    //When not mousing over we should land here.
    //But when hardware acceleration is turned on, Z is larger than 1.0 when mousing over.
    //However it's not garbage, random, or anything else hinting at undefined behavior.
}

Since I'm also using quite boilerplate X11 window creation code I'll simply state that I'm obtaining a 24 bit framebuffer and the calls to query the provided surface seem to confirm it's 24 bits. Is there anything else I could be missing here on my end or is this a driver bug?

Thanks!

Hi,
I recently raised an issue on the rpi linux sources repo, but I think this might be the better place for it
raspberrypi#1344

One of the recent changes there, seems to prevent the kernel from booting up when dtoverlay=vc4-kms-v3d is enabled, commit id 8924ecf

that being said without that commit my system will bootup but vc4 is having problems recognising the monitor for some reason (I'm still in the process of trying different options from the default to see if I'm missing something that needs to be compiled in directly)

[drm:vc4_hdmi_bind] *ERROR* Failed to get pixel clock
[    2.228836] vc4-drm soc:gpu@7e4c0000: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517
[    2.242500] vc4-drm soc:gpu@7e4c0000: master bind failed: -517

perhaps this is related to the issue of the system not booting when there's no monitor connected that others have been seeing

Previous debugging session indicated that the clock driver was failing at <100Mhz, and most non-1920x1080 resolutions were below that. However, 2016-02-15 debugging indicated that the clock driver was doing OK, but all non-1920x1080 resolutions were broken.

I am testing an application (mupen64plus with the GLideN64 graphics plugin) using the closed source driver and this driver. When I use this driver, the CPU usage is much higher, to the point that performance suffers on some games (when CPU gets to 95%+ busy, whereas using the closed source driver it wouldn't be higher than 60-70%)

I profiled the application using google-perftools, and __driDriverGetExtensions_vc4 is using anywhere from 12-22% of the CPU time, with nouveau_drm_screen_create being the next highest at 8-12% (they are the top 2 functions for CPU usage).

I guess my other question would be: why is it not using vc4_drm_screen_create?

Currently we call our tiles in raster order. If you do a hilbert fractal-like walk instead it can slightly increase cache locality for the texture sampler.

grateful for kernel compilation instructions at https://dri.freedesktop.org/wiki/VC4/

after building and installing the kernel I'm having trouble booting it (get's stuck on rainbow screen).
The following may be the issue:

The kernel will have installed under /boot with some version (make kernelversion tells you what it was). Update your config.txt to contain:

avoid_warnings=2 # VPU shouldn't smash our display setup.
kernel=vmlinuz-KERNELVERSION
device_tree=dtbs/KERNELVERSION/bcm2836-rpi-2-b.dtb

is vmlinuz (second line of config.txt) correct? should it be vmlinux?

and then comes the pasting of correct values for KERNELVERSION

output of make kernerversion is: 4.6.0

but should I replace KERNELVERSION with 4.6.0-next-20160524 (since that's the version I did git checkout for)?

another thing, the dtbs folder doesn't exist in my /boot.

current contents of /boot:
System.map-4.6.0-next-20160524 fixup_db.dat
bcm2709-rpi-2-b.dtb fixup_x.dat
bcm2710-rpi-3-b.dtb kernel7.img
bootcode.bin overlays
cmdline.txt start.elf
cmdline.txt.backup start_cd.elf
config.txt start_db.elf
config.txt.backup start_x.elf
fixup.dat vmlinux-4.6.0-next-20160524
fixup_cd.dat

System specs: Raspberry Pi 3 with arch linux ARM installed.

We need this for zero copy display of camera contents.

This might be a documentation issue. I've tried compiling drm-vc4-next and for-next branches in order to get IF statement support in shaders on my Rpi3. I got Mesa git compiled that otherwise works on latest Rpi official kernel.

drm-vc4-next didn't have the Rpi3 device tree. for-next had but I had to compile the .dtb manually. drm-vc4-next seemed to be working on Rpi2, but didn't want to load mesa dri module of vc4 for some reason. drm-vc4-next booted Rpi3 to black screen when I put the rpi3 .dtb from for-next in there.

Maybe some sd card image would be useful for people who just want to test their user space apps.

In short, how to test the latest Mesa OpenGL stack?