Hi,
If you're worried about FP16 interpolation accuracy (which, as the vendor
states, only gets you 10 bits of accuracy, so only 1024 different values --
definitely not big enough to drive a maximized window at normal desktop
resolutions), you can try using normalized GL_SHORT texture coordinates
Hi,
There's a few reasons that Wayland not to report or allow clients to choose
absolute screen position.
The biggest is that from our experience with X11, it's hard to even
*define* such a space. Laptops plug into external monitors and projectors.
People with differently sized monitors have gaps
Hi Han,
You cannot position surfaces absolutely using the traditional xdg-shell
protocol. However, for embedded cases, there are protocols like ivi-shell
which provide that functionality.
On Fri, Dec 29, 2017 at 10:09 AM, Han, Guowei <
guowei@johnsonoutdoors.com> wrote:
> Hi,
>
>
>
> Wonder
a demo i can learn from? Currently i
> am creating a bigger surface bigger than screen size. and make subsurface
> so i can posion them as i want. Really don't think its a good way to do it.
>
> Sent from my iPhone
>
> On Jan 2, 2018, at 4:25 PM, Jasper St. Pierre
> wrote
l.com [mailto:magc...@gmail.com] *On Behalf Of *Jasper
> St. Pierre
> *Sent:* Wednesday, January 03, 2018 12:24 PM
> *To:* Han, Guowei
> *Cc:* Kai-Uwe ; wayland freedesktop.org>
> *Subject:* Re: Window positioning
>
>
>
> Hi Han,
>
> Allowing yourselves to place mu
Hi,
>From IRC conversations with krh a long time ago, this is indeed intentional
and the cursor surface should "lose its role" in modern parlance.
The original intention was to prevent glitching of the cursor surface. e.g.
If the left side of the surface has a resize left cursor, you leave, and
h
To be clear, the patch does break backwards compatibility with compositor
behavior -- it only weakens a guarantee by saying that transparent
fullscreen content is undefined. Existing compositor behavior is still
allowed.
However, it does mean that clients might not get the output they desire
under
(Coming into this one late)
When I first wrote xdg-shell, I maintained that attaching a NULL buffer
should be illegal since it has no benefit compared to destroying the
surface, but compositors might not reset all data attached to the surface,
making a weird exception where clients depend on bugs
g order,
window position, or user-added hints or settings) should leak through an
unmap/map cycle, if such wording hasn't been added already.
On Sun, Jul 16, 2017 at 11:32 PM, Jonas Ådahl wrote:
> On Sun, Jul 16, 2017 at 11:16:25PM -0700, Jasper St. Pierre wrote:
> > (Coming into this o
Hi,
The trick is a variant of the well-known integer-to-float conversion
trick you do if you don't have dedicated hardware for it [0].
64-bit floats have a 52-bit significand and a floating exponent.
Wayland's 24.8 fixed point format can be thought of as a 32-bit
significand and a fixed exponent
The first thing I thought about with full-window is how, in fullscreen
mode, Firefox puts up a status bar when you put your mouse to the top
of the window, assuming there's a screen edge there.
You are totally allowed to lie -- and that doesn't really need to be
"proposed" at all -- you just have
Yeah. wl_display is the "bootstrap" phase on which everything else
rests. In the protocol, it's implicit knowledge that there is always
an wl_display object with ID 1. It never gets created or destroyed,
you just start using ID 1.
On Tue, Dec 22, 2015 at 4:55 AM, Pekka Paalanen wrote:
> On Tue, 2
I don't quite understand the need, want, or mechanism for this.
For high performance or VR systems where context switch overhead would be
too much (and I don't believe this, since they tend to use separate
acceleration chips for real-time work), the answer would not be to move
from userspace to th
It would help if you actually read the spec that was there before
commenting. The difference between toplevels and popups is not whether
they have a parent (toplevels indeed have a set_parent method), but
that popups take an implicit pointer and keyboard grab, e.g. menus and
comboboxes. They have w
The current major issue with Phabricator for me currently is that it
doesn't support patch-based code review, unless this has changed in
the meantime:
http://stackoverflow.com/questions/20756320/how-to-prevent-phabricator-from-eating-my-commit-history
( The linked article has since moved to
https
No? The parent is the surface the tooltip is laid on top of.
On Wed, Feb 3, 2016 at 12:59 AM, Giulio Camuffo wrote:
> 2016-02-03 10:39 GMT+02:00 Jonas Ådahl :
>> An xdg_tooltip is a new window type used to implement tooltip like
>> surfaces. See the interface documentation for details.
>>
>> Sign
, 150)
Attach main buffers to toplevel_wl_surface and tooltip buffers to
tooltip_wl_surface. tooltip_xdg_tooltip is a tooltip surface attached
to the toplevel.
On Wed, Feb 3, 2016 at 1:02 AM, Giulio Camuffo wrote:
> 2016-02-03 11:00 GMT+02:00 Jasper St. Pierre :
>> No? The parent is the surface the
t be that
we do positioning on first-attach, and we say that the tooltip is
defined to be 0,0 relative to the surface. That is an idea, though I'm
+0 on it.
On Wed, Feb 3, 2016 at 11:08 AM, Bill Spitzak wrote:
>
>
> On Wed, Feb 3, 2016 at 1:06 AM, Jasper St. Pierre
> wrote:
>>
On Wed, Feb 3, 2016 at 1:00 PM, Bill Spitzak wrote:
>
>
> On Wed, Feb 3, 2016 at 11:36 AM, Jasper St. Pierre
> wrote:
>>
>> set_parent was moved to xdg_toplevel. Perhaps that's a good idea,
>> perhaps it's not. This does mean that a tooltip's parent
https://cgit.freedesktop.org/~krh/weston/?h=remote
:)
On Tue, Feb 9, 2016 at 5:57 PM, Jason Ekstrand wrote:
> On Tue, Feb 9, 2016 at 8:55 AM, Derek Foreman
> wrote:
>>
>> I saw a presentation once where someone said that even the simplest
>> implementation of wayland network transparency that j
There's other reasons, too.
Mice and keyboards need to be demulitplexed --you have one mouse
cursor on the screen, and you can move it between applications. You
select keyboard focus, and the compositor needs to figure out which
window to deliver key events to.
Joypads tend to be exclusive contro
I have to bring this up, because it's not necessarily true. There's
something you're missing. After working on embedded SoCs, I realize
that a lot of them put the YUV video plane *behind* the main RGB
plane. This allows them to do subtitles and OSD controls over the
video without stacking it RGB ->
On Thu, Mar 24, 2016 at 10:06 AM, Andy Ritger wrote:
... snip ...
> eglstreams or gbm or any other implementation aside, is it always _only_
> the KMS driver that knows what the optimal configuration would be?
> It seems like part of the decision could require knowledge of the graphics
> hardwar
I think this should be done at the application level. If an
application is running, it has many other ways to fingerprint your
computer, including listing the files in your homedir, checking cpuid,
MAC address, etc. The issue here is that there is an application
platform that runs untrusted user co
You're probably referring to my response when you say "GNOME does not
care about cross-platform apps doing privileged operations". My
response wasn't meant to be speaking on behalf of GNOME. These are my
opinions and mine alone.
My opinion is still as follows: having seen how SELinux and PAM work
On Sun, Mar 27, 2016 at 7:33 PM, Drew DeVault wrote:
> On 2016-03-27 4:41 PM, Jasper St. Pierre wrote:
>
> What are your specific concerns with it? I would tend to agree. I think
> that it's not bad as an implementation of this mechanic, but I agree
> that it's approac
I really hope that distributions don't see security policies as a
differentiator. This is how we got SELinux vs. AppArmor and real-world
apps having to ship both kinds of policies (or Fedora flat out
ignoring any idea of third-parties and such and including literally
every application ever in its c
On Tue, Mar 29, 2016 at 5:24 AM, Drew DeVault wrote:
>> Thirdly, it's important to take a step back. 'Wayland doesn't support
>> middle-button primary selections' is a feature gap compared to X11;
>> 'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
>> the forest of user-visib
wl_registry and wl_registry.bind are about globals and creating new
instances of globals.
A compositor can opt to provide a new global interface by using the
wl_global_create API. Immediately, an event is broadcasted to all
clients: the wl_registry.global event, which contains a name (the
uint32_t
I think min/max hints are acceptable in xdg-shell.
On Mon, Apr 4, 2016, 12:33 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:
> On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan
> wrote:
>
>>
>> Hi Mike,
>>
>> - Original Message -
>> > [...]
>> >
>> > Yes, I know you are not c
ivier Fourdan wrote:
> Hi all,
>
> - Original Message -
>> On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre"
>>
>> said:
>>
>> > I think min/max hints are acceptable in xdg-shell.
>>
>> i agree. they are realistic things a ap
On Tue, Apr 5, 2016 at 2:36 AM, Olivier Fourdan wrote:
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to advertise such a maximum
> or minimum size the compositor can use.
>
> As a result, the compositor may try to maximize or fullscre
I figured min/max would be double-buffered state and require a commit
to take affect. In fact, anything else means that we can't extend with
additional size constraints in the future, since they couldn't be
applied atomically.
On Mon, Apr 11, 2016 at 12:02 PM, Bill Spitzak wrote:
> Because of the
On Mon, Apr 11, 2016 at 12:59 AM, Olivier Fourdan wrote:
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to specify a maximum or
> minimum size.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the clie
Shouldn't missing fields in structs be auto-initialized to 0 / NULL? I
thought that was part of the C specification.
On Tue, Jul 7, 2015 at 8:52 AM, Christopher Michael
wrote:
> This patch adds missing placeholders for the wl_output listener
> functions 'done' and 'scale. Currently these placehol
Wacky. In any case, NULL is not a valid listener, which is sort of
terrible, but it is how it is. You need to create an empty function
that does nothing.
On Tue, Jul 7, 2015 at 10:17 AM, Christopher Michael
wrote:
> On 07/07/2015 01:15 PM, Jasper St. Pierre wrote:
>>
>> Shouldn&#
My issue with this is that you're tying two things together. You want
access to """a surface""", and you think you can do this by having
global cross-client objects and handles and such. I don't see a need
for this. We can just add a new protocol that does what we want.
We have a few requirements:
No, it's not the same thing. You want an xdg_surface interface exposed
on both sides. We don't want that. The resulting derail was us
collectively ramming our heads straight into the wall trying to figure
out any way that having the same interface exposed on both sides could
make any sense.
xdg_su
The shell is a client. Both are technically correct, but I'm fine with
this change if it makes things easier to read. We do use the terms
"shell" and "client" way too much. :)
On Thu, Jul 9, 2015 at 10:07 AM, Christopher Michael
wrote:
> Documentation for the prepare_lock_surface event descriptio
If the client still has key focus, then it should get the key release.
That sounds like a compositor bug to me.
On Thu, Jul 16, 2015 at 10:28 AM, Arnaud Vrac wrote:
> On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre
> wrote:
>
>> On Wed, Jun 10, 2015 at 4:50 AM, Carlos Gar
We need to fix that documentation, then, along with fixing Weston.
mutter will give you an error with this event stream, since attaching
a NULL buffer for an xdg_surface is invalid.
This behavior is one of the reasons why I removed this ability from
xdg_surface and instead made it an error -- the
Reviewed-by: Jasper St. Pierre
On Tue, Sep 1, 2015 at 8:32 AM, Derek Foreman wrote:
> Right now many toolkits (toytoolkit, gtk+ and EFL) will send an
> ack_configure request immediately in response to a configure event,
> even if they're not immediately committing the surfac
l frame.
>> >
>>
>> It sounds like your application is committing to the wl_surface behind
>> Qt's back somehow, and it only works occasionally by luck.
>>
>> > I will keep debug if any other race conditions in my implementation.
>> >
>> &g
We can pick any number of strategies to deal with unstable protocols.
We can give it a special name, we can say that any version < 1000 is
considered unstable, we can use a special request. That's not too
important -- we're all aware of how to implement that.
The more important issue, for me, at l
er = wl_container_of(launcher_base,
launcher, base);
+
+ launcher_direct_restore(&launcher->base);
+ wl_event_source_remove(launcher->vt_source);
+
+ if (launcher->tty >= 0)
+ close(launcher->tty);
+
+ free(launcher);
+}
+
+struct launcher_in
We're refactoring this to have multiple launcher "implementations".
---
Makefile.am | 4 +-
src/launcher-logind.c | 940 ++
src/launcher-logind.h | 123 +++
src/launcher-util.c | 2 +-
src/logind-util.c | 940 -
In the time since this code was written, logind has gained new APIs to
handle VT switching automatically and activate sessions. Switch to that.
---
src/launcher-logind.c | 219 +-
1 file changed, 40 insertions(+), 179 deletions(-)
diff --git a/src/l
Nope. Why would it be? Also, please CC wayland-de...@freedesktop.org
in the future.
On Sun, Sep 27, 2015 at 8:31 PM, Bryce Harrington wrote:
> On Mon, Sep 28, 2015 at 09:00:04AM +0530, vlse wrote:
>> As per this weston git commit ae5df83f8e029e427f5d587622b3d25b3d1b4964
>>
>> You say: launcher-lo
To be honest, the more I think about it, the more likely I am to just
want to add back in a global coordinate system. There's too many
problems that GNOME is having by omitting it. For starters, menu and
tooltip positioning that works correctly. Saving and restarting window
positions is something t
I don't necessarily like this. The absence of a serial can have
radical meanings on behavior. Being able to pass 0 to mean "no serial"
anywhere we currently rely on a serial seems like poor design to me,
and can easily be done by mistake.
In cases where we have two behaviors for serial-aware and
n
We have a few constraints. First off, not all enums are closed. Some
are intentionally open, like xdg_shell.state. So we definitely need a
distinction between a closed enum and an open enum. I'm not familiar
enough with Rust to be able to apply something to that.
Second, I think we need to make a
As I mentioned on your post on Reddit [0], SDL2's video mode hooks are
no-ops, which explains why SDL isn't changing the resolution. You
could change SDL's code to use a different fullscreen mode. I am still
struggling why you need to change the resolution with a modeset.
[0]
https://www.reddit.c
e to resort to xor'ing
> the value with the no-serial value, meaning the numerical values are all
> different.
>
>
>
> On Wed, Sep 30, 2015 at 1:23 PM, Jasper St. Pierre
> wrote:
>>
>>
>> In cases where we have two behaviors for serial-aware and
>>
I imagine get/put is named after the kernel style. I typically see
ref/unref for userspace names (or ref/destroy, but nobody likes that).
On Sun, Oct 4, 2015 at 8:34 AM, Giulio Camuffo wrote:
> 2015-07-18 0:30 GMT+03:00 Derek Foreman :
>> Sometimes the compositor wants to make sure a shm pool doe
I imagine it's sampling from shared memory owned by the client during
its own rendering.
On Sun, Oct 4, 2015 at 11:21 AM, Bill Spitzak wrote:
> On 10/04/2015 08:34 AM, Giulio Camuffo wrote:
>>
>> 2015-07-18 0:30 GMT+03:00 Derek Foreman :
>>>
>>> Sometimes the compositor wants to make sure a shm p
My issue with this whole "we don't have a maintainer" thing is that we
don't have someone to make a decision. I have lots of patches and
ideas that I'd love to contribute (and have attempted in the past),
but usually the result is that there's some bikeshedding and
discussion on the list, and then
Mir seems to be pushing forward with their compositor-based attachment
protocol, and if they've analyzed it and established that it covers
most cases, I'm totally fine with us taking that.
Descriptive, not prescriptive :)
On Thu, Oct 8, 2015 at 1:16 PM, Daniel Stone wrote:
> Hi,
>
> On 1 October
... snip ...
On Thu, Oct 8, 2015 at 12:56 PM, Daniel Stone wrote:
> Hi,
>
> That's a fair (and accurate) criticism, but again I don't think that
> needs one big cheese. There are quite a few people here who I think
> are fairly empowered to shut down discussions that rathole into
> totally unrela
Agreed. It should be possible to pop up windows from the keyboard.
On Tue, Oct 13, 2015 at 8:41 AM, Bill Spitzak wrote:
> On 10/06/2015 02:48 PM, Ben Hummon wrote:
>>
>> Weston does not allow popup menus initiated by keyboard. Remove the
>> broken keyboard shorcut for a popup from the stacking de
The goal of focus-stealing prevention isn't to prevent hostile clients
from stealing the focus. It's to allow friendly clients to upgrade the
experience if they can track the originating event that originally
opened a window. For instance, if I launch GIMP but then go back to
typing in a terminal,
In one case, an invalid serial dictates that the window should have it's
focus attempts prevented. In the no-serial case, focus world be stolen.
On Tue, Oct 13, 2015, 10:25 AM Bill Spitzak wrote:
> On 10/13/2015 09:53 AM, Jasper St. Pierre wrote:
> > The goal of focus-stealing pr
Most desktop CRTCs support a XOR key in their ROP, since it was
required by Windows for such a long time. I don't think Linux has
support for that in KMS, nor for similar things like alpha keying as
well. Perhaps we'll get it as a plane property at some point.
I don't know of any mobile/embedded c
On Mon, Oct 19, 2015 at 7:22 PM, Jonas Ådahl wrote:
> Hi again,
... snip ...
> xdg-shell.xml: Should we bite the bullet and rename this one, or just continue
> letting its stability state be non-discoverable? It's clearly already used,
> and
> renaming it will be painful, so not sure about this
I'm struggling to understand the motivation for this patch.
krh has always said that you need to think of uint and int as two
entirely separate types -- mixing both in math will likely screw up.
You can see this in other places -- widths are often expressed as
signed ints in the protocol, not unsi
Out of curiosity, why do you require that we don't switch VTs in Weston?
On Tue, Oct 27, 2015, 8:23 AM Vikas Patil Gmail
wrote:
> Hi Daniel,
>
> Thanks for your comment and suggestions. I will surely ask to freesacle
> regarding it.
>
> I was thinking VTs sharing don't have dependencies on GAL2D
Agreed. Absolute input needs to be handled separately. The usage pattern on
an absolute input device is that the cursor warps to the new position, it
didn't simply move from the old to the new.
As an example, pointer barriers shouldn't take effect on absolute input.
On Tue, Oct 27, 2015, 10:40 AM
To help clear things up, I think we should deprecate the
wl_surface.damage request and document that the coordinates are
effectively undefined -- for legacy reasons, if you see
wl_surface.damage, it should be considered a damage for the entire
surface.
On Fri, Nov 6, 2015 at 10:55 AM, Derek Forema
does something similar.
On Sat, Nov 7, 2015 at 2:32 AM, Daniel Stone wrote:
> On 6 November 2015 at 19:08, Jasper St. Pierre wrote:
>> To help clear things up, I think we should deprecate the
>> wl_surface.damage request and document that the coordinates are
>> effective
esults and
have to throw it out.
On Sat, Nov 7, 2015 at 9:41 AM, Daniel Stone wrote:
> Hi,
>
> On 7 November 2015 at 16:59, Jasper St. Pierre wrote:
>> I don't see where. I see eglSwapBuffersWithDamage still looking like
>> it shoves the rects across
unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> new file mode 100644
> index 000..196c332
> --- /dev/null
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -0,0 +1,624 @@
> +
> +
> +
> +
> +Copyright © 20
1,048,575
groups of people taking carve-outs.
On Fri, Dec 4, 2015 at 4:50 PM, Bryce Harrington wrote:
> On Fri, Dec 04, 2015 at 12:41:16PM -0500, Mike Blumenkrantz wrote:
>> Reviewed-by: Jasper St. Pierre
>
> Reviewed-by: Bryce Harrington
>
>> ---
>> unstable
On Fri, Dec 13, 2013 at 12:57 PM, Maarten Baert
wrote:
> On 13/12/13 16:01, Martin Peres wrote:
> > I may be wrong, but other unix users shouldn't be able to
> > communicate with another user's compositor unless this
> > user specifically allowed that by adding him to his/her group.
> Okay, then t
---
desktop-shell/shell.c | 57 ++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 9fbac00..52d82f6 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -176,6 +176,8 @@
Wayland has a lot of components: the code generator, the protocol, the
client/server lib implementation, the design decisions we made to tie it
all together. Yes, we aren't the greatest at documentation and we know that
a lot is missing, but in general we assume experience with traditional
toolkits
7;s a lot more details, but this might get
you to understand what's going on.
[1] http://wayland.freedesktop.org/architecture.html
http://nouveau.freedesktop.org/wiki/IntroductoryCourse/ - this is a good
> example of getting people involved.
>
> Now I'm ready for starting to dig the
Sorry if this was discussed before, but any reason this is being put in
Wayland, and in the "wl_" namespace? DMA-BUF is a private Linux kernel
feature that's really semi-stable, not used by all drivers, and I'd hate
for it to bit-rot and tell people not to use it, the same way wl_shell
went. Having
On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres wrote:
> Le 07/01/2014 01:45, Sebastian Wick a écrit :
>
> Am 2014-01-06 19:33, schrieb Martin Peres:
>>
>>> Le 06/01/2014 19:10, Sebastian Wick a écrit :
>>>
Am 2014-01-06 16:05, schrieb Martin Peres:
> As I said before, I think trustin
On Tue, Jan 7, 2014 at 2:43 PM, Pekka Paalanen wrote:
> On Tue, 7 Jan 2014 14:26:36 -0500
> "Jasper St. Pierre" wrote:
>
> > On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres
> > wrote:
> >
> > > Would it be ok for you if the compositor asked the user
le
Hangouts" so that it could show up as an application that could request
access.
[0] http://www.superlectures.com/guadec2013/more-secure-with-less-security
On Wed, Jan 8, 2014 at 2:34 AM, Pekka Paalanen wrote:
> On Tue, 7 Jan 2014 15:00:31 -0500
> "Jasper St. Pierre&q
ck a écrit :
>
> Am 2014-01-08 13:02, schrieb Martin Peres:
>>
>>> On 07/01/2014 20:26, Jasper St. Pierre wrote:
>>>
>>>>
>>>> Would it be ok for you if the compositor asked the user to agree
>>>> for the program to
&
If the user installed an app that takes screenshots of the screen
periodically and dumps them to a disk, I'd imagine that's functionality he
wanted. Why would we prompt him?
On Wed, Jan 8, 2014 at 2:17 PM, Martin Peres wrote:
> Le 08/01/2014 19:47, Jasper St. Pierre a écrit :
&
Security is based on trust. If you trust nothing, the computer won't do
very much for you. You can't even trust it to compute correctly.
What's the threat model here? Let's say that we design a screenshot API,
and in your opinion it's the worst thing ever. Who's attacking? How are
they attacking?
On Thu, Jan 9, 2014 at 3:54 PM, Martin Peres wrote:
> Le 09/01/2014 20:36, Jasper St. Pierre a écrit :
>
> Security is based on trust. If you trust nothing, the computer won't do
>> very much for you. You can't even trust it to compute correctly.
>>
>
>
On Thu, Jan 9, 2014 at 7:05 PM, Martin Peres wrote:
> On 09/01/2014 23:57, Maarten Baert wrote:
>
>>
>> On 09/01/14 21:54, Martin Peres wrote:
>>
>>> The worse thing that can happen is an application running with the
>>> user's uid grabbing and sending periodical screenshots to a distant server
>
On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres wrote:
> Le 10/01/2014 16:44, Maarten Baert a écrit :
>
> On 10/01/14 14:56, Martin Peres wrote:
>>
>>> Please provide a detailed explanation for that and tell me how likely it
>>> is to ever end up upstream.
>>>
>> If by 'upstream' you mean the ker
Hey,
This came up during the mutter implementation. See my questions here for
what prompted this. I found the proposed phrasing a bit confusing as well...
https://bugzilla.gnome.org/show_bug.cgi?id=705502#c16
On Fri, Jan 17, 2014 at 6:37 AM, Jonas Ådahl wrote:
> On Fri, Jan 17, 2014 at 12:20:
If we respect the ICCCM, we need to map the child window when the client
asks for it to be mapped. If the WM_TRANSIENT_FOR hint specifies an invalid
window, we just ignore it.
Looking through the mutter code, it seems that if we don't recognize a
window specified in WM_TRANSIENT_FOR, we warn and i
Yeah, this makes sense.
Reviewed-by: Jasper St. Pierre
On Sun, Jan 19, 2014 at 4:32 AM, Jonas Ådahl wrote:
> Clarify some semantics of wl_subsurface.place_below and
> wl_subsurface.place_below that were not specified.
>
> Signed-off-by: Jonas Ådahl
> ---
>
> Hi,
>
&g
Reviewed-by: Jasper St. Pierre
On Sun, Jan 19, 2014 at 4:32 AM, Jonas Ådahl wrote:
> Make it clear that multiple requests before commit are allowed and how it
> is handled.
>
> Signed-off-by: Jonas Ådahl
> ---
> protocol/wayland.xml | 4
> 1 file changed, 4 inserti
On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak wrote:
>
> - When the compositor creates a shell_surface having the TOPLEVEL type,
>> it sets a numeral ID for it, and sends a "map" event to the desktop_shell
>> client ;
>>
>
> You must allow a "toplevel" to become a non-toplevel and vice-versa,
>
On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak wrote:
> Jasper St. Pierre wrote:
>
> Hiding windows should not have any influence over the client, as many
>> desktop environments, including Weston, want to show live previews for
>> minimized or hidden windows in alt
On Thu, Jan 30, 2014 at 9:03 PM, Bill Spitzak wrote:
> Jasper St. Pierre wrote:
>
> A simple problem is a floating window shared by two main windows.
>>
>> Can you give a concrete example of such a case? Not because I'm assuming
>> none exist, but beca
On Sun, Feb 2, 2014 at 1:06 AM, Kristian Høgsberg wrote:
> On Sat, Feb 01, 2014 at 09:39:12PM +0100, Quentin Glidic wrote:
> > From: Quentin Glidic
> >
> > Signed-off-by: Quentin Glidic
> > ---
> >
> > v2: Update .gitignore (Thanks Jasper)
>
> I looked into this and I did have generated .c and .
You can see our layers here:
https://git.gnome.org/browse/mutter/tree/src/meta/common.h#n572
On Tue, Feb 4, 2014 at 2:45 AM, Emilio Pozuelo Monfort wrote:
> On 03/02/14 17:14, Emilio Pozuelo Monfort wrote:
> > Hi Bill,
> >
> > On 30/01/14 23:33, Bill Spitzak wrote:
> >> There really should not
What compositor are you using, and how did you build Xwayland? Did you
build xf86-video-wayland as well?
On Wed, Feb 5, 2014 at 12:18 PM, Bill Spitzak wrote:
> I was wondering if my problem is not something anybody else is seeing.
>
> I have Wayland X11 compositor running. This is on an Nvidia
wlshm is old. You should just be able to just install xf86-video-wayland
and have everything work.
On Wed, Feb 5, 2014 at 12:46 PM, Bill Spitzak wrote:
> On 02/05/2014 09:21 AM, Jasper St. Pierre wrote:
>
>> What compositor are you using
>>
>
> The X11 compositor you get
Well, there's not really anything that allows process A to arbitrarily
modify process B's memory. The only thing that's close is memory-mapped
files, and that's already what we use to share image data between the
client and the compositor.
There's also memfd, which is "more secure" than a memory-m
ail.com] *On Behalf Of *Jasper
> St. Pierre
> *Sent:* Sunday, February 09, 2014 12:23 AM
>
> *To:* Wang, Quanxian
> *Cc:* wayland-devel@lists.freedesktop.org
> *Subject:* Re: Is there any way to let compositor set the data in client
> space and then return back to client?
&g
The parameter was dropped...
---
protocol/xdg-shell.xml | 6 --
1 file changed, 6 deletions(-)
diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
index f0d04aa..7e4193b 100644
--- a/protocol/xdg-shell.xml
+++ b/protocol/xdg-shell.xml
@@ -243,12 +243,6 @@
ignore it if it does
The client had logic to adjust the dx/dy parameter of the window when
resizing, but it was broken: nothing enabled that code, and it would only
work for the first resize.
To make up for it, desktop-shell had code to flat out ignore the dx/dy
parameters when resizing and anchor it its own way. This
1 - 100 of 394 matches
Mail list logo
