[OE-core] weston startup problem

[Tom Hochstein]

Hi Jussi,

Thanks for the help.

Here are the relevant steps of the problem:


1.      weston.service sets XDG_RUNTIME_DIR, then starts Weston

2.      Weston starts up and registers its Wayland server socket in XDG_RUNTIME_DIR

3.      pam starts and sets XDG_RUNTIME_DIR to another location

4.      Wayland client fails to find the Wayland server socket.

At this point, I realize I’m not exactly sure what will happen. Looking at the Weston man page, it appears possible that the Wayland client will still be able to connect through the default Wayland server socket. I can’t immediately test this to know for sure, but regardless, there is still an issue except for the default case.

Tom

From: Jussi Kukkonen [mailto:jussi.kukkonen at intel.com]
Sent: Friday, September 09, 2016 1:41 AM
To: Tom Hochstein <tom.hochstein at nxp.com>
Cc: Patches and discussions about the oe-core layer (openembedded-core at lists.openembedded.org) <openembedded-core at lists.openembedded.org>
Subject: Re: [OE-core] weston startup problem

On 24 August 2016 at 20:08, Tom Hochstein <tom.hochstein at nxp.com<mailto:tom.hochstein at nxp.com>> wrote:
Hi All,

Hi, sorry for missing this in the originally,

The weston systemd startup implementation is not working correctly and I need some help fixing it.

With systemd and pam on the image, the expected behavior is that XDG_RUNTIME_DIR would already be set when weston is launched from weston.service. Turns out XDG_RUNTIME_DIR is not set, and weston.service sets it itself. This is already a problem, and the problem would be worse except that weston happens to use a different folder. If weston.service is modified to use the same folder name, the folder ends up getting replaced later by pam.


I can see our XDG_RUNTIME_DIR handling indeed should be cleaned up but just so I understand the whole issue: can you explain the problem you have in detail? It seems one issue is that the variable isn't set outside of  Xsession (it really should) but why is it a problem if weston.service decides a runtime directory for itself? How does pam interfere with that?


Thanks,
 Jussi


From looking at the weston-launch code and its pam handling, I thought to try the weston-launch option '--user=root' to force the creation of the pam session. This does seem to help, and I was able to get it mostly working by modifying the openvt args in weston-start, removing -e and adding -w:

openvt -v -s -w -- weston-launch --user=root -- --modules=xwayland.so --log=/var/log/weston.log

The problem I have now is that keyboard input goes to both weston and the desktop. I tried with and without the -s option, and there is no difference.

I'm stuck at this point and would appreciate some help.

Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160909/83e5f373/attachment-0002.html>