Re: Current state of Window Decorations

On Thu, 25 Jun 2020 17:16:30 +0300 Pekka Paalanen said: > On Thu, 25 Jun 2020 19:01:33 +1000 > Brad Robinson wrote: > > > That said, what would be the recommended way to implement this - would you > > typically have one surface for the decorations and an embedded sub-surface > > for the content

Re: Current state of Window Decorations

On Thu, 25 Jun 2020 19:01:33 +1000 Brad Robinson said: > Thanks Simon/Pekka, > > As a toolkit developer coming from Windows/OSX this is fairly shocking. > I'm aware of the decoration protocol, but given it's not supported (and by > the sound of it never will be) on some of the major distros make

Re: Current state of Window Decorations

On Thu, 25 Jun 2020 11:57:42 +1000 Brad Robinson said: > Hey All, > > What's the current state and/or plans for window decorations with Wayland? > > I just stumbled on this post > >, and after reading the com

Re: Best practices for client side buffer management

On Wed, 24 Jun 2020 19:17:57 +1000 Brad Robinson said: EFL has the same model - it tracks damage rects (either sent by expose/damage events from windowing system combined with a set of rect regions it calculates itself based on previous frame state vs current frame state and which exposed/visible

Re: Best practices for client side buffer management

On Fri, 19 Jun 2020 13:24:12 +1000 Brad Robinson said: > Hi All, > > I'm fairly new to Wayland and Linux GUI programming in general, but doing > some experiments to figure out how to integrate it into my custom UI > toolkit library and have a couple of questions about client side buffer > manage

Re: Best practices for saving and restoring window layout

On Fri, 5 Jun 2020 13:09:20 +0300 Pekka Paalanen said: > On Fri, 5 Jun 2020 02:06:00 +1000 > Brad Robinson wrote: > > > Hi All, > > > > First post here... > > > > I'm looking into porting an existing UI library to Gtk+ and I'm struggling > > to solve a couple of problems related to window pos

Re: Implemented lower window when middle click on titlebar in gtk/mutter

On Thu, 7 May 2020 14:28:17 +0200 Mildred Ki'Lya said: > Le 07/05/2020 à 11:15, Carsten Haitzler (The Rasterman) a écrit : > >> I suppose that the client can declare the title bar area, and the > >> compositor can then handle clicks in this area. is there someth

Re: Implemented lower window when middle click on titlebar in gtk/mutter

On Mon, 4 May 2020 12:08:46 +0200 Mildred Ki'Lya said: > Hi, > > For a long time I delayed using Wayland on my computer for about three > reasons: inability to restart the gnome-shell (Alt-F2, r), slowness in > gnome-shell, and inability to lower client-side decorated windows on > middle clic

Re: Chrome Remote Desktop and Wayland

On Thu, 9 Apr 2020 12:05:57 -0700 Erik Jensen said: > On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl wrote: > [snip] > > DRM master and input device revocation should be handled more or less > > already by most if not all compositors, by closing devices, by then > > going dorment until access is re

Re: gitlab.fd.o financial situation and impact on services

On Thu, 27 Feb 2020 22:27:04 +0100 Daniel Vetter said: Might I suggest that given the kind of expenses detailed here, literally buying 1 - 4 reasonably specced boxes and hosting them at OSUOSL would be incredibly cheaper? (we (enlightenment.org) have been doing so for years on a single box). We f

Re: Weston screenshooter blocks the display for over a second

On Mon, 28 Oct 2019 18:43:02 +0100 CHUCO POGA said: > When attempting to make a screenshot under weston with Mod + S > (weston-screenshooter), the entire display get's blocked for over a second. > That causes an ugly jitter on the screen when displaying dynamic content > (such as movies) > > I h

Re: XDC allocator workshop and Wayland dmabuf hints

On Thu, 17 Oct 2019 12:09:44 +0300 Pekka Paalanen said: > On Mon, 14 Oct 2019 06:02:59 -0700 > James Jones wrote: > > > On 10/13/19 2:05 PM, Scott Anderson wrote: > > > (Sorry to CCs for spam, I made an error in my first posting) > > > > > > Hi, > > > > > > There were certainly some interesti

Re: What can I replace X Pixmaps with?

On Fri, 11 Oct 2019 10:58:44 +0100 Brandon Dowdy said: > Hi, > > I know this mailing list is mainly for anything about Wayland and I know > that Wayland doesn't deal with rendering, so this may be the wrong place to > ask or get advice about this, but I just wanted to get some advice (and may >

Re: One question on wayland desing on buffer

On Mon, 02 Sep 2019 08:40:41 +0800 "HalleyZhao" said: > Hi experts: wayland designs a light-weight server, usually client manages > buffer by themselves. It gives client more flexibility, migration > rendering/composition between different server, subsurface to keep layout > while keeping view h

Re: HDR support in Wayland/Weston

On Mon, 04 Mar 2019 08:32:45 + Simon Ser said: > On Monday, March 4, 2019 8:13 AM, Graeme Gill wrote: > > And the current favorite is "blue light filter" effects, for which numerous > > applications are currently available. They tweak the white point > > of the display by arbitrarily modifyi

Re: wayland menu

On Wed, 12 Dec 2018 11:14:48 + Carsten Haitzler (The Rasterman) said: > On Tue, 11 Dec 2018 21:12:29 +0100 David Craven said: > > There is already a dbus protocol for this canonical came up with for > ubuntu/unity and it's got support in several toolkits a

Re: wayland menu

On Tue, 11 Dec 2018 21:12:29 +0100 David Craven said: There is already a dbus protocol for this canonical came up with for ubuntu/unity and it's got support in several toolkits already. Look into com.canonical.AppMenu.Registrar (google for it). This is also already implemented by at least some w

Re: Use-case for CTRC background color?

On Fri, 16 Nov 2018 09:19:17 +0530 Harish Krupo said: > Hi, > > This patch [1] introduces the background crtc color property. This > property is available on some display controlers and allows setting a > non-black colors for pixels not covered by any plane (or pixels covered > by the transparen

Re: Why isn't Xwayland just a Wayland client?

uldn't change the default (so they added more protocol to negotiate decorations). A compositor will NOT decorate windows unless as per above. It doesn't have to be put in protocol specs to be a hard fact of life in Wayland. -- --------- Codito, ergo sum - "I code, therefore I am&

Re: Why isn't Xwayland just a Wayland client?

he default in X11 is "window manager decorates" which is the opposite of Wayland. > Cheers, > Joseph > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-

Re: Remote Desktop with Wayland

believe it cannot switch between local and remote > modes, it will always be remote. There is also the screen-share plugin, > but I doubt that's a solution here either, I would guess it is missing > the local locking while in remote use. > > I

Re: [RFC wayland-protocols] inputfd - direct input access protocol

l a gamepad/jostick etc. protocol has to do is pass on the same data as the kernel device. unlike a kernel device it'd at least be portable as a different OS may or may not support the same devices. if we're doing the "well we'll emulate a linux evdev device then on all platforms" then why not

Re: [RFC wayland-protocols] inputfd - direct input access protocol

but a gaming mouse does not...)... > _______ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] inputfd - direct input access protocol

