Dragging a window around crashes X

[skjegg]

Hello.. I've been running the BuildRaspbianVc4.py scrip over the last couple of days, and it finally finished this morning. After completing, I rebooted, but the PI2 I have won't boot off that image. Is there some magic steps I'm missing between finishing running the script and rebooting? EDIT: Managed to get it up and running, through /boot/config.txt tweaking..

PI2 Running Jessie, upgraded from wheezy and fully updated

Turns out it does boot, possbily after messing with settings in /boot/config.txt but still no GUI. Can ssh in, and see that the vc4 driver is being loaded, which is exciting.. EDIT: Some more messing with /boot/config.txt, and I now get all the way to x. Dragging a window around in LXDE with openbox causes a crash

Some dmesg output that seems relevant: (EDIT: may not be anymore, leaving here in case it is..)

[ 1.584912] vc-cma: Videocore CMA driver [ 1.588868] vc-cma: vc_cma_base = 0x00000000 [ 1.593625] vc-cma: vc_cma_size = 0x00000000 (0 MiB) [ 1.599047] vc-cma: vc_cma_initial = 0x00000000 (0 MiB) [ 1.604752] vc-mem: phys_addr:0x00000000 mem_base=0x3dc00000 mem_size:0x3f000000(1008 MiB) [ 1.613415] [drm] Initialized drm 1.1.0 20060810 [ 1.620277] vc4-drm soc:vc4@0x7e4c0000: bound 3fc00000.brcm,vc4-v3d (ops vc4_v3d_ops) [ 1.629973] vc4-drm soc:vc4@0x7e4c0000: bound 3f206000.brcm,vc4-pixelvalve (ops vc4_crtc_ops) [ 1.638672] vc4-drm soc:vc4@0x7e4c0000: bound 3f207000.brcm,vc4-pixelvalve (ops vc4_crtc_ops) [ 1.647362] vc4-drm soc:vc4@0x7e4c0000: bound 3f807000.brcm,vc4-pixelvalve (ops vc4_crtc_ops) [ 1.655992] [drm:vc4_hdmi_bind] ERROR Failed to get ddc i2c adapter by node [ 1.663209] vc4-drm soc:vc4@0x7e4c0000: failed to bind 3f902000.brcm,vc4-hdmi (ops vc4_hdmi_ops): -517 [ 1.673614] vc4-drm soc:vc4@0x7e4c0000: master bind failed: -517

[gohai]

@skjegg The driver running out of memory when dragging windows is a known issue.

What settings did you have to change in config.txt to make it boot?

[skjegg]

At this point I am not 100% sure which changes were needed, but I ended up specifying some values for the framebuffer height/width after fiddling with pretty much anything that had to do with HDMI settings, since the error message above was pointing to something hdmi related. I'm away from the PI for the next 3-4 days, so i can't double check, but I believe it's only the framebuffer ones, and MAYBE the setting to force hdmi vs. dvi that are left at this point. I'll update this once I can check it out.

Dragging windows seems like a common operation.. I know this is quite experimental/early, but do you see this driver reaching some level of maturity in the near future?

[gohai]

@skjegg I can't say.. this script is mainly there to make it easier for people to get involved and to hack on the driver and related infrastructure. You can assume that the driver will be included in future Raspbian releases when the driver is feature complete and ready for widespread use!

[ktb83dev]

@gohai Thank you for making this project and the builds available. I've been trying out Anholt's kernel and Mesa driver every once in a while since last March, but it's very nice to not need to compile everything in order to check in on the progress of the project.

Things look like they are coming along nicely. The 20150808-1312-vc4 build image works fairly well on my Pi2B other than the occasional crash from window dragging and perhaps some other scenarios. I have not upgraded it to Jessie. xscreensaver-gl and glxgears both work. /usr/lib/xscreensaver/flyingtoasters -fps (8-16 FPS) /usr/lib/xscreensaver/flyingtoasters -fps -delay 0 (10-20 FPS) vblank_mode=0 /usr/lib/xscreensaver/flyingtoasters -fps -delay 0 (11-25 FPS) glxgears (46-52 FPS) vblank_mode=0 glxgears (75-104 FPS)

OpenArena works fairly well and with cma=512M, it's very playable.

