Currently, when someone runs weston on KMS/DRM without weston-launch, they usually have no keyboard / mouse permissions, which generally ends up requiring a reboot. So weston should detect being run on KMS/DRM without weston-launch, and exit.
(In reply to comment #0) > Currently, when someone runs weston on KMS/DRM without weston-launch, they > usually have no keyboard / mouse permissions, which generally ends up > requiring a reboot. > > So weston should detect being run on KMS/DRM without weston-launch, and exit. I don't use weston-launch in the realm of my testing activities and prefer not to. And I've never had the issue that you've described. It seems you're trying to solve the issue from the wrong direction... shouldn't weston just detect the permission problems instead of forcing a hard multi-directional relationship on weston-launch? Having weston check if weston-launch was used to run it doesn't seem to make sense to me (i.e. why not just have weston take on the responsibilities of weston-launch in that case?).
Today: <intgr> Hi, I'm using the Arch Linux packages of Weston 1.0.5. When I launch weston with DRM backend, my mouse and keyboard don't work -- I can't switch back to a text terminal or do anything else. Any ideas? <intgr> The only thing that seems to work is Ctrl+Alt+Del <soreau> intgr: Perhaps a permissions problem? <soreau> intgr: Are you using weston-launch to start weston drm backend and have your user part of the weston-launch group? <intgr> D'oh, my bad, I was just running weston and not weston-launch. <soreau> intgr: Generally speaking, you only want to run weston directly if you're using the x11 backend <Darxus> intgr: https://wiki.archlinux.org/index.php/Wayland#Usage_2 <intgr> Thanks <Darxus> It would be nice if it did something other than make your system unusuable if you run weston instead of weston launch on drm. <intgr> Yeah <Darxus> Is there a reason not to make it exit when it doesn't have access to keyboard / mouse input? <intgr> Having mouse only wouldn't be terribly useful either :) <daniels> Darxus: distinguishing between hotplug with devices coming later, and couldn't add any devices, is really hard <Darxus> daniels: Ah, that's unfortunate. Any thoughts on how this failure mode could be improved? <krh> we can detect weston trying to run on kms without weston-launch though <daniels> Darxus: not coherently at 8pm on friday <Darxus> krh: That sounds useful. <krh> yeah, somebody should do that :) <Darxus> Hehe. <soreau> krh: thanks <Darxus> krh: I suppose somebody should at least open a bug. Want me to? For weston to exit when run on kms? <krh> Darxus: that sounds good
(In reply to comment #1) > (In reply to comment #0) > > Currently, when someone runs weston on KMS/DRM without weston-launch, they > > usually have no keyboard / mouse permissions, which generally ends up > > requiring a reboot. > > > > So weston should detect being run on KMS/DRM without weston-launch, and exit. > > I don't use weston-launch in the realm of my testing activities and prefer > not to. And I've never had the issue that you've described. > > It seems you're trying to solve the issue from the wrong direction... > shouldn't weston just detect the permission problems instead of forcing a > hard multi-directional relationship on weston-launch? Having weston check > if weston-launch was used to run it doesn't seem to make sense to me (i.e. > why not just have weston take on the responsibilities of weston-launch in > that case?). weston-launch is the only supported way to run weston on KMS. weston-launch isolates the few things requiring root-priviledges in a tiny process with no unsafe dependencies for easy auditing, letting weston run as a regular user. Running weston on kms can only work if it is run as root, which is not a scenario we support.
(In reply to comment #3) > weston-launch is the only supported way to run weston on KMS. weston-launch > isolates the few things requiring root-priviledges in a tiny process with no > unsafe dependencies for easy auditing, letting weston run as a regular user. > Running weston on kms can only work if it is run as root, which is not a > scenario we support. Yes, we have weston permissions as suid root and run it that way. IIRC, the reason we initially avoided weston-launch was because it always return an exitcode of 0 regardless of how weston exited. This was bad for detecting if weston crashed during an automated test. Curiously, I just tried running weston-launch again and now I always get a "Hangup" message with exitcode 129 regardless of how I kill weston (i.e. SIGTERM, SIGKILL, SIGABRT, SIGSEGV). This makes it even more difficult (from a testing perspective) to detect "weston as the cause" for test failures. Is there any technical reason why weston-launch couldn't exit with weston's exitcode?
(In reply to comment #4) > (In reply to comment #3) > > weston-launch is the only supported way to run weston on KMS. weston-launch > > isolates the few things requiring root-priviledges in a tiny process with no > > unsafe dependencies for easy auditing, letting weston run as a regular user. > > Running weston on kms can only work if it is run as root, which is not a > > scenario we support. > > Yes, we have weston permissions as suid root and run it that way. IIRC, the > reason we initially avoided weston-launch was because it always return an > exitcode of 0 regardless of how weston exited. This was bad for detecting > if weston crashed during an automated test. Curiously, I just tried running > weston-launch again and now I always get a "Hangup" message with exitcode > 129 regardless of how I kill weston (i.e. SIGTERM, SIGKILL, SIGABRT, > SIGSEGV). This makes it even more difficult (from a testing perspective) to > detect "weston as the cause" for test failures. Is there any technical > reason why weston-launch couldn't exit with weston's exitcode? That's a good point - we should do that.
(In reply to comment #5) > > Yes, we have weston permissions as suid root and run it that way. IIRC, the > > reason we initially avoided weston-launch was because it always return an > > exitcode of 0 regardless of how weston exited. This was bad for detecting > > if weston crashed during an automated test. Curiously, I just tried running > > weston-launch again and now I always get a "Hangup" message with exitcode > > 129 regardless of how I kill weston (i.e. SIGTERM, SIGKILL, SIGABRT, > > SIGSEGV). This makes it even more difficult (from a testing perspective) to > > detect "weston as the cause" for test failures. Is there any technical > > reason why weston-launch couldn't exit with weston's exitcode? > > That's a good point - we should do that. Yes, if we did that, then I wouldn't be entirely opposed to resolving this bug as Darxus described. I've added a bug 60935 for it.
commit 32069c09eab9547db3f023fc515e4eba2778efca Author: Rafal Mielniczuk <rafal.mielniczuk2@gmail.com> Date: Wed Mar 27 18:39:28 2013 +0100 compositor-drm: ensure we run drm-backend using weston-launch We do this by checking if launcher_sock != -1 This fixes https://bugs.freedesktop.org/show_bug.cgi?id=60926
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.