ved > > > event. > > > + See wp_inputfd_device.focus_in for more details. > > > + > > > + When this event is received, the client must > > > wp_inputfd_device.destroy > > > + the object. > > > + > > > + > > > +

Re: [RFC wayland-protocols] inputfd - direct input access protocol

ide the same capabilities. > + > + If applicable, this event contains the surface that has the focus. > + In some cases, the focus may not be tied to a specific client surface > + but is given to the client independent of any

Re: [RFC wayland] move away from C

On Sat, 1 Apr 2017 09:41:51 -0500 Derek Foreman said: > On 01/04/17 09:24 AM, Carsten Haitzler (The Rasterman) wrote: > > On Sat, 1 Apr 2017 14:03:21 +0100 Auke Booij said: > > > >> The C programming language was developed in the early '70s. It was > >> al

Re: [RFC wayland] move away from C

On Sat, 1 Apr 2017 09:41:51 -0500 Derek Foreman said: > On 01/04/17 09:24 AM, Carsten Haitzler (The Rasterman) wrote: > > On Sat, 1 Apr 2017 14:03:21 +0100 Auke Booij said: > > > >> The C programming language was developed in the early '70s. It was > >> al

Re: [RFC wayland] move away from C

/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Interface for injection of input events

r ways. -- ----- Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Interface for injection of input events