I also ran the OpenArena anholt demo (http://dri.freedesktop.org/wiki/Benchmarking/#openarena) and here are the first try results: 840 frames 156.1 seconds 5.4 fps 74.0/185.8/1304.0/56.2 ms.

After some OpenArena configuration tweaking, the result is a little better: 840 frames 133.4 seconds 6.3 fps 70.0/158.8/954.0/55.3 ms.

After setting cma=512M in cmdline.txt, I get: 840 frames 31.7 seconds 26.5 fps 14.0/37.8/267.0/15.0 ms.

Note: I had to rename ~/.openarena/baseoa/demos/anholt.dm_68 to ~/.openarena/baseoa/demos/anholt.dm_66 for some reason.

Some simple WebGL stuff works in iceweasel (v31.8.0) and chromium (v44.0.2403.89). Anything complicated usually crashes with CMA memory allocation errors. If I set cma=512M in cmdline.txt, then more WebGL stuff works and it works better, but it still tops out at 4-8 FPS even with fairly simple animations. Some WebGL tests and benchmark tools will lock everything up or crash a browser even with cma=512M.

I have been experiencing frequent trouble with key presses getting stuck down (not releasingggggggggggggggg ;-) ) within Xorg. Sometimes the key presses seem to be stuck indefinitely, but usually tapping some keys can eventually get the repeating key to stop. It can happen with any key when using evdev or when using the kbd and mouse drivers. I don't know what causes this problem, but it can make doing even simple things a challenge. Update: I was able to avoid this problem by adding dwc_otg.fiq_fsm_mask=0xF to cmdline.txt which also got rid of a bunch of "Transfer to device (...) endpoint (...) frame (....) failed - FIQ reported NYET. Data may have been lost" messages in the logs for the keyboard and mouse.

I haven't been able to get the 20150821-1625-vc4 build to work on my Pi2B. Starting Xorg just leads to a black screen. The cursor is visible/works in this case and the desktop (LXDE and Xfce) or LightDM seems to be there (based on the way the cursor changes when hovering over the area where the LightDM username and password input field should be), I just can't see anything.

What settings did you have to change in config.txt to make it boot? For me, using hdmi_drive=2 in config.txt was necessary for my Pi2B to successfully boot. I do not need to set framebuffer_width and framebuffer_height in config.txt. I'm using a relatively old Samsung LCD TV with HDMI 1.3, 1360x768@60Hz.

I2C (/dev/i2c-1) doesn't appear to be working properly on my Pi2B. I've tried various Device Tree settings to get /dev/i2c-1 to show up, but have not been successful. I suppose that might be due to the kernel config (CONFIG_I2C_BCM2708 is not set). /dev/i2c-2 is present.

I don't mean to bother you with any of the above issues, but perhaps this feedback will be helpful to others. Thanks again.

[gohai]

@ktb83dev Thanks for the report!

I wasn't aware that larger cma parameters could also boost frame rates, but I'll try this out myself. Sadly there doesn't seem to have been much upstream work Mesa vc4 in the last six weeks, so I've also stopped doing builds for now (also because I am in the middle of moving). But I'll plan to resume shortly. The "stuck" keys are also happening for me - I'll try the kernel parameter you mentioned. With regards to i2c-1 being unavailable: I believe that's the expected behavior on the Pi 2 - i2c-2 is what's being exposed on the board's pin headers.

[gohai]

@ktb83dev I'll test 20150821-1625-vc4 here in a bit. Might be that a Mesa change happen to break it for vc4.

[ktb83dev]

I built the latest Mesa yesterday (as well as the latest libvdpau, libdrm and maybe some others... and no, VDPAU still doesn't work). Everything that did work still works with those updated on the 20150808-1312-vc4 build. One file does need a small change due to a recent commit in the Mesa master branch. The third argument to the function nir_ssa_def_rewrite_uses in /src/gallium/drivers/vc4/vc4_nir_lower_io.c (line 51, I think) needs to be removed because of this commit -- http://cgit.freedesktop.org/mesa/mesa/commit/?id=a4aa25be1e0a27b1a6a6b0bcf576beb9dfe1ea7a.

Regarding I2C, all the RPF kernels I've used and built myself all expose i2c-1 for the Pi2B which I normally use for an RTC as well as other stuff. Personally, I've never used i2c-2 for anything. This is from my last RPF Pi2B kernel build .config:

# CONFIG_I2C_BCM2835 is not set
CONFIG_I2C_BCM2708=m
CONFIG_I2C_BCM2708_BAUDRATE=100000

However, with the last Pi2B anholt kernel I built, the .config was like this:

CONFIG_I2C_BCM2708=m
CONFIG_I2C_BCM2708_BAUDRATE=100000
CONFIG_I2C_BCM2835=m

For whatever reason (I can't remember exactly), both CONFIG_I2C_BCM2708 and CONFIG_I2C_BCM2835 seemed to be necessary for everything to work.

The window dragging issue seems to be less of a problem with higher cma allocations, but it can still happen.

Other games that work fairly well include Nexuiz, Doom (using Doomsday), Quake, Assault Cube (from regular Debian armhf), Tux Racer, Minetest and probably some others which I'm not recalling at the moment.

[gohai]

Hi @ktb83dev

Thanks for the comments.. I am currently rebuilding with current mesa et al, believe your compilation error was recently fixed by Eric as well.

I'll double-check i2c-2 working on the Pi 2 - but this is what I get on Raspbian kernels as well (with the overlay added), so I believe this is all the expected behavior.