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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

have to. Kwin guys disagreed but they couldn'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 -

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

edesktop.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: Remote Desktop with Wayland

d, I 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 believe the functionality

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

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 just do so with keyboard input too? why not so this everywhere and just have an fd per input dev

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

t 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, theref

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

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

+ will provide 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 surface. In that case, > + the surface is null. > + > +

Re: [RFC wayland] move away from C

On Sat, 1 Apr 2017 09:41:51 -0500 Derek Foreman <der...@osg.samsung.com> said: > On 01/04/17 09:24 AM, Carsten Haitzler (The Rasterman) wrote: > > On Sat, 1 Apr 2017 14:03:21 +0100 Auke Booij <a...@tulcod.com> said: > > > >> The C programming lang

Re: [RFC wayland] move away from C

On Sat, 1 Apr 2017 09:41:51 -0500 Derek Foreman <der...@osg.samsung.com> said: > On 01/04/17 09:24 AM, Carsten Haitzler (The Rasterman) wrote: > > On Sat, 1 Apr 2017 14:03:21 +0100 Auke Booij <a...@tulcod.com> said: > > > >> The C programming lang

Re: [RFC wayland] move away from C

.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] Interface for injection of input events

cess in other 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 <ppaala...@gmail.com> said: > On Tue, 28 Mar 2017 16:20:28 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <

Re: [RFC] Interface for injection of input events

e 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. > > So 99% of the work here would be to define the interface and get everyone to > agree on it. agreed on this. > Any comments or suggestions? &g

Re: [RFC] Interface for injection of input events

curity has 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?

o 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 Rasterman (Carsten Haitzler)ra

Re: [RFC wayland-protocols] Color management protocol

On Sat, 14 Jan 2017 11:52:25 +0100 Kai-Uwe <ku.b-l...@gmx.de> said: > Am 14.01.2017 um 03:24 schrieb Carsten Haitzler (The Rasterman): > > On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen <ppaala...@gmail.com> > > said: > >> Oh, ok, that's why. We coul

Re: [RFC wayland-protocols] Color management protocol

for a spin. > >>> (Another 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/pr

Re: [RFC wayland-protocols] Color management protocol

h 32bit ints per rgb etc. to say "display this exact uncalibrated color as-is without luts or anything else in the way"... but apply it to a separate toplevel window/surface (and put your guided ui controls in another window) or... use a subsurface. -- - 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] Add the color-management protocol

m or desktop chooses your 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 Raster

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

is means that, in order to get > colour-correct rendering through EGL, you either have to have it > 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 thing

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

GL. Given that people will want to do (at least vaguely) > colour-correct GL rendering, 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, the

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

On Tue, 20 Dec 2016 18:25:40 +1100 Graeme Gill <grae...@argyllcms.com> 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 a

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

summary="the passed icc data is invalid" /> > > > + > > > + > > > + > > > + > > > + > > > + This interface represents a color space that can be attached to > > > surfaces. > > > + It is used

Re: [RFC wayland-protocols] Color management protocol

ppings to do exact 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)ras.

Re: [RFC wayland-protocols] Color management protocol

On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill <grae...@argyllcms.com> said: > Carsten Haitzler (The Rasterman) wrote: > > On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill <grae...@argyllcms.com> > > said: > > > a display may not have a single native color

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

file > +descriptor to the ICC profile data of this colorspace. > + > + > + > + > + > +This event occurs after a get_profile_fd request and returns the file > +descriptor to the ICC profile data of this colorspace. > + > + > + > + > + > -- > 2.10.2 > > ___ > 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

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

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

but it's kind of 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 (Carst

Re: [RFC wayland-protocols] Color management protocol

On Wed, 14 Dec 2016 23:23:59 +1100 Graeme Gill <grae...@argyllcms.com> said: > Carsten Haitzler (The Rasterman) wrote: > > On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill <grae...@argyllcms.com> said: > > > this == support for color correction protocol AND actually

Re: [RFC wayland-protocols] Color management protocol

On Wed, 14 Dec 2016 18:49:14 +1100 Graeme Gill <grae...@argyllcms.com> said: > Carsten Haitzler (The Rasterman) wrote: > > On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill <grae...@argyllcms.com> said: > > >> Right. So a protocol for querying the profile of

Re: [RFC wayland-protocols] Color management protocol

On Wed, 14 Dec 2016 18:27:13 +1100 Graeme Gill <grae...@argyllcms.com> said: > Carsten Haitzler (The Rasterman) wrote: > > On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill <grae...@argyllcms.com> said: > > >> The correct approach to avoiding such issues is simply

Re: [RFC wayland-protocols] Color management protocol

On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill <grae...@argyllcms.com> said: > Carsten Haitzler (The Rasterman) wrote: > > On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill <grae...@argyllcms.com> said: > > >> I thought I'd explained this in the previous

Re: [RFC wayland-protocols] Color management protocol

On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill <grae...@argyllcms.com> 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

Re: [RFC wayland-protocols] Color management protocol

rested 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