On Tue, 28 Mar 2017 14:31:24 +0300 Pekka Paalanen said: > On Tue, 28 Mar 2017 16:20:28 +0900 > Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen > > said: > > > > > > == Authentication/Identification == >

Re: [RFC] Interface for injection of input events

> Because of what it does, there is no real code-sharing between compositors - > they would just use their own intrastructure to hook to the dbus interface > and create virtual devices. On the client-side it's much the same thing, > binding to dbus is trivial. > &

Re: [RFC] Interface for injection of input events

s been an elephant in the room for a while and we don't really have a consensus on how to support extra privileges other than to say "don't do it at all" or "not a wayland problem". :( -- - Codito, ergo sum - "I code, therefore I am" --

Re: It seems regular linux desktops can't run android apps even on Wayland?

ould be (but less than Windows), no one really is going to chase this moving target that ever becomes more and more closed over time. Given that ... any EGL stack talk and Wayland is kind of moot. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Ras

Re: [RFC wayland-protocols] Color management protocol

On Sat, 14 Jan 2017 11:52:25 +0100 Kai-Uwe said: > Am 14.01.2017 um 03:24 schrieb Carsten Haitzler (The Rasterman): > > On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen > > said: > >> Oh, ok, that's why. We could as easily have the compositor show the > >&

Re: [RFC wayland-protocols] Color management protocol

nother path would be to obtain one of Richard's > >>> ColorHug's, but I think seeing how the commercial > >>> software operates as well, would add a broader perspective.) > >> > >> Even watching some videos of a typical calibration/profiling work

Re: [RFC wayland-protocols] Color management protocol

he protocol could > simply take 3 numbers for the color instead of an image buffer. Then > people would not get the urge to abuse this interface for e.g. > application splash screens. i kind of like the idea of a special protocol with 32bit ints per rgb etc. to say "display this

Re: [RFC wayland-protocols] Add the color-management protocol

eference/test compositor. if you want a fully working desktop these days it's gnome's mutter, enlightenment or more recently kde's kwin has been catching up. there is a tiling wm called sway as well. that's the major compositors that are actually meant for "every day&q

Re: [RFC wayland-protocols] Add the color-management protocol

compositor. choose gnome? it'll be mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be kwin etc. etc. etc. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com _

Re: [RFC wayland-protocols] Add the color-management protocol

t; attached to the surface (which the client can see and control), or you > have to grow EGL API for the entire breadth of colour management. This > is a lot of the reason why we have things like opaque region attached > to the surface, wi

Re: [RFC wayland-protocols] Add the color-management protocol

that makes surface rather than bufer the > right choice. i actually meant wl_buffer which is really the abstraction on top of these buffers... ? -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com _

Re: [RFC wayland-protocols] Add the color-management protocol

On Tue, 20 Dec 2016 18:25:40 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > > what if the display can do different color profiles for different regions? > > my example is yuv colorspace. 601 vs 709 etc. actually can be assigned per > > hw pla

Re: [RFC wayland-protocols] Add the color-management protocol

gt; > > + > > > + This interface represents a color space that can be attached to > > > surfaces. > > > + It is used by the zwp_color_management_v1 interface. > > > + > > > > so... here is my question

Re: [RFC wayland-protocols] Color management protocol

xact color correction for that colorspace. if i have 2 sRGB monitors i may get 2 sRGB colorspaces each with different transform constants/gamma lut tables etc. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)

Re: [RFC wayland-protocols] Color management protocol

On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill > > said: > > > a display may not have a single native colorspace. it may be able to > > switch. embedded devi

Re: [RFC wayland-protocols] Add the color-management protocol

