Re: wl_fixed_to_double() function only correct when fixed value is greater than zero

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

Re: [PATCH] xdg-shell: remove constraints for fullscreen

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

Re: [RFC weston] clients: Don't attach a buffer if mouse cursor surface is unchanged

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

Re: Window positioning

gt; > > > *From:* magc...@gmail.com [mailto:magc...@gmail.com] *On Behalf Of *Jasper > St. Pierre > *Sent:* Wednesday, January 03, 2018 12:24 PM > *To:* Han, Guowei <guowei@johnsonoutdoors.com> > *Cc:* Kai-Uwe <ku.b-l...@gmx.de>; wayland <wayland-devel@lists. >

Re: Window positioning

asper. Do u know if there's 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, J

Re: Window positioning

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

Re: Screen dimensions, top level surface positioning...

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

Re: Fragment Shader of FP16 produces incorrect image drawing.

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

Re: [PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording

er, 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 <jad...@gmail.com> wrote: > On Sun, Jul 16, 2017 at 11:16:25PM -0700, Jasper St. Pierre wrote: > > (

Re: [PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording

(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

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

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

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

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

Re: [PATCH v2] xdg-shell: add preferred min/max size requests

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

Re: [PATCH] xdg-shell: add set_max_size request

<ofour...@redhat.com> wrote: > Hi all, > > - Original Message - >> On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre" >> <jstpie...@mecheye.net> >> said: >> >> > I think min/max hints are acceptable in xdg-shell. >

Re: [PATCH] xdg-shell: add set_max_size request

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 - >> > [...] >> > >> >

Re: history/semantics of uint32_t name

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

Re: Collaboration on standard Wayland protocol extensions

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

Re: Collaboration on standard Wayland protocol extensions

On Sun, Mar 27, 2016 at 7:33 PM, Drew DeVault <s...@cmpwn.com> 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 >

Re: Collaboration on standard Wayland protocol extensions

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

Re: Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

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

Re: Introduction and updates from NVIDIA

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

Re: desktop-shell: How to enable really alpha blending of weston background?

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

Re: Question regarding joystick/gamepad support in wayland

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

Re: [RFC wayland 00/18] Wayland network transparency :)

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 >>

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

150, 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 <giuliocamu...@gmail.com> wrote: > 2016-02-03 11:00 GMT+02:00 Jasper St. Pierre <

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

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

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

On Wed, Feb 3, 2016 at 1:00 PM, Bill Spitzak <spit...@gmail.com> wrote: > > > On Wed, Feb 3, 2016 at 11:36 AM, Jasper St. Pierre <jstpie...@mecheye.net> > wrote: >> >> set_parent was moved to xdg_toplevel. Perhaps that's a good idea, >> perhaps it's not.

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

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 <spit...@gmail.com> wrote: > > > On Wed, Feb 3, 2016 at 1:06 AM, Jasper St. Pierre <jstpie...@me

Re: Moving bugs to Phabricator

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

Re: [PATCH wayland-protocols 0/3] xdg_surface base interface and xdg_tooltip

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

Re: kernel level window management

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

Re: [IDEA] Support several fullscreen behaviors - potentially rename 'fullscreen'

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

Re: inserting a "wl_display" object

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

Re: [PATCH] xdg-shell: add state range reservation for EFL

groups of people taking carve-outs. On Fri, Dec 4, 2015 at 4:50 PM, Bryce Harrington <br...@osg.samsung.com> wrote: > On Fri, Dec 04, 2015 at 12:41:16PM -0500, Mike Blumenkrantz wrote: >> Reviewed-by: Jasper St. Pierre <jstpie...@mecheye.net> > > Reviewed-by: Bryce Harrin

Re: [PATCH 1/2] xdg-shell: Bump unstable version to 6

v6.xml > @@ -0,0 +1,624 @@ > + > + > + > + > +Copyright © 2008-2013 Kristian Høgsberg > +Copyright © 2013 Rafael Antognolli > +Copyright © 2013 Jasper St. Pierre > +Copyright © 2010-2013 Intel Corporation > + > +Permission is hereby gra

Re: [RFC wayland] protocol: Add wl_surface.buffer_damage

something similar. On Sat, Nov 7, 2015 at 2:32 AM, Daniel Stone <dan...@fooishbar.org> wrote: > On 6 November 2015 at 19:08, Jasper St. Pierre <jstpie...@mecheye.net> wrote: >> To help clear things up, I think we should deprecate the >> wl_surface.damage request and do

Re: [RFC wayland] protocol: Add wl_surface.buffer_damage

t. On Sat, Nov 7, 2015 at 9:41 AM, Daniel Stone <dan...@fooishbar.org> wrote: > Hi, > > On 7 November 2015 at 16:59, Jasper St. Pierre <jstpie...@mecheye.net> wrote: >> I don't see where. I see eglSwapBuffersWithDamage still looking like >> it shoves the rects a

Re: [RFC wayland] protocol: Add wl_surface.buffer_damage

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

Re: Is VT sharing possbile with weston 1.8.0 with fbdev backend?

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

Re: [PATCH weston v2 02/21] input: Make pointer grab motion callbacks take an event struct

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

Re: [PATCH] compositor: Disallow negative geometries in backend output configs

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

Re: Unstable protocol name breakage

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

Re: I-beam cursor color changing based on the background

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

Re: [PATCH v2 3/3] clients: Disable popup shortcut in stacking demo

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

Re: [PATCH wayland] server: Make serial number 0 mean invalid

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,

Re: [PATCH wayland] server: Make serial number 0 mean invalid

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 <spit...@gmail.com> wrote: > On 10/13/2015 09:53 AM, Jasper St. Pierre wrote: > > Th

Re: [RFC 1/2] Introduce wl_probe_visible protocol

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:

Re: State of Wayland protocol development

... 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

Re: [PATCH wayland] shm: Add wl_shm_buffer get/put functions

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 : >>

Re: [PATCH wayland] shm: Add wl_shm_buffer get/put functions

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 : >>> >>>

Re: Enums, bitfields and wl_arrays

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

Re: Can I enable mode switching from wayland/weston?

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]

Re: [PATCH wayland] server: Make serial number 0 mean invalid

e. I think most will have 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 <jstpie...@mecheye.net> > wrote: >> >> >> In cases where we

Re: [PATCH wayland] server: Make serial number 0 mean invalid

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

Re: random window position with desktop shell

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

Re: Don't make systemd a hard dependency for weston

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 >>

[PATCH weston 1/3] launcher: Rename logind-util to launcher-logind

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

[PATCH weston 2/3] launcher: Split out launcher implementations into three distinct ones

launcher->vt_source); + + if (launcher->tty >= 0) + close(launcher->tty); + + free(launcher); +} + +struct launcher_interface launcher_direct_iface = { + launcher_direct_connect, + launcher_direct_destroy, + launcher_direct_open, + la

[PATCH weston 3/3] launcher-logind: Remove old VT switching code, move to SwitchTo/Activate

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

Re: wl_surface.attach with NULL wl_buffer behaviour

my implementation. >> > >> > [3741557.293] -> wl_surface@20.frame(new id wl_callback@25) >> > [3741557.476] -> wl_surface@20.attach(wl_buffer@29, 0, 0) >> > [3741557.676] -> wl_surface@20.damage(0, 0, 800, 480) >> > [3741557.906] -> wl_su

Re: [PATCH weston] xdg-shell: Clarify ack_configure behaviour

Reviewed-by: Jasper St. Pierre <jstpie...@mecheye.net> On Tue, Sep 1, 2015 at 8:32 AM, Derek Foreman <der...@osg.samsung.com> wrote: > Right now many toolkits (toytoolkit, gtk+ and EFL) will send an > ack_configure request immediately in response to a configure event,

Re: wl_surface.attach with NULL wl_buffer behaviour

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

Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs

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 raw...@gmail.com wrote: On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: On Wed, Jun 10, 2015 at 4:50 AM

Re: [PATCH] Documentation for the prepare_lock_surface event description, is incorrect

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 cpmich...@osg.samsung.com wrote: Documentation for the

Re: cross-client surface references

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.

Re: cross-client surface references

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: 1.

Re: [PATCH] screenshooter: Add missing field initializers for wl_output_listener

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 cpmich...@osg.samsung.com wrote: On 07/07/2015 01:15 PM, Jasper St. Pierre wrote

Re: [PATCH] screenshooter: Add missing field initializers for wl_output_listener

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 cpmich...@osg.samsung.com wrote: This patch adds missing placeholders for the wl_output listener functions 'done' and 'scale.

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

I'm for it as well. On Wed, Jun 24, 2015 at 9:53 AM, Dima Ryazanov d...@gmail.com 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 d...@gmail.com wrote: (Oops, sent too soon by accident.) Yep,

Re: Stacking subsurface siblings

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 jstpie...@mecheye.net wrote: I was not aware you could stack subsurfaces under a parent surface at all. Is this intended protocol

Re: Stacking subsurface siblings

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 raw...@gmail.com wrote: Hi, I'm wondering if a behaviour of

Re: Stacking subsurface siblings

at 5:11 PM, Jasper St. Pierre jstpie...@mecheye.net 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 raw...@gmail.com wrote: I'm not sure, but I find it very useful for a video player. The video is stacked

Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs

On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org 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 thread. I

Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs

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

Re: Wayland Compatibility for arm 64-bit?

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 ppaala...@gmail.com wrote: On Mon, 8 Jun 2015 19:49:15 +0300 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 28 May 2015 11:35:46

Re: Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.

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

Re: [PATCH libinput v2] Fix to avoid use of undefined pointer values.

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 j...@osg.samsung.com wrote:

Re: [PATCH xwayland 4/4] xwayland: Make the XYToWindowProc implementation aware of touchpoints

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 carl...@gnome.org wrote: For these, we must first lookup the DIX sequence

Re: [PATCH xwayland] xwayland: Throttle our cursor surface updates with a frame callback

This makes sense to me. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Mon, May 25, 2015 at 12:15 PM, Rui Matos tiagoma...@gmail.com 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

Re: [PATCH v2 1/3] xwayland: Fix the addition and removal of outputs

Expecting anything atomic from X11 in the first place is a wrong assumption. On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa mchqwe...@gmail.com wrote: Hi, On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov d...@gmail.com wrote: Add the output to the list when it's created rather than when its

Re: EGL-X Applications on XWayland

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,

Re: Proposal for better collaboration on xdg-shell

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,

Re: [PATCH weston 08/17] xdg-shell: Further clarify xdg_surface.move semantics

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 ppaala...@gmail.com wrote: On Tue, 7 Apr 2015 18:40:03

Re: [PATCH weston 03/17] xdg-shell: Document error conditions when popup and surface getters

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

Re: EFL/Wayland and xdg-shell

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 dan...@fooishbar.org wrote: On 14 April 2015 at 04:19, Jasper St. Pierre jstpie...@mecheye.net wrote: Boo

Re: EFL/Wayland and xdg-shell

On Mon, Apr 13, 2015 at 5:02 PM, Bryce Harrington br...@osg.samsung.com 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

Re: EFL/Wayland and xdg-shell

On Mon, Apr 13, 2015 at 7:59 PM, Derek Foreman der...@osg.samsung.com 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

Re: xdg-shell and always centered surfaces

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 think

Re: Xfig menus don't appear - bug?

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 jstpie...@mecheye.net wrote: No, sorry. I'll take a look

Re: [PATCH weston 06/17] xdg-shell: Require a buffer and a wl_surface.commit for mapping a window

On Tue, Apr 7, 2015 at 6:03 PM, Bryce Harrington br...@osg.samsung.com 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

Re: [PATCH weston 10/17] xdg-shell: Clarify the meaning of app ID and give example

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

Re: Xfig menus don't appear - bug?

No, sorry. I'll take a look today. On Mon, Apr 6, 2015 at 10:22 AM, Felix E. Klee felix.k...@inka.de wrote: Should I report this somewhere? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org

Re: [PATCH weston v2] xwm: don't let X windows steal the focus

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 the

[PATCH weston] xwayland: Stack windows on top when activating them

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. ---

[PATCH weston] xwayland: Correct input for undecorated clients

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

Re: [PATCH weston] desktop-shell: don't allow negative values in drag resize

Yeah, this is obviously correct. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Wed, Mar 18, 2015 at 9:16 AM, Derek Foreman der...@osg.samsung.com wrote: Now clamping width and height to a minimum of 1, 1 when drag resizing. Signed-off-by: Derek Foreman der...@osg.samsung.com

[PATCH weston 3/3] launcher-logind: Remove old VT switching code, move to SwitchTo/Activate

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

[PATCH weston 1/3] launcher: Rename logind-util to launcher-logind

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

[PATCH weston 2/3] launcher: Split out launcher implementations into three distinct ones

, + launcher_direct_activate_vt, + launcher_direct_restore, +}; diff --git a/src/launcher-impl.h b/src/launcher-impl.h new file mode 100644 index 000..53ced0e --- /dev/null +++ b/src/launcher-impl.h @@ -0,0 +1,39 @@ +/* + * Copyright © 2015 Jasper St. Pierre + * + * Permission to use, copy

[PATCH weston 0/3] Rework the launcher infrastructure

that a smoother handover can be done from display managers like gdm, where we can have a VT allocated to us instead of requiring that we're opened on our own VT. There should not be any regressions in existing behavior. Cc: David Herrmann dh.herrm...@gmail.com Cc: Ray Strode rstr...@redhat.com Jasper St

  1   2   3   4   >