How do I run Wayland outside of X?

[Kristian Høgsberg]

On Mon, Apr 9, 2012 at 2:04 PM,  <darxus at chaosreigns.com> wrote:
> On 04/09, Bill Spitzak wrote:
>> The best result I have had was by altering weston to chown root.root
>> and to turn on the setuid bit, and then running from a pty I switch
>> to with Ctrl+Alt+1. In this case it certainly takes over the screen
>> and displays a hash of colors and lines that seem to be the same
>
> As Scott said, sounds like a Nouveau bug.  Try running
> "~/source/drm/tests/modetest/modetest -v" outside of X.  Hopefully that will
> fail too, and you can report a bug to Nouveau similar to this one:
> https://bugs.freedesktop.org/show_bug.cgi?id=34469
> modetest should flip back and forth between a color test pattern and a
> solid grey screen.
>
>> colors as the X display. However nothing works and I cannot get out
>> of it except by rebooting. Previous versions of wayland I could get
>> out of by typing Ctrl+Alt+8 to get back to X, then Ctrl+Alt+1 to get
>> the pty again, and then ^C, but now nothing works.
>
> That could be just how badly Nouveau is failing.
>
>> I think perhaps I need to turn off X but I'm not sure how you do
>> that! If I don't have to turn off X, can I run it by just clearing
>> $DISPLAY before running it?
>
> Don't need to turn off X.
>
>
> Also, I'd recommend getting wayland 0.85 to work before trying to fight
> with master, which occasionally breaks, so it's not immediately obvious if
> the problem is local or the stuff in the repo is just currently broken.
>
> http://www.chaosreigns.com/wayland/buildscript/dl/wayland-build-0.85.sh
> http://www.chaosreigns.com/wayland/buildscript/
>
> I think I made some modifications to the version that builds master since
> you downloaded it.  If people *really* want to use that I guess I could
> modify my 0.85 build script to only check out the branches required for
> 0.85 instead of master depending on a variable.
>
>
> On 04/09, Scott Moreau wrote:
>>    You shouldn't have to stop X or change permissions on the weston binary.
>>    It should be enough to run src/weston from the weston source directory
>>    with escalated permissions, outside of X (in a tty).
>
> Changing permissions as he did is necessary to run weston outside of X if
> installed without SUID root, as he did.
>
>>    I wouldn't worry much about this right now since you're using ubuntu and
>>    ubuntu currently does not support systemd. (See�
>>    [1]https://wiki.ubuntu.com/systemd for more information). Weston should
>>    work fine in drm but it sounds like your graphics drivers are broken.
>
> Heavily culled IRC conversation:
>
> 09:47 < pq> I think there's something not exactly right with the socket
>            permissions, when weston is suid-root, but never looked into
>            it - judging from user reports
> 10:27 < krh> devilhorns: what kind of errors do you get?
> 10:33 < devilhorns> krh, I get "failed to create display: Permission
>                    denied"
> 11:15 < krh> devilhorns: what permissions do you have?
> 11:19 < devilhorns> krh, wrt perms: srwxr-xr-x root users for the wayland
>                    socket
> 02:32 < pq> krh, maybe you have a different umask to everyone else who get
>            permission denied on the socket of a suid-root weston?
> 07:26 < krh> pq: or maybe everybody else is running ubuntu which doesn't
>             have systemd or a real $XDG_RUNTIME_DIR and the runtime
>             dir has different permissions/sticky bits that /tmp
> 07:26 < krh> [krh at minato ~]$ echo $XDG_RUNTIME_DIR
> 07:26 < krh> /run/user/krh
> 07:48 < pq> krh, ah! Indeed, /tmp usually has permission bits that restrict
>            files to the owner.
> 08:44 < krh> pq: I've suggested that people set it to /tmp if it's not set
> 09:06 < CIA-98> weston: benjaminfranzke wayland/weston:master *
>                rbfeda130de34 / (13 files in 2
>                dirs): Introduce weston-launch
>                http://cgit.freedesktop.org/wayland/weston/commit/?id=bfeda130de340c090895d23ea0a5742521ff0078
> 12:09 < krh> pq: bnf weston-launcher should fix the socket permission problem
>
> Actually it sounds like weston-launcher is needed to handle a permissions
> problem in master.  If weston is SUID root, clients end up without
> permission to connect to it.

Nothing changed in master with respect to socket permissions, so I'm
not sure why you're seeing this problem only now.  I'm not saying
there isn't a problem, I just wonder why you're only seeing it now.
Anyway, weston-launch is indeed the solution to these problems.  We
isolate all priviledged operations in this small helper and the
compositor will run as the user (and create the socket as the user).
There a three ways to use weston-launch: shiny, old-skool, and
big-hammer:

  1) Use a distro that uses systemd and make sure you have the
libsystemd-login package installed at weston configure time.  That way
weston-launch will allow you to launch weston if you're in a local
session (as opposed to logged in over ssh, or through a remote
wordpress exploit, for example).

  2) Create a weston-launch group, add yourself to the group.  Then
weston-launch will let you launch weston as yourself.

  3) Run sudo weston-launch -u $USER.  weston-launch will run as root,
but exec weston itself as the user passed on the command line.

weston-launch is useful on its own and clearly shows the priviledged
steps we need to take to get weston to run.  It is also the kind of
system-integration thing that a distro may want to  tie into its
startup/login mechanism in a different way, and in that case
weston-launch is a good reference for that.

Kristian