Informs the server that the client will not be using this protocol > +object anymore. > + > + > + > + > + > +This request will cause a profile_fd event that returns a file > +descriptor to the ICC profile data of this colorspace. > + >

Re: [RFC wayland-protocols] Color management protocol

these constraints. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Raster

Re: Remote display with 3D acceleration using Wayland/Weston

your job to do it. that is what virtual-gl would be. a local headless wayland compositor (for wayland mode) with some kind of display front end on the other end. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten

Re: [RFC wayland-protocols] Color management protocol

On Wed, 14 Dec 2016 23:23:59 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill said: > > > this == support for color correction protocol AND actually the support for > > providing the real colorspace o

Re: [RFC wayland-protocols] Color management protocol

On Wed, 14 Dec 2016 18:49:14 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill said: > > >> Right. So a protocol for querying the profile of each output for its > >> surface is a base requiremen

Re: [RFC wayland-protocols] Color management protocol

On Wed, 14 Dec 2016 18:27:13 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill said: > > >> The correct approach to avoiding such issues is simply > >> to make both aspects Wayland (extension) p

Re: [RFC wayland-protocols] Color management protocol

On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill said: > > >> I thought I'd explained this in the previous post ? - perhaps > >> I'm simply not underst

Re: [RFC wayland-protocols] Color management protocol

On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > > wouldn't it be best not to explicitly ask for an output colorspace and just > > provide the colorspace of your buffer and let the compositor decide? e.g. if > > y

Re: [RFC wayland-protocols] Color management protocol

is not interested enough in exactly what's going > on color wise to be aware of the distinctions between linear light space > compositing and other approaches. > > Cheers, > > Graeme Gill. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

ompositor will fake it and reduce your colors down to sRGB, or your apps produce sRGB by default and have code paths for extended colorspace support *IF* it exists AND different colorspaces are natively supported by the display hardware. -- - Codito, ergo sum - "I code, therefore I

Re: [RFC wayland-protocols] Color management protocol

corresponding CRTC regions for a given Surface. > > > > Get corresponding Output(s) for a CRTC. > > > > Get unique Monitor identifier for an Output (i.e. EDID) > > > > Get/Set CRTC per channel lookup tables. > > > >

Re: [RFC wayland-protocols] Color management protocol

On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > Hi, > > > but is the intent that compositors MUST support color management and > > applications will fail entirely or fail to display even partly correctly if > > c

Re: [PATCH wayland v2] wayland-server: abort instead of posting events with wrong client objects

