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
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
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
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
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
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
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,
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
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
(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
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
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 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
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
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
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
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
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 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
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
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
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 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 ->
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
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
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
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:
>>
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
... 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
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
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
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
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
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
>>
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
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
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
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
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
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
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 -
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 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
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
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
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
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
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
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
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:
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
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
I'm for it as well.
On Wed, Jun 24, 2015 at 9:53 AM, Dima Ryazanov wrote:
> Bringing this up again. What do you guys think? Does it make sense to push
> this change?
>
> On Wed, May 27, 2015 at 1:50 AM, Dima Ryazanov wrote:
>>
>> (Oops, sent too soon by accident.)
>>
>> Yep, DISPLAY always needs
Tue, Jun 16, 2015 at 5:11 PM, Jasper St. Pierre
> wrote:
>>
>> Why can't you use the video as the main surface and an OSD as a
>> subsurface?
>>
>> On Tue, Jun 16, 2015 at 11:09 AM, Arnaud Vrac wrote:
>> > I'm not sure, but I find it very usef
le
> option with wayland is to have a surface for the OSD and a subsurface for
> the video which is stacked under.
>
> On Tue, Jun 16, 2015 at 5:02 PM, Jasper St. Pierre
> wrote:
>>
>> I was not aware you could stack subsurfaces under a parent surface at
>> all.
I was not aware you could stack subsurfaces under a parent surface at
all. Is this intended protocol behavior? The fact that you might be
able to do that at all in Weston might be a bug.
On Tue, Jun 16, 2015 at 7:46 AM, Arnaud Vrac wrote:
> Hi,
>
> I'm wondering if a behaviour of weston related t
On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho wrote:
> On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
>> What is the value of clients having this information?
>
> The same there is in having wl_touch.cancelled. See the cases in the
> original email in the th
What is the value of clients having this information? I think we've
tried to hide grab semantics from the point of view of the client and
simply say "we can revoke input at any time, including in response to
a request you make", which gives us, the compositor, a lot more leeway
with future possibil
ARM is still little-endian. I can't imagine that there are any
compatibility issues with ARM 64-bit and Wayland.
On Mon, Jun 8, 2015 at 9:51 AM, Pekka Paalanen wrote:
> On Mon, 8 Jun 2015 19:49:15 +0300
> Pekka Paalanen wrote:
>
>> On Thu, 28 May 2015 11:35:46 +
>> Sumadhurakalyan Singamchet
Note that there are non-obvious consequences to this. The keymap is
hierarchical upon layouts and levels. You can either do a depth-first
search, or a breadth-first search. This can change behavior.
XKeysymToKeycode is documented as doing a breadth-first search. This can
have consequences in behavi
I can't find any standard for asprintf outside of the glibc library,
which doesn't mention anything about undefined behavior. Am I missing
something?
http://www.gnu.org/software/libc/manual/html_node/Dynamic-Output.html
On Fri, May 29, 2015 at 10:29 AM, Jon A. Cruz wrote:
> Well, no.
>
> It is c
I'm planning on removing this hook and just make compositors deal with
the fallout. Unfortunately, it hasn't been merged yet.
http://patchwork.freedesktop.org/patch/43021/
On Wed, May 27, 2015 at 9:42 AM, Carlos Garnacho wrote:
> For these, we must first lookup the DIX sequence from the Sprite,
This makes sense to me.
Reviewed-by: Jasper St. Pierre
On Mon, May 25, 2015 at 12:15 PM, Rui Matos wrote:
> In some extreme cases with animated cursors at a high frame rate we
> could end up filling the wl_display outgoing buffer and end up with
> wl_display_flush() failing.
>
&
Expecting anything atomic from X11 in the first place is a wrong assumption.
On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa wrote:
> Hi,
>
> On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov wrote:
>>
>> Add the output to the list when it's created rather than when its
>> properties
>> change (as p
Currently, EGL-X applications will fall back to software rendering,
assuming you're using a mesa-based GL, simply because mesa doesn't
have support for DRI3 in its EGL layer, and Xwayland doesn't have
support for DRI2.
Either of those can be fixed, it's just that nobody has tried yet.
On Tue, May
Yeah. I think some people were assuming xdg-shell was final, and I was
its gatekeeper, and it's what GNOME wants and you have to fight to get
other things in.
That wasn't my intention at all! My goal was to build a solid base for
the rest of the DEs to eventually work more like how Bryce wants, bu
If there's an application that wants a move indicator, we could
provide a "moving" state, but since the application doesn't get any
feedback about the move, ever, I'm not sure this is useful.
On Thu, Apr 30, 2015 at 7:36 AM, Pekka Paalanen wrote:
> On Tue, 7 Apr 2015 18:40:03 -0700
> Bryce Harrin
Oh, nice catch, that's a typo. The expected behavior here is that you
cannot change from xdg_surface to xdg_popup or cursor surface or
anything.
You should be able to destroy and recreate the xdg_surface without
destroying the wl_surface.
On Thu, Apr 30, 2015 at 7:08 AM, Giulio Camuffo wrote:
>
Yeah, that was extremely uncalled for. Was a difficult day at work,
and I was already cranky. I messed up, that was my fault, and I
apologize.
On Wed, Apr 15, 2015 at 12:31 PM, Daniel Stone wrote:
> On 14 April 2015 at 04:19, Jasper St. Pierre wrote:
>> Boo hoo.
>>
>> you
On Mon, Apr 13, 2015 at 7:59 PM, Derek Foreman wrote:
... snip ...
> That all makes sense - set_window_geometry() was a bit of a red herring
> here.
>
> Some EFL developers want the application to have a way to know its
> rotation so it can, for example, render drop shadows correctly.
>
> Take a
On Mon, Apr 13, 2015 at 5:02 PM, Bryce Harrington wrote:
> A couple weeks ago I gave a talk on Wayland to the EFL folks at the
> Enlightenment Developer Day in San Jose. They've already implemented a
> Wayland compositor backend, so my talk mainly speculated on Wayland's
> future and on collectin
Hi.
set_window_geometry is about the "window geometry" of a surface,
relative to the overall surface. It's a difficult concept to explain,
but I feel the docs do a good enough job.
Currently it's not possible to specify initial window location. Can
you give your exact use case here so we can thin
It's described as murky because it is super murky.
In the brave new world, apps are supposed to be D-Bus Activatable.
That means setting DBusActivatable=true in their desktop file. A
requirement for this is that desktop file name needs to match their
bus name. D-Bus doesn't require this -- the des
On Tue, Apr 7, 2015 at 6:03 PM, Bryce Harrington wrote:
> On Tue, Apr 07, 2015 at 05:01:21PM +0800, Jonas Ådahl wrote:
>> Require the client to have attached (either previously committed, or
>> newly) a buffer to the corresponding wl_surface, and that the window
>> will not be potentially mapped u
Menus appear fine on my machine. I assume it's the recent Xwayland
bugs. Try weston from master combined with:
http://lists.freedesktop.org/archives/xorg-devel/2015-February/045701.html
On Mon, Apr 6, 2015 at 10:27 AM, Jasper St. Pierre
wrote:
> No, sorry. I'll take a look toda
No, sorry. I'll take a look today.
On Mon, Apr 6, 2015 at 10:22 AM, Felix E. Klee wrote:
> Should I report this somewhere?
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-d
It's because there are multiple windows, and "window" is ambiguous.
First of all, there's the actual window that the event was generated
on. That isn't actually sent to you. When the event bubbles up, you
get three windows:
"root", which is the root window of the source window. Used for
finding th
Now that we've removed the XYToWindow handler in Xwayland, we actually
have to stack windows properly. This stacks windows on top when
activating them.
Note that for a fully robust Xwayland implementation, we'll need a
complete stack tracker implementation, unfortunately.
---
xwayland/window-mana
We were correctly handling decorated and fullscreen clients, but left
uninitialized values in the input region for undecorated clients. Fix
this behavior.
---
xwayland/window-manager.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xwayland/window-manager.c b/xway
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
We're refactoring this to have multiple launcher "implementations".
---
Makefile.am | 4 +-
src/launcher-logind.c | 953 ++
src/launcher-logind.h | 120 +++
src/launcher-util.c | 2 +-
src/logind-util.c | 953 -
1 - 100 of 394 matches
Mail list logo