Send patches to ~sircmpwn/public-in...@lists.sr.ht, please. Thanks!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hiya all, just writing to share that I have removed the paywall from my
(WIP) Wayland book:
https://wayland-book.com
I have also made it available under CC-BY-SA. The source code is
available here:
https://git.sr.ht/~sircmpwn/wayland-book
Enjoy!
___
On Fri Feb 28, 2020 at 7:33 AM, Daniel Stone wrote:
> Unfortunately that wouldn't help unless they moved the entire project
> to SourceHut. What's hurting is storing and transferring all the
> images used for the CI builds, not doing the builds themselves.
> Currently execution runs on a fleet of
I rigged up SourceHut CI for use with gitlab.fd.o several months ago, as
part of investigation to see if wlroots and sway could be moved there.
It's still set up - anyone with a sr.ht account can go to dispatch.sr.ht
and create a task which rigs up GitLab commits to builds.sr.ht jobs. I
filed a
Just a head's up that I have opened up an MR on wayland-protocols to
discuss the introduction of a new protocol:
https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/12
wayland-protocols members, please take a look. Thanks!
___
On Fri Nov 15, 2019 at 11:29 AM, Pekka Paalanen wrote:
> All existing flags in zwp_linux_dmabuf are not hints either. If a
> compositor does not correctly implement each flag every time a client
> specifies one or more, the result is more or less incorrect. Hence all
> compositors must always
On Fri Nov 15, 2019 at 12:39 AM, Scott Anderson wrote:
> > A hint is merely a hint. The compositor can abide or not by that.
> > This flag will explicitly close the client connection if the buffer
> > can't be scanned out when this flag is passed.
>
> This flag doesn't sound like a hint to me, but
Can you elaborate more on non-DRM use-cases? Most compositors are
already going to use direct scan-out as much as possible, and can make
reasonably well informed choices about when to do so. For example,
fullscreen surfaces will generally always be scanned out if possible.
More interesting
s Ådahl @jadahl
> * KWin: Roman Gilg @romangg
> * Qt: Johan Helsing @johanhelsing
> * Weston: Daniel Stone @daniels, Pekka Paalanen @pq
> * wlroots (& its users): Drew DeVault @ddevault, Simon Ser @emersion
Acked-by: Drew DeVault on behalf of wlroots
__
I don't know of a way to do this today, but I think it would make for a
reasonable addition to wl_display.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
o a client, 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
---
v8 changes lease_manager -> lease_device on the grounds that managers
are singletons and this interface has one global per DRM device
On Thu Oct 24, 2019 at 10:50 AM Drew DeVault wrote:
> So, I'm not sure what the action items are here. It seems like we might
> have uncovered a potentially icky race condition in Linux, but that this
> protocol is not really affected.
Bump. Happy
So, I'm not sure what the action items are here. It seems like we might
have uncovered a potentially icky race condition in Linux, but that this
protocol is not really affected.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
Regarding hotplugging, the Wayland compositor is probably keeping track
of hotplugs itself and withdrawing/offering connectors as appropriate.
Also, when the lease is issued, the compositor withdraws that connector.
For the client, upon hotplug I imagine the DRM asks start to fail, and
it handles
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
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
o a client, 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 to use to
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
o a client, 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 k
o a client, 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 impl
o a client, 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
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
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:
o a client, 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 and kmscu
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 a client, 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-lease-u
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 mailing list
wayland-devel@list
ed 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/listin
/commit/?h=v4.15-rc9=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 xdg-output
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
at.
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:
> > How does
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
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
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
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
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
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.
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
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
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-*
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
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 /
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
---
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
---
gainst 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
Reviewed-by: Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
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
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.org/m
hell/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 @@
+
+
+
+ Copy
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
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
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.
--
Drew DeVault
an 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
Reviewed-by: Drew DeVault <s...@cmpwn.com>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
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 should
remove xdg-shell. But it's presence makes it hard to deny layer-shell
onsumers 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 embracing the differences between shells is a
better design than attempting to fit a square peg in a variety of holes.
--
Dre
e 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
) 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
___
wayland-devel mail
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 both that copyri
ling list posts will not be 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
Signed-off-by: Drew DeVault <s...@cmpwn.com>
Reviewed-by: Simon Ser <cont...@emersion.fr>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
Only change is the additional
.../xdg-output/xdg-output-unstable-v1.xml | 47 ++-
1 file changed, 45 insertions(+), 2
Signed-off-by: Drew DeVault <s...@cmpwn.com>
Reviewed-by: Simon Ser <cont...@emersion.fr>
---
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/
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
___
wayland-devel mailing list
wayland-devel@lists.freede
ing 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 some vague theoretical
compositor either, my own compositor has s
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
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.
>
Signed-off-by: Drew DeVault <s...@cmpwn.com>
Reviewed-by: Simon Ser <cont...@emersion.fr>
---
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
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.
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,
t.
> 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 agree that it would be better to attach
it t
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.
--
Drew DeVault
__
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
n 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
then 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
nd 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
Signed-off-by: Drew DeVault <s...@cmpwn.com>
Reviewed-by: Simon Ser <cont...@emersion.fr>
---
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
ors 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 clarifying that persistence of names between sess
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.
Signed-off-by: Drew DeVault <s...@cmpwn.com>
Reviewed-by: Simon Ser <cont...@emersion.fr>
---
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/xd
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 <s...@cmpwn.com>
Reviewed-by: Simon Ser <cont...@emersion.fr>
---
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/xd
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 <s...@cmpwn.com>
Reviewed-by: Simon Ser <cont...@emersion.fr>
---
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-out
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
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
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
1 - 100 of 149 matches
Mail list logo