ruct wl_closure *closure; > > struct wl_object *object = &resource->object; > > > > + verify_objects(resource, opcode, args); > > closure = wl_closure_marshal(object, opcode, args, > > &obj

Re: [RFC wayland-protocols] Color management protocol

On Fri, 09 Dec 2016 14:06:46 +0100 Niels Ole Salscheider said: > Am Freitag, 9. Dezember 2016, 12:02:07 CET schrieb Carsten Haitzler: > > On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill said: > > > Carsten Haitzler (The Rasterman) wrote: > > > > i'm curious.

Re: [RFC wayland-protocols] Color management protocol

t/Get source and destination rendering intents for a Surface. > > > > Given that Wayland doesn't seem to have current support for configuring > > CRTC's, Outputs etc., there still seem to be some big gaps to fill to add > > even core color management support as part of the Wayland protocol. > > > > Graeme Gill. > > > > > > > > > > > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

nd color management. > > You don't have color management until you are able to profile the output > > device, so this is not something that can be left until latter! > > > > Graeme Gill. > > > > > > _______ > >

Re: [RFC wayland-protocols] Color management protocol

On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > > i'm curious... is the intent to make it requird that all compositors support > > color management (and thus have to support all the possible colorspaces > > defined)

Re: [RFC wayland-protocols] Color management protocol

or the support then adapt appropriately (and always fall back to SRGB as is defined as the default if it's not supported)? what is the path/intent for this? -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Kinetic scroll in libinput Xorg driver

y kinetic magic would be > dependent on you guessing when the next wheel event comes in (or doesn't). > stop events are only sent for "finger" sources, i.e. on the touchpad. oh the way we're doing it is far simpler... we don't need stop events at all

Re: Hello!

; than "Re: Contents of wayland-devel digest..." > > > Today's Topics: > > 1. Re: Kinetic scroll in libinput Xorg driver > (Carsten Haitzler (The Rasterman)) >2. Re: Kinetic scroll in libinput Xorg driv

Re: Kinetic scroll in libinput Xorg driver

ooked pretty boring steppy-steppy. so i was just assuming it needed switching on. :( maybe i need a full wl compositor-to-kms+libinput for it to work? -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Kinetic scroll in libinput Xorg driver

makes the > > user > > experience worse. this would have to be off by default and if it's off by > > default... you need ways of turning it on client by client ... and even > > then > > there are a pile of other problems you'll hit. so my suggestion is - &g

Re: Kinetic scroll in libinput Xorg driver

> > input layer this simply doubles the amount of this and likely > > makes the user > > experience worse. this would have to be off by default and if it's > > off by > > default... you need ways of turning it on client by client ... and &

Re: Kinetic scroll in libinput Xorg driver

le of other problems you'll hit. so my suggestion is - don't. add to your favorite toolkits instead if they don't have it. they have far more information about the context at the time and the use cases needed etc. -- - Codito, ergo sum - "I code, therefore I am&

Re: Weston does not do transparent backgrounds

tion, Could you please suggest... > > > > > > > > Hi, > > > > > > > > I can't say if that will help, that kind of use case was never > > > > intended. What will happen depends on the kernel driver and the EGL > > > > imple

Re: [PATCH] Introduce keyboard grabbing protocol

the consequences. if the vm decides that as a result of the grab error it will exit... who do you blame? compositor that is saying "no" and tell it to always say yes... or the app that chooses to take this as a fatal condition and exit? :) -- ---

Re: Weston does not do transparent backgrounds

d to have garbage there. I'm also not sure if the > > blending equation used accounts for destination alpha != 1.0. > > Therefore there may be a few things you have to fix before you see > > anything. > > > > I believe you'll find that the assumption of an opaque > > primary framebuffer is quite deeply rooted in Weston. > > > > Also note that GL support has been removed from the fbdev backend, > > too. See: > > https://cgit.freedesktop.org/wayland/weston/commit/src/ > > compositor-fbdev.c?id=e77f8ad79bdf3613dc7e587ea0cf5b9d39e4f8e0 > > > > > > Thanks, > > pq > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

On Fri, 5 Aug 2016 23:18:19 +0900 Carsten Haitzler (The Rasterman) said: > On Fri, 5 Aug 2016 07:45:50 -0500 Derek Foreman said: > > > On 27/07/16 02:54 AM, Jonas Ådahl wrote: > > > xdg-foreign is a protocol meant to enable setting up inter surface > > > relations

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

t. A handle may be > > + used to import the surface multiple times. > > + > > + > > + > > + > > + > > + > > + > > + > > + A xdg_imported object represents an imported reference to surface > > exported > > + by some client. A client can use this interface to manipulate > > + relationships between its own surfaces and the imported surface. > > + > > + > > + > > + > > + Notify the compositor that it will no longer use the xdg_imported > > + object. Any relationship that may have been set up will at this > > point > > + be invalidated. > > + > > + > > + > > + > > + > > + Set the imported surface as the parent of some surface of the > > client. > > + The passed surface must be a toplevel xdg_surface. Calling this > > function > > + sets up a surface to surface relation with the same stacking and > > positioning > > + semantics as xdg_surface.set_parent. > > + > > + > > + > + summary="the child surface"/> > > + > > + > > + > > + > > + The imported surface handle has been destroyed and any > > relationship set > > + up has been invalidated. This may happen for various reasons, for > > + example if the exported surface or the exported surface handle has > > been > > + destroyed, if the handle used for importing was invalid. > > + > > + > > + > > + > > + > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston on framebuffer?

On Wed, 20 Jul 2016 21:49:57 +0200 Christer Weinigel said: > Hi, > > On 07/20/2016 01:04 AM, Carsten Haitzler (The Rasterman) wrote: > >> With this I managed to get a desktop and was unable to start > >> wayland-terminal. Redrawing of the graphics felt fairly sn

Re: Weston on framebuffer?

you seem to have serious input lag which implies to me that it has nothing to do with your cpu speed and is something else deeper and more involved. time to trace things and see how they go. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Hai

Re: Introduction and updates from NVIDIA

te of things, we'd be left with having both a gbm path and an eglstreams path and have to runtime select based on driver. this means maintaining both, and sooner or later the lesser used one bitrots. we have bugs that happen in one path only and not the other and so on. if there were to be a

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

we could also state that using strictly negative values would raise a > > protocol error? > > > > Cheers, > > Olivier > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

gt; >> it's not the specific case I'm interested in here :-) > >> > >> Cheers, > >> Olivier > >> > > > > Yes, I know you are not currently advocating for it, but you've proved my > > point--others will see this go in and then they will push for it. Adding > > any form of size hints is a slipper slope which leads to more size hints > > imo. > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

I think are better handled by the client doing the resize > however, so only min/max should be sent. > > On 04/04/2016 07:20 PM, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre" > > said: > > > >> I

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

gt; - add a similar "preferable min size" request > > > > Then we can continue discussing from there. > > > > Cheers, > > Olivier > > > > > > -- > Jasper > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

; > that are absolutely required in order to create a usable desktop > > environment. > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

it becoming universal - plan for xdg. if you want to keep it private or experiment locally- make it a separate protocol. > > ... you might be surprised. 4k ones are already out there. ok . not 1.3ghz - > > 2ghz - but no way you can capture even 4k with the highest end arms unless > >

Re: Collaboration on standard Wayland protocol extensions

tands the other position. It's not > > > hard to reach a compromise on this. > > > > it's sad that we have to have this disagreement at all. :) go on. join the > > dark side! :) we have cookies! > > Never! I want my GTK apps and my Qt apps to have the s

