upport for desktops that allow third-party
integrations that are portable across compositors.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On 2017-12-28 8:38 PM, Emil Velikov wrote:
> On 28 December 2017 at 18:05, Drew DeVault wrote:
> Surely you are familiar that weston provides libweston with somewhat
> similar functionality, right?
>
> Since your email is aimed at wayland-devel, it might be better to
> poin
it up.
I think if you examine libweston and wlroots you'll find that though
they fill similar niches, they do so in very different ways.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
protocols that could use them.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
alid Wayland surface on any compositor. I don't think we need to
explicitly require clients to handle CSD for that reason.
The assumption is that the compositor implementing this protocol will
support both.
--
Drew DeVault
___
wayland-devel ma
On 2018-03-14 3:16 PM, Simon Ser wrote:
> However, the situation we'd like to avoid is clients wanting decorations not
> implementing CSD at all and relying on this protocol to show them via SSD.
> What
> about rewording this sentence to:
I understand where you're coming from, but this is not so
It seems that this was partially done in
a3cf97ff982638bf7ed23b4303eba280c521b54d; this patch just corrects an
oversight.
---
stable/xdg-shell/xdg-shell.xml | 3 ---
1 file changed, 3 deletions(-)
diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..2255d77
On 2018-03-15 3:04 PM, Mike Blumenkrantz wrote:
> It seems to me that there is no harm in restating that clients are required
> to implement CSD inside a protocol which permits adding a separate,
> optional method of window decoration.
>
> Note that it is not an assumption that clients/compositor
dg-shell).
The "requirement" has never been as strong as you're implying, and
certainly has never been expressed in the protocols.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ol text in this thread
> acknowledges that fact:
This isn't true. The core Wayland protocol takes no stance at all on any
kind of decorations. It's designed to accommodate for systems where CSD
doesn't even make sense, like IVI systems or phones.
I don't want to drag this on much further, what changes do we need to
make to get this merged?
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
nical feedback and I guess will find a place to mention that CSDs
are mandatory.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
These values describe window decoration modes.
-
-
+
+
Then updating the prose accordingly. We can include a note along the
lines of "if the client chooses not to use server-side decorations, it
is responsible for its own window management oper
ide decorations, it is
> responsible for its own window management operations.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
How about:
If the client chooses not to use server-side decorations, it may be
responsible for its own window management operations.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland
On 2018-03-20 9:52 AM, Mike Blumenkrantz wrote:
> this adds implementation from a related discussion long ago in which
> it was decided that it would be useful for clients to know if/where their
> windows were tiled so that various behaviors and visuals could be modified
> to improve UX
>
> a win
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
unstable/xdg-output/xdg-output-unstable-v1.xml | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
b/unstable/xdg-output/xdg-output-unstable-v1.xml
index 0c0c481..65623f0 100644
On 2018-04-08 3:22 PM, Daniel Stone wrote:
> A name event would be great, but this is missing a string param to
> carry the actual name.
Whoops!
> In order to not breaking existing clients, it also needs to:
> - come after the 'done' event so we don't renumber events
> - bump the xdg_output
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
Thanks Daniel for pointing out my silly mistakes
unstable/xdg-output/xdg-output-unstable-v1.xml | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
b/unstable
Good feedback.
On 2018-04-09 11:09 AM, Pekka Paalanen wrote:
> Does this name correspond to the physical connector or to the specific
> monitor connected? Or some abstract "output" concept, see the next
> paragraph about clone mode.
Doesn't matter, whatever the compositor wants. Should be unique
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
Updated to incorporate Pekka's feedback.
unstable/xdg-output/xdg-output-unstable-v1.xml | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
b/unstabl
On 2018-04-10 12:20 PM, Pekka Paalanen wrote:
> Oh yes, that's a good point. This is actually a good reason to repeat
> the question:
>
> Does the name identify the connector or the monitor?
I suppose I should repeat the answer, too: one xdg_output maps to one
wl_output and has a unique name.
It
s
a nice vague term that compositors can give any meaning they like.
Will it address your concerns if I:
1. Add a statement clarifying that the names are unique across all
living wl_outputs and may be reused if the corresponding wl_output
global is removed
2. Add a statement clarifyin
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
This version clarifies the uniqueness constraint, mapping of names to
wl_outputs, and persistence between sessions.
.../xdg-output/xdg-output-unstable-v1.xml | 19 ++-
1 file changed, 18 insertions(+), 1 deletion
wayland can name the X11 outputs based on their genuine names rather
than assigning e.g. XWAYLAND0
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
n the user reconfigures the output layout, can the compositor
> send updated names to all clients that already have an xdg-output object?
You could do this but it would be exceedingly silly of you considering
that the other xdg_output requests furnish the client with layout
inform
might turn out to be short-sighted but a new shell would probably
break enough other stuff that this'll just be another pill of many we
have to swallow when the time comes.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
not known what format
> you'll get, I don't think Xwayland can make any use of this.
Can you elaborate on what expectations Xwayland would have? I am open to
restricting the format a bit, e.g. to ASCII characters or so.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
s protocol. It's not important for
the client to understand that. They just need these two needs fulfilled.
To that end, rather than making a futile attempt to describe outputs in
terms that won't apply in all cases, the current revision aims only to
secure these two guarantees.
--
Dr
resource. We may
as well be explicit.
> I'm not really talking about a new shell, but about e.g xdg_popup, or if
> we for some reason need another xdg_surface based window type that is
> neither xdg_popup or xdg_toplevel.
I see, this is a good point. I agre
On 2018-04-13 4:59 PM, Jonas Ådahl wrote:
> Neither these need the "set_mode" or "preferred_mode" stuff.
I don't think I'm following. I wonder if you have time to write up a
proposed revision to the patch?
> > Clients have an arbitrary surface in which they can render whatever they
> > want, inc
On 2018-04-13 4:33 PM, Pekka Paalanen wrote:
> The other events have more precise wording here, allowing the event to
> be sent again if the information changes.
This is deliberate - I don't think the name should change. I'll write it
up explicitly.
___
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
This revision addresses Pekka's feedback, specifying that the output
name will not change over the lifetime of the xdg_output. This also
answers a question from an earlier email:
On 2018-04-11 11:02 AM, Pekka Paalanen wrote:
>
On 2018-04-16 10:36 AM, Pekka Paalanen wrote:
> that's seems contradictory to what you replied here:
You're right, it does.
> > You could do this but it would be exceedingly silly of you considering
> > that the other xdg_output requests furnish the client with layout
> > information anyway.
>
>
me does not change over the lifetime of the
+wl_output.
Will wait a while for a little more feedback to come in and then will
send off a new patch.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
alue.
Why is this important?
> What I'm assuming is a major reason for keeping things relatively vague
> is to make sure that it's not specifically connector data, as that may
> not be available for centain types of compositors.
Yes, that is a major reason. This also isn't
utput_manager.get_xdg_output). This event is only sent once per
+xdg_output, and the description does not change over the lifetime of the
+wl_output global. The description is optional, and may not be sent at all.
+
+
+
--
Drew DeVault
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
This revision adds an additional description field.
.../xdg-output/xdg-output-unstable-v1.xml | 46 ++-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
b
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
Reviewed-by: Jonas Ådahl
---
Only change is the additional
.../xdg-output/xdg-output-unstable-v1.xml | 47 ++-
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
e considerably more
difficult than looking up the commit message.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
, which is suitable for storing in config files,
command line arguments, etc. A warmer "description" event is also
provided to (optionally) provide a more human readable name, and has
much broader restrictions on its form.
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
Reviewed
hell-unstable-v1.xml
@@ -0,0 +1,285 @@
+
+
+
+Copyright © 2018 Drew DeVault
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that
ompositor implementations
(likely to be 6 soon) and has many client implementations. Is the role
of wayland-protocols to be a small few who judge the worthiness of
protocols for inclusion, or an instrument of the community? Because the
community supports this protocol.
--
Drew DeVault
I'm in favor of a deprecated attribute in the XML format, and
we're working on sunsetting wl_shell for good over in wlroots. There may
soon be a patch from one of us adding deprecation support to
wayland-scanner.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
icipate in the view
abstraction. And even for those who do use the view abstraction, it's a
very thin abstraction, and consumers of views are exposed to
shell-specific concerns. This is more work, but allows us to have _much_
better support for each shell.
In short, we think that e
ypothetical - there are
compositors out there today for which xdg-shell is ill-suited. IVI shell
exists for this very reason. xdg-shell is poorly suited to phones as
well.
Of course, I'm playing devil's advocate here. I don't think we sh
Reviewed-by: Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
s and add another:
* "phone-style" (for lack of a better term) applications (a browser,
mail client, image viewer) which can expect to not manage its own size
or position on screen.
This necessitates a separate shell. Maybe this shell uses xdg-surface...
but I see very little advantage in doing so. Using xdg-toplevel would be
totally nuts.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Can you be more specific about your use-case? As far as I can tell, you
want to find out how the devices were configured by the compositor. On
sway this is as straightforward as reading sway's debug log.
I guess I'm not clear on why a more complex solution is necessary.
--
Dr
Does it make more sense to make libinput provide this information in a
structured/predictable way via its log callback, then pull that out of
compositor logs?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org
Maybe `ltrace --library=libinput.so ./run-compositor` would be
sufficient?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
nstable/layer-shell/layer-shell-unstable-v1.xml
diff --git a/unstable/layer-shell/layer-shell-unstable-v1.xml
b/unstable/layer-shell/layer-shell-unstable-v1.xml
new file mode 100644
index 000..0297750
--- /dev/null
+++ b/unstable/layer-shell/layer-shell-unstable-v1.xml
@@ -0,0 +1,288 @@
+
heir working implementation to simplify the development of other
> compositors...
It's an unstable protocol, they should expect to make changes.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.
t should be
functionally equivalent, albiet with a frame or two of the pointer being
locked or unlocked at the incorrect time, which really doesn't matter.
Implementing persistent locks using only oneshots is basically a single
line of code afaict.
--
Drew DeVault
Bumping this patch for review.
>It seems that this was partially done in
>a3cf97ff982638bf7ed23b4303eba280c521b54d; this patch just corrects an
>oversight.
>---
> stable/xdg-shell/xdg-shell.xml | 3 ---
> 1 file changed, 3 deletions(-)
>
>diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-she
Reviewed-by: Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
d Wayland protocol against the
ephemeral "it may exist eventually" out-of-band negotiation process.
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
---
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml | 5 +
1 file changed, 5 insertions(+)
diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
index 378e8ff..e801e41 100644
--- a/unstable/xdg-decoration/xdg-decor
On 2018-12-10 3:24 PM, Jonas Ådahl wrote:
> This reason comes up everytime D-Bus is mentioned, and I think it's
> somewhat counter productive; I don't think this is a problem clients
> should try to avoid so hard. D-Bus is more or less the universal IPC on
> Linux, is used quite extensively to all
This is a great plan, Daniel, thank you for taking the time to write it
up and help push this problem towards a solution.
On 2019-02-19 4:50 PM, Daniel Stone wrote:
> My first, hopefully uncontroversial, suggestion: introduce a list of
> compositors / compositor frameworks, as well as clients / c
On 2019-02-21 2:53 PM, Pekka Paalanen wrote:
> the list seems purely informative. Is it actually bad if it ends up
> containing hundreds of entries? If someone actually wants their
> individual apps listed, why not?
You're right, I retract my concerns about the list being unwieldy. I was
thinking
On 2019-02-21 3:47 PM, Daniel Stone wrote:
> Glibly, I'd probably just categorise the sway* clients in under the
> Sway/wlroots project, unless they had separate governance, opinions,
> roadmaps, etc? Similarly, I'm not sure there's much reason for us to
> separate the toytoolkit and simple-* clie
On 2019-02-21 6:11 PM, Jonas Ådahl wrote:
> IMHO we should choose one or the other, not some combination where
> Gitlab sends E-mails to the mailing list for merge requests, as this
> would mean we'd end up with multiple diverging versions of the same
> discussion thread.
fwiw I think a mailing l
On 2019-02-21 4:00 PM, Pekka Paalanen wrote:
> Let's forget about the prefixes or namespaces indicating anything about
> endorsement or acceptance.
I don't think using prefixes/namespaces for acceptance/blessedness is
going to be a good idea, but I do think defining some namespaces and a
scope fo
On 2019-03-08 11:28 AM, Daniel Stone wrote:
> > If we're establishing a table, it may make sense to give wlroots as a
> > whole a seat at that table. wlroots is where the implementation lives,
> > after all, for all of the compositors who use it. We already kind of do
> > this with wlr-protocols.
>
I've written up a governance document for us to bikeshed, which is
included at the end of this email. Some comments upfront.
Logistical notes:
- We'll need a wayland-protocols mailing list. This should probably be
members only, to reduce noise.
- Members will be given push access to the upstrea
Sorry for the delay, catching up on my emails now. Responding to Daniel
as the other emails don't have much actionable stuff, but I read
everything on this thread. Thanks for the feedback!
On 2019-04-08 6:18 PM, Daniel Stone wrote:
> On the members-only front, I think it's important for us to be
On 2019-04-18 11:19 AM, Pekka Paalanen wrote:
> Would be interesting to hear what you think after you've submitted 5
> MRs to the same project, to be able to see past the first-time setup
> cost.
Is it much different from Github? I've used Github extensively and I
understand the Gitlab flow is pre
Here's an updated governance document for everyone to consider. Changes
from the first version:
- Use wayland-devel instead of a dedicated mailing list
- Use Gitlab for reviewing new protocols
- Extend discussion period for governance amendments from 30 days to 60
- Permit either 1 or 2 points of
Compositors are free to render surfaces at their discretion. This
change clarifies that for xdg-shell's fullscreen surfaces.
---
This point has been a recurring cause for frustration in Sway
development, as users expect windows beneath transparent fullscreen
windows to be shown. The main use-case f
mplying that.
I didn't mean weasel wording in a pejorative way, just as a metaphor for
trying to nail down a precise definition which includes the protocols
the speaker wants and excludes those they don't (myself included).
> On Wed, Jun 19, 2019 at 10:52:32AM -0400, Drew DeVault wrote:
On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:
> This changes the semantics in a non-backward compatible way; clients
> relying on the currently defined behavior would break, so I'll have to
> nack this change. You'd have to add a `set_fullscreen_translucent` or
> something like that if the des
/commit/?h=v4.15-rc9&id=62884cd386b876638720ef88374b31a84ca7ee5f
Signed-off-by: Marius Vlad
Signed-off-by: Drew DeVault
---
This updates Marius's original patch series implementing DRM leasing for
Wayland. This cleans up the XML style, reworks resource lifetimes, adds
a little link to x
d by Rust), and
dramatically increase complexity and churn for questionable gains.
wayland-rs: woo-hoo!
libwayland RiiR: cause for forking
--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
ently: "You can use the Rust implementation
> only if you don't need Vulkan, openGL, or any interop with a
> Wayland-aware system library".
Isn't the latter more of the RiiR way, anyway? ;)
--
Drew DeVault
___
wayland-devel m
lient, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.
Signed-off-by: Marius Vlad
Signed-off-by: Drew DeVault
---
Makefile.am | 1 +
unstable/drm-lease/README| 5 +
unstable/drm-lease/drm-le
On Fri Jun 28, 2019 at 10:37 AM Simon Ser wrote:
> I'm now wondering if DRM leasing is that much different from xdg-shell
> set_fullscreen requests.
>
> Is DRM leasing that much of a big deal regarding security? (Especially
> if the compositor has a policy to lease only non-desktop outputs)
>
> O
lient, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.
Signed-off-by: Marius Vlad
Signed-off-by: Drew DeVault
---
This version changes the EDID from a wl_array to a file descriptor, to
account for possibly large EDIDs. I've updated my wlroots
I have submitted a Vulkan extension which takes advantage of this
protocol for Vulkan-based VR clients:
https://github.com/KhronosGroup/Vulkan-Docs/pull/1001
This can be combined with my mesa/radv implementation:
https://git.sr.ht/~sircmpwn/mesa
As well as my xrgears tree:
https://git.sr.ht/~s
On Mon Jul 15, 2019 at 5:46 PM Simon Ser wrote:
> > +
> > +
> > +Indicates the client no longer wishes to receive connector events.
> > The
> > +compositor may still send connector events until it sends the
> > finish
> > +event, however.
> > +
> > +The c
lient, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.
Signed-off-by: Marius Vlad
Signed-off-by: Drew DeVault
---
v4 addresses feedback from Simon Ser.
Makefile.am | 1 +
unstable/drm-lease/README
lient, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.
Signed-off-by: Marius Vlad
Signed-off-by: Drew DeVault
---
v5 adds a connector_id event, which is necessary for adding support to
Xwayland without requiring an overhaul of the Vulkan
lient, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.
Signed-off-by: Marius Vlad
Signed-off-by: Drew DeVault
---
When implementing this for Xwayland, we realized that we would really
like to be able to obtain a lease with zero connectors. The
Xwayland patch based on this work:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/248
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
A lazy Sunday project. Opens an XDG toplevel and prints interesting
events. Does other useful things like maintaining an XKB state and
printing key events in the form of keysyms and UTF-8 strings, dumping
keymaps to a file, and filtering out events you aren't interested in.
For sway at least, I ima
Err, here's the URL:
https://git.sr.ht/~sircmpwn/wev
:)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Mon Sep 2, 2019 at 3:51 PM Pekka Paalanen wrote:
> Hi Drew,
>
> I seem to recall that you didn't want to add multi-DRM-device support
> here just yet and go first with just one implied DRM device. That is
> ok, but would be nice to have a TODO note somewhere near the top in the
> XML file sayin
On Thu Sep 5, 2019 at 9:34 PM Simon Ser wrote:
> 2.1. Protocol namespaces
>
> a. Namespaces are implemented in practice by prefixing each interface name in
> a
>protocol definition (XML) with the namespace name, and an underscore (e.g.
>"xdg_wm_base").
> b. Pro
On Thu Sep 12, 2019 at 2:42 PM Pekka Paalanen wrote:
> > This was resolved by choosing to have multiple drm_lease_manager
> > globals, one for each DRM device. No reworking should be necessary.
>
> in that case, document it in the XML please.
ack
> > The main issue is that we have no way to enum
Hey folks! I wanted to let you know that I've put online the drafts for
a book I've been working on about the Wayland protocol, aptly called
"The Wayland Protocol":
https://wayland-book.com
Please take a look if you're interested and let me know if you have any
feedback. It's complete up through
I feel like this discussion is getting derailed. The purpose of this
extension is not for general purpose fullscreen applications which want
to have more control over the display than would normally be afforded to
them. The intention is not that the compositor would ever lease a
display it normally
On Sun Sep 15, 2019 at 2:21 AM Vlad Zahorodnii wrote:
> BTW, Chapter 4 contains a typo: maniuplate -> manipulate.
Thanks for pointing this out!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On Sat Sep 14, 2019 at 8:20 PM Jean-François Dagenais wrote:
> https://www.isitdownrightnow.com/wayland-book.com.html
>
> Down at the moment...
Whoops. One of these days, I'll figure out systemd.
___
wayland-devel mailing list
wayland-devel@lists.freede
On Mon Sep 16, 2019 at 11:57 AM Pekka Paalanen wrote:
> > Or, simplifying things, we could send them that non-master fd and then
> > they can just query it themselves and match the resources by their IDs
> > with the resources offered for lease by the compositor. I'm not sure why
> > constraining t
On Tue Sep 17, 2019 at 7:53 PM Jonas Ådahl wrote:
> I think both for stable and unstable the same limitation can be
> as problematic. A protocol that fits in xdg/wp may still only be
> relevant for a single compositor and multiple toolkits, or vice versa,
> even when declared stable. Seems to me li
On Thu Sep 19, 2019 at 9:02 PM Jonas Ådahl wrote:
> I think that if there is a consensus that it's within the correct scope
> and no-one nacks it, there shouldn't need be any artifical bureaucratic
> road blocks in the way.
I mean, I'm not in any particular hurry to get any particular protocol
thr
A cross-desktop solution is being worked on for compositors supporting
wlroots protocols:
https://github.com/any1/wvnc
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
I propose adding a clause which explicitly states that "open source" is
defined as "distributed under an OSI-approved license".
With that change:
Acked-by: Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.f
lient, but since they are tied
up in DRM we need to use DRM leasing to get them into client's hands.
Signed-off-by: Marius Vlad
Signed-off-by: Drew DeVault
---
v7's main change is that, upon binding to the drm_lease_manager, the
server now sends along a non-master DRM fd for the client
On Thu Oct 17, 2019 at 6:08 PM Simon Ser wrote:
> Should we keep the connector event, now that we have an unprivileged
> DRM FD?
>
> Alternatives include:
>
> - Let the client use the FD to get what it needs (EDID/a configured
> output/something else).
Isn't this:
> - Keep an event to adverti
On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote:
> One thing I did not know the last time was that apparently
> systemd-logind may not like to give out non-master DRM fds. That might
> need fixing in logind implementations. I hope someone would step up to
> look into that.
>
> This protocol ai
1 - 100 of 152 matches
Mail list logo
