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.
Regar
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 ma
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 f
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
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
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, bu
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.
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.
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 s