Re: Collaboration on standard Wayland protocol extensions

7;m doing it now, and I want > your input on it. Provide feedback now and implement later if you need > to, but if you don't then the protocols won't meet your needs. > > > let me complicate it for you. let's say i'm playing a video fullscreen. you > > now have to convert argb to yuv then encode when it would have been far more > > efficient to get access directly to the yuv buffer before it was even > > scaled to screen size... :) so you have just specified a protocol that is > > by design inefficient when it could be more efficient. > > What, do you expect to tell libavcodec to switch pixel formats > mid-recording? No one is recording their screen all the time. Yeah, you > might hit performance issues. So be it. It may not be ideal but it'll > likely be well within the limits of reason. you'll appreciate what i'm getting at next time you have to do 4k ... or 8k video and screencast/capture that. :) and have to do miracast... on a 1.3ghz arm device :) > > yes - but when, how often and via what mechanisms pixels get there is a very > > delicate thing. > > And yet you still need to convert the entire screen to a frame and feed > it into an encoder, no matter what. Feed the frame to a client instead. is the screen a single frame or multiple pieced together by scanout hw layers? :) what is your protcol/interface to the "screen stream". if you have it be a simple "single buffer" then you are going to soon enough run into issues. :) > > so far we don't exactly have a lot of inter-desktop co-operation happening. > > it's pretty much everyone for themselves except for a smallish core > > protocol. > > Which is ridiculous. > > > do NOT try and solve security sensitive AND performance sensitive AND design > > limiting/dictating things first and definitely don't do it without everyone > > on the same page. > > I'm here to get everyone on the same page. Get on it. let's work on the things we do have in common first. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

ow have to convert argb to yuv then encode when it would have been far more efficient to get access directly to the yuv buffer before it was even scaled to screen size... :) so you have just specified a protocol that is by design inefficient when it could be more efficient. > > there's a d

Re: Collaboration on standard Wayland protocol extensions

render when > > the client wants? this can have all kinds of nasty effects in the rendering > > pipeline - for use our rendering pipeline iss not in the compositor but via > > the same libraries clients use so altering this pipeline affects regular > > apps as well as compo

