(Actual version is 1.1.0, but this is not an option on Bugzilla.) Running weston-launch from the console on an updated (sudo aptitude update; sudo aptitude upgrade) Raspbian install (Raspberry Pi Model B) yields the following: Date: 2013-06-14 UTC [00:39:42.877] weston1.1.0 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.1.0 Build: 1.0.0-488-gcd0b379-dirty Bump version (2013-06-03 14:53:21 +0100) [00:39:42.879] OS: Linux, 3.6.11+, #474 PREEMPT Thu Jun 13 17:14:24 BST 2013, armv61 [00:39:42.886] Loading module '/usr/lib/weston/rpi-backend.so' [00:39:42.921] initializing Raspberry Pi backend Following that, the whole system hngs: the cursor stops blinking; virtual terminals cannot be switched; nothing else happens until the system is forcibly rebooted. This happens both with stock configuration, and with the latest firmware + boot config modifications suggested in http://wayland.freedesktop.org/raspberrypi.html
And, nevermind. It appears to function properly when run on the default "pi" account, which I now see is mentioned at the very top of the page I linked...
Yeah, not getting any input devices leaves one without any local access to the RPi. However, all that is frozen really should be just input devices and output, as long as Weston is running. The ssh server should still work, allowing to log in remotely and kill weston with SIGTERM, after which the console should work again. I'm reopening this bug to serve as a reminder, that I really should make sure Weston on RPi exits immediately, if it cannot open any input devices. And make that overridable by a config or command line option. Ah, the other thing: I should also make sure to handle failure to use VCHIQ properly. Actually, I think what happened here is not about input devices, but the VCHIQ connection, which failed unexpectedly due to lack of permissions, and the console was not restored, leaving it unusable. So that's two more items in my TODO, but currently no time to fix. If anyone wants to work on these, let me know. There are actually lots of little loose ends with the rpi-backend.
Pekka, can we close this?
Hi Kristian, sorry, I think I have hijacked this bug for my own purposes, so I'm now changing the summary to match. There is a possibility that using the real weston-launch will now properly clean up the VT, if weston exits abnormally (e.g. libbcm_host calls _exit() or something equally surprising). But until someone actually reports that as working or I get to test it myself, I would prefer to leave this open for now.
Okay, Jonny confirmed, weston-launch apparently cleans up the VT setup nicely. The failure case was no permissions to access /dev/vchiq, which caused rpi-backend.so to fail with the message "* failed to open vchiq instance", and dropping back to a fully working VT and shell. The code trying to open the device (in userland.git) calls exit(-1) on error, like I guessed. For posteriority: please use the real weston-launch program coming with weston. If you simply run 'weston' as root, the VT clean-up is not guaranteed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.