at. either compositor 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 cod

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

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

t wl_closure *closure; > > struct wl_object *object = >object; > > > > + verify_objects(resource, opcode, args); > > closure = wl_closure_marshal(object, opcode, args, > > >interface->events[opcode])

Re: [RFC wayland-protocols] Color management protocol

On Fri, 09 Dec 2016 14:06:46 +0100 Niels Ole Salscheider <niels_...@salscheider-online.de> said: > Am Freitag, 9. Dezember 2016, 12:02:07 CET schrieb Carsten Haitzler: > > On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill <grae...@argyllcms.com> said: > > > Carsten

Re: [RFC wayland-protocols] Color management protocol

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

Re: [RFC wayland-protocols] Color management protocol

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

On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill <grae...@argyllcms.com> 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

Re: [RFC wayland-protocols] Color management protocol

ps need to query for 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 Hai

Re: Kinetic scroll in libinput Xorg driver

> you won't get stop events for wheel events, so any 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: Hello!

dit your Subject line so it is more specific > 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 drive

Re: Kinetic scroll in libinput Xorg driver

nd things looked 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 Haitz

Re: Kinetic scroll in libinput Xorg driver

; 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

Re: Kinetic scroll in libinput Xorg driver

d hack this > > in at the > > 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

Re: Kinetic scroll in libinput Xorg driver

t. 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" -- The Rasterman (Carsten H

Re: Weston does not do transparent backgrounds

ct the alpha. > > > > > > > > > > Any update or direction, Could you please suggest... > > > > > > > > Hi, > > > > > > > > I can't say if that will help, that kind of use case was never > > > > intended. What will h

Re: [PATCH] Introduce keyboard grabbing protocol

uences. 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? :) -- - Codito, ergo sum -

Re: Weston does not do transparent backgrounds

the alpha channel because Xwayland > > surfaces used 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) <ras...@rasterman.com> said: > On Fri, 5 Aug 2016 07:45:50 -0500 Derek Foreman <der...@osg.samsung.com> said: > > > On 27/07/16 02:54 AM, Jonas Ådahl wrote: > > > xdg-foreign is a protocol meant t

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

> to > > + import the surface by calling xdg_importer.import. A handle may be > > + used to import the surface multiple times. > > + > > + > > + > > + > > + > > + > > + > > + > > + A xdg_imported o

Re: Weston on framebuffer?

On Wed, 20 Jul 2016 21:49:57 +0200 Christer Weinigel <chris...@weinigel.se> 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 o

Re: Weston on framebuffer?

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

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

_geometry). > > > > Then 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 Raste

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

t'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. Addin

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

s. > Both of these 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" > > <jstpie...@

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

upposed to be just a small core set of features > > 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

. you keep things in yuv space and drop your bandwidth > > requirements hugely. in fact you never leave yuv space and make use of the > > hw layers and the video decoder decodes directly into scanout buffers. you > > MAY be able to stuff the yuv buffers back into an encoder and re-encode >

Re: Collaboration on standard Wayland protocol extensions

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 nex

Re: Collaboration on standard Wayland protocol extensions

ave 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

res, regardless of who's doing it. At some point you're going to > have to get the pixels you're rendering and hand them off to someone, be > that libavcodec or a privledged client. yes - but when, how often and via what mechanisms pixels get there is a very delicate thing. > > > We can make Wayland support use-cases that are important to our users or > > > we can watch them stay on xorg perpetually and end up maintaining two > > > graphical stacks forever. > > > > priorities. there are other issues that should be solved first before > > worrying about the pandoras box ones. > > These are not pandora's box. These are small, necessary features. i disagree. i've been doing graphics for long enough to smell the nasties from a mile off. it's not trivial. the decisions that are made now will haunt us for a lifetime. they are not internal details that can be fixed easily. even internal details are hard to fix once enough code relies on them... 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. 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. -- - 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

; ___ > 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 Ras

Re: Introduction and updates from NVIDIA

ecome 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

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

bringing them up for standardization in xdg-shell. This is definitely the right thing to do. that is the plan. once we get there, it'll be time to come back with them. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras

Re: EFL/Wayland and xdg-shell

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

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

Re: libinput: Support for long press key detection?

On Mon, 27 Oct 2014 11:16:16 -0700 Bill Spitzak spit...@gmail.com 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 already

Re: libinput: Support for long press key detection?

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

Re: libinput: Support for long press key detection?

? 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 am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com

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

fbdev-backend. Thanks, pq -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel

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

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

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

-- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel

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

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

Re: [Question] Z-order management in Wayland

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

Re: [Question] Z-order management in Wayland

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

Re: [Question] Z-order management in Wayland

On Thu, 31 Jul 2014 15:44:40 -0700 Bill Spitzak spit...@gmail.com 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. That does not work

Re: Wayland API to get the id of focus window [Seema Singh]

it. :) -- - 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: Wayland API to get the id of focus window [Seema Singh]

cleanliness of design. so maybe you should first explain what you are doing, where and why, and then... we can figure out what to do about it. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com