Re: Collaboration on standard Wayland protocol extensions

rms :) > -- > Drew DeVault > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am"

Re: Introduction and updates from NVIDIA

not, regardless of the compositor (consumer) decisions. adapting to become more efficient is far more than a stream of 1 surface and a stream of buffers. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EFL/Wayland and xdg-shell

t;> without proper testcases, and we're also relying on clients to not > >> hold our entire display pipeline hostage, so we'd need some kind of > >> arbitrary timeout too I guess. It is entirely doable, but the > >> complexity makes me think that this would

Re: EFL/Wayland and xdg-shell

sy it'd be to implement. > >> > >> This is stuff I would hope would be provided and implemented by the > >> DE. As a multimonitor user who quite often watches things on one > >> monitor while coding on another, I'd turn this feature off. > > > >

Re: EFL/Wayland and xdg-shell

op'. > > xdg-shell should be seen as the proper shell protocol everybody should > strive to support. It's entirely possible that DEs have their own > protocols they put on top: GTK+ has gtk-shell, for instance. we also will likely extend too with some e-shell as it means we can prototype and implement new features rapidly, and then consider bringing them up for standardization in xdg-shell. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EFL/Wayland and xdg-shell

gt; sounded straightforward and like it could be useful to investigate more. > > I'd like to see FITS revived, or the better bits of it moved into > Weston's test suite. Protocol dumps aren't particularly useful as > they're very dependent on things l

Re: libinput: Support for long press key detection?

On Mon, 27 Oct 2014 11:16:16 -0700 Bill Spitzak said: > On 10/26/2014 05:35 AM, Carsten Haitzler (The Rasterman) wrote: > > > to implement longpress you need to implement timeouts - this is where it > > begins getting high level and far more hairy than libinput is. toolkits &

Re: libinput: Support for long press key detection?

On Sun, 26 Oct 2014 13:10:43 +0100 Stefanie Behme said: > Am 21.10.2014 um 21:03 schrieb Carsten Haitzler (The Rasterman): > > On Tue, 21 Oct 2014 20:21:26 +0200 Stefanie Behme > > said: > > > >> Hi, > >> > >> on last ELCE in Duesseldorf I l

Re: libinput: Support for long press key detection?

ind of long press detection? How > could this look like? Any ideas? can you explain why this needs or should be done at the libinput level and not in the app/toolkit where it already is handled (at least in some toolkits). -- --------- Codito, ergo sum - "I code, therefore I

Re: [Help]Question about graphics architecture for weson/wayland

; > > Oh, so this was your real question. > > > > If you have a DRM kernel driver supporting KMS, use Weston's drm-backend > > but pass --use-pixman on the command line. > > > > If you do not have a DRM driver, but you do have /dev/fb0, use Weston's &g

Re: [Help]Question about graphics architecture for weson/wayland

are (Pixman) > > > > renderer. That will not use the GPU either, but does need DRM and KMS. > > > > > > > > > 4.Does GPU kernel drvier consist of kernel/driver/gpu/xxxx(.ko??) > > > > > and of kernel/d

Re: [Help]Question about graphics architecture for weson/wayland

/gpu/drm/(DRM_.ko)? > > > > Roughly yes. > > > > > 5.Does user side drvier consist of EGL/OpenGLES? > > > > The user space side of the driver usually implements EGL and OpenGL > > (desktop/ES/whatever). > > > > > 6.grap

Re: [Interest] qt5 window setGeometry and move not work in wayland platform

th events (whenever a window > >> appears or disappears on an output). > >> > >> This is not 100% thought through, but maybe a starting point. > >> > >> > >> > >> ___ > >> wayland-devel maili

Re: [Question] Z-order management in Wayland

On Thu, 31 Jul 2014 15:44:40 -0700 Bill Spitzak said: > On 07/31/2014 03:21 PM, Carsten Haitzler (The Rasterman) wrote: > > >> Wait a second, how is click-to-raise being done? > > > > not by the client - by the compositor. the client has no control over that. > &g

  1   2   >