Re: Where should project Weston go?
On 10.12.2014 14:36, Daniel Stone wrote: understandable, but this is not a failure of upstream. If you redesigned your patches to avoid the (IMO massive) design flaws and resubmitted, or communicated with us earlier on so your original design was more suitable, this could've been avoided. Regardless of the "massive design flaws" it works just fine IRL... :) There was no assurance that the vastly more complex approach would be acceptable. In particular, you've been complaining about the lack of documentation. We would absolutely welcome a lot of patches and help there, since it is a weak spot. Is that something you'd be interested in helping with? I'm not particularly interested on developing Wayland nor Weston, just a mere user trying to make use of it. I have other stuff to do. My view is just from my external user's perspective. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Where should project Weston go?
On 9.12.2014 11:46, Bryce Harrington wrote: Perhaps the situation could be improved via some patches from you? We tried for the multi-seat, but it wasn't so much welcomed. We'll probably just maintain our fork for what we need. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Where should project Weston go?
On 9.12.2014 1:26, Bryce Harrington wrote: But I imagine 'minimal' is intended here in more of an engineering sense, and interpret it myself to mean something like: Focuses on principle features not superfluous stuff better handled by other projects; doesn't overengineer algorithms to squeeze a few drops of performance; feature selection by what fits nicely and makes sense, not I would like to ask, what/where are those "other projects". As long as there are no such projects, weston is the one used and also the metrics to judge overall project in terms of quality and performance. I've noticed over the years, that I can say until I'm blue in the face that "Wayland is just a protocol, Weston is just a reference implementation, and you need to look at desktop environments to provide Wayland compositors;" but people still keep asking me, "Okay, but when can I ditch X and just use Wayland as my desktop?" If it wants to be just protocol and reference implementation, Documentation needs to improve vastly. At the current level of documentation and ease-of-use for example of libwayland, I'm not holding my breath waiting to see anything product quality built ground-up based on what Wayland project produces. Now it looks like someone's GUI engine programming experiment. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 2/2] support specifying custom directories for the client and server
On 25.11.2014 15:01, Pekka Paalanen wrote: However, all upstream cases will use XDG_RUNTIME_DIR, which probably is not appropriate for your use case, depending on how you actually start things. That's why I thought providing an alternative could be useful. It still supports XDG_RUNTIME_DIR too, but using the wayland specific variables allows override. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Support for adjusting socket access rights to allow group of users to connect to the socket.
On 19.11.2014 16:22, Pekka Paalanen wrote: When a session compositor is started, you can already use WAYLAND_SOCKET environment variable to pass an opened connection to it. If your system compositor forks session compositors, no problem. If something else starts your session compositors, you need a wrapper program to pre-create a connection to the socket file in the shared directory (that is not your XDG_RUNTIME_DIR) and then exec the session compositor. We are running system compositor under one special user session, in this case user "genivi". This is normal session other than it is not visible to logind (pam_systemd is not called). Then, in our login manager (TLM), other seats are set to wait for the system compositor lock file to appear before logging in default (guest) user sessions. These are normal sessions visible to logind and weston for each seat runs inside the user session. When user is logged out, the weston instance is terminated and restarted for the next user session. Passing WAYLAND_SOCKET environment from a user session of user X to another newly created user sessions Y and Z is not very straightforward operation... Also lifetime of the Y and Z vary and new sessions will be spawned after one is terminated while the system compositor persists. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 2/2] support specifying custom directories for the client and server
On 19.11.2014 12:56, Pekka Paalanen wrote: I have very hard time deciding if we should allow the environment to overwrite the server and client assumptions on where the socket is. It would be easier for me to accept new API functions that operate with absolute paths or existing fds explicitly, but those of course require both servers and clients to be written to use them. A bit tricky part in current Weston is case where you use wayland-backend. In this case Weston is client to another Weston and in addition server providing a socket to it's client. In this setup the server is sort of proxy between lower level server and the client. Since both instances solely use XDG_RUNTIME_DIR, the wayland-backend client weston is trying to connect to a socket there are create a new socket with same name in the same place... The change is intended to allow a way to tell this second weston where to look for the client socket and where to place the server socket. Usually these two are not the same place... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Support for adjusting socket access rights to allow group of users to connect to the socket.
On 20.10.2014 18:13, Daniel Stone wrote: Each to their own; I don't think it's necessarily any more complex than split compositors, since at some point you have to deal with input splitting anyway, and if you want both security (i.e. random users not opening random devices) and performance (i.e. no unnecessary hops through input compositor for events), you end up having to deal with input splitting in your system compositor anyway. Access control is no different whether you have 1 weston or 3 westons running. It is about amount of changes needed, fairly small patch vs almost complete weston rewrite... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Support for adjusting socket access rights to allow group of users to connect to the socket.
On 20.10.2014 17:26, Daniel Stone wrote: Makes sense, although you can already enforce isolation with a single shared compositor ... Only weston can access the DRM compositor socket since it's the only one having group privileges for doing it. So each user has their own contained environment. DRM compositor is using fullscreen-shell and nested ones are using what ever other shell they wish. We looked into input methods splitting with a shared compositor but it was getting a bit too complex. So now each nested compositor will manage their own set of input devices. So we have a functional setup with two displays, two mice, two keyboards and a touch screen. With the current approach. Two users have two mouse pointers and can type on the keyboard same time and window focus management and such works without modifications. Doing it through environment variables is just plain nasty though; I really don't like this patch. I'd much rather see an explicit call, or users creating the appropriate fd and then just passing it to the lib. OK, then I think it would be better to move the socket creation out from libwayland and just pass the socket descriptor to libwayland. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Support for adjusting socket access rights to allow group of users to connect to the socket.
On 17.10.2014 20:00, Jason Ekstrand wrote: On Thu, Oct 16, 2014 at 9:23 AM, Imran Zaman mailto:imran.za...@gmail.com>> wrote: This is used for nested compositor architectures. Could you please provide a little more explanation than that. What kind of nesting are you doing? We have one system compositor using DRM backend and then nested compositors for each user using wayland backend. This is in order to share single GPU with multiple display outputs among multiple users. Also, why are you doing this through environment variables and not something explicit? For instance, the compositor can easily grab the socket and chmod it. It has the privileges and knows what socket it is. This is related to the other patch that allows modifying location of the server/client socket location. I thought that the access control is best being close to the place where socket is created. Otherwise it is hard to follow what is going on if the related code is scattered across modules. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
