Re: Current state of Window Decorations

[The Rasterman]

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 area?  eg: what happens if you use a drawing library
> > (cairo/skia whatever) for the decorations but then want to embed opengl
> > content for example.
> 
> Hi,
> 
> while it may be attractive to use one surface for your content and
> several (sub-)surfaces for the decorations, I believe it can cause
> "seams" to become visible if the compositor is doing anything else than
> showing the pixels 1:1, e.g. fractional scaling, zoom, tilted windows (a
> gimmick in Weston, freedom to arbitrarily rotate windows). It is hard to
> do bilinear sampling across multiple textures, so it is likely the
> adjacent edges of two surfaces are not blended perfectly by a
> compositor. Whether that actually disturbs users or not depends on what
> is being show and how. Maybe it's not a big concern.

well.. in this case to do this right the compositor is forced to first
pre-render all the subsurfaces to an fbo (for example) THEN take that FBO and do
whatever scaling/stretching/manipulation to it. so it is possible to get it
right on the compositor side, but it'll basically make things less efficient
than the client-side doing this already and handling buffer age for partial
updates right which means most of the time it'll never update the frame areas
anyway.

> If you use one big surface for decorations behind the main content, you
> obviously waste the memory in the decorations buffer occluded by the
> main content. Hence piecing together decorations from four small
> surfaces.
> 
> My personal opinion favours blitting decorations into the main surface.
> With OpenGL it's not a problem per se, but the toolkit API you expose
> might make it difficult if the premise is that the user can own "the
> full surface" with OpenGL directly.
> 
> If your main content comes from a video decoder or a camera, it may be
> best to use sub-surface(s). Blitting into a video frame might not work
> too well. Not having to copy the video content is the main intended use
> case for sub-surfaces.
> 
> 
> Thanks,
> pq


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[The Rasterman]

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 makes it almost
> worthless.

It's a different world. There isnt a single entity (Microsoft for Windows,
Apple for OSX) telling you how to look, draw and do something. It is fragmented
due to history and that's just something that has to be accepted.

There will always be a very small number of toolkits that have to do this so
the audience to appease here is very small.

> Seems odd to offload this responsibility to every toolkit without providing
> a mechanism to achieve any consistency.  Or... is this just my background
> in Windows/OSX where consistency in these areas is really encouraged and
> this just isn't expected on Linux?

You already gave up consistency with > 1 toolkit. Buttons, scrollbars,
sliders, even font rendering etc. etc. will all vary between them. They all
need separate themes/configuration to even begin to get any consistency and
that's not including behaviour (right click menu in entries, scrollbar and
wheel behaviour e.g. no accel with wheel vs accel, smooth or jump scrolling, and
so on). 

> 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 area?  eg: what happens if you use a drawing library
> (cairo/skia whatever) for the decorations but then want to embed opengl
> content for example.
> 
> Brad
> 
> On Thu, Jun 25, 2020 at 6:25 PM Pekka Paalanen  wrote:
> 
> > On Thu, 25 Jun 2020 11:57:42 +1000
> > Brad Robinson  wrote:
> >
> > > Hey All,
> > >
> > > What's the current state and/or plans for window decorations with
> > Wayland?
> > >
> > > I just stumbled on this post
> > > <
> > https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
> > >,
> > > and after reading the comments I've got to say I'm quite shocked that
> > > getting a window to appear on screen with title bars and decorations that
> > > match the rest of the OS appears to be a non-trivial task.
> > >
> > > Am I missing something? Have things changed since that post was written?
> >
> > Hi,
> >
> > I don't think you're missing much.
> >
> > Without specific Wayland extensions saying otherwise, clients either
> > decorate themselves or live without decorations. I believe the state of
> > the art is:
> >
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/master/unstable/xdg-decoration
> >
> > I wouldn't say that the fact that Wayland extensions exist for
> > server-side decorations means that a Wayland client would be right to
> > not implement client-side decorations. Any compositor likely does not
> > implement all the extensions ever defined or even in wayland-protocols
> > repository, so clients should have fallbacks. However, it is up to you
> > as a developer to decide which fallbacks you implement and which you do
> > not. Obviously that will affect your user experience on compositors
> > where the fallback would be necessary but you didn't implement it.
> >
> > Unfortunately we don't have the wayland-protocols adoption website up
> > yet, where you could see which compositors and toolkits support which
> > extensions. Weston does not support the extension, but I would assume
> > some other compositors do.
> >
> > There are good justifications for both client-side and server-side
> > decorations. Which one is better depends on your goals and policies,
> > and what you value more, which is why the question raises so much heat
> > that few people like to talk about it much as it nearly always
> > escalates to a flame war when more people join the discussion.
> >
> > For example, for some, "match the rest of the OS" is a non-goal, and
> > making the app itself look consistent is a goal. For others, it's the
> > opposite. Will the application always look and feel the same no matter
> > in what environment you run it in, or should it change itself according
> > to the environment. How do you make the user feel at home? There is a
> > lot more to it than just decorations.
> >
> >
> > Thanks,
> > pq
> >


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[The Rasterman]

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 comments I've got to say I'm quite shocked that
> getting a window to appear on screen with title bars and decorations that
> match the rest of the OS appears to be a non-trivial task.
> 
> Am I missing something? Have things changed since that post was written?

That's how it is. Correct. The point is that clients draw their own decorations
and handle events on them to initiate actions (like begin a move or resize or
close/exit etc.).

The position (for Wayland) has always been "that's the job of a toolkit and apps
will 99% of the time not know or care as the toolkit takes care of it". The
major toolkits all do take care of it and do client side decorations, so it's
a solved problem. It's necessary as there is no guarantee that a compositor will
support any server-side decorations. Unfortunately as you are making a toolkit,
this now is part of your problem-set to address.

I was initially not happy with the client side decoration position of Wayland
but I've come around and I think its definitely the better path for both
consistency (frames match the content now rather than clash), simple "every
frame is perfect" handling (otherwise you end up with complex synronization
protocols to sync rendered content of of the frame and content so they match on
every frame) and efficiency (you can get more screen content to live in
hardware layers to have zero-copy/composite updates of application content,
given that hardware layers are often a scarce resource).

I don't think there is much point in the "have decorations match" line of
thought because move a few pixels further into the app and the content is not
going to match anyway, unless you spend a lot of effort trying to match.
Given the fragmented state of toolkits anyway there is fairly little point, so
I would take the direction of "extend your view of the toolkit to also
design/define the titlebar and other border elements, shadows etc. and ensure
all of that can have a consistent matching look with the content of the window
with some simpler external control points to do things like perhaps select a
base and hilight etc. color if possible so you can later color-match at least".

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Best practices for client side buffer management

[The Rasterman]

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 regions needed updating and it can do "just re-render a
blinking cursor" region without a full buffer render. you just needs to handle
a set of buffers and partial updates properly. it can also be done with opengl
(using the  buffer age extension and also hinting to the compositor/display
system which regions changed with swap with damage regions too, but it's the
same idea as with software rendering so i'll just cover software).

so you keep a set of buffers. A, B, C. at a minimum A and B, but ABC is the
best.

you fully render A, then display it. you then render all of B and display, then
all of C and display. you now have 3 fully rendered buffers. you will be in a
steady state like this through 99.999% of the life of a window (unless it
resizes where we begin with a new set of buffers, or we do fun things like
drop all buffers but the visible one to compact memory usage).

from now on, let us call the set of rectangles that define the regions rendered
as Ar, Br and Cr per buffer. every time we need to render a frame we are doing
frames in order ABCABCABCABCA... etc.

that means we have the calculated "these areas need updating" ArBrCrArBrCr...
etc. ..

so those are the regions you actually calculate to ne re-rendered. it's the
minimum update area to cover changes. to do this right though you have to
actually over-render. so let us call the set of rects that you REALLY render
and tell the compositor you updated as u. so we have AuBuCuAuBuCu... let us say
+ is the UNION of 2 rect regions.

current u == current r + previous r + previous - 1 r.

so: Cu = Cr + Br + Ar
then next frame is A again: Au = Ar + Cr + Br
then: Br = Br + Ar + Cr

etc

you keep a sliding window of the last 2 frames with of rect regions you union
(merge with) the current frame's update rects... then render that. you can play
tricks like copy back some regions from a previous frame instead of
re-rendering them (as it's a read from, not a write to that buffer it's safe..
but beware that readbacks may have issues especially if regions are not mapped
as non-cachable because they are being scanned out/displayed for example. it
depends on hardware entirely so the safe thing is to their shadow them and make
a copy before you display or just re-render them. it turns out the just
re-render is simpler to do and generally performant).

so basically you need to start thinking of a ring of buffers and managing
those and tracking updates over multiple frames... then you can happily do
fairly minimal "only update this region" drawing. i've been doing this for
many years .. even in X11. it's not a wayland specific thing. you will HAVE
to do this if you want to do partial updates with acceleration like with
opengl :) it works...

this all removes the need for copies and allows zero-copy minimum region
partial updates. :)

p.s.  reason for 3 buffers is to allow for the compositor having not released
the current front buffer yet. compositor can hold onto its buffer. you can have
already sent/submitted a new buffer that's waiting on the compositor to notice
and pick up, and in the meantime you still have a 3rd buffer you can prepare
another frame on while the one in flight arrives and the compositor releases
what it has.

you will need to come up with solutions for if you render this, submit it then
the compositor is still hanging onto its buffer now with 2 in flight. at this
point you can block or "defer" the frame until the 3rd buffer is released, or
perhaps just don't submit a new buffer until the first buffer was released.
then you can just render AGAIN to the 3rd buffer that you have not sent yet,
updating it and now you only render the partial update regions on this one
since the last frame... keep going until compositor releases the first buffer.

i prefer the first method of "defer the rendering and don't render anything
until we get the in-flight buffer to the compositor AND it releases the current
one as this avoids getting too far ahead of the compositor and avoids rendering
possibly useless frames that will never be displayed because the compositor is
having a hiccup and blocking for a few hundred ms - on a heavily loaded system
either cpu or gpu wise its better to back off and not just render more frames
and give things space to get past the spike of work. using the frame requests
from the compositor is a way of this all working out well as compositor calls
you saying "i need a new frame now" and this serves as a kind of throttling in
these cases anyway.

> Hi All,
> 
> @Guillermo: yep, that's exactly the same problem I'm thinking about.
> 
> I had an idea that I'm wondering about  the rendering model in my
> toolkit is essentially the 

Re: Best practices for client side buffer management

[The Rasterman]

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
> management.
> 
> Firstly, this is how I'm allocating the backing memory for client side
> buffer pools.  This is C# p-invoking to libc, and basically it's using
> mkstemp() to get a temp file, ftruncate() to set its length, mmap() to map
> it and then unlink() once mapped so temp files aren't left behind.  Any
> issues with this approach?
> 
> // Get temp file
> var sb = new
> StringBuilder(System.IO.Path.Join(System.IO.Path.GetTempPath(),
> "mmXX"));
> int fd = mkstemp(sb);
> ftruncate(fd, (ulong)capacity);

i assume GetTempPath() will be looking at /tmp ... and /tmp may not be a
ramdisk. it may be a real disk... in which case your buffers may be getting
written to an actual disk. don't use /tmp.

you might wan to to loop at shm_open or memfd or libdrm for specific drivr
allocation calls like drm_intel_bo_alloc_tiled, drm_intel_bo_map/unmap etc. the
latter libdrm ones wo9uld allow your buffers to possibly be scanned out
directly to the screen or used as textures directly without copies, but will
need careful handling, so do this only as an advanced step.

> // Map it
> var addr = mmap(IntPtr.Zero, (ulong)capacity, Prot.Read |
> Prot.Write, Map.Shared, fd, 0);
> 
> // Unlink it (so temp files not left behind)
> unlink(sb.ToString());
> 
> Secondly I'm wondering about practical strategies for managing client side
> buffers.  The toolkit in question basically needs arbitrarily sized buffers
> to render whatever size the window happens to be.  Seems like to use a
> buffer pool for this would require some sort of heap manager to manage
> what's in each pool.  I'm wondering if there's any recommendations or best
> practices for how to deal with this.  eg: create one big pool and
> explicitly manage what's in there as a heap, use lots of little pools with
> one buffer in each, a combination of both, something else?

resizes of windows are less common (in general) than rendering to them. here
i'd go for a scheme of N buffers in a ring per window. so you have buffers A,
B, C and you first render to A then display it, then next frame B, then C, then
A, then B, then C. You could get away without C. as the buffers retain their
state you can take advantage of this and only partially render part of a
buffer for updates "since 1 or 2 frames ago" (depending if you do double or
triple buffering). as its predictable ABCABCABC you can just keep a "Sliding
window of the update regions of the past N frames" and merge those into the
"current amount to update" but always store per-frame update rectangle regions
before this merge-at-render-time. 3 buffers allows you to be rendering a 3rd
buffer while 1 buffer is queued to be displayed and one is still being
displayed. if you find you need a 4th buffer, perhaps just overdraw the 3rd on
you just did and "update it" ... or just block or don't update yet as you are
getting too far ahead of the compositor.

> Finally, the toolkit already maintains an off-screen buffer with the
> window's current contents rendered into it.  I'll probably replace that
> with a Wayland buffer, but wondering about partial updates.  eg: if the
> client only needs to redraw a part of the window what's the correct process
> to update just that part with Wayland.  Can I just update the existing
> buffer and prompt Wayland to just redraw that part?

no. never do that. always have more than 1 and update a buffer that is not
being displayed or queued to be displayed. the above sliding window allows your
partial rendering to work as you can depend on previous content still being
there where you left it from N frames ago.

> Any advice appreciated...
> 
> Brad


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Best practices for saving and restoring window layout

[The Rasterman]

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 positioning when using
> > Wayland as the backend.
> > 
> > I've read through the posts on this list's archive about window positioning
> > and it's clear that a global coordinate system isn't something that Wayland
> > supports - fair enough and I understand the reasons why.
> > 
> > However, I'm wondering what the recommendations are for applications with
> > complicated user-controllable layouts that need to be persisted not only
> > across application runs, but also between documents and across application
> > modes.
> > 
> > For example:
> > 
> > * my application is a music app where the user might have many plugin
> > windows carefully positioned across multiple monitors.
> > * each document file has a different set of plugins loaded and those plugin
> > windows need to be restored to their previous location.
> > * the app can be in "Live" mode or "Edit" mode and switching between modes
> > saves and restores the plugin window locations for each mode.
> > 
> > How should such an app be handled under Wayland?
> > 
> > Note: the app doesn't need to be able to explicitly position windows. It
> > just needs a way to capture and restore a window's position.  An opaque
> > string or data structure that the app can save and use to later reposition
> > a window back to that same place would be perfect.  It would need to be
> > client persistable though - eg: giving a window an id that the window
> > manager can use to store previous geometry probably wouldn't suffice.
> 
> Hi,
> 
> I believe the above is the consensus: ask the server to give you a
> token that records the current state, including position, of the
> window. You store the token, or any number of tokens. When you want to
> recall old state, you pass the token back to the compositor.
> 
> The problem is that I don't remember seeing an extension spec for this.
> It has been talked about, sure, but at least wayland-protocols does not
> seem to have anything for it.

https://git.enlightenment.org/core/enlightenment.git/tree/src/protocol/session-recovery.xml

we have one... already supported in efl too. we use it for recovery across
restarts of the compositor (app doesn't exit when it loses its wl connection -
ti hangs around trying to reconnect every now and again then when it reconnects
it provides this uuid - it could be used for much more).

the xml isn't totally clear... but the compositor creates the uuid and sends it
to the client per surface. clients when recovering set the uuid on a surface so
the compositor can match it up, otherwise they do a get of the uuid. on a clean
shutdown of a window that is not to be recovered they destroy the uuid. you
could destroy it right after successful restoration too.

the compositor then handles restoring state for that uuid (knowing
position/size/virtual desktop and so on).

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

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 like
> >> that already existing? Is there anything that has prevented to do this
> >> before?
> > So you want this to only happen when middle-clicking in the titlebar? Then
> > it does require the client to deal with it as only it knows precisely the
> > things in a titlebar that are the titlebar (and not other buttons too like
> > close and what not, and tyring to expose all of this to the compositor to
> > deal with just is endlessly complex).
> That's why I was thinking that there should be a protocol to let clients 
> know where the titlebar area is. Reading past mails, I believe this 
> should allow the titlebar to be non rectangular. I saw that there was an 
> idea of a mask the client sends to the server. Was it rejected for some 
> reason or was it just never implemented?

It's far too complex. People would like to be able to keep compositors really
simple if they can. It also disallows dynamic decisions based on the state and
input at the time. It requires continual updates of this list of rectangles...
when it is possible to do it client side. If it is possible to do client-side,
leave it client-side.

> > So what you need really is clients deal with this. That means every toolkit
> > and/or app will have to follow suit and do it too.
> This is the other solution, but how do all the clients know it's middle 
> click to lower? How do they know it's not middle-click and not 
> double-click? How do they know it's lower and not to minimize or 
> maximize? We can't reasonably ask every wayland client to look at GNOME 
> configuration files (and every other window manager for that matter).

They already don't know what double-click is... or mouse wheel on title etc. -
nothing new. Expect all toolkits/clients to disagree here. On one hand forcing
them to do the same thing limits freedom. E.g. I'd want to make double click
shade the window (next-like roll up into the titlebar) and wheel up.down
shade/unshade. Toolkits are already free to disagree what a mouse wheel does
when scrolled over a scrollable area. They do slightly different things. They
already can disagree on what happens with scrollbars. They can already
disagree with tab/shift tab navigation (e.g. EFL does tab/shift tab but also
down up/down/left/right in addition). This argument always appears. What is one
toolkit wants close button on top-left? Or one desktop insists titlebars are to
be at the bottom of windows? Shall everyone then implement every possible UI/UX
decision a WM/compositor wants?

If I were to tell Gnome and KDE they must now implement shading into the
titlebar on double-click in CSD because I want to do this they will probably
tell me to get lost as it's yet more work to do and it's "not popular". Just as
much as I would say "But double-click shades the window, not maximizes it. It
has done so for me since like 1996/7 or so and still does.". :) Pushing policy
at clients from the compositor is going to end up with push-back and already is
inconsistent in so many other areas so you'll never solve it with some protocol
you might be able to address one specific thing, but then there are still 8439
others you won't solve... :)

> > If you want middle-mouse anywhere to do this (like alt+left mouse drag is
> > seconded anywhere to move a window). then the compositor can do this with
> > clients being ignorant of it happening.
> We can't just steal every middle-click everywhere on the window. It has 
> to be on the title bar.

You can... alt+left click is generally stolen on all windows already as a handy
mov-the-window. A compositor CAN steal whatever events it likes... :) I leave
it up to user config and bindings to decide what it steals or not. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

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 click like on X11. The performance getting better and better (and 
> with the realtime option enabled in mutter) I decided to scratch my itch 
> and implement lowering in waylang for Gtk client-side decorations.
> 
> My work is implemented as an upgrade to the gtk-shell protocol:
> 
> - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1221
> 
> - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1821
> 
> It works, but I do not like how it works and the fact that it's Gtk 
> specific (although other toolkits could implement the gtk protocol). 
> Also, I don't like that it's the client that should look up the window 
> manager configuration to know that middle clicking means lowering the 
> window. It's up to the compositor to map the middle click to lower and 
> not the client.
> 
> So I'm asking it here, what would be the wayland solution for a 
> cross-toolkit and cross-environment solution?
> 
> I suppose that the client can declare the title bar area, and the 
> compositor can then handle clicks in this area. is there something like 
> that already existing? Is there anything that has prevented to do this 
> before?

So you want this to only happen when middle-clicking in the titlebar? Then it
does require the client to deal with it as only it knows precisely the things
in a titlebar that are the titlebar (and not other buttons too like close and
what not, and tyring to expose all of this to the compositor to deal with
just is endlessly complex).

So what you need really is clients deal with this. That means every toolkit
and/or app will have to follow suit and do it too.

If you want middle-mouse anywhere to do this (like alt+left mouse drag is
seconded anywhere to move a window). then the compositor can do this with
clients being ignorant of it happening.

> Thank you,
> 
> Mildred
> 
> 
> ___
> 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" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Chrome Remote Desktop and Wayland

[The Rasterman]

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 returned to the compositor. I don't know
> > if there is any compositor that can already handle continuing it's
> > session headless with an active PipeWire stream.
> 
> Ideally, (though not a strict requirement for us), there'd also be a
> way to specify the resolution of the offscreen virtual display (to
> match the resolution of the client) without modifying the modes used
> locally once the session is switched back to the local display(s).
> 
> [snip]
> > More or less, yes. Launching sessions without DRM master and going
> > headless is probably things we can add capability fields for in the
> > session .desktop files, and show dialogs like "Wait" or "Terminate
> > session" if a conflict appears (as mentioned in the linked GDM bug). All
> > of this would also not need be specific to a certain windowing system,
> > so that you we can use the same APIs for handling both Wayland sessions,
> > X11 sessions, and whatever more types that may eventually appear.
> 
> You mentioned that integration with session management makes sense to
> discuss with display manager folks. Where would be the best place to
> discuss other such potential cross-windowing system remote-desktop
> APIs like .desktop fields or headless startup?

my take is this should be a daemon like a hybrid login manager/sshd, but
instead of a text login shell, it authenticates then launches a "virtual fb"
parent compositor that sets up a wayland compositor "rendering to ram" and then
launches the actual user session as a wayland client. this will require
compositors that are compatible need to support targeting both drm/kms directly
in the tty AND as a wayland client of this compositor. this compositor would
probably use something like the wayland fullscreen shell. it would be this
compositor that encodes and transmits the compositing results over the network
as well as reading in input from the remote system. the dbus session problem
just need working around probably with another dbus session bus launched for
this session and if apps have a problem with being run multiple times with
different dbus sessions on the same system/homedir.. well.. there is nothing to
be done - it's a problem with that app. it only matters if the user is logged
in on the console and remotely and uses one of these types of apps. they can
opt to not use them or do that, or these apps get fixed.

if they want to "take over their existing console login session" the same idea
applies but this remote compositor is actually a full system-wide fullscreen
compositor and can auth some user then redirect their on screen session to be
remote (and issue appropriate monitor reconfiguring when this happens) and
replace their on-console session with a picture of a horses behind until the
remote session ends... the same daemon can do both just with the option of it
being a system-wide console compositor as opposed to "virtual, only for remote
clients" most of the code is the same/shared. then they will bypass the above
singleton problem apps by having only a single login (gui one) and single dbus
session.

the takeaway from this is more that the ecosystem at large needs to support
compositors running as wayland clients with a system compositor using a
fullscreen shell with all the appropriate logic to handle real local screens and
expose them and let the client compositor configure them, as well as doing the
"virtual rendering to memory and fake a virtual screen and modify that one (or
ones if you want multiple screens) by unplugging/plugging it with new resolution
options etc. if this system compositor is fairly lean and efficient and
essentially doesn't get in the way of real desktop compositors, then it
probably will be supported by most major compositors eventually.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

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 farm out CI to travis via gihub mirrors as it's not considered
an essential core service (unlike mailing lists, git, phabricator whch nwe
still run - we can live without CI for a while and find other ways).

The cost is the odd HDD replacement every few years and maybe every 10y or so a
new box. That's a massively lower cost than you are quoting below.

OSUOSL provide bandwidth, power, rack space etc. for free. They have been
fantastic IMHO and the whole "no fat bills" is awesome and you get a full
system to set up any way you like. You just bring the box. That should drop cost
through the floor. It will require some setup and admin though.

> Hi all,
> 
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
> 
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
> 
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
> 
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
> 
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.
> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> xorg-de...@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston screenshooter blocks the display for over a second

[The Rasterman]

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 have looked into the screenshooter client code and did some performance
> measurements, and it appears that the while(!buffer_copy_done) loop which
> calls wl_display_roundtrip takes a second to finish. Is there any way to
> make the screenshot async, to not interfere the currently displayed
> content? Or is it the way the protocol works under the hood?

If the screen is freezing entirely then it's not the client that is at fault
but the compositor, so you want to be debugging the compositor code (weston)
not the client. The client may help illustrate which requests are being sent at
that time, but it's the compositor at fault here.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: XDC allocator workshop and Wayland dmabuf hints

[The Rasterman]

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 interesting changes discussed at the allocator
> > > workshop during XDC this year, and I'd like to just summarise my
> > > thoughts on it and make sure everybody is on the same page.
> 
> Hi Scott and James,
> 
> thanks for the write-up, it all sounds good to me FWI'mW.
> 
> 
> > -As you note, this limits things to formats/layouts that can be 
> > composited (basically, things that can be textures).  "Things that can 
> > be textures" is a superset of "Things that can be scanned out" for these 
> > purposes on our HW, so that's fine for NVIDIA.  Does that hold up 
> > elsewhere?  A secondary motivation for me was that the compositor could 
> > transition back to compositing from overlay compositing without 
> > requiring a blit or a new frame from the client in cases where that 
> > didn't hold up, but I don't know if that's interesting or not.
> 
> It is interesting.
> 
> The compositor transitioning back from overlay to compositing without
> requiring a new frame from the client is a minimum requirement under
> normal circumstances in Wayland architecture. If a compositor cannot do
> that because of a buffer format, how could a conversion blit be
> possible either?
> 
> In Wayland architecture, having the compositor (display server) wait
> for any client before it is able to update the screen is unacceptable
> because it has a high risk of disturbing visual glitches.

Or it has the result of a single non-responsive client holding the compositor
hostage, unable to update the screen until that client responds. This also
would be unacceptable.

This requires there be a hardware accelerated conversion "blitter" somewhere
that is able to convert between such displayable and non displayable formats,
and/or that all such formats be clearly specified and documented and such
conversions need to be done on the CPU as a fallback.

Unless of course we're dealing with the kinds of content that are "secure" or
"encrypted" etc. with some kind of DRM (digital rights management) scheme in
place where the whole point is to have that buffer only ever displayable as a
hardware plane. In these cases The compositor can replace such buffers with a
picture of a horse to indicate that that buffer is not intended to be visible
when it has to fall back to a composited path, but it needs to know that this is
intended vs. a bug.

> OTOH, I have heard of special use cases, where all buffers should
> always go on overlays and falling back to composition would be
> considered a bug. For such cases, there are some ideas towards that at
> https://gitlab.freedesktop.org/wayland/weston/issues/244 .
> 
> 
> Thanks,
> pq


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: What can I replace X Pixmaps with?

[The Rasterman]

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
> be some ideas as well) for what I can replace X Pixmaps with(if I'm able to
> and if it's possible to do so, of course) since I'm feeling a bit stuck
> with that at the moment.
> 
> I am working on a fork of a window decorator and I want to replace X
> Pixmaps with something else(or at least, an equivalent to it) so I can make
> it less X-specific and less X-reliant (and kind-of more cross-platform,
> perhaps...? If I know what I'm talking about and if you know what I'm
> talking about, that is) for rendering window decorations.
> 
> Is there anything that I can replace X Pixmaps with? I was mainly thinking
> cairo_surfaces from Cairo(unless I'm missing the point with this or I'm
> missing the point with how Cairo is *supposed* to be used) or EGLSurfaces
> from EGL(but it sounds like it would be a bit complicated(and just a *tad*
> bit over-engineered, perhaps...?) to set up *just* for a window decorator,
> but I don't know, I just want your opinion on this), but I don't know if
> those would be suitable to use for a window decorator or not(kind-of my
> third concern about this).

It all depends on the use case. If it is meant to be displayed in a window
(surface) directly (this is the content of the window in a buffer) then you
will want wayland shm buffers or dmabufs (from drm). If it's for the purposes
of drawing/rendering which is what I think you want mostly (rendering *TO* a
target shm or dmabuf in the end), then this is totally tied to your rendering
system.

I suspect you are using X requests to do this (XCopyArea, XFillRectangle,
XFillPolygon etc.). All of these are requests for the XServer to do this work
for you remotely as a client, thus X provides pixmaps as pixel buffers/storage
objects. There is XPutImage/XShmPutImage and friends which which is about
copying data from a client to the server (or back the other way). As you are no
longer asking your display server to render this is no longer needed. It's all
local. It depends how you render locally in the end.

At the most basic: malloc() your own blobs of memory for pixel storage and write
your own code to process pixels by walking the memory and copying data from one
place in memory to another, write values in (draw rectangles, lines, copy 2D
regions breaking them into spans etc. etc.). This is by far the most portable
as then the only problem in the end is what pointer for what buffer to write
to and its dimensions. It has no dependencies beyond the final output
targets which you will need anyway. The final buffer you present in can be a
shm buffer itself, thus just another pointer like all your other memory but
the memory is obtained by creating a shared memory segment, not malloc. You can
run without a display system and target /dev/fb device you mmaped in, can
target a shm buffer you send to the xserver with XShmPutImage or just XPutImage
for the slower network capable path. You can also upload those pixels to a
texture with glTextImage/glTextSubImage etc. etc. ... the big downside being
that you have to write all your own rendering code, optimize it etc. ... you
will learn a lot in the process but it'll take a lot of time and effort.

There are many libraries out there that can do this for you in various ways and
at various levels. That is the point of toolkits. They tend to give you the
highest level APIs and hide almost all of the details so you don't need to know
or care. You can then look for the lower levels of those toolkits if you want
more control. There are a fair few to choose from.

You can use rendering libraries like cairo or drop one level down and use
pixman too. You could just use OpenGL (then learn EGL+Opengl-ES2 for best
portability - that's my suggestion if you plan on going down that path) or even
Vulkan if you want to be trendy. Note that these libraries will pretty much
then require a GPU accelerator. There are software implementations of OpenGL
rendering stacks but they tend to be rather slow compared to special hand
crafted 2D rendering code.

> Also, are there (available) replacements or substitutes or alternatives to
> using X Pixmaps that don't involve using X functions or do I have to try
> substituting X Pixmaps on my own (somehow?)
> 
> I think that's it for all of the information and all of the questions that
> I have written down and thought about(at least, for now). I've been
> thinking and wondering about this for a little while now and I hope all of
> this is clear and understandable to you.
> 
> I hope to seek a response from you soon.
> 
> Cheers,
> 
> Brandon Dowdy


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

Re: One question on wayland desing on buffer

[The Rasterman]

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 hiarchy.  however, there is something not convenient for
> wayland server. take android surfaceflinger as counterpart, surfaceflinger
> manages the buffer/layer of surface, then any client (owns the BufferQueue
> client proxy) can update the surface directly. that is, mediaserver in
> android can enqueueBuffer to update the surface directly. in wayland world, a
> mediaserver has to pass the buffer (handle) to app/UI process, then the
> surface is updated in app process.  Is my above understanding correct? 

Correct. Clients are totally isolated from each other. Client A (media server)
can't modify resources or even know client B (video player) exists VIA the
compositor. This is both for security and simplicity. This makes Wayland
compositors/servers nice and simple. They only deal with the client that owns
those surfaces/buffers and can assume that client presents precisely what it
wants to have presented. It's a "client problem" to deal with a media server if
there is such a thing, take buffers from that media server and then pass them
on to the compositor. This  makes things like synchronisation much easier as
"the client does it" and can either just draw media buffers using opengl or
whatever mechanisms itself into a single buffer of it's own, or split them out
into subsurfaces and ensure those subsurfaces and other rendered content are
syncrhonized correctly.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[The Rasterman]

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 modifying the hardware per channel LUTs.
> > (i.e. f.lux, Redshift, SunsetScreen, Iris, Night Shift, Twilight etc.)
> >
> > Such applications have their place for those who like the effect, but
> > ideally such usage would not simply blow color management away.
> 
> FWIW wlroots has a protocol for this [1]. GNOME and KDE have this feature
> directly integrated in their compositor.
> 
> > In order of desirability it would be nice to:
> >
> > 3) Have the hardware Luts restored after an application that uses them
> >exits (i.e. like OS X handles it).
> 
> Agreed. This is done in our protocol and there's no such issue when builtin in
> the compositor.
> 
> > 2) Implement virtual per channel LUTs, with the compositor combining them
> >together in some way, and have some means of the color management
> > applications being aware when the display is being interfered with by
> > another application, so that the user can be warned that the color
> > management state is invalid.
> 
> Is there a "good way" to combine multiple LUTs?
> 
> > 1) A color managed API that lets an application shift the display white
> > point using chromatic adaptation, so that such blue light filter
> > applications can operate more predictably, as well as some means of the
> > color management applications being aware of when this is happening.
> 
> How should this look like? Disclaimer: I have no idea how these applications
> work and I know nothing about color management.
> 
> I'm guessing this is a restriction of the "change the whole LUTs" API. Are
> there any features the "blue light filter" app won't be able to implement when
> switching to this API? Would the compositor part become complicated (judging
> from [2] it seems different "blue light filter" apps may compute LUTs
> differently)?
> 
> Since many compositors (GNOME, KDE, wlroots, maybe more) implement a way to
> apply a "blue light filter", I think it's important to be able to notify color
> management applications that they don't have exclusive access. Or maybe this
> should just be handled internally by the compositor? (Display a warning or
> something?)

apps should not have exclusive access. we're re-doing the whole horrid "install
colormap" thing from the x days of 256 color (or paletted/colormapped displays).

> Thanks,
> 
> [1]:
> https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-gamma-control-unstable-v1.xml
> [2]: https://github.com/jonls/redshift/blob/master/README-colorramp
> 
> --
> Simon Ser
> https://emersion.fr
> 
> ___
> 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" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland menu

[The Rasterman]

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 already. Look into
> com.canonical.AppMenu.Registrar (google for it).
> 
> This is also already implemented by at least some wayland compositors.
> (enlightenment does - optional module to load for the feature). it works in
> X11 and wayland too.

actually let me correct this - it works with xwayland and x clients. it would
need some changes to deal with wayland clients (you';d need some kind of uuid
for wl surfaces to replace the windowid used for x11).

> > Hi,
> > 
> > This isn't a concrete proposal but I think it would be nice to have
> > support for compositors implementing a menu like interface that
> > wayland clients can use. What this menu is or how it is implemented is
> > up to the compositor. The client would register an action in a tree
> > like structure and be notified when it occurs. This would allow
> > implementing for example a mac osx style compositor where the main
> > application menu is rendered outside of the window and changes
> > depending on what window has focus, or provide a more vim like
> > multimode experience with unified keybindings. I think this would help
> > toolkits like qt provide a native look and feel on wayland and
> > compositors define what a native look and feel is.
> > 
> > Regards,
> > David
> > ___
> > 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" --
> Carsten Haitzler - ras...@rasterman.com
> 
> ___
> 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" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland menu

[The Rasterman]

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 wayland compositors.
(enlightenment does - optional module to load for the feature). it works in X11
and wayland too.

> Hi,
> 
> This isn't a concrete proposal but I think it would be nice to have
> support for compositors implementing a menu like interface that
> wayland clients can use. What this menu is or how it is implemented is
> up to the compositor. The client would register an action in a tree
> like structure and be notified when it occurs. This would allow
> implementing for example a mac osx style compositor where the main
> application menu is rendered outside of the window and changes
> depending on what window has focus, or provide a more vim like
> multimode experience with unified keybindings. I think this would help
> toolkits like qt provide a native look and feel on wayland and
> compositors define what a native look and feel is.
> 
> Regards,
> David
> ___
> 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" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Use-case for CTRC background color?

[The Rasterman]

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 transparent regions of higher planes). I would like to implement
> a userspace consumer of this propery in weston.
> The primary use case for this property is for compositors to set the
> background color. I am planning on implementing it as follows:
> * The desktop client would bind to the weston-desktop-shell protocol.
> * The weston-desktop-shell would have a wrapper for the wl_output
> object.
> * The client would create a wrapper for wl_output (maybe called
> weston_desktop_shell_output).
> * This output interface will have an event to advertise its capability
> to set the background color directly.
> * Once the capability is found and if the client wishes to set the
> background color, it would use the set_background_color request in the
> weston_desktop_shell_ouput interface to set the color by providing the
> r,g,b primaries.
> 
> I have not completely thought this through, so I am sure this is
> incomplete and will require modification. I would like to know your
> comments and suggestions on the above method (or even if we could use
> this property differently) before I begin the implementation.

this smells of race conditions to me. compositor can bring up an output long
before the client has seen it yet and made a decision as to its color, so
welcome to "flicker of color" violating "every frame is perfect".

this also does not seem to synchronise with other content a compositor might put
there itself like a background image to a desktop like weston does by default
for example, or to whatever surface may be being used as a background (now
multiple clients can fight over this background color that may be different to
the background surface and its content and thus not visually match), also
violating "every frame must be perfect". background color that would fill in
areas not covered by this background image IMHO are integral to the  shell
"feel" like the and thus should be part and parcel of that and that
client/surface exclusively, or be compositor internal and no client can play
with it.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

On Thu, 7 Sep 2017 08:17:29 +0200 Joseph Burt <caseo...@gmail.com> said:

> On Thu, Sep 7, 2017 at 1:17 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> >
> > It is CSD in Wayland for Wayland clients, unless somehow compositor and
> > client negotiate something else. In the default case, if a client does not
> > decorate it will not get any decorations (titlebar and so on) at all.
> 
> IIRC that's not specified in the protocol, just what Weston does, and
> there's no negotiation protocol. Am I wrong? That might be a hole in
> Wayland, but not really related to Xwayland, so I guess off-topic
> here.

It doesn't have to be specified in the protocol. It is what every compositor
does because everyone agreed early on that CSD is the default. Weston did it
then everyone else did it. To be compatible everyone stayed the same. They 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 - "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: Why isn't Xwayland just a Wayland client?

[The Rasterman]

On Wed, 6 Sep 2017 15:49:48 +0200 Joseph Burt <caseo...@gmail.com> said:

> Hi Olivier,
> 
> On Wed, Sep 6, 2017 at 1:05 PM, Olivier Fourdan <four...@gmail.com> wrote:
> >
> > One thing to consider as well is that you will need to decorate the X11
> > windows as Wayland is basically client side decorations.
> 
> I was under the impression that Wayland doesn't specify client- or
> server-side decoration, and currently also doesn't have a protocol to

It is CSD in Wayland for Wayland clients, unless somehow compositor and client
negotiate something else. In the default case, if a client does not decorate it
will not get any decorations (titlebar and so on) at all.

> indicate which will be done, right? So that's a little sticky as it
> is, but In any case, decoration has to be done no matter what happens
> in this X11 side channel, as it does now.

Correct as the 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-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

[The Rasterman]

On Tue, 22 Aug 2017 11:00:19 +0300 Pekka Paalanen <ppaala...@gmail.com> said:

> On Fri, 18 Aug 2017 22:36:08 +0300
> Rostislav Krasny <rosti@gmail.com> wrote:
> 
> > Hi there,
> > 
> > I want to use Linux at work on my workstation PC but currently I
> > can't. The main reason is lack of useful Remote Desktop access to
> > Linux from outside. By useful Remote Desktop access I mean how it's
> > implemented in Windows. In Windows you can connect to a locally
> > started session and continue it remotely. When you do this the local
> > computer will be locked. You can go back to the local computer, unlock
> > it and take over the local session by entering your password. Also you
> > can connect to a Windows computer without any existing session and
> > this will start a new one remotely. After that you can go to that
> > computer, unlock it and continue that session locally. I need this
> > functionality to continue my work outside the office or from other
> > location in the office (a meeting room or a workplace of a colleague).
> 
> Hi,
> 
> that is a very nice description of a useful feature. I wonder if KDE,
> GNOME or Enlightenment would have something like that in their roadmap?

we currently have some bits and pieces, but not everything. eventually we do
want to offer remote access to an existing session (more likely via vnc
protocol or something more custom), but we're not there yet. still have other
things to do until we go there.

> > Today's Remote Desktop server solutions in Linux can't provide the
> > above functionality. I've tried xrdp, several implementations of VNC
> > and X2Go. None of them function as needed. They do one of the
> > following:
> > 
> > 1. Always start a new session
> > 2. Continue a locally started session in a sharing mode when the local
> > computer is not locked and anyone near it can see what I do and even
> > intervene to that session by local mouse and keyboard.
> > 
> > X2Go has even additional problem supporting different resolutions of
> > remote and local computers.
> > 
> > As far as I know you've also added the RDP support into the Weston
> > compositor. Do you support the Windows Remote Desktop functionality as
> > described above or this functionality should be implemented by a
> > higher layer that uses Weston? Or what other project (that uses
> > Wayland) should I ask about this?
> 
> I'm not too familiar with Weston's RDP-backend, but given it's a
> separate backend, 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 you describe must intimately integrate with
> the compositor and cannot be achieved by applications atop alone.
> 
> 
> 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: [RFC wayland-protocols] inputfd - direct input access protocol

[The Rasterman]

ads/joysticks are only "special" if your view of the world is
> > one of
> > "everything is a pc with a keyboard and mouse and joysticks etc. are
> > just
> > occasionally used input devices only for some specialist games".
> > 
> > that view of the world is really limited. smart tv's, consoles,
> > handheld game
> > systems and many more do not share this view of the world. in these
> > worlds
> > gamepads etc. are often primary input devices that do act as
> > surrogate
> > keyboards and mice along with other stuff (conceptually if your view
> > of the
> > world is that of a pc).
> 
> It really isn't, sorry. In fact, I'm pretty certain that you can
> implement a gaming console's interface far more easily with this
> protocol than with the original one.

how so? all 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 just do
so with keyboard input too? why not so this everywhere and just have an fd per
input device rather than wayland protocol.

it's all inconsistent this way. some input is protocol. some is a special
fd with a device-driver level protocol not a wayland one.

if the kernel devices are so well done to "just expose them" as a fd then why
not simply transfer that protocol into a wayland protocol event and be done
with it? at least we're then consistent with the way input events are done.
that or dump wayland protocol input device events and do them the device fd
way...

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

[The Rasterman]

On Tue, 04 Apr 2017 11:29:30 +0200 Bastien Nocera <had...@hadess.net> said:

> On Tue, 2017-04-04 at 08:16 +0900, Carsten Haitzler wrote:
> > On Fri, 31 Mar 2017 17:29:19 +1000 Peter Hutterer <peter.hutterer@who
> > -t.net>
> > said:
> > 
> > If you're going to do this ... why not just do it for keyboards,
> > mice, touch
> > panels etc. too?
> > 
> > My point is - the same reasons these other devices don't be lazy and
> > stick
> > their heads in the sand with these other devices are the same reasons
> > joysticks, gamepads etc. etc. should also be UNDERSTOOD by the
> > compositor
> > before passing them on so they compositor can filter out special
> > buttons (eg a
> > power button and handle it internally, or a "home" button to go back
> > to the
> > home screen etc.).
> 
> Just like the superb joystick support in X11, amirite? :)

well - do better. there already was a proposal to add joystick/gamepad protocol
support to wayland protocol a few months back but it was rejected. i think
that's a far better solution than this.

> The protocol is a well-known, extensible one (evdev), already supported
> by all the games on Linux that support joypads. And if it's not good
> enough, your compositor can choose not to pass the raw device node's
> file descriptor to the application, but pass a file descriptor with a
> simpler protocol, or pass the joypad events as key presses.
> 
> Your compositor's choice.
> 
> Demarshalling and remarshalling the protocol means you have a layer of
> indirection that's usually not necessary, and just makes it harder to
> support new features from the bottom of the stack upwards.

gamepads with power buttons. the wii controller has one. you want to filter
that out and not pass it to a client. just like keys. there are home buttons
too - same thing. menu buttons and so on. in some cases the game controller is
the ONLY interface you have to the device and so various buttons and actions
need trapping just like a keyboard or mouse do.

that's why i say - the same logic that applies to mouse and keyboard should
apply to all other input devices like joysticks etc. - so if just passing an fd
is "just fine" for a joystick then scrap all the kbd/mouse protocol and pass
those through directly too. that or do them the same way. the marshalling and
demarshalling are just fine for mice and keyboards (gaming mice can produce
1000, 2000 or even more events per second... so don't tell me that magically a
gamepad is special and needs low latency and so on 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

[The Rasterman]

ovides the object id of the devices,
> > > + any static information about the device (device name,
> > > + vid/pid, etc.) is sent through the wp_inputfd_device interface.
> > > +
> > > + Which devices are compatible input devices for this seat is a
> > > + decision made by the compositor, the protocol makes no guarantee
> > > + that any specific device becomes available as inputfd device to a
> > > + client.
> > > +  
> > > +   > > summary="the newly added device"/>
> > > +
> > > +  
> > > +
> > > +  
> > > +
> > > +  The wp_inputfd_device interface represents one device accessible
> > > +  directly by an fd passed to the client.
> > > +
> > > +  A device has a number of static characteristics, e.g. device
> > > +  name and pid/vid. These capabilities are sent in an event sequence
> > > +  immediately after the wp_inputfd_seat.device_added event. This
> > > initial
> > > +  event sequence is terminated by a wp_inputfd_device.done event.
> > > This
> > > +  sequence is sent only once and always before the first
> > > +  wp_inputfd_device.focus_in event.
> > > +
> > > +
> > > +
> > > +  
> > > + This destroys the client's resource for this inputfd object.
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + The name is a UTF-8 encoded string with the device's name,
> > > intended
> > > + for presentation to the user.
> > > +
> > > + This event is sent in the initial burst of events before the
> > > + wp_inputfd_device.done event.
> > > +
> > > + This event is optional, if the required information is not
> > > available
> > > + for this device the event is omitted.
> > > +  
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + This event is sent in the initial burst of events before the
> > > + wp_inputfd_device.done event.
> > > +
> > > + This event is optional, if the required information is not
> > > available
> > > + for this device the event is omitted.
> > > +  
> > > +  
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + This event is sent to notify the client of a custom property that
> > > + applies to this device. The property is a standard key/value
> > > store
> > > + in UTF-8 format, interpretation of both strings is left to the
> > > + client. The wayland protocol makes no guarantees about the
> > > content
> > > + of each string beyond its text encoding.
> > > +
> > > + Compositors and clients need to agree on a dictionary of
> > > properties.
> > > + For example, a compositor may designate the device to be of
> > > + 'joystick-type' 'gamepad'. This dictionary is out of the scope of
> > > + this protocol.
> > > +  
> > > +  
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + This event is sent immediately to signal the end of the initial
> > > + burst of descriptive events. A client may consider the static
> > > + description of the device to be complete and finalize
> > > + initialization of the device.
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + Sent when the device has been removed from the system.
> > > +
> > > + If the client currently has the device focus, a
> > > + wp_inputfd_device.focus_out event is sent before the removed
> > > event.
> > > + See wp_inputfd_device.focus_in for more details.
> > > +
> > > + When this event is received, the client must
> > > wp_inputfd_device.destroy
> > > + the object.
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + This enum specifies the format of the file descriptor passed to
> > > + clients with the wp_inputfd_device.focus_in event.
> > > +  
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + Notification that this client now has the focus and/or access to
> > > + this device. The decision what consitutes focus left to the
> > > + compositor. For example, a compositor may tie joystick focus to
> > > the
> > > + wl_pointer focus of this seat. The protocol does not guarantee
> > > that
> > > + any specific client ever receives the focus for a device.
> > > +
> > > + The client is passed a file descriptor with access to this
> > > + device. This file descriptor is valid until a subsequent
> > > + wp_inputfd_device.focus_out event. Upon
> > > wp_inputfd_device.focus_out, the
> > > + compositor may revoke the fd and further operations will fail.
> > > +
> > > + However, due to potential race conditions a client must be able
> > > to
> > > + handle errors as if it opened the fd itself. No guarantee is
> > > + given that the wp_inputfd_device.focus_out event or
> > > wp_inputfd_device.removed
> > > + event are sent before the client encounters an error on the file
> > > + descriptor.
> > > +
> > > + A compositor guarantees that the underlying device does not
> > > change
> > > + until a wp_inputfd_device.removed event. In other words, if the
> > > fd
> > > + type allows querying capabilities through the fd, a client needs
> > > to
> > > + do so only once at the first focus_in. Subsequent focus_in events
> > > + 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.
> > > +
> > > + The protocol guarantees that focus_in and focus_out always come
> > > in
> > > + pairs. If the client currently has the focus and the device is
> > > + removed, a focus_out event is sent to the client before the
> > > + wp_inputfd_device.removed event.
> > > +  
> > > +  
> > > +  
> > > +  
> > > +   > > summary="The current surface that has the device's focus"
> > > allow-null="true"/>
> > > +
> > > +
> > > +
> > > +  
> > > + Notification that this client no longer has focus and/or access
> > > to
> > > + this device. Further reads from this device's file descriptor
> > > + will fail. The client must close(2) the file descriptor received
> > > in
> > > + the wp_inputfd_device.focus_in event.
> > > +
> > > + This event does not mean the device was removed, merely that the
> > > + device is focused elsewhere. For device removal, see
> > > + wp_inputfd_device.removed.
> > > +
> > > + See wp_inputfd_device.focus_in for more details.
> > > +  
> > > +
> > > +  
> > > +
> > > +
> > > +
> ___
> 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

[The Rasterman]

tor is valid until a subsequent
> + wp_inputfd_device.focus_out event. Upon wp_inputfd_device.focus_out,
> the
> + compositor may revoke the fd and further operations will fail.
> +
> + However, due to potential race conditions a client must be able to
> + handle errors as if it opened the fd itself. No guarantee is
> + given that the wp_inputfd_device.focus_out event or
> wp_inputfd_device.removed
> + event are sent before the client encounters an error on the file
> + descriptor.
> +
> + A compositor guarantees that the underlying device does not change
> + until a wp_inputfd_device.removed event. In other words, if the fd
> + type allows querying capabilities through the fd, a client needs to
> + do so only once at the first focus_in. Subsequent focus_in events
> + 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.
> +
> + The protocol guarantees that focus_in and focus_out always come in
> + pairs. If the client currently has the focus and the device is
> + removed, a focus_out event is sent to the client before the
> + wp_inputfd_device.removed event.
> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> + Notification that this client no longer has focus and/or access to
> + this device. Further reads from this device's file descriptor
> + will fail. The client must close(2) the file descriptor received in
> + the wp_inputfd_device.focus_in event.
> +
> + This event does not mean the device was removed, merely that the
> + device is focused elsewhere. For device removal, see
> + wp_inputfd_device.removed.
> +
> + See wp_inputfd_device.focus_in for more details.
> +  
> +
> +  
> +
> +
> +
> ___
> 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] move away from C

[The Rasterman]

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 language was developed in the early '70s. It was
> >> always considered a proof of concept, as it was clear to everyone
> >> involved that any serious programming lanugage should have a garbage
> >> collector. Indeed, Dennis Ritchie is widely known to have said:
> >>
> >> "What I would really like is to extend this prototype into a garbage
> >> collected, multi-paradigm, modern programming language, supported by a
> >> major player in the industry."
> >>
> >> Of course, the language thus envisioned would later be implemented as
> >> C pound (not to be confused with the cloud programming language #C).
> >>
> >> Let's catch up to 1990 and translate major parts of wayland to the
> >> language of the people - haskell.
> >
> > ummm... how about no?
> 
> Don't read the internets on April 1st.

good point. i totally didnt know what date it was... :)

> Thanks,
> Derek
> 
> >
> >> Some early code can be found here:
> >> https://github.com/abooij/sudbury
> >> Existing wayland clients run without recompilation. Compositors are
> >> not supported yet.
> >> ___
> >> 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] move away from C

[The Rasterman]

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 language was developed in the early '70s. It was
> >> always considered a proof of concept, as it was clear to everyone
> >> involved that any serious programming lanugage should have a garbage
> >> collector. Indeed, Dennis Ritchie is widely known to have said:
> >>
> >> "What I would really like is to extend this prototype into a garbage
> >> collected, multi-paradigm, modern programming language, supported by a
> >> major player in the industry."
> >>
> >> Of course, the language thus envisioned would later be implemented as
> >> C pound (not to be confused with the cloud programming language #C).
> >>
> >> Let's catch up to 1990 and translate major parts of wayland to the
> >> language of the people - haskell.
> >
> > ummm... how about no?
> 
> Don't read the internets on April 1st.

oh good. point. i had no idea what date it was :)

> Thanks,
> Derek
> 
> >
> >> Some early code can be found here:
> >> https://github.com/abooij/sudbury
> >> Existing wayland clients run without recompilation. Compositors are
> >> not supported yet.
> >> ___
> >> 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] move away from C

[The Rasterman]

On Sat, 1 Apr 2017 14:03:21 +0100 Auke Booij <a...@tulcod.com> said:

> The C programming language was developed in the early '70s. It was
> always considered a proof of concept, as it was clear to everyone
> involved that any serious programming lanugage should have a garbage
> collector. Indeed, Dennis Ritchie is widely known to have said:
> 
> "What I would really like is to extend this prototype into a garbage
> collected, multi-paradigm, modern programming language, supported by a
> major player in the industry."
> 
> Of course, the language thus envisioned would later be implemented as
> C pound (not to be confused with the cloud programming language #C).
> 
> Let's catch up to 1990 and translate major parts of wayland to the
> language of the people - haskell.

ummm... how about no?

> Some early code can be found here:
> https://github.com/abooij/sudbury
> Existing wayland clients run without recompilation. Compositors are
> not supported yet.
> ___
> 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] Interface for injection of input events

[The Rasterman]

On Tue, 28 Mar 2017 15:33:41 -0700 Jordan Sissel <j...@semicomplete.com> said:

> I am interested in the security concerns here, but are there reliable
> barriers between different processes run by the same user in the same
> desktop session? What is the threat model y'all are defending against?

the assumption is a model where random apps are downloaded by a suer and these
apps are untrusted. they might be malware. they might want to rummage through
your address book and send it to someone to sell for a profit or to monitor
your file usage ... or become a keylogger and snarf your usernames and
passwords. apps are untrusted.

what is wanted is that wayland protocol and design it self does not OPEN holes
via the display system to such malicious clients/apps. wayland can do nothing
about the rest of the OS but it can at least secure itself well enough.

so we are operating on the assumption that if someone is in this scenario they
are then ALSO applying some kind of MAC/sandboxing setup to limit what these
untrusted apps can do/access on the "OS side" (ptrace, opening, writing of
files, and so on), so ASSUMING a well managed sandbox the app is running in, we
want to not expose anything more to the app other than what it should be
allowed to access. generally in wayland that has meant "very little". apps are
considered hostile/untrusted by default.

reality is though that for some things some apps do need access to do "trusted"
things where they may need access to all input or be able to generate input
(feed in fake input events) and so on. this should be heavily restricted and
part of this discussion is "how would this be done?" because being able to
see/modify some arbitrary other apps window is a recipe for disaster. being
able to inject input is even more so. so only special processes that are fully
trusted should be allowed to do this...

and given the many sandboxing methods... how would a compositor even enforce
such restriction? we could define one "blessed" mechanism. SMACK? containers?
something else? then what about wayland on non-linux? this makes securing
access to privileged features difficult cross-platform and so having some way
to do this in a portable way would be nice and make everyone's life simpler...
of course still assuming the OS somehow is doing sandboxing of the process 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

[The Rasterman]

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 <ppaala...@gmail.com>
> > said:
> > 
> > > > == Authentication/Identification ==
> > > > The goal is to filter clients based on some white/blacklist, so that
> > > > e.g. xdotool can access this interface but others cannot.  
> > > 
> > > Hi,
> > > 
> > > if one allows a generic tool that essentially exposes everything at
> > > will, there isn't much point in authenticating that program, because
> > > any other program can simply call it.  
> > 
> > This is where right now I might lean to some environment variable with a
> > cookie/key the compositor provides *and that may change from session to
> > session or on demand).
> > 
> > So compositor might putenv() then fork() + exec() something like a terminal
> > app.. and then this terminal app and anything run from it inherits this env
> > var... and thus now has the secret key to provide...
> > 
> > This also allows the compositor to run any such process that passes the
> > key/cookie along to other processes/tools it determines are safe. It would
> > require the compositor have a "safe user initiated or approved" way to run
> > such things.
> 
> Hi,
> 
> that doesn't sound too bad. Initially the cookie could be passed in the

Just saying... it's the first (and best) idea that comes to mind.

We use SMACK in Tizen to sandbox apps. But I am sure others will use other
schemes. If every OS/distro has some other sandboxing scheme it'll be REALLY
hard for compositors to be portable as they then have to support every possible
security scheme to auth privileged clients.

If i make the assumption that a sandboxing scheme will at a minimum disallow
apps that are not meant to have access to the environment of a process to read
it (i.e. /proc/PID/environ), and that an app given a cookie will be careful not
to pass it on (via publicly readable files, IPC, or execution) to other apps it
does not also trust as much as itself...

Then an environment variable actually works nicely. An app can read it then
putenev()/unsetenv() it after it's already been used or stored elsewhere (or
before forking+executing anything untrusted).

This should work irrespective of the MAC/sandboxing mechanism and thus would
provide some kind of method "we all agree on" for granting some kind of
privileges to some client.

If there is a better idea, please do share. This is not necessarily the best.
It's just the best one that popped int my little head. :)

> env, until something better comes around. Also the restrictions and

I think that we should specify the environment variable much like XDG does too.
If it is otherwise shared via another mechanism, at least for now that could be
"implementation defined" based on the sharing/IPC protocol or whatever between
those processes.

> privileges carried with a cookie could vary based on how it was
> generated, e.g. cookies created for a container could be invalid for
> clients outside that specific container. Or require matching to SElinux
> or SMACK or whatever attributes. Or none of these at first. Completely
> up to the compositor.

I see no reason why a compositor can't impose EXTRA restrictions like the
above. E.g. check cookie AND then also check client container or smack label
or... whatever. So if the cookie leaked outside of this sandbox it would be
invalid anyway. Each cookie can indeed also represent different access
privileges so a cookie would only at best grant access to what it was intended
to gain access to and nothing more (if the compositor did it right).

> So now we need a spec for the cookie. An opaque binary blob with
> variable size, limited by some maximum size? 1 kB max?

I'm pretty agnostic on what it is. I might lean to a string, not a binary blob.
Because This is easily embedded in an environment variable as-is.

I would suggest that the compositor use something like a SHA256 hash and then
base64 encode it (so it'd end up being 48 bytes of a string + 0 byte).

But perhaps an opaque binary blob in protocol and define the environment
variable to be a base64 encoding of that?... or hex? ...

> (To ensure e.g. Wayland can relay the maximum sized cookie in one
> message.)
> 
> This could be the generic starting point for all privileged interfaces,
> Wayland and others. How the client will get the cookie in the first
> place is left undefined. The cookie should probably be optional too, in
> case another scheme already grants the privileges.

I would agree with making it optional if the compositor c

Re: [RFC] Interface for injection of input events

[The Rasterman]

> merge state from different (physical) devices. This just makes the actual
> device handling implementation trivial.
> 
> It gets a bit more difficult if we want to have this per-seat though. Seat
> is a wayland concept so we could fold that in, but then you're leaking the
> seat configuration. So I'm not 100% sure we even want this, or whether we
> should just make sure it can be retrofitted in the future.
> 
> == Use for testing ==
> Came up several times, I'm not yet convinced this is a good compositor testing
> interface beyond basic input. A good testing interface likely requires
> something more compositor-specific where more of the window state is made
> available. But it could work as an interim solution.

well i don't see event injection being useful for testing if it doesn't ALSO
come with an interface for event recording...

> == Input coordinate handling ==
> Keys and mouse buttons are trivial unless we want custom focus (we don't).
> Relative coordinates are ok too, absolute ones are trickier because they
> rely on screen layout not available to the client.
> 
> So the specification needs to include a behaviour we can stick to forever,
> something like "in pixels as measured from the logical top-left of the
> top-left-most screen" etc. Not difficult per se, but this stuff is usually
> prone to corner-case unhappiness.

well in the case where you r compositor doesn't work this way (e.g. wraps your
display around 3d bunny rabbits)... i guess the whole interface can just not be
offered. i think the important thing here is:

1. this is optional and may not be available based on compositor and scenario
2. even if possible to support  the compositor may forbid it any time

as long as this is the baseline assumption... 

> == Input coordinate filtering ==
> One use-case that was mentioned to me was effectively "intercept button X
> and send key events 'abc' instead". This is not possible with the current
> proposal and I'm not sure it can be without going overboard with
> specifications. It *may* be possible to provide some global hotkey hooks I
> have not come up with a good solution to that.

this i think should remain a compositor thing.

> == Window management ==
> This is beyond the current suggestion but also where it gets both
> interesting and difficult.

this is also tricky too. here i also think keeping this private to compositors
is the right way to go for now.

> I have a sample org.freedesktop.WoodoTool.Desktop interface that would send
> Edge signals to clients. The compositor decides when these are triggered,
> the client can react to these things with custom commmands.
> 
> But this is where we get into the proper scripting territory and that's also
> where the opinions will diverge quite quickly.
> 
> For example, xdotool supports things like "search for window with name 'foo'
> and activate it". Implementing this is ... tricky. Now we need some
> definition of what a window classifies as and how windows are sorted within
> a process - compare multiple GIMP windows with multiple gnome-terminal
> windows for example. Not specifying exactly what order we return leaves us
> open to behavioural dependencies which may break in the future.
> 
> In other words, an interface to search for windows of a given application
> is technically feasable but extremly hard to get right.
> 
> Anyway, with the separation of interfaces this is not something we need in
> the first iterations. But one legitimate question is whether just an
> implementation for virtual input devices is sufficient or whether it's
> largely pointless without any additional window-management capabilities.
>
> == Implementation ==
> 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.
> 
> 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?
> 
> Cheers,
>   Peter
> ___
> 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] Interface for injection of input events

[The Rasterman]

On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <ppaala...@gmail.com> said:

> > == Authentication/Identification ==
> > The goal is to filter clients based on some white/blacklist, so that e.g.
> > xdotool can access this interface but others cannot.
> 
> Hi,
> 
> if one allows a generic tool that essentially exposes everything at
> will, there isn't much point in authenticating that program, because
> any other program can simply call it.

This is where right now I might lean to some environment variable with a
cookie/key the compositor provides *and that may change from session to session
or on demand).

So compositor might putenv() then fork() + exec() something like a terminal
app.. and then this terminal app and anything run from it inherits this env
var... and thus now has the secret key to provide...

This also allows the compositor to run any such process that passes the
key/cookie along to other processes/tools it determines are safe. It would
require the compositor have a "safe user initiated or approved" way to run such
things.

Unless there is some other mechanism that could work like this.

> > Either way, this is a problem that *must* be solved but not necessarily one
> > that affects the API itself (beyond what is required to make it
> > technically feasable, e.g. passing cookies around)
> 
> It's essentially the same problem we have with all the privileged
> Wayland interfaces, too.
> 
> Containers or sandboxing have been mentioned as a possible way to let
> the OS reliably identify the running program.

At least as a way to avoid them leaking keys like above example... then a
sandboxed system can ensure sandboxed processes don't have access to such
cookies/keys but otherwise compositors themselves do not have to support a
SPECIFIC sandboxing mechanism... :) they simply auth/compare the cookie/key.
the compositor could also have several cookies/keys and revoke any it chooses
to at any time and different clients are provided different keys.

Either way, security 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" --
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: It seems regular linux desktops can't run android apps even on Wayland?

[The Rasterman]

On Wed, 22 Mar 2017 01:19:55 -0300 Lúcio Boari <lucbo...@gmail.com> said:

> Hello I'm Lúcio. I'm not a programmer so maybe what I am discussing here is
> somehow erroneous. Today I was wondering why it's not possible to have
> Android apps running natively on a Linux desktop since Android runs atop
> the Linux Kernel and it is pretty much compatible with the x86
> architecture, and since Google has always open sourced their code. I made
> some research and found this page
> <http://www.jlekstrand.net/jason/projects/wayland/wayland-android/>which
> explains basically a triple layered EGL context will always exist if you
> try to attach the Android's display server on Wayland, and very few drivers
> are capable of handling this.
> 
> Why does the same thing doesn't happen with Xwayland? Isn't it the same
> kind of problem? It is a pity things are this way because if Android apps
> were compatible with the standard linux system there would be a certain
> advantage in shipping a standard Linux distro on smartphones and tablets
> over the plain Android System to not talk about regular computers which
> would gain a huge amount of applications.
> 
> I hope you Wayland developers could make a way to attach Androrid
> applications on Wayland, but if there's really no good way to do this
> currently... If there is I'd like to know why there's apparently no one
> interested to make such a thing to happen...

Android is NOT an open OS. Not these days. Google very much push apps to RELY
on Google Play Services and "upgrade" from old Android API's. All development
of core Android API's (e.g. location API) stopped and all future additions
happen to Google Play Services which is proprietary, closed and specific to
Google.

Just because Android and "Desktop/Server Linux" (aka GNU/Linux - until Android
I never though I'd use this term) share the same kernel does not mean that are
anything alike further up the stack. They are vastly different with different
libc's and just about everything higher up being different.

So Android apps are NOT compatible with GNU/Linx. Android is a completely
different OS that just shares ONLY the kernel and nothing more worth talking
about. Because it is a foreign OS possibly even more so than iOS or OSX would
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 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

[The Rasterman]

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 could as easily have the compositor show the
> >> color swatch only on a part of the output and leave the rest of the
> >> area for normal use.
> >>
> >> However, if that is done with a special protocol so that the compositor
> >> actually knows this is the profiling color swatch, it can make sure
> >> other windows cannot interfere. It could be like the color swatch was
> >> on an always-on-top overlay. You cannot do that any other way from a
> >> Wayland client.
> >>
> >> And if unform color for the swatch is all you need, the 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 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.
> 
> +1 for subsurface. The compositor can even take over responsibility to
> move the belonging window to the desired output, for the case the
> underlying application can not manage or handle that itself (e.g. for
> mirrored outputs).

indeed as it knows the parent surface etc. and thus can "do the right thing"
without the calibration app needing to know or care at all.

in the end a calibrator really just needs to present some data (unmolested by
gamma luts/color correction/blending etc.) onto a display so some colorimiter
device dangling on the screen can read it and feed back what it sees. using
this dat produce a set of calibration data a compositor (or an app) canuse
later that would be applicable to that monitor.

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

[The Rasterman]

f a "special-purpose client" than, say, a CAD
> >> application, a code editor, or an application that lets you create 3D
> >> scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.
> >
> > Graeme just managed to explain to me why the profiling app needs access
> > to the VideoLUT (see [1]) which is a global resource. That makes the
> > profiling app a very special case on Wayland, because on Wayland we
> > very very carefully avoid unconditional access to such global
> > resources, so that apps cannot take the user or the desktop hostage or
> > mess it up even if they tried to(*). Changing the VideoLUT will mess up
> > all other windows on that output, and the profiling app will not even
> > tolerate any other windows on that output at the same time.
> >
> > Any application you listed does not require similar access to a global
> > resource. A profiling app OTOH cannot use the normal content delivery
> > paths because as Graeme explained they often do not reach the full
> > precision without changing the VideoLUT.
> >
> > Another example of where Wayland denies access to global resources is
> > that an application cannot make an input grab at will. Input grabs are
> > always conditional, and breakable. We should have similar behaviour
> > also with "screen grabs" like these.
> >
> > [1]
> > https://lists.freedesktop.org/archives/wayland-devel/2017-January/032616.html
> >
> > (*) The classic example of messing up the user's desktop is games
> > changing the X server video mode, and for one reason or another (don't
> > care, bug, broken, crashed) never restores it to original, or even if
> > it does restore, all your icons on the desktop get squashed in the
> > top-left corner. That is one reason why Wayland does not have a RandR
> > interface.
> >
> >
> >> Graeme Gill wrote:
> >>> I'm also thinking it would really help a lot if you and
> >>> others contributing to this thread were able
> >>> to procure something like a X-Rite i1 display Pro,
> >>> run up the manufacturer provided software on
> >>> MSWindows or OS X to get a feel for what it does,
> >>> then fire up DisplayCAL+ArgyllCMS on Linux/X11
> >>> and take it 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/profiling workflow on
> >> YouTube may already help.
> >
> > That's an excellent idea! Could you recommend some, so I don't pick a
> > random "oh, but they're doing it wrong" video?
> >
> >
> > Thanks,
> > pq
> >
> >
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> 
> 
> Best regards
> 
> [1] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-January/032619.html
> 
> --
> Benoit (blocage) Gschwind
> ___
> 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

[The Rasterman]

On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen <ppaala...@gmail.com> said:

> On Fri, 13 Jan 2017 16:37:57 +0100
> Florian Höch <lists+wayland-de...@hoech.org> wrote:
> 
> > Am 13.01.2017 um 16:19 schrieb Richard Hughes:
> > > On 13 January 2017 at 14:56, Florian Höch <lists+wayland-de...@hoech.org>
> > > wrote:  
> > >> .. also guarantee that nothing else will be shown on that specific
> > >> output  
> > > 
> > > FWIW, I'd be fine just displaying a color swatch on the entire screen
> > > with no window decorations; the only reason we use a composited window
> > > in gnome-color-manager is so the user knows where the put the sensor.  
> > 
> > Well, that will work for profiling, as long as you don't mind not being
> > able to see progress information (which I would consider a real drawback).
> > Besides it's surely a bit awkward that the computer then cannot be as
> > easily used differently in the meantime if it doesn't have a second
> > monitor connected (not that I'd recommend it, but I often have a music
> > player open during measurements and sometimes it's nice to have the
> > ability to adjust the playlist while lengthy measurements are still
> > running, to give an example. Also who am I to tell people with their new
> > gigantic 4K 40" desktop monitor that they can't use the rest of the
> > available real estate while a comparatively tiny measurement swatch is
> > displayed in the center?).
> > Also a fullscreen color swatch will probably not be able to deal
> > gracefully with things like OLED screens which might have automatic
> > power limiting depending on displayed content and such, which could
> > botch the measurements in a way that makes the resulting profile useless.
> > 
> > It certainly won't work for guided adjustment (unless you re-implement
> > UI), where the feedback displayed in the UI is supposed to guide the
> > user through adjustments to (e.g.) monitor controls he/she needs to make.
> 
> Oh, ok, that's why. We could as easily have the compositor show the
> color swatch only on a part of the output and leave the rest of the
> area for normal use.
> 
> However, if that is done with a special protocol so that the compositor
> actually knows this is the profiling color swatch, it can make sure
> other windows cannot interfere. It could be like the color swatch was
> on an always-on-top overlay. You cannot do that any other way from a
> Wayland client.
> 
> And if unform color for the swatch is all you need, the 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 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

[The Rasterman]

On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy <li...@colorremedies.com> said:

> So...
> 
> Do applications (wayland clients) choose what compositor to use? Each
> application could be using a different compositor?
> 
> Does it make any sense that there'd be three different classes of
> compositor: no-color management, assume sRGB color management, and
> full color management (all objects are explicitly tagged and the
> compositor is doing display compensation with the help of e.g. lcms)?
> Or am I missing something about compositors?

your choice of wm 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 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

[The Rasterman]

On Wed, 21 Dec 2016 09:56:05 + Daniel Stone <dan...@fooishbar.org> said:

> Hi,
> 
> On 21 December 2016 at 00:36, Carsten Haitzler <ras...@rasterman.com> wrote:
> > On Tue, 20 Dec 2016 16:46:07 + Daniel Stone <dan...@fooishbar.org> said:
> >> On 19 December 2016 at 02:08, Carsten Haitzler <ras...@rasterman.com>
> >> wrote:
> >> > so... here is my question - shouldn't the colorspace be tired to a
> >> > buffer? not a surface? yes. i know. the surface "displays" the buffer...
> >> > but the colorspace is intrinsic to the buffer content... right?
> >>
> >> Conceptually, buffer is a good shout, but buffers are hidden from you
> >> in EGL. 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... ?
> 
> No, I mean that client rendering looks like this in EGL:
> egl_dpy = eglGetPlatformDisplay(...);
> egl_cfg = eglChooseConfig(egl_dpy, ...);
> egl_surf = eglCreateWindowSurface(egl_dpy, egl_cfg, ...);
> egl_ctx = eglCreateContext(egl_dpy, egl_cfg, ...);
> (bool) eglMakeCurrent(egl_dpy, egl_surf, egl_surf, egl_ctx);
> {
> (void) gl*();
> (bool) eglSwapBuffers();
> }

oh yeah. i was not thinking if client is using egl and eglswapbuffers is hiding
everything. i was thinking clients explicitly sending buffers.

> At no point does an EGL client ever come into contact with the
> wl_buffers produced by EGL. They are utterly opaque, and hidden inside
> the EGL implementation. This 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 things like opaque region attached
> to the surface, with the commit latched, rather than buffers.
> 
> Cheers,
> Daniel
> 


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

[The Rasterman]

On Tue, 20 Dec 2016 16:46:07 + Daniel Stone <dan...@fooishbar.org> said:

> Hi,
> 
> On 19 December 2016 at 02:08, Carsten Haitzler <ras...@rasterman.com> wrote:
> > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
> > <niels_...@salscheider-online.de> said:
> >> +  
> >> +
> >> +  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 - shouldn't the colorspace be tired to a buffer?
> > not a surface? yes. i know. the surface "displays" the buffer... but the
> > colorspace is intrinsic to the buffer content... right?
> 
> Conceptually, buffer is a good shout, but buffers are hidden from you
> in EGL. 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, 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

[The Rasterman]

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 assigned per
> > hw plane... they are different colorspaces ... :)
> 
> It isn't a different color space though, just a different color encoding,
> since the primaries haven't changed.
> 
> Analogous examples: XYZ and Yxy space. XYZ and L*a*b* space. RGB and LCH.

it's a different mapping of byte1, byte2, byte3 within a pixel to different r,g
and b points in the visible spectrum. :)

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

[The Rasterman]

> > > +  
> > > +
> > 
> > as above. should this be tied to an output at all? ok. so an event. great.
> > 
> > > +
> > > +   > > + summary="the passed icc data is invalid" />
> > > +
> > > +  
> > > +
> > > +  
> > > +
> > > +  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 - shouldn't the colorspace be tired to a buffer?
> > not a surface? yes. i know. the surface "displays" the buffer... but the
> > colorspace is intrinsic to the buffer content... right?
> 
> I'm not sure, I can see reasons for both. I thought about wl_buffer as the 
> storage while wl_surface contains transformations that have to be applied.
> But the color profile is obviously tied to the pixel values.

well this is up for debate... to my mind it belongs to the buffer imho...
but...?

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


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

[The Rasterman]

On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill <grae...@argyllcms.com> said:



at this point i'm going to summarize this. this might be more helpful than
continuing point by point rebuttals as i sense that there's something missing
in this conversation:

summary of what i think should be the case (or roughly):

1. if colorspace/profile with buffer from client matches screen compositor
SHOULD do nothing with the pixels unless it has to (eg has to blend them with
content below or otherwise do effects etc. designated by its layout policy).
2. if null colorspace then compositors generally agree to ALSO not touch pixels
and transform them unless it has to blend them etc. like #1, but irrespective
of the output
3. if colorspace/profile does NOT match the display then compositor can either
a) transform colors to get them correct on another display or b) leave them
along and just leave things as they are and perhaps let the user know that the
colors for that window/surface may be wrong on that display, or limit the
screens that display that buffer based on context.

how to clients select a colorspace? compositor sends available colorspaces to
client (maybe send per surface actually?). client picks one and renders content
given that colorspace/profile and presents that to the compositor for display.
compositor may update colorspaces that are available at any time.

colorspaces/profiles should be nominal colorspace with a whole bunch of numbers
detailing adjustments/mappings 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...@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

[The Rasterman]

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 colorspace. it may be able to
>  > switch. embedded devices can do this as the display panel may have extra
>  > control lines for switching to a different display gammut/profile. it may
>  > be done at the gfx card output level too... so it can change on the fly.
> 
> That's not a typical situation though, but nothing special would be
> happening - a new profile may be installed by the user as well,
> in which case an application should re-render to accommodate
> the change.

the user at most should be interacting with compositor settings/tools to
configure a specific profile for a display (let's assume a fixed profile for
that screen), so a compositor tool to tell the compositor the profile changed
(pressed a button on the monitor to change it). when they alter the compositor,
then compositor can tell applications.

>  > yes. compositors right now work in display colorspace. they do no
>  > conversions. eventually they SHOULD to display correctly. to do so they
>  > need a color profile for the display.
> 
> For enhanced color management yes. But core comes first, and is necessary
> for many color critical applications, because the compositor will never
> have the color transformations they require.

they will have to have them, or then not support that colorspace at all.

>  > it may be that a window spans 8 different screens all with different
>  > profiles. then what?
> 
> As I've explained several times, what happens is that the application
> is aware of this, and transforms each region appropriately - just
> as they currently do on X11/OS X/MSWin systems.

not in wayland. not acceptable. the app will never know which windows it is on.
as i have said - could be wrapped around a sphere or a room full of bunnies
bouncing about across 8 screens.

>  > with a
>  > proper color correcting compositor it can make them all look the same.
> 
> As will a color aware application given appropriate color management support.

it can't if it doesn't know how a window or buffer is transformed or mapped to
screens.

> The code is already there to do all that in color critical application.

then they get to pick a colorspace and render to that. attahc that to the
buffer. compositor will do whatever it wants. e.g. if that buffer is on the
screen it matches it'd do no transform. maybe it does no transforms at all. and
simply hovers some indicator above the serface telling you if the surface
colorspace matches the screens colorspace or not. maybe compositor disallows
the window to be moved off the screen that matches the colorspace. that can be
configured via the compositor.

>  > if i mmove the
>  > window around the client has drawn different parts of its buffer with
>  > different colorspaces/profiles in mind and then has to keep redrawing to
>  > adjust as it moves.
> 
> Yes.

and now you just hit "unacceptable in wayland land" space. which is why i tell
you that this is not acceptable.

>  > you'll be ablew to see "trails" of incorrect coloring around the
>  > boundaries of the screens untl the client catches up.
> 
> It's damage, just like any other, and color critical users using
> color critical applications will take "trails" over wrong color
> anytime. No "trails" and wrong color = a system they can't use.

and totally unacceptable for wayland space. so a big fat no to that kind of
design.

>  > the compositor SHOULD do any color correction needed at this point.
> 
> Not at all. That's a way to do it under some circumstances yes, but
> it's not satisfactory for all.

it is up to the compositor. if the goal is to make colors visibly as uniform as
is possible given the displays that exist then it should. not all compositors
will. they may do things differently like above. maybe limit location of a
window/surface or place an indicator above a window when it is fully on the
correct screen for its color profile, and/or they may transform colorspaces.

>  > if you want
>  > PROPER color correction the compositor at a MINIMUM needs to be able to
>  > report the color profile of a screen even if it does no correcting.
> 
> Yes - exactly what I'm suggesting as core color management support.

but it doesnt have to tell you which screen it is nor tell you which screen
your window is on. it's an option of 1 of various colorspaces to be able to use
given a specific compositor.

>  > yes you may have
>  > multiple screens. i really dislike the above scenario of incorrect pixel
>  &

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

[The Rasterman]

wonder if this shoiuld be done this way. does it not expose too
much about an output? what happens when the output changes its colorspace?
imagine it has software controls where it can chnage its mapping or hardware
buttons etc.? shouldnt we just have a list of colorspaces available (that may
change at any time so some kind of event indicating a change would be needed)?

> +
> +  
> +This request returns a zwp_colorspace_1 object for the sRGB color
> +space. The sRGB color space is initially attached to all surfaces.
> +  
> +  
> +

ok - so srgb is default as it implicitly is now. but is this necessary? if no
actual blending takes place isn't this moot? any surface with a buffer with
alpha i don't think is going to get this fussy...

> +
> +  
> +This request returns a zwp_colorspace_v1 object for the blending
> color
> +space of the compositor. All surfaces are converted by the compositor
> +to the blending color space before the blending operations. Once the
> +blending is performed, a further color conversion to the output color
> +spaces is carried out by the compositor.
> +A client should render in the blending color space returned by this
> +request if it does any color conversion on its own. This allows the
> +compositor to skip the color conversion to the blending color space.
> +  
> +  
> +
> +
> +
> +  
> +This event will be sent when the color space of an output is changed.
> +  
> +  
> +

as above. should this be tied to an output at all? ok. so an event. great.

> +
> +   + summary="the passed icc data is invalid" />
> +
> +  
> +
> +  
> +
> +  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 - shouldn't the colorspace be tired to a buffer? not
a surface? yes. i know. the surface "displays" the buffer... but the colorspace
is intrinsic to the buffer content... right?

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

[The Rasterman]

On Sun, 18 Dec 2016 16:25:13 +0100 Niels Ole Salscheider
<niels_...@salscheider-online.de> said:

> I feel like the discussion drifts off a bit. You (Graeme) obviously know much 
> more about color management than I do. But as Pekka already pointed out there 
> are a few constraints that originate in the design decisions of wayland and 
> are quite different to these of X11. We can't change these constraints but 
> have to find a solution that works well with them:
> 
> - A normal application CANNOT control the hardware directly (it can't program 
> LUTs, for example).
> 
> - A normal application CANNOT alter global settings of the compositor (like 
> setting color profiles for the outputs). This can only be done by the 
> compositor or a few trusted applications. The user will just have to use the 
> settings dialog provided with the compositor. Because of that it does not 
> matter if this is implementation dependent.
> 
> - You DO NOT know which parts of a surface are shown on which screen.
> 
> - We aim to be pixel-perfect.
> 
> I think these constraints mean that we must let the compositor take part in 
> the color correction, at least if more than one screen is involved. If we do 
> so, we should also be able to expect that the compositor can handle a bit
> more complicated cases (e. g. an arbitrary number of different surfaces with 
> different color profiles).

bingo. and while we're at it we should solve our yuv colorspace issues too
(same as rgb. currently bt601, bt709 and bt2020 need supporting).

> When I proposed this protocol my focus was on applications that may not be 
> color managed currently. I thought for example about web browsers or simple 
> image viewers where I would view (but not edit) photos.
> Your focus is obviously on professional applications. I think both use cases 
> are equally important and we should not treat one as an afterthought of the 
> other.
> 
> I would be glad if we could come up with a solution that works for both 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" --
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 display with 3D acceleration using Wayland/Weston

[The Rasterman]

On Wed, 14 Dec 2016 11:42:54 -0600 DRC <dcomman...@users.sourceforge.net> said:

...snip...

> Again, not how it currently works when using Weston with the RDP back end.

weston is not the only wayland compositor. is the the sample/test compositor.
wayalnd does not mean sticking to just what weston does.

i suspect weston's rdp back-end forces a sw gl stack because it's easier to be
driver agnostic and run everywhere and as you have to read-back pixel data for
transmitting over rdp... why bother with the complexity of actual driver setup
and hw device permissions etc...

what pekka is saying that it's kind of YOUR job then to make a headless
compositor (base it on weston code or write your own entirely from scratch
etc.), and this headless compositor does return a hw egl context to clients. it
can transport data to the other server via vnc. rdp or any other method
you like. your headless compositor will get new drm buffers from client when
they display (having rendered using the local gpu) and then transfer tot he
other end. the other end can be a vnc or rdp viewer or a custom app your wrote
for your protocol etc. ... but what you want is perfectly doable with
wayland... 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 (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

[The Rasterman]

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 the support for
> > providing the real colorspace of the monitor, providing non SRGB pixel data
> > by clients in another colorspace (eg adobe) and it MUST work or apps will
> > literally fall over.
> 
> That's not a scheme I'm recommending.

ok. that's fine. i'm happy with that.

...snip...

> > not a format. a colorspce. R numbers are still R, as are G and B. it's just
> > that they point to different "real life spectrum" colors and so they need
> > to be transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).
> 
> My point stands. I've not mentioned new colorspaces.

if it's RGB or YUV (YCbCr) it's the same thing. just vastly different color
mechanisms. color correction in RGB space is actually the same as in YUV. it's
different spectrum points in space that the primaries point to.

 color management require introducing such things. BT.601, BT.709, BT.2020.
the compositor MUST KNOW which colorspace the YUV data uses to get it correct.
i'm literally starting at datasheets of some hardware and you have to tell it
to use BT.601 or 709 equation when dealing with YUV. otherwise the video data
will look wrong. colors will be off. in fact BT.709 == sRGB.

now here comes the problem... each hardware plane yuv may be assigned to MAY
have a different colorspace. they also then get affected by the color
reproduction of the screen at the other end.

you HAVE to provide the colorspace information so the compositor CAN assign you
to the correct hw plane OR configure the plane correctly OR configure the
yuv->rgb conversion hardware to be correct.

this is no different to RGB space but you don't tend to find hardware
specifically helping you out (yes gpu + shader can do a transform fast. i'm
talking hw layers or dedicated acceleration units that have existed for yuv
for a long time).

any list of colorspaces IMHO should also include the yuv colorspaces where/if
possible. if a colorspace is not supported by the compositor then the appjust
needs to take a "best effort". the default colorspace today could be considered
BT.709/sRGB. also you could say "it's null transform" colorspace. i.e. you know
nothing so don't try colorcorrect.

> > i really do not think this is needed. simply a list of available colorspaces
> > would be sufficient. application then provide data in the colorspace of it's
> > choice given what is supported by the compositor and the input data it
> > has...
> 
> And I think it is core, for all the reasons I've listed.
> 
> >>  enhanced: The compositor is provided with source colorspace
> >>   profiles by the application.
> > 
> > i again don't see why this is needed.
> 
> Hmm. How else does the compositor know how to transform from
> the given colorspace to the display colorspace ?

my point was i don't think it's needed to split this up.

compositor lists available colorspaces. a list of 1 sRGB or null-transform or
adobe-rgb(with transform matrix), wide-gammut, etc. means thathat is the one
and only output supported.

> > again - we're just arguing who does the transform.
> 
> It's not "just", it's the point.

not as i see it. given a choice of output colorspaces the client can choose to
do its own conversion, OR if it's colorspace of preference is supported by the
compositor then choose to pass the data in that colorspace to the compositor
and have the compositor do it.

> > i don't see the point. the
> > compositor will have a list of colorspaces it can display (either A screen
> > can display this OR can be configured to display in this colorspace, ... OR
> > the compositor can software transform pixels in this colorspace to whatever
> > is necessary to display correctly).
> 
> I don't know how many different ways I can explain the same thing. The
> compositor can't know how to transform color in all the ways an application
> may need to transform color. I think it is unlikely for instance, that you are
> proposing that the compositor support full N-Color, device links, ICC-Max
> support, etc., or the infinity of ways that haven't been invented yet to
> transform between color spaces. So the core color management requirement
> is that the application be able to transform into the device colorspace
> itself.

*sigh* and THAT IS WHY i keep saying that the client can choose to do it's own!
BUT this is not going to be perfect across multiple screens unless all screens
share the same colorspace/profile. let's say:

1 screen is a professional grade monitor with wide gamm

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

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 each output for its
> >> surface is a base requirement.
> > 
> > i totally disagree. the compositor should simply provide available
> > colorspaces (and generally only provide those that hardware can do). what
> > screen they apply to is unimportant.
> 
> Please read my earlier posts. No (sane) compositor can implement CMM
> capabilities to a color critical applications requirements,
> so color management without any participation of a compositor
> is a core requirement.

oh course it can. client provides 30bit (10bit per rgb) buffers for example and
compositor can remap. from the provided colorspace for that buffer to the real
display colorspace.

> > if the colorspace is native to that display or possible, the compositor
> > will do NO CONVERSION of your pixel data and display directly (and instead
> > convert sRGB data into that colorspace).
> 
> Relying on an artificial side effect (the so called "null color transform")
> to implement the ability to directly control what is displayed, is a poor
> approach, as I've explained at length previously.

but that is EXACTLY what you have detailed to rely on for color managed
applications. for core color management you say that the client knows the
colorspace/profile/mappings of the monitor and renders appropriately and
expects its pixel values to be presented 1:1 without remapping on the screen
because it knows the colorspace...

> > if your surface spans 2 screens the compositor may
> > convert some to the colorspace of a monitor if it does not support that
> > colorspace. choose the colorspace (as a client) that matches your data best.
> > compositor will do a "best effort".
> 
> No compositor should be involved for core support. The application
> should be able to render appropriately to each portion of the span.

then no need for any extension. :) compositor HAs to be involved to at least
tell you the colorspace of the monitor... as the screen is its resource.

> > this way client doesnt need to know about outputs, which outputs it spans
> > etc. and compositor will pick up the pieces. let me give some more complex
> > examples:
> 
> That only works if the client doesn't care about color management very much -
> i.e. it's not a color critical application. I'd hope that the intended use of
> Wayland is wider in scope than that.

how does it NOT work? let me give a really simple version of this.

you have a YUV buffer. some screens can display yuv, some cannot. you want to
know which screens support yuv and know where your surface is mapped to which
screens so you can render some of your buffer (some regions) in yuv and some
in rgb (i'm assuming packed YUVxYUVxYUVx and RGBxRGBxRGBx layout here for
example)... you wish to move all color correct rendering, clipping that correct
(yuv vs rgb) rendering client-side and have the compositor just not care.

this leads to the artifacts i was mentioning. just this one will be a LOT more
obvious.

> > compositor has a mirroring mode where it can mirror a window across multiple
> > screens.
> 
> Sure, and in that case the user has a choice about which screen is
> properly color managed. Nothing new there - the same currently
> applies on X11, OS X, MSWin. Anyone doing color critical work
> will not run in such modes, or will just use the color managed screen.

the point of wayland is to be "every frame is perfect". this breaks that.

> > some screens can or cannot do color management.
> 
> Nothing to do with screens - core color management is up to
> the application, and all it needs is to know the display profile.

i mean they are able to display wider gammut of color beyond the limited sRGB
range that is common.

> > what happens when the colorspace changes on the fly (you recalbrate
> > the screen or output driving hardware). you expect applications to directly
> > control this and have to respond to this and redraw content all the time?
> 
> Yep, same as any other sort of re-rendering event (i.e. exactly what happens
> with current systems - nothing new here.)

and this leads to imperfect frames.

> > this can be far simpler:
> > 
> > 1. list of supported colorspaces (bonus points if flags say if its able to
> > be native or is emulated).
> > 2. colorspace attached to buffer by client.
> > 
> > that's it.
> 
> If you don't care so much about color, yes. i.e. this is
> what I call "Enhanced" color management, rather than core.

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

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
> >> to make both aspects Wayland (extension) protocols, so
> >> that Wayland color management and color sensitive applications
> >> have the potential to work across all Wayland systems,
> >> rather than being at best balkanized, or at worst, not
> >> supported.
> > 
> > "not supported" == sRGB (gamma). 
> 
> No, not supported = native device response = not color managed.

and for most displays that is sRGB.

> > render appropriately.
> > most displays are not
> > capable of wide gammuts so you'll HAVE to handle this case no matter what.
> 
> I've no idea what you mean.

most displays have "horrible color response". they are sRGB. they cannot
display a wider part of the color spectrum. some professional monitors/displays
can do this. eg 98% of abobe RGB for example.

either way monitors tend to have slightly different color reproduction and most
are "not that good" so basically sRGB. the compositor then is effectively
saying "unmanaged == sRGB, but it may really be anything so don't be fussy".

> > 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.
> 
> No compositor is involved. If the application doesn't know
> the output display profile, then it can't do color management.

it can assume sRGB.

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

[The Rasterman]

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 post ? - perhaps
> >> I'm simply not understanding where you are coming from on this.
> > 
> > you didn't explain before if the point is for this to be mandatory or
> > optional.
> 
> I'm not sure exactly what you mean by "this".

this == support for color correction protocol AND actually the support for
providing the real colorspace of the monitor, providing non SRGB pixel data by
clients in another colorspace (eg adobe) and it MUST work or apps will
literally fall over.

at the end of the day there will be some extension and then some form of
guidance to developers. e.g. you can guarantee this will work, or "this may or
may not work. deal with it".

> I've suggested two color management extensions, one building on
> the other. By being an extension, I assume that neither one is
> mandatory, although "core" would be a dependence of "enhanced".

well there are extensions that are managed outside of wayland as a project.
these obviously are not mandatory. the more core it becomes the more it is
likely "mandatory".

> > above you basically say it has to be mandatory as applications will then
> > fail to run (at least some set of them might).
> 
> That's not at all what I said. I said that applications have the
> option of falling back to more basic approaches :-
> enhance back to core, core back to none.

yes. my bad. i misread the replies and quotes. i thought you said "not at all"
to the "clients should fall back" path.

> > when you add extra features like new colorspace support, people writing apps
> > and toolkits nee to know what the expectation is. can they just assume it
> > will work, or do they need to have a fallback path on their side.
> 
> I've not mentioned any new colorspace support, so I'm not
> sure what you are talking about.

not a format. a colorspce. R numbers are still R, as are G and B. it's just
that they point to different "real life spectrum" colors and so they need to be
transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).

> > compositor writers need to know too. if color management is mandatory then
> > their compositor is basically broken until they add it.
> 
> Naturally a compositor that supports an extension, would
> would have to implement it!
> 
> > i don't see a difference between enhanced and core.
> 
> Hmm. They are quite distinct.
> 
>  core: The application either implements its own CMM (lcms or
>   ArgyllCMS icclib/imdi etc.), or uses a system provided CMM
>   (i.e. ColorSync, WCS, AdobeCMM etc.).
>  enchanced: The compositor implements some level of CMM itself,
>   using one of the above libraries, GPU etc.
> 
>  core: The application requires information from the graphics
>   system (via Wayland in this particular discussion), namely
>   the profile for the display corresponding to each
>   pixel region.

i really do not think this is needed. simply a list of available colorspaces
would be sufficient. application then provide data in the colorspace of it's
choice given what is supported by the compositor and the input data it has...

>  enhanced: The compositor is provided with source colorspace
>   profiles by the application.

i again don't see why this is needed.

>  core: The application uses its CMM to transform source colorspaces
>   to the display colorspaces, and sends the pixels to the graphics system.
> 
>  enhanced: The compositor uses its CMM to transform the pixels provided
>   by the application in the provided source colorspaces to the display
>   colorspaces.

again - we're just arguing who does the transform. i don't see the point. the
compositor will have a list of colorspaces it can display (either A screen can
display this OR can be configured to display in this colorspace, ... OR the
compositor can software transform pixels in this colorspace to whatever is
necessary to display correctly).

the client simply chooses what colorspace to provide buffers in. it chooses the
one that is best for it.

> > color management means:
> > 
> > 1. being able to report what colorspace is "default" on the display right
> > now (and what may be able to be enabled possible at request).
> 
> I'm not sure what you mean by "enabled". A display colorspaces is just
> information that is needed by the CMM, so it is either known and available to
> what needs it, or not known or not available to what needs it.

a colorspace that is enabled is when the displ

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

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 decide? e.g. if
> > your window is on top, or it's the largest one, or it's focused,then the
> > compositor MAY switch the colorspace of that monitor to match your surface's
> > buffer colorspace, and if it goes into the background or whatever, switch
> > back? it can (and likely should) emulato other colorspaced then.
> 
> That doesn't seem like color management. Ultimately you arrive
> at the native display space, so if things are to look as intended,
> something (application or compositor) should transform from
> a non-native spaces into the native space.
> 
> At a practical level, if it is expected that the compositor
> deals with transparency (which I assume it does), then I'd
> suggest something simple - compositing in output device space
> (Isn't that what current Wayland compositors are doing ?),

a display may not have a single native colorspace. it may be able to switch.
embedded devices can do this as the display panel may have extra control lines
for switching to a different display gammut/profile. it may be done at the gfx
card output level too... so it can change on the fly.

yes. compositors right now work in display colorspace. they do no conversions.
eventually they SHOULD to display correctly. to do so they need a color profile
for the display.

it may be that a window spans 8 different screens all with different profiles.
then what? currently the image looks a bit different on each display. with a
proper color correcting compositor it can make them all look the same. if you
want apps to be able to provide "raw in screen colorspace pixels" this is going
to be horrible especially as windows span multilpe screens. if i mmove the
window around the client has drawn different parts of its buffer with different
colorspaces/profiles in mind and then has to keep redrawing to adjust as it
moves. you'll be ablew to see "trails" of incorrect coloring around the
boundaries of the screens untl the client catches up.

the compositor SHOULD do any color correction needed at this point. if you want
PROPER color correction the compositor at a MINIMUM needs to be able to report
the color profile of a screen even if it does no correcting. yes you may have
multiple screens. i really dislike the above scenario of incorrect pixel tails
because this goes against the whole philosophy of "every frame is perfect". you
cannot do this given your proposal. it can only be done if the compositor
handles the color correction and the clients just provide the colorspace being
used for their pixel data.

> or as a refinement, compositing in a per-channel light
> linearised space, that is reversible at the bit level.
> 
> Bottom line is that a color critical application won't
> use compositor transparency for anything it cares about.

i'm totally ignoring the case of having alpha. yes. blending in gamma space is
"wrong". but it's fast. :)

> > e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
> > re-render everything else that is sRGB into adobe argb space... there might
> > be a slight "flicker" so to speak as maybe some banding appears in some
> > gradients of SRGB windows or colors are ever so slightly off, but the
> > compositor is optimizing for the surface it thinks it most important.
> 
> Sounds cumbersome. It's certainly not how existing systems work.
> 
> > i really don't like the
> > idea of applications explicitly controlling screen colorspace.
> 
> I'm not sure what you mean by that. Traditionally applications render
> to the display colorspace. Changing the display setup (i.e. switching
> display colorspace emulation) is a user action, complicated only by the
> need to make the corresponding change to the display profile, and re-rendering
> anything that depends on the display profile.

being able to  modify what the screen colorspace is in any way is what i
dislike. only the compositor should affect this based on it's own decisions.

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

[The Rasterman]

inear
> > if the compositor cares about good colors.
> 
> It's not clear to me that any application that is interested in good
> color would trust it to blending operations.
> 
> I'd also imagine that there is a class of applications wishing to get the
> compositor to deal with gross display differences (Wide gamut vs.
> sRGB-like for instance) but 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

[The Rasterman]

On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill <grae...@argyllcms.com> said:

> Niels Ole Salscheider wrote:
> > Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> 
> >> Looking through the current Wayland color-management protocol
> >> proposal, I think it is missing a really fundamental thing -
> >> managing the output device color calibration state and color
> >> profile. I guess the assumption is that this is being done
> >> by colord, but my understanding is that colord is specific
> >> to Gnome based systems, and certainly depends on DBus, which
> >> Wayland does not. [ Please correct me if I've got any of this wrong. ]
> 
> > It is (currently) up to the compositor to decide how to implement this. The 
> > compositor could come with its own settings for the output color profiles
> > or query some other program. This might be colord, but it could also be 
> > kolormanager, or something else.
> 
> 1) This doesn't address how this information is communicated
>to a Wayland application.
> 
> 2) Expecting color management applications to deal with
>configuring the compositor in a platform dependent
>way, is expecting far too much. I for one am not
>about to add multiple platform dependent back
>ends (multiple flavors of Linux, BSD's, Android,
>etc.) to my tools to do this, and no other major
>platform expects it (i.e. none of MSWindows, OS X
>or X11 based systems have this requirement.)
> 
> The correct approach to avoiding such issues is simply
> to make both aspects Wayland (extension) protocols, so
> that Wayland color management and color sensitive applications
> have the potential to work across all Wayland systems,
> rather than being at best balkanized, or at worst, not
> supported.

"not supported" == sRGB (gamma). render appropriately. most displays are not
capable of wide gammuts so you'll HAVE to handle this case no matter what.
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 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

[The Rasterman]

t I would regard as features of
> > > > a reasonable color management facility for a graphics
> > > > system such as Wayland are:
> > > > 
> > > > * That color management protocol's have two uses :- 1) configuring
> > > > 
> > > >   color management and 2) allowing applications to use color management.
> > > >   These two uses may need different security profiles.
> > > >   The assumption should be that color management applications
> > > >   used to create calibrations, profiles and configure the
> > > >   state of color management, are of equal importance to color
> > > >   managed applications that depend on a properly profiled and
> > > >   configured color management system, since you can't have latter
> > > >   with out the former.
> > > > 
> > > > * Color management of a graphics rendering system such as Wayland
> > > > 
> > > >   should be split into two levels (possibly two extensions) :-
> > > >   
> > > >   1) Core == output device management, which involves identifying output
> > > > 
> > > > devices, controlling their calibration state (Video LUT), installing a
> > > > color profile resources associated with that output device, and
> > > > identifying
> > > > which rendered pixels go to which output device(s). This is the most
> > > > basic
> > > > requirement, since this is the bare minimum for applications to be
> > > > properly
> > > > color managed. It is also a necessary resource for the second level to
> > > > be
> > > > able to operate.
> > > > 
> > > >   2) Enhanced == input space management, which assumes a graphics
> > > >   server rendering system capable of color management. This involves
> > > > 
> > > > labeling an input raster with a color profile, and controlling the
> > > > manner
> > > > of rendering (i.e. rendering intent, maybe blending space ? etc.) This
> > > > is
> > > > useful for implementing default color management (e.g. as a means of
> > > > coping
> > > > with wide gamut displays when many applications are not color aware), or
> > > > as
> > > > a low developer overhead means of implementing basic color management in
> > > > non color critical applications.
> > > > 
> > > > Translating these aims into a more concrete set of capabilities might
> > > > look like this:
> > > > 
> > > > Core:
> > > > Get 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.
> > > > Clear/Set/Get ICC profile associated with an Output.
> > > > 
> > > > Event notifications:
> > > > - CRTC to surface mapping change
> > > > - Output to CRTC mapping change
> > > > - Monitor to Output connection change
> > > > - ICC profile associated with Output change
> > > > 
> > > > Enhanced:
> > > > Clear/Set/Get default color management source RGB ICC profile
> > > > for a
> > > > 
> > > > display. Disable/Enable/UseDefault color management flag for a Surface.
> > > > 
> > > > Clear/Set/Get source RGB ICC profile for a Surface.
> > > > Set/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
> 
> 
> ___
> 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 wayland v2] wayland-server: abort instead of posting events with wrong client objects

[The Rasterman]

On Fri, 9 Dec 2016 15:51:10 +0100 Giulio Camuffo <giuliocamu...@gmail.com> said:

> 2016-12-08 20:36 GMT+01:00 Derek Foreman <der...@osg.samsung.com>:
> > Check that all the objects in an event belong to the same client as
> > the resource posting it.  This prevents a compositor from accidentally
> > mixing client objects and posting an event that causes a client to
> > kill itself.
> >
> > It's intended that the compositor killing itself be easier to debug
> > than the client killing itself for something that it's completely
> > innocent of.
> 
> It may be easier, but as an user the compositor crashing is a highly
> disruptive event, and i think we should strive to avoid it at all
> times. By all means, log the problem, get a backtrace and print it,
> maybe, but i don't agree with the abort(). Unless the problem really
> is unrecoverable, but it seems this is not the case. If it was an
> assert(0) it may be better, but i'm not sure i'd like that either.

i agree. aborts are VERY anti-social for a library to do. reporting an error
and making the function a "NOP" is by far the best thing. 

> Cheers,
> Giulio
> 
> >
> > Signed-off-by: Derek Foreman <der...@osg.samsung.com>
> > ---
> >
> > Changes since v1:
> > uses get_next_arguments and arg_count_for_signature in the normal fashion
> > abort instead of assert
> >
> >
> > This does not address Pekka's request for a new_id test, as it's not
> > immediately clear to me how to write it.
> >
> >  src/wayland-server.c | 29 +
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/src/wayland-server.c b/src/wayland-server.c
> > index 9d7d9c1..429dbef 100644
> > --- a/src/wayland-server.c
> > +++ b/src/wayland-server.c
> > @@ -160,6 +160,33 @@ log_closure(struct wl_resource *resource,
> > }
> >  }
> >
> > +static void
> > +verify_objects(struct wl_resource *resource, uint32_t opcode,
> > + union wl_argument *args)
> > +{
> > +   struct wl_object *object = >object;
> > +   const char *signature = object->interface->events[opcode].signature;
> > +   struct argument_details arg;
> > +   struct wl_resource *res;
> > +   int count, i;
> > +
> > +   count = arg_count_for_signature(signature);
> > +   for (i = 0; i < count; i++) {
> > +   signature = get_next_argument(signature, );
> > +   switch (arg.type) {
> > +   case 'o':
> > +   res = (struct wl_resource *) (args[i].o);
> > +   if (res && res->client != resource->client) {
> > +   wl_log("unrecoverable error: The compositor
> > "
> > +  "tried to use an object from one "
> > +  "client in an event for a different "
> > +  "client.\n");
> > +   abort();
> > +   }
> > +   }
> > +   }
> > +}
> > +
> >  WL_EXPORT void
> >  wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode,
> >  union wl_argument *args)
> > @@ -167,6 +194,7 @@ wl_resource_post_event_array(struct wl_resource
> > *resource, uint32_t opcode, struct wl_closure *closure;
> > struct wl_object *object = >object;
> >
> > +   verify_objects(resource, opcode, args);
> > closure = wl_closure_marshal(object, opcode, args,
> >  >interface->events[opcode]);
> >
> > @@ -206,6 +234,7 @@ wl_resource_queue_event_array(struct wl_resource
> > *resource, uint32_t opcode, struct wl_closure *closure;
> > struct wl_object *object = >object;
> >
> > +   verify_objects(resource, opcode, args);
> > closure = wl_closure_marshal(object, opcode, args,
> >  >interface->events[opcode]);
> >
> > --
> > 2.10.2
> >
> > ___
> > 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

[The Rasterman]

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 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)... or are we going to go the path of:
> > > I'd be happy if there was support for core color management (i.e.
> > > application color management), before adding layers that depend on the
> > > core.
> > 
> > but is the intent that compositors MUST support color management and
> > applications will fail entirely or fail to display even partly correctly if
> > compositor doesnt support color management or doesnt support the color
> > profile/space requested by the client? or will it be expected that apps need
> > to always be able to convert to sRGB for compatibility and then have added
> > colorspace capabilities if it's supported? what is the intent?
> 
> We can't make support for this protocol mandatory because color correction 
> might be too much overhead for compositors for embedded devices.

well graeme disagrees and effectively thinks it should be. :)

> But I would say that every compositor that does some sort of color correction 
> should also implement the color management protocol.
> If the protocol is not supported by the compositor you would assume that you 
> have to output the colors in the device color space (or just ignore it if you 
> do not care about accurate colors).
> ___
> 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

[The Rasterman]

nt.
> >   These two uses may need different security profiles.
> >   The assumption should be that color management applications
> >   used to create calibrations, profiles and configure the
> >   state of color management, are of equal importance to color
> >   managed applications that depend on a properly profiled and
> >   configured color management system, since you can't have latter
> >   with out the former.
> > 
> > * Color management of a graphics rendering system such as Wayland
> >   should be split into two levels (possibly two extensions) :-
> > 
> >   1) Core == output device management, which involves identifying output
> > devices, controlling their calibration state (Video LUT), installing a
> > color profile resources associated with that output device, and identifying
> > which rendered pixels go to which output device(s). This is the most basic
> > requirement, since this is the bare minimum for applications to be properly
> > color managed. It is also a necessary resource for the second level to be
> > able to operate.
> > 
> >   2) Enhanced == input space management, which assumes a graphics
> >   server rendering system capable of color management. This involves
> > labeling an input raster with a color profile, and controlling the manner
> > of rendering (i.e. rendering intent, maybe blending space ? etc.) This is
> > useful for implementing default color management (e.g. as a means of coping
> > with wide gamut displays when many applications are not color aware), or as
> > a low developer overhead means of implementing basic color management in
> > non color critical applications.
> > 
> > Translating these aims into a more concrete set of capabilities might
> > look like this:
> > 
> > Core:
> > Get 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.
> > Clear/Set/Get ICC profile associated with an Output.
> > 
> > Event notifications:
> > - CRTC to surface mapping change
> > - Output to CRTC mapping change
> > - Monitor to Output connection change
> > - ICC profile associated with Output change
> > 
> > Enhanced:
> > Clear/Set/Get default color management source RGB ICC profile for a
> > display. Disable/Enable/UseDefault color management flag for a Surface.
> > Clear/Set/Get source RGB ICC profile for a Surface.
> > Set/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

[The Rasterman]

On Fri, 09 Dec 2016 14:29:14 +0100 Niels Ole Salscheider
<niels_...@salscheider-online.de> said:

> Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> > Niels Ole Salscheider wrote:
> > 
> > Hi,
> > 
> > > The first version of my proposal had such a flag. I removed it and
> > > replaced it by the described version based on feedback from Zoxc
> > > (zox...@gmail.com).
> > Do you have a link to the specifics ?
> 
> Most of the discussion happened on IRC back then. It should be in the logs 
> but...
> 
> > > I can see advantages with both solutions. One advantage with the current
> > > proposal is that you can have a surface that covers multiple screens. In
> > > this case the compositor can still try its best to correct the colours
> > > for all but the main screen.
> > 
> > I'm not quite sure what you mean. Generally an application will have
> > specific reasons for wanting to do it's own color management - for
> > instance, perhaps it is previewing a CMYKOGlclm file, and wants to
> > treat out of gamut mapping and black point mapping in a particular way, etc.
> > I don't think the Wayland compositor is going to be expected to handle
> > CMYKOGlclm etc. input rasters, never mind all the requirements of
> > specialist application color management!
> 
> This is of course something that the client application has to do. It would 
> query the main output for its surface, do the conversions to that color space 
> and then attach the output color space to the surface.
> 
> The compositor now must not touch the parts of the surface on the main output 
> (where the color spaces match). But it could still try to convert from the 
> color space of the main output to that of a secondary screen if the surface 
> covers two screens with different color profiles.
> 
> This might of course cause artifacts when one of the screens has a too small 
> gamut but still seems better than ignoring this.
> 
> But then again most people that work with professional applications would not 
> make them cover multiple screens, I guess. Therefore I'm not opposed to
> adding a flag that indicates that the application wants to disable color
> corrections completely for that surface, independent of the output.

why not simply let the compositor decide. if a surface spans multile screens it
may have to emulate on another screen (egh one screen can do adobe arg, another
is ye-olde sRGB). this is simply a matter of letting the compositor know what
colorspace the rgb values are in so it can "do the appropriate thing". :)

> > Which is not to say that compositor color management doesn't have its
> > place - it is ideal for applications that just want to use "RGB", and
> > not deal with specific display behavior.
> 
> Very simple applications would just keep the attached sRGB color space and 
> maybe place images on subsurfaces with the embedded color space from the
> image attached.
> 
> Applications that care a bit more about color correction (but do not have 
> professional needs) could convert all their colors to the blending color
> space of the compositor. I'd expect this blending color space to be linear if
> the compositor cares about good colors.
> This would have the advantage that the compositor does not have to do the 
> conversion "application output color space -> blending color space".

if compositor just lists what colorspaces it can do, which happen to have
native hardware support (i.e. the display panel itself is capable of it), then
client can choose whatever works best, and compositor just "does its best" too
which may mean adjusting dislpay gammut or output transforms at the gpu level
or via side-bad protocols with the display panel itself if that were to exist.

> > > Back then I argued that this might not be good enough if you want to
> > > calibrate the monitor. But the consent was that this would require
> > > another protocol to disable all colour corrections anyway and that it
> > > could be developed at a later point.
> > 
> > I strongly disagree with this idea - disabling application-side color
> > management is a fundamental step in achieving end to end 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.
> > 
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 
> _

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

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 colorspaces
> > defined)... or are we going to go the path of:
> 
> I'd be happy if there was support for core color management (i.e. application
> color management), before adding layers that depend on the core.

but is the intent that compositors MUST support color management and
applications will fail entirely or fail to display even partly correctly if
compositor doesnt support color management or doesnt support the color
profile/space requested by the client? or will it be expected that apps need to
always be able to convert to sRGB for compatibility and then have added
colorspace capabilities if it's supported? what is the intent?

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

[The Rasterman]

On Fri, 2 Dec 2016 12:30:53 + Daniel Stone <dan...@fooishbar.org> said:

> Hi Nils,
> 
> On 19 November 2016 at 16:29, Niels Ole Salscheider
> <niels_...@salscheider-online.de> wrote:
> > it has been some time since I proposed the first two RFCs for a color
> > management protocol in weston. You can find the old discussions here:
> >
> > https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
> > https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html
> >
> > During the discussion of the second RFC it became clear that color
> > correction was out of scope for weston at that time.
> > In the meantime wayland-protocols was split from weston and libweston was
> > created. Several wayland compositors start to see everyday usage and
> > wide-gamut screens became more common so that color management becomes more
> > important.
> >
> > Therefore I think that the situation has changed and I'd like to propose
> > this protocol for inclusion in wayland-protocols again.
> > What do you think?
> 
> Yes, I think you're right, and it's time to start looking at it again.
> Now Weston is a bit more mature/capable, the desktop environments have
> caught up and are at the point where it makes sense for them to look
> at it, and we have wayland-protocols rather than the old
> weston/protocols/ dumping ground, it's probably the right time.

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)... or are we going to go the path of:

99% of apps won't care so color correction is an optional extra and apps 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 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

[The Rasterman]

On Fri, 28 Oct 2016 13:32:06 +1000 Peter Hutterer <peter.hutte...@who-t.net>
said:

> On Fri, Oct 28, 2016 at 08:25:51AM +0900, Carsten Haitzler wrote:
> > On Thu, 27 Oct 2016 11:51:00 +0200 Carlos Garnacho <carl...@gnome.org> said:
> > 
> > > Hey Carsten!,
> > > 
> > > On Thu, Oct 27, 2016 at 4:11 AM, Carsten Haitzler <ras...@rasterman.com>
> > > wrote:
> > > > On Wed, 26 Oct 2016 06:57:53 + "Alexis BRENON @Wayland"
> > > >  said:
> > > >
> > > >> Just to be sure that I understand clearly, what you call 'Toolkit' is
> > > >> libraries like GTK, Qt, and co. that are used by developers to build
> > > >> their apps, isn't it ?
> > > >
> > > > yes. toolkit == EFL, Qt, GTK+ and others (SDL is kind of a toolkit),
> > > > FLTK, ... chromium/blink is basically a toolkit of its own etc.
> > > >
> > > > at least looking at gtk3 here it doesn't do momentum with wheel/axis
> > > > scrolling (out of the box). maybe it needs enabling?
> > > 
> > > FWIW, that should happen out of the box whenever we got
> > > wl_pointer.axis_stop on both axes:
> > > https://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n3399
> > >
> > > The usual caveats apply, that doesn't help if the app plays smart and
> > > tries to implement its own scroller widget.
> > 
> > i was testing under x with my wheel and 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?
> 
> 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 doing it is far simpler... we don't need stop events at all.
just some "move 1 tick up.down" is enough. (or 2 ticks, 3 ticks...) also i was
using my mouse wheel not a touch pad... so thats probably why.

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

[The Rasterman]

On Thu, 27 Oct 2016 23:55:36 +0530 Rohit Burra <iamroh...@gmail.com> said:

> I am Rohit, a student at Vishnu Institute of Technology. I am interested in
> the Wayland project and would like to contribute. I can write code in C,
> Python. My GitHub profile: https://github.com/iamrohit7/  Can anyone please
> help me get started? I tried searching for beginner/easy bugs which most
> other projects have but couldn't find any.

my advice. "poke it and see how it wobbles" first. make a wayland client app
"from scratch with no toolkit other than libwayland-client to talk to a
compositor". get pixels on screen. update them. (maybe got for a shm client so
you have a bit more of a raw idea). then once you can get content... handle
input (kbd/mouse/whatever) and respond. keep going. add features. explore more
and more of protocol features (you'll figure this out by this point). you will
at some point get comfortable with how wayland works as a protocol. a lot f the
people if not most who work on wayland have spent YEARS working with things
like x11 (and have their likes and hates) and thus have a lot of experience. if
you are fresh to all of this (you haven't written toolkits or window
managers/compositors in x11) you have little experience to build on i guess and
so should build some. when you get to the above point you should begin to have
some todo-items magically on your own. most of the "todo items" now get driven
by specific app/compositor or "desktop env" needs. most projects are still
getting to having a complete solid wayland implementation (compositor and
client side in toolkits) and are busy restoring functionality they had under
x11 before.

> Thank you
> 
> Cheers,
> Rohit
> 
> On Oct 27, 2016 5:30 PM, <wayland-devel-requ...@lists.freedesktop.org>
> wrote:
> 
> Send wayland-devel mailing list submissions to
> wayland-devel@lists.freedesktop.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> or, via email, send a message with subject or body 'help' to
> wayland-devel-requ...@lists.freedesktop.org
> 
> You can reach the person managing the list at
> wayland-devel-ow...@lists.freedesktop.org
> 
> When replying, please edit 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 driver
>   (Carsten Haitzler (The Rasterman))
>3. Re: Kinetic scroll in libinput Xorg driver (Silvan Jegen)
>4. Re: Kinetic scroll in libinput Xorg driver (Carlos Garnacho)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 27 Oct 2016 11:10:58 +0900
> From: Carsten Haitzler (The Rasterman) <ras...@rasterman.com>
> To: Christian Stroetmann <stroetm...@ontolab.com>
> Cc: "Alexis BRENON @Wayland" <brenon.alexis+wayl...@gmail.com>,
> wayland-devel@lists.freedesktop.org
> Subject: Re: Kinetic scroll in libinput Xorg driver
> Message-ID: <20161027111058.194287583206f24ddb5ea...@rasterman.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Wed, 26 Oct 2016 14:14:13 +0200 Christian Stroetmann
> <stroetm...@ontolab.com> said:
> 
> > On 26.10.2016 08:57, Alexis BRENON @Wayland wrote:
> >
> > @Raster: Thank you for your reminder.
> >
> > Maybe Enlightenment with Tiling2 and kinetic scrolling is already what
> > you need.
> 
> yes. and then load the tiling module (and enable tiling for the desktops you
> want it on etc. - in tiling settings).
> 
> > If I remember correctly I3 (www.i3wm.org)<http://i3wm.org/> might work
> > together with Wayland as well.
> 
> possibly might work too.
> 
> > In general, I have seen at all major toolkits transistion efforts to
> > Wayland since around 2 years. Some have matured while others are
> > experimental so to say.
> 
> indeed.
> 
> > Best Regards
> > Christian Stroetmann
> >
> > > Just to be sure that I understand clearly, what you call 'Toolkit' is
> > > libraries like GTK, Qt, and co. that are used by developers to build
> > > their apps, isn't it ?
> > >
> > > Finally, do you know some tiling DE/WM Wayland compliant ?
> > >
> > > Kind,
> > > Alexis.
> > >
> > > Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler <ras...@rasterman.com
> > > <mailto:ras...@rasterman.com>> a écrit :
> > >
> > > On Mon, 24 Oct 2016 18:42

Re: Kinetic scroll in libinput Xorg driver

[The Rasterman]

On Thu, 27 Oct 2016 11:51:00 +0200 Carlos Garnacho <carl...@gnome.org> said:

> Hey Carsten!,
> 
> On Thu, Oct 27, 2016 at 4:11 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Wed, 26 Oct 2016 06:57:53 + "Alexis BRENON @Wayland"  > +wayl...@gmail.com> said:
> >
> >> Just to be sure that I understand clearly, what you call 'Toolkit' is
> >> libraries like GTK, Qt, and co. that are used by developers to build their
> >> apps, isn't it ?
> >
> > yes. toolkit == EFL, Qt, GTK+ and others (SDL is kind of a toolkit),
> > FLTK, ... chromium/blink is basically a toolkit of its own etc.
> >
> > at least looking at gtk3 here it doesn't do momentum with wheel/axis
> > scrolling (out of the box). maybe it needs enabling?
> 
> FWIW, that should happen out of the box whenever we got
> wl_pointer.axis_stop on both axes:
> https://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n3399
>
> The usual caveats apply, that doesn't help if the app plays smart and
> tries to implement its own scroller widget.

i was testing under x with my wheel and 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 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

[The Rasterman]

On Wed, 26 Oct 2016 06:57:53 + "Alexis BRENON @Wayland"  said:

> Just to be sure that I understand clearly, what you call 'Toolkit' is
> libraries like GTK, Qt, and co. that are used by developers to build their
> apps, isn't it ?

yes. toolkit == EFL, Qt, GTK+ and others (SDL is kind of a toolkit), FLTK, ...
chromium/blink is basically a toolkit of its own etc.

at least looking at gtk3 here it doesn't do momentum with wheel/axis scrolling
(out of the box). maybe it needs enabling? qt - same story. (not in standard
scrollable regions like in the file selector) but efl's scrollable regions do
silky smooth scrolling with momentum out of the box when you scroll your wheel
around - also as long as thumbsrcoll is enabled (it is on mobile profile) click
and drag to do the same like on mobile devices - with momentum when releasing.

my point here is - if you go mess with the input events as they actually come
from a device, it will totally mess with this kind of code that is doing all
the smoothing, interpolation and animated momentum already. it isn't the job of
a low level input event to go and try and pretend to have events it does not to
try and produce these kinds of effects which are already done at the toolkit
level by at least 1 toolkit, and the input device doesn't have the context
information a toolkit has to know when to stop, bounce back, or just do this in
steps rather than with momentum (eg with a slider widget).

> Finally, do you know some tiling DE/WM Wayland compliant ?

yes. enlightenment with tiling module enabled will do this. tiling module is a
bit rough, but people do use it.

> Kind,
> Alexis.
> 
> Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler <ras...@rasterman.com> a
> écrit :
> 
> > On Mon, 24 Oct 2016 18:42:31 + "Alexis BRENON @Wayland"  > +wayl...@gmail.com> said:
> >
> > > Hello everyone,
> > >
> > > I would like to implement kinetic scroll in the libinput driver for Xorg.
> > >
> > > I know that it's probably not the intended use of libinput ; as explained
> > > in the documentation, it's the client that have to manage that.
> > >
> > > However, as an Xorg user not happy with the synaptics driver, I would
> > like
> > > to add a similar feature (fixing small disagreements encountered with
> > > synaptics) to libinput, allowing Xorg users to easily move to libinput
> > > without losing this feature.
> > >
> > > My first idea is to implement the kinetic scroll using a thread that
> > sends
> > > axis events as long as there is no button event, key event or motion
> > event
> > > higher than a threshold.
> > >
> > > It makes some time since the last time I developed in C, and maybe it's
> > not
> > > the better way to do it. I would be happy to hear your advices.
> > >
> > > One thing I'm thinking of is then to add some options in the Xorg
> > > configuration file to enable/disable this feature, choose the events
> > > stopping the kinetic scroll and change some thresholds. This will allow
> > to
> > > easily disable this feature in the future in case the clients manage the
> > > kinetic scroll on their own.
> > >
> > > What do you think of this? Is there someone already working on it? Is my
> > > proposition a good way to implement it?
> > >
> > > Thanks for your attention.
> > >
> > > Kind regards,
> > > Alexis BRENON.
> >
> > we already do kinetic scrolling higher up in the toolkit. we do
> > acceleration
> > using these events and we do smooth animated scrolling in our scroller and
> > not
> > just stepping, as well as momentum as we slid with bouncing at the ends.
> > it's
> > already done in toolkit out of the box. if you try and 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 client ... and even
> > then
> > there are a pile 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" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >


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

[The Rasterman]

On Wed, 26 Oct 2016 14:14:13 +0200 Christian Stroetmann
<stroetm...@ontolab.com> said:

> On 26.10.2016 08:57, Alexis BRENON @Wayland wrote:
> 
> @Raster: Thank you for your reminder.
> 
> Maybe Enlightenment with Tiling2 and kinetic scrolling is already what 
> you need.

yes. and then load the tiling module (and enable tiling for the desktops you
want it on etc. - in tiling settings).

> If I remember correctly I3 (www.i3wm.org)<http://i3wm.org/> might work 
> together with Wayland as well.

possibly might work too.

> In general, I have seen at all major toolkits transistion efforts to 
> Wayland since around 2 years. Some have matured while others are 
> experimental so to say.

indeed.

> Best Regards
> Christian Stroetmann
> 
> > Just to be sure that I understand clearly, what you call 'Toolkit' is 
> > libraries like GTK, Qt, and co. that are used by developers to build 
> > their apps, isn't it ?
> >
> > Finally, do you know some tiling DE/WM Wayland compliant ?
> >
> > Kind,
> > Alexis.
> >
> > Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler <ras...@rasterman.com 
> > <mailto:ras...@rasterman.com>> a écrit :
> >
> > On Mon, 24 Oct 2016 18:42:31 + "Alexis BRENON @Wayland"
> >  > +wayl...@gmail.com <mailto:wayl...@gmail.com>> said:
> >
> > > Hello everyone,
> > >
> > > I would like to implement kinetic scroll in the libinput driver
> > for Xorg.
> > >
> > > I know that it's probably not the intended use of libinput ; as
> > explained
> > > in the documentation, it's the client that have to manage that.
> > >
> > > However, as an Xorg user not happy with the synaptics driver, I
> > would like
> > > to add a similar feature (fixing small disagreements encountered
> > with
> > > synaptics) to libinput, allowing Xorg users to easily move to
> > libinput
> > > without losing this feature.
> > >
> > > My first idea is to implement the kinetic scroll using a thread
> > that sends
> > > axis events as long as there is no button event, key event or
> > motion event
> > > higher than a threshold.
> > >
> > > It makes some time since the last time I developed in C, and
> > maybe it's not
> > > the better way to do it. I would be happy to hear your advices.
> > >
> > > One thing I'm thinking of is then to add some options in the Xorg
> > > configuration file to enable/disable this feature, choose the events
> > > stopping the kinetic scroll and change some thresholds. This
> > will allow to
> > > easily disable this feature in the future in case the clients
> > manage the
> > > kinetic scroll on their own.
> > >
> > > What do you think of this? Is there someone already working on
> > it? Is my
> > > proposition a good way to implement it?
> > >
> > > Thanks for your attention.
> > >
> > > Kind regards,
> > > Alexis BRENON.
> >
> > we already do kinetic scrolling higher up in the toolkit. we do
> > acceleration
> > using these events and we do smooth animated scrolling in our
> > scroller and not
> > just stepping, as well as momentum as we slid with bouncing at the
> > ends. it's
> > already done in toolkit out of the box. if you try and 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 client ... and
> > even then
> > there are a pile 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"
> > --
> > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > <mailto:ras...@rasterman.com>
> >
> >
> >
> > ___
> > 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: Kinetic scroll in libinput Xorg driver

[The Rasterman]

On Mon, 24 Oct 2016 18:42:31 + "Alexis BRENON @Wayland"  said:

> Hello everyone,
> 
> I would like to implement kinetic scroll in the libinput driver for Xorg.
> 
> I know that it's probably not the intended use of libinput ; as explained
> in the documentation, it's the client that have to manage that.
> 
> However, as an Xorg user not happy with the synaptics driver, I would like
> to add a similar feature (fixing small disagreements encountered with
> synaptics) to libinput, allowing Xorg users to easily move to libinput
> without losing this feature.
> 
> My first idea is to implement the kinetic scroll using a thread that sends
> axis events as long as there is no button event, key event or motion event
> higher than a threshold.
> 
> It makes some time since the last time I developed in C, and maybe it's not
> the better way to do it. I would be happy to hear your advices.
> 
> One thing I'm thinking of is then to add some options in the Xorg
> configuration file to enable/disable this feature, choose the events
> stopping the kinetic scroll and change some thresholds. This will allow to
> easily disable this feature in the future in case the clients manage the
> kinetic scroll on their own.
> 
> What do you think of this? Is there someone already working on it? Is my
> proposition a good way to implement it?
> 
> Thanks for your attention.
> 
> Kind regards,
> Alexis BRENON.

we already do kinetic scrolling higher up in the toolkit. we do acceleration
using these events and we do smooth animated scrolling in our scroller and not
just stepping, as well as momentum as we slid with bouncing at the ends. it's
already done in toolkit out of the box. if you try and 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 client ... and even then
there are a pile 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" --
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 does not do transparent backgrounds

[The Rasterman]

st...
> > > >
> > > > 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
> > > > implementation, we cannot know what they (being proprietary) do.
> > > >
> > > > After you get that working, you still need to get the framebuffer
> > > > rendered such that you actually get alpha < 1.0 on some parts. You
> > > > may have problems with Weston's rendering. A non-opaque surface is
> > > > always rendered with blending and weston never uses glClear, so that
> > > > might cause blending artifacts. OTOH, in some cases the
> > > > renderer deliberately ignores 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
> >
> >


-- 
- 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] Introduce keyboard grabbing protocol

[The Rasterman]

On Tue, 30 Aug 2016 19:33:17 +0300 Constantine Kharlamov <hi-an...@ya.ru> said:

> 2016-08-30 15:22 GMT+02:00 Jonas Ådahl :
> > I think having a grab would mean one is focused. Though the point of
> > having a key grabbing protocol is simply to override the compositors
> > keybindings. A virtual machine will be very annoying to work with if
> > you can't have the VM or remote desktop client override those. For
> > example I want to Alt-Tab inside the VM or inside the remotely
> > controlled desktop; I wouldn't want to be forced to reconfigure all
> > remotely controlled desktops or virtual machines to use Ctrl-Tab.
> 
> Hello, coming here from the news.
> 
> I'm having the opposite use-case: at office I need to work with WinXP in
> VirtualBox, and it is annoying as hell that I have to press an additional key
> to switch desktop/window in the host system. It is annoying enough, that the
> fact that an ancient version of Awesome WM didn't allow to grab its keys
> become a show stopper for upgrading Awesome, for migrating to i3, and now to
> upgrading whole system.
> 
> If one really wants some apps to grub Compositor's keys, I think the
> compositors should offer the user to (dis)allow it.

that's the point. use a compositor that lets you enable or disable this. or
provide patches. compositors are now in charge of this policy. (likely they
should allow disabling on a per-window basis and be able to re-identify the
window/surface again next time it's created so it can re-apply the ban). just
because there is a protocol does not mean compositor have to slavishly
implemented it globally for everything. they can choose not to  as they see fit
and of course you are left with 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? :)

-- 
- 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 does not do transparent backgrounds

[The Rasterman]

ing artifacts. OTOH, in some cases the
> > renderer deliberately ignores 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

[The Rasterman]

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 to enable setting up inter surface
> > > relationships across clients. Potential use cases are out-of-process
> > > dialogs, such as file dialogs, meant to be used by sandboxed processes
> > > that may not have the access it needs to implement such dialogs.
> > > 
> > > It works by enabling a client to export a surface, creating a handle
> > > for the exported surface. The handle, in form of a unique string, may
> > > be shared in some way with other clients (for example the provider of
> > > the file dialog) which can then import the exported surface.
> > 
> > Have you considered passing an fd (have the compositor create a pipe)
> > instead of a string?
> > 
> > Then the shared token is impossible to guess.
> > 
> > Even so, this looks workable and not too hard to implement.
> 
> are you sure this should just be some client chosen string. this sounds bad in
> that it means if client choose bad strings they compromise their security.
> 
> https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wayland/session-recovery.xml
> 
> - the compositor will provide a uuid via an event. the idea is the compositor
> picks some big long sha1 or whatever hash string. client supplies this if it
> reconnects after compositor went away unexpectedly (crash/restart/upgrade).
> 
> i think a similar system but uuid's for "naming a surface" would be good. then
> client a can say "hey this dialog is for uuid xyz" as long as the client
> owning xyz can provide the uuid do this other one.
> 
> the point of uuid's is so they CAN survive process restarts too, compositor
> restarts etc. unlike fd's where the last process holding that fd dies  you
> lost the handle.

better:

https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wl2/session-recovery.c
https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wl2/session-recovery.h

and wrapper:

https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wl2/ecore_wl2_window.c

> > Reviewed-by: Derek Foreman <der...@osg.samsung.com>
> > 
> > Thanks,
> > Derek
> > > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> > > ---
> > > 
> > > Changes since v1:
> > > 
> > >  - Spelling and grammar fixes
> > >  - Wording changes (unexport -> revoke)
> > >  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
> > >  - Added sandbox client -> unsandboxed file browser dialog example to
> > > protocol description
> > >  - Removed left-over note about restriction of importing a handle only
> > > once. It should be possible to import a handle multiple times, but the
> > > protocol text had only been updated in one of two places.
> > > 
> > > 
> > > Jonas
> > > 
> > > 
> > > 
> > >  Makefile.am  |   1 +
> > >  unstable/xdg-foreign/README  |   4 +
> > >  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 ++
> > > ++ +++ 3 files changed, 191 insertions(+)
> > >  create mode 100644 unstable/xdg-foreign/README
> > >  create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > > 
> > > diff --git a/Makefile.am b/Makefile.am
> > > index 9e2a029..35df201 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -9,6 +9,7 @@ unstable_protocols
> > > = \
> > > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml  \
> > > unstable/tablet/tablet-unstable-v1.xml
> > > \
> > > unstable/tablet/tablet-unstable-v2.xml
> > > \
> > > +
> > > unstable/xdg-foreign/xdg-foreign-unstable-v1.xml  \
> > > $(NULL) 
> > >  stable_protocols
> > > = \ diff
> > > --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README new file
> > > mode 100644 index 000..f5bcb83
> > > --- /dev/null
> > > +++ b/unstable/xdg-foreign/README
> > > @@ -0,0 +1,4 @@
> > > +xdg foreign protocol
> > > +
> > > +Maintainers:
> > > +Jonas Ådahl <jad...@gmail.com>
> > > diff --gi

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

[The Rasterman]

 > be
> > +   used.
> > +  
> > +
> > +
> > +
> > +  
> > +   The import request imports a surface from any client given a handle
> > +   retrieved by exporting said surface using xdg_exporter.export. When
> > +   called, a new xdg_imported object will be created. This new object
> > +   represents the imported surface, and the importing client can
> > +   manipulate its relationship using it. See xdg_imported for details.
> > +  
> > +
> > +   > +  summary="the new xdg_imported object"/>
> > +   > +  summary="the exported surface handle"/>
> > +
> > +  
> > +
> > +  
> > +
> > +  A xdg_exported object represents an exported reference to a surface.
> > The
> > +  exported surface may be referenced as long as the xdg_exported
> > object not
> > +  destroyed. Destroying the xdg_exported invalidates any relationship
> > the
> > +  importer may have established using xdg_imported.
> > +
> > +
> > +
> > +  
> > +   Revoke the previously exported surface. This invalidates any
> > +   relationship the importer may have set up using the xdg_imported
> > created
> > +   given the handle sent via xdg_exported.handle.
> > +  
> > +
> > +
> > +
> > +  
> > +   The handle event contains the unique handle of this exported
> > surface
> > +   reference. It may be shared with any client, which then can use it
> > to
> > +   import the surface by calling xdg_importer.import. 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?

[The Rasterman]

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 of the graphics felt fairly snappy, but the
> >> lag from pressing a key on the keyboard until a character showed up in
> >> the terminal was slow, probably between a quarter to half a second.
> >>
> >> So my question is if this is the performance I should expect with weston
> >> on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
> >> and there are easy ways to speed it up?
> 
> > when you say redraw is snappy... that implies that output is fast. so time
> > from deciding to render and update and it appearing is very short. but 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.
> 
> I put up a short video here:
> 
> http://zoo.weinigel.se/misc/2016-07-20-213549.webm

that's not snappy. :) startup takes quite a while. but after that moving the
terminal window around is maybe getting you 6-7fps or so.

> On the framebuffer I don't perceive any lag at all between a keypress 
> and the character appearing on the screen.
> 
> With weston-terminal running I can drag the window around and even 
> though it's not very fast and there's a bit of tearing it isn't too bad. 
> The response when dragging feels ok.  Keypresses feel laggy even though 
> mouse motion doesn't, but I'm not sure if that's because I don't notice 
> the lag when moving the mouse or if it is a real difference.

well they are done by different things. the move will be done directly by
weston itself. it will be asked to begin a window move by the client and then
just do it itself. render the changes. key events have a different path. they
go to client, client handles it, draws new frame, then weston has to update
screen with that new frame.

it seems to be either weston-terminal is just slow at drawing there and thus is
ending up taking a while to draw, add another 200ms or so for weston itself and
thats probably what's going on.

weston reads input, sends 1 or more key events to client.
client gets input now does some updates/rendering (let's say takes 200ms
assuming weston terminal is slow-ish at rendering). let's now say client sends
update buffer to weston. weston now gets it, spends 200ms rendering, then reads
buffered input, sends backto client (it may have sent it before), but weston
will be either rendering a frame (takes 200ms or a bit less) or sending events.
not both. that means at least some events could take 600ms to come back to the
screen (almost half a second) because weston got blocks then client renders,
then come back to screen. so maybe 500ms on average. half a second.

i think rendering is slow and due to the above it just adds latency to the
point where you see it easily. you only have a single cpu. any cpu time used up
one place cannot be used elsewhere. no multilpe cores. :)

that's my guess. weston is either reading input + sending, or drawing, and the
big blobs of time spent drawing mean it's not reading and sending. so that adds
UP to ~200ms THEN client gets these. client may be still drawing a previous
frame, so doesn't respond for a little bit. let's say 100ms. then client draws.
let's say 100ms, then client sends new frame over to compositor. compositor
gets frame, begins draw. now 200ms more. NOW you see what you just typed. 600ms
later. more or less. which is about what it looks like. when moving a window,
weston gets mouse events, weston redraws, repeat. so 200ms lag. speed up the
drawing or allow drawing to happen in parallel and you're good.

remember weston is the SAMPLE compositor. it will not have been tuned to run
ultra-fast on your setup. you likely have a 16bpp display but what's actually
going on is clients are rendering in 32bpp so taking longer to render that they
would natively (like the text console), and then weston is likely rendering in
32bpp too... THEN it's down-converting to 16bpp for display. none of that is
free. :) you will likely not find much support these days that doesn't involve
down-conversion as everyone is handling alpha and thus 32bpp (yes you can do
16bpp+alpha mask for example, or pack argb  into 16bpp and other
imaginative ways of getting it). dropping the whole pipeline down to something
like 16bpp+masks and a very carefully tuned pipeline would help.

(the reason i say 16bpp + masks is you can do a memcpy for the 16bpp data
direct to memory and since this doesn't convert it likely will be 2-3 times
faster - on the compositor fb side. on the client side the mask can be
pre-computed once for the window

Re: Weston on framebuffer?

[The Rasterman]

On Tue, 19 Jul 2016 18:10:16 +0200 Christer Weinigel <chris...@weinigel.se>
said:

> Hi,
> 
> I'm trying to port Linux to a Samsung S3C2416 based system (actually an
> oscilloscope, http://blog.weinigel.se/2016/05/01/sds7102-hacking.html).
> 
> The S3C2416 is a 400MHz ARM9 with a fairly dumb framebuffer, it has some
> 2D acceleration (pixel/line drawing with alpha, copy rectangle with
> alpha and/or color key) but as far as I can tell nobody has added Linux
> support for it.
> 
> I'm going to need some kind of GUI for the box and somebody mentioned
> that Weston has framebuffer support nowdays.  I turned on the Weston
> config option in buildroot (2015.5) and managed to get something that
> didn't work to begin with, the OS abstraction stuff requires support for
> posix_fadvise but for some reason that didn't work with ulibc but I
> hacked around that.  libinput didn't like eudev and didn't want to
> recognize a USB keyboard and USB mouse to begin with but I just
> hardcoded the device type instead of relying on udev to tag the devices.
> 
> With this I managed to get a desktop and was unable to start
> wayland-terminal.  Redrawing of the graphics felt fairly snappy, but the
> lag from pressing a key on the keyboard until a character showed up in
> the terminal was slow, probably between a quarter to half a second.
> 
> So my question is if this is the performance I should expect with weston
> on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
> and there are easy ways to speed it up?
> 
> Is there any documentation on how to convert the framebuffer driver for
> the S3C2416 to a KMS driver and how to add acceleration support?  Can
> weston use this?
> 
> Or is wayland/weston not really suited for this kind of old hardware and
> what should I use in that case?
> 
>   /Christer

when you say redraw is snappy... that implies that output is fast. so time from
deciding to render and update and it appearing is very short. but 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 Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

On Tue, 12 Apr 2016 15:25:36 + Mike Blumenkrantz
<michael.blumenkra...@gmail.com> said:

> Sure, that sounds good to me!

i like the idea of keeping < 0 invalid for now... it leaves wiggle room in
future to maybe make it valid and have special meaning but for now is invalid
thus can be assumed to not be used.

> On Tue, Apr 12, 2016 at 11:24 AM Olivier Fourdan <ofour...@redhat.com>
> wrote:
> 
> > Hi Mike.
> >
> > > Okay, if we're not going with uints then at the least can the "use 0 to
> > > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> > > cover that case?
> >
> > I think we should simply indicate that the width and height must be
> > greater than or equal to zero, so we remain consistent with the other
> > descriptions (namely set_window_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 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

[The Rasterman]

On Mon, 4 Apr 2016 12:05:05 -0700 Bill Spitzak <spit...@gmail.com> said:

> I do not like clients having to update this value continuously as
> conditions change. I would prefer any kind of design where the calculation
> of the maximum size is deferred until it is actually used, ie at the point
> that the user does whatever action attemts to make the window larger.

why? apps rarely change min/max size and if they do they invariably also want
to resize and re-render. what is the problem with changing min and/or max size
at the same time? it's not like its a huge cost considering everything else...

> Perhaps an event similar to fullscreen saying "make yourself the largest
> size you want" would work. I'm wondering if "maximize" can just be reused
> for this.

the logic behind a max size hint is not to have the apps switch to it but to
know in advance what it might be so you can lay out windows nicely - very
useful for tiling wm's.

> On Mon, Apr 4, 2016 at 11:15 AM, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> 
> >
> >
> > On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan <ofour...@redhat.com>
> > wrote:
> >
> >> Hi Mike,
> >>
> >> > Hm, you raise some interesting points. However, I think your argument is
> >> > somewhat misled by your claim that "this case is unique". If there is an
> >> > application which does not want to be larger than a certain size, why
> >> could
> >> > there not also be an application which does not want to be smaller than
> >> a
> >> > certain size?
> >>
> >> It's unique because switching to maximize/fullscreen is not an
> >> interactive resize, ie the client doesn't have its word on the state change
> >> that implies the resize, and is mandatory configure event, until it's set
> >> by the compositor (ie too late, the client must obey, period).
> >>
> >
> > Maximize can mean different things in different cases. For example,
> > suppose a compositor has a maximize policy where it can "maximize" a window
> > to take up the top-left 25% of the screen. This size could be too small for
> > the application, yet it falls within your non-interactive resize case.
> >
> >
> >>
> >> > It seems like continuing to add size hints based on this logic is almost
> >> > guaranteed, especially if you then add in the point of tiling
> >> > policies--surely handling tiling would be made even easier by adding
> >> > min/step/aspect sizes!
> >> >
> >> > To me, xdg-shell should just be a bare minimum of things required to
> >> > implement a UI with Wayland. Perhaps if there's a real need for size
> >> hints
> >> > (which I really hope there isn't, since it made X11 window sizing very
> >> > annoying) then there should be a separate size hints protocol where all
> >> of
> >> > this can be implemented?
> >>
> >> One case where a compositor may need a min size hint is a tiling
> >> window/compositing manager, so it can base its heuristics on those hints
> >> from the clients to get the optimal window size for tiling, but I would let
> >> those who implement such a window/compositor manager advocate for that,
> >> 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

[The Rasterman]

On Mon, 4 Apr 2016 22:40:10 -0700 Bill Spitzak <spit...@gmail.com> said:

> I think sending stepping size or aspect is not needed, but steps will 
> work only if the client can add a constant. Ie the width can be n*A+B 
> where A and B are specified by the client. The X11 version did not allow 
> a client to add a border that was not a multiple of the steps thick, 
> which made it pretty much impossible.

yes the x11 version DId allow this. that's what base size was. stepping was to
be done as base size + integer * step. read icccm.

of course when i mention stepping i do mean base + size in integer multiples
of a step as that is what icccm did and what existing apps have come to support
and use and... what is necessary.

> Aspect also needs the ability for the client to add a constant so a 
> frame can be put around the fixed-content area.

aspect does this too. in fact it was min and max aspect  accounting for
base size too:

http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html

x11 did get this right. aspect was really minimally useful. stepping was useful
for just about every terminal and min/max have been widely used by apps.

> 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...@mecheye.net> said:
> >
> >> I think min/max hints are acceptable in xdg-shell.
> >
> > i agree. they are realistic things a apps have as constraints on their
> > content. knowing in advance what those constraints might be can make life
> > for a compositor much easier.
> >
> > eg. if you set max size and its < screen size (or whatever size a maximized
> > window might be in the wm) the em/compositor can disable the maximize action
> > entirely.
> >
> > already pointed out - tiling wms can alter their layout policy for content
> > eg placing content that has a small max height along the bottom or top of
> > your screen.
> >
> > yes - asking for max size opens up min size too.
> >
> > i would argue size stepping is kind of needed too - the case of a tiling wm
> > with eg:
> >
> > +---+---+
> > | 1 | 2 |
> > +---+---+
> > | 3 | 4 |
> > +---+---+
> >
> > if all the windows are terminals whose content is only correct at "size
> > units" (because otherwise the terminal pads out N pixels without expanding
> > the terminal grid there just wasting space), then when resizing the
> > dividers across the middle of the screen -0 dragging them up/down or
> > left/right a wm might want to limit the sizing to steps of N pixels
> > assuming all clients involved share a common size step (the implied default
> > is 1 pixel). without this hint a wm is unable to do anything sensible here.
> >
> > i am not saying the wm MUST follow the hints. there are impossible cases.
> > one window (1) uses size step 10x10, and (2) uses 9x9... there are very few
> > points where they "agree". (at 0x0 +base, 90x90 + base , 180x180 + base
> > etc.) so as a wm i would assume it would only follow stepping if all steps
> > are multiples of each other eg 3x3, 6x6, 9x9 or 2x2, 4x4, 6x6, 8x8 etc. ...
> > (or are the same). clients still have to deal with arbitrary sizing in some
> > sensible way.
> >
> > aspect hints tho are rather painful. they assume a single piece of content
> > that has to retain aspect (eg 1 movie). i'd personally not want to go this
> > far. :)
> >
> >> 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 <ofour...@redhat.com>
> >>> wrote:
> >>>
> >>>>
> >>>> Hi Mike,
> >>>>
> >>>> - Original Message -
> >>>>> [...]
> >>>>>
> >>>>> 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.
> >>>>
> >>>> My turn to play the Devil's advocate then :-)
> >>>>
> >>>> And even if we end with more hints eventually, what is wrong with that?
> >>>>
> >>>> I reckon if we had hints in X11, it's also because people have had a n

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

[The Rasterman]

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.

i agree. they are realistic things a apps have as constraints on their content.
knowing in advance what those constraints might be can make life for a
compositor much easier.

eg. if you set max size and its < screen size (or whatever size a maximized
window might be in the wm) the em/compositor can disable the maximize action
entirely.

already pointed out - tiling wms can alter their layout policy for content eg
placing content that has a small max height along the bottom or top of your
screen.

yes - asking for max size opens up min size too.

i would argue size stepping is kind of needed too - the case of a tiling wm
with eg:

+---+---+
| 1 | 2 |
+---+---+
| 3 | 4 |
+---+---+

if all the windows are terminals whose content is only correct at "size units"
(because otherwise the terminal pads out N pixels without expanding the
terminal grid there just wasting space), then when resizing the dividers across
the middle of the screen -0 dragging them up/down or left/right a wm might want
to limit the sizing to steps of N pixels assuming all clients involved share a
common size step (the implied default is 1 pixel). without this hint a wm is
unable to do anything sensible here.

i am not saying the wm MUST follow the hints. there are impossible cases. one
window (1) uses size step 10x10, and (2) uses 9x9... there are very few points
where they "agree". (at 0x0 +base, 90x90 + base , 180x180 + base etc.) so as a
wm i would assume it would only follow stepping if all steps are multiples of
each other eg 3x3, 6x6, 9x9 or 2x2, 4x4, 6x6, 8x8 etc. ... (or are the same).
clients still have to deal with arbitrary sizing in some sensible way.

aspect hints tho are rather painful. they assume a single piece of content that
has to retain aspect (eg 1 movie). i'd personally not want to go this far. :)

> 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 <ofour...@redhat.com>
> > wrote:
> >
> >>
> >> Hi Mike,
> >>
> >> - Original Message -
> >> > [...]
> >> >
> >> > 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.
> >>
> >> My turn to play the Devil's advocate then :-)
> >>
> >> And even if we end with more hints eventually, what is wrong with that?
> >>
> >> I reckon if we had hints in X11, it's also because people have had a need
> >> for such a mechanism...
> >>
> >> Cheers,
> >> Olivier
> >>
> >
> > Sure, and as I said, I have no issues with that if a separate (optional)
> > protocol  is created for it. I just don't think that the best place for it
> > is in xdg-shell, which is supposed 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

[The Rasterman]

 your users to
> bring the best tools available into your environment?

because i have implemented extensibility many times over in the past 20 years.
i've come to the conclusion that they create a poor user experience with
loosely integrated components that either look ugly, don't work like the rest of
the de or do horrible hacks that then create trouble. what does work well is
tight integration. the manpower we have we have i'd RATHER devote to making
things better out of the box and having features than just saying "bah - we
give up and hope someone else will do it". every time i have done this, it has
lead to sub-optimal or poor results. you give up solving a problem and instead
then rely on 3rd party tools that don't look right, or function well, or
integrate or then don't support things YOU want to do later on (eg like the
per-screen profiles in screen output config).

maybe YOU want to do it that way - fine. that's your choice, but most other
DE's are integrated. They work on/provide their own tools and code and logic. :)

> > i disagree. i can't take linux and just use some bsd device drvier with it
> > - oh dear. that's against the spirit free software! i have to port it and
> > integrate it (as a kernel module). wayland is about making the things that
> > HAVE to be shared protocol just that. the things that don't absolutely have
> > to be, we don't. you are able to patch, modify and extend your de/wm, all
> > you like - most de's provide some way to do this. gnome today uses js. e
> > uses loadable modules. i am unsure about kde. :)
> 
> Sure, but you can use firefox and vim and urxvt while your friend
> prefers termite and emacs and chromium, and your other friend uses gedit
> and gnome-terminal and surf.

big difference - "apps" vs "desktop". of course this line is a grey area. i
consider the line at shelves/panels/filemanager/settings for desktop and
system/desktop bg/wallpaper/config tools/virtual keyboards/wm+compositor those
are on the desktop side. browser, terminals, editors are firmly in "apps" land.
it may be that your de of choice provides apps that work with the
look/feel/philosophy/toolkit of your de - but they are separate. that is where
i draw the line.

> > what happens when you need to restart sway after some development? where do
> > all your terminals/editors/ide's, browsers/irc clients go? they vanish and
> > you have to re-run them?
> 
> Most of my users aren't developers working on sway all the time. Sway
> has an X backend like Weston, I use that to run nested sways for
> development so I'm not restarting Sway all the time. The compositor
> crashing without losing all of the clients is a pipe dream imo, I'm not
> going to look into it for now.

then you are relying on x to do development, you can never get rid of x11 -
ever then...

i don';t see it as a pipe dream. all you need is the ability to recognize a
client and its surfaces from a previous connection and have clients reconnect
and provide whatever information is necessary to restore that state (eg an id
of some sort).

> > > > aaah ok. so compositor adapts. then likely i would express this as a
> > > > "minimize your decorations" protocol from compositor to client, client
> > > > to compositor then responds similarly like "minimize your decorations"
> > > > and compositor MAY choose to not draw a shadow/titlebar etc. (or client
> > > > responds with "ok" and then compositor can draw all it likes around the
> > > > app).
> > > 
> > > I think Jonas is on the right track here. This sort of information could
> > > go into xdg_*. It might not need an entire protocol to itself.
> > 
> > i'd lean on a revision of xdg :)
> 
> I might lean the other way now that I've seen that KDE has developed a
> protocol for this. I think that would be a better starting point since
> it's proven and already in use. Thoughts?

if you plan on 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
> > you avoid conversion. 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
> > again ... just. but it'd be better not to decode AND encode by take the
> > mp4/whatever stream directly and shuffle it down the network pipe. :)
> > 
> > believe it or not TODA

Re: Collaboration on standard Wayland protocol extensions

[The Rasterman]

hat have a minx/max size without introducing the
need for a floating property. that is something entirely different. not solved.
what happens when you need to restart sway after some development? where do all
your terminals/editors/ide's, browsers/irc clients go? they vanish and you have
to re-run them?

> > > You misunderstand me. I'm not suggesting that these apps be crippled.
> > > I'm suggesting that, during the negotiation, they _object_ to having the
> > > server draw their decorations. Then other apps that don't care can say
> > > so.
> > 
> > aaah ok. so compositor adapts. then likely i would express this as a
> > "minimize your decorations" protocol from compositor to client, client to
> > compositor then responds similarly like "minimize your decorations" and
> > compositor MAY choose to not draw a shadow/titlebar etc. (or client
> > responds with "ok" and then compositor can draw all it likes around the
> > app).
> 
> I think Jonas is on the right track here. This sort of information could
> go into xdg_*. It might not need an entire protocol to itself.

i'd lean on a revision of xdg :)

> > > I don't want to rehash this old argument here. There's two sides to this
> > > coin. I think everyone fully understands 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 same decorations,
> dammit :) Too bad I don't have much hope for making my cursor theme
> consistent across my entire desktop...

but COOKIES! COOOKIES! :)

> > > 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 :)
> 
> I'll go back to the earlier argument of "we shouldn't cripple the
> majority for the sake of the niche". Who on Earth is going to drive an
> 8K display on a 1.3ghz ARM device anyway :P

... 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 you
avoid conversion. 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 again ... just.
but it'd be better not to decode AND encode by take the mp4/whatever stream
directly and shuffle it down the network pipe. :)

believe it or not TODAY tablets with 4k screens ship. you can buy them. they
are required to support things like miracast (mp4/h264 stream over wifi). it's
reality today. products shipping in the 100,000's and millions. :)

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

[The Rasterman]

 your backlog. I'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

[The Rasterman]

ising this info from the compositor is not
> > standardized. what do you advertise to clients? where/when? at connect
> > time? at surface creation time? what negotiation is it? it easily
> > could be that 1 screen or desktop is tiled and another is not and you
> > dont know what to tell the client until it has created a surface and
> > you know where that surface would go. perhaps this might be part of a
> > larger set of negotiation like "i am a mobile app so please stick me
> > on the mobile screen" or "i'm a desktop app - desktop please" then
> > with the compositor saying where it decided to allocate you (no mobile
> > screen available - you are on desktop) and app is expected to adapt...  
> 
> In Wayland you create a surface, then assign it a role. Extra details
> can go in between, or go in the call that gives it a role. Right now
> most applications are creating their surface and then making it a shell
> surface. The compositor can negotiate based on its own internal state
> over whether a given output is tiled or not, or in cases like AwesomeWM,
> whether a given workspace is tiled or not. And I don't think the
> decision has to be final. If the window is moved to another output or
> really if any of the circumstances change, they can renegotiate and the
> surface can start drawing its own decorations.

yup. but this signalling/negotiation has to exist. currently it doesnt. :)

> > there's SIMPLE stuff like - what happens when compositor crashes? how do we
> > handle this? do you really want to lose all your apps when compositors
> > crash? what should clients do? how do we ensure clients are restored to the
> > same place and state? crash recovery is important because it is always what
> > allows updates/upgrades without losing everything. THIS stuff is still "un
> > solved". i'm totally not concerned about screen casting or vnc etc. etc.
> > until all of these other nigglies are well solved first.
> 
> I'm still not on board with all of this "first" stuff. I don't see any
> reason why we have to order ourselves like this. It all needs to get
> done at some point. Right now we haven't standardized anything, and each
> compositor is using its own unique, incompatible way of taking
> screenshots and recording videos, and each is probably introducing some
> kind of security problem.

you aren't going to talk me into implementing something that is important for
you and not a priority for e until such a time as i'm satisfied that the other
issues are solved. you are free to do what you want, but standardizing things
takes a looong time and a lot of experimentation, discussion, and repeating
this. we have resources on wayland and nothing you described is a priority for
them. there are far more important things to do that are actual business
requirements and so the people working need to prioritize what is such a
requirement as opposed to what is not. resources are not infinite and free.

> > apps can show their own content for their own bug reporting. for system-wide
> > reporting this will be DE integrated anyway. supporting video capture is a a
> > can of worms. as i said - single buffer? multiple with metadata? who does
> > conversion/scaling/transforms? what is the security model? and as i said -
> > this has major implications to the rendering back-end of a compositor.
> 
> The compositor hands RGBA (or ARGB, whatever, I don't care, we just pick
> one) data to the client that's recording. This problem doesn't have to
> be complicated. As for the "major implications"...

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.

> > there's a difference. when its an internal detail is can be changed and
> > adapted to how the compositor and its rendering subsystem work. when its a
> > protocol you HAVE to support THAT protocol and the way THAT protocol defines
> > things to work or apps break.
> 
> You STILL have to get the pixels into the encoder on the compositor
> side. You will ALWAYS have to do that if you want to support video
> captures, 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

[The Rasterman]

ps it would require just exposing all the
layers, their config and have the client "deal with it" ? but that means the
compositor needs to expose its screen layout. do you include pointer or not?
compositor may draw ptr into the framebuffer. it may use a special hw layer.
what about if the compositor defers rendering - does a screen capture api force
the compositor to 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 compositor. ... can of worms :)

> --
> 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" --
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: Introduction and updates from NVIDIA

[The Rasterman]

no way the client WILL know what WILL be done
because that decision is made much later. long after client has allocated and
rendered its frame. the compositor now reacts to this input and makes a
decision (and may change its decision frame by frame).

it's an inefficiency then to de-tile and re-tile (or compress then
decompress ... etc.). there really should be a compositor to client hinting
protocol that covers how many subsurfaces might be best, what formats might be
best etc. etc. - e.g. in this case if there are many surfaces on screen the
compositor might just tell all clients "please stick to 1 surface with argb, no
scanout" and at least until all clients re-draw and copy/convert their buffers
into non-scanout buffers there is a cost to display (de-tile/de-compress). too
bad. then once all clients have adapted, things work better.

> The nice thing about EGLStreams here is that if the consumer (the Wayland
> compositor) wants to use the content in a different way, the producer
> must be notified first, in order to produce something suitable for the
> new consumer.

that's the problem... the compositor (consumer) makes this decision LATER, not
BEFORE. :) things have to work, efficiently or 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

[The Rasterman]

 that this would best be proven either as an
  external extension, or something that was prepared to live out-of-tree
  for a little while whilst it was proven.
 
  oh sure. we'd end up doing this kind of thing regardless - in xdg and
  wayland core or not. if not - we'd do an extn and have it all working etc.
  - then maybe come back for hey - this stuff works - see? how about we
  standardize and all agree on the same core protocol for this now?
 
 Yes! This is exactly how the system is supposed to work. :)
 
 Sounds like we're pretty much on the same page, and do have a couple
 of concrete points picked out. Progress!

sure. i expect the coming few years to be a bit chaotic and messy as dust
settles and everyone figures out how to work within a wayland world, and has to
fill gaps that had been filled before and perhaps the original teams that
solved these problems in x11 are long gone/moved on, but once this settles a
bit and we've had our fracases... things will be streamlined and well known. it
just will take time.


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

[The Rasterman]

 tries to do, although
   is specific to the client process rather than window iirc).
 
  It's similar to
  http://standards.freedesktop.org/idle-inhibit-spec/latest/re01.html
 
  It would require careful semantics that I'm not so sure about. Why is
  it being tied to the surface rather than the process important?
 
  because inhibition is about an app saying my window content is important -
  keep it visible and don't blank/dim etc.. people brute-force use a global
  control because that is all they have had, but it is really about content.
  that surface is playing a movie - when doing so - tag that surface as
  please don't blank me! (and likely another flag like please don't dim
  me!). if the surface is destroyed, hidden, moved to another virtual
  desktop - the inhibition can be lifted by the compositor as the content's
  desire to be always visible is now irrelevant due to context. and
  no-fullscreen mode does not equate to inhibit screensaver.
 
 Yes, exactly.
 
   They also
   suggested per-output blanking support so e.g. laptop lvds could be
   blanked but the projector be inhibited, or when watching a movie on
   dual-head, hyst the non-movie head powersaves off.  They also suggested
   having a 'dim' functionality which would put the display to maximum
   dimness rather than blanking it completely; I'm not sure on the use case
   here or how easy 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.
 
  thus why it should be on a surface. if my movie playback is on my external
  tv monitor and it asks to inhibit - the compositor will stop blanking the
  external screen, but it may happily blank the internal screen on the laptop
  - which is exactly what we really would want. if the information is
  per-surface, this kind of smart behavior is possible. there is no need for
  apps to know about multiple monitors and which to inhibit if the inhibition
  is tied to a surface.
 
 Which somewhat ties into the point I made earlier about descriptive
 intent ('this surface is a movie') rather than imperative commands
 ('don't blank wl_output@17').

agreed totally.

   I had hoped to discuss collaboration on testing, but without specifics
   there didn't seem to be strong interest.  One question was about
   collecting protocol dumps for doing stability testing or performance
   comparison/optimization with; while we're not doing that currently, that
   sounded straightforward and like it could be useful to investigate more.
  
  
   There was some confusion over what the purpose of xdg-shell really is;
   it was looked at as a reference implementation rather than as a
   lowest-common denominator that should be built *onto*.  So it seems that
   Wayland have some messaging to do to ensure xdg-shell really is
   'cross-desktop'.
 
  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.
 
 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...@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

[The Rasterman]

 above would be another extension.

  They also
  suggested per-output blanking support so e.g. laptop lvds could be
  blanked but the projector be inhibited, or when watching a movie on
  dual-head, hyst the non-movie head powersaves off.  They also suggested
  having a 'dim' functionality which would put the display to maximum
  dimness rather than blanking it completely; I'm not sure on the use case
  here or how easy it'd be to implement.
 
 If you have a per-surface inhibition API, per-output blanking becomes
 an implementation detail.

indeed. which is why we like it. it makes life simple to have smart behavior
for the desktop as a whole.

  I had hoped to discuss collaboration on testing, but without specifics
  there didn't seem to be strong interest.  One question was about
  collecting protocol dumps for doing stability testing or performance
  comparison/optimization with; while we're not doing that currently, that
  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 like exact file descriptors;
 replaying a protocol dump is basically exactly what a test client
 does. We can measure how quickly those run.
 
 Cheers,
 Daniel
 ___
 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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EFL/Wayland and xdg-shell

[The Rasterman]

 testing or performance
  comparison/optimization with; while we're not doing that currently, that
  sounded straightforward and like it could be useful to investigate more.
 
 
  There was some confusion over what the purpose of xdg-shell really is;
  it was looked at as a reference implementation rather than as a
  lowest-common denominator that should be built *onto*.  So it seems that
  Wayland have some messaging to do to ensure xdg-shell really is
  'cross-desktop'.
 
 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: libinput: Support for long press key detection?

[The Rasterman]

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 do this and have timeout infra with their mainloop handling.
 
 That's not always true, especially for very simple toolkits (GLUT for 
 example), and for demo code that shows how to use a window system api.

glut is a pretty primitive toolkit and doesn't do a very large amount of things
most of the full toolkits do, like have any timed infra. you could do it with a
slave thread though.

  Should they also do press vs
  drag handling too with hysteresis.
 
 I think having the compositor do this would be an excellent idea. 
 Currently it is very annoying that the rule for switching from click to 
 drag varies somewhat between applications. hover detection and whether 
 a click is a double would be immensely useful too. And get keyboard 
 repeat in there too.
 
 You are right that libinput should not do this. I see it as something 
 the compositor does. It is just like the gestures for touch.

now you're higher level - compositor. slight problem here is that to do click
cancellation the compositor would need to know the geometry of every clickable
element (button) within every surface at all times. this kind of violates a lot
of wayland design principles. click vs drag is more universal though, but then
we need to creat new event protocols for indicating this drag begin event for
instance. another event for longpressed etc. - the compositor does have
mainloop infra and thus timeouts don't have to be hacked into threads just to
stuff one into the wrong layer.

  Then where is
  the drag point? n pixels from first touch?
 
 Yes. The rule for sending a drag started event is some integration of 
 mouse motion and speed and second and third derivatives exceeding some 
 threshold. It also needs to be per-device, some of them may be able to 
 include pressure or other controls.
 
  at boundary of widget?
 
 No, obviously not. If the client gets a drag started event, it is free 
 to remember that fact and not do anything about it until it gets motion 
 outside the widget.
 
  often dragging out of the widget cancels the click
  action - again widget sets do this.
 
 Of course the client does this. When the mouse goes outside the widget 
 it stops dragging. Compositor does not care. Any feedback such as 
 changing the cursor is done by the client.
 
  should libinput do it? you are looking at a
  long and obstacle-filled slippery slope to put this kind of thing in
  libinput.
 
 I see it as immensely simpler than the api to communicate user 
 preferences for this stuff to clients, which is going to be required if 
 multiple seats and outputs and remote desktops are used.
 
 Also gestures are already being done this way. The mouse and keyboard 
 should not be different.

-- 
- 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: libinput: Support for long press key detection?

[The Rasterman]

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 that the development of libinput
  was started to handle input devices in Wayland compositors. I had a look
  in the API documentation and found that the enum libinput_key_state
  has these values: LIBINPUT_KEY_STATE_RELEASED and
  LIBINPUT_KEY_STATE_PRESSED.
 
  There is a need to detect if a key is pressed (and hold) for a certain
  amount of time. If this is the case a long-press key event is send. It
  is also possible that several long-press key events are defined for one
  key, e.g.:
  - 500 ms: KEY_STATE_LONG_PRESSED_1
  - 1000 ms: KEY_STATE_LONG_PRESSED_2
  - 5000 ms: KEY_STATE_LONG_PRESSED_3
 
  A long press on a key is e.g. used to create a screen shot.
 
  Is there any plan to support this kind 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).
 
 Since the input handling code was put in an own library to avoid 
 duplicated code I was wondering if long press detection could also be 
 part of libinput. Then this has not to be implemented in every app/toolkit.
 
 Regarding the answer from Peter, that this would be too high level for 
 libinput, just for my information I wonder where is the border of 
 libinput? Which kind of input handling will be part and which not?

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 do
this and have timeout infra with their mainloop handling. they also do press vs
drag handling too with hysteresis. should libinput do this too? then where is
the drag point? n pixels from first touch? at boundary of widget? if there is a
boundary - where is it? often dragging out of the widget cancels the click
action - again widget sets do this. should libinput do it? you are looking at a
long and obstacle-filled slippery slope to put this kind of thing in libinput.

- 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: libinput: Support for long press key detection?

[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 that the development of libinput 
 was started to handle input devices in Wayland compositors. I had a look 
 in the API documentation and found that the enum libinput_key_state 
 has these values: LIBINPUT_KEY_STATE_RELEASED and 
 LIBINPUT_KEY_STATE_PRESSED.
 
 There is a need to detect if a key is pressed (and hold) for a certain 
 amount of time. If this is the case a long-press key event is send. It 
 is also possible that several long-press key events are defined for one 
 key, e.g.:
 - 500 ms: KEY_STATE_LONG_PRESSED_1
 - 1000 ms: KEY_STATE_LONG_PRESSED_2
 - 5000 ms: KEY_STATE_LONG_PRESSED_3
 
 A long press on a key is e.g. used to create a screen shot.
 
 Is there any plan to support this kind 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 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: [Help]Question about graphics architecture for weson/wayland

[The Rasterman]

On Tue, 19 Aug 2014 06:59:22 + Yang Andy williamyan...@hotmail.com said:

 Hi Pekka
 
 Thank you very much for your reply.
 
  If you have a DRM kernel driver supporting KMS, use Weston's drm-backend
  but pass --use-pixman on the command line.
 
 DRM kernel driver is for display device? Not for GPU?
 
 In other words,i can use drm-backend even though i have no GPU device.

you may not have a drm driver for your hardware, but nothing stops you having
fdrm and kms drivers even without a 3d gpu. you may havd 2d accel hardware that
you want to manage or just simply buffer allocation/management (a lot of older
hardware requires display buffers to be in linear/physical (not virtual) memory
and thus requires a specialized allocator. some requires it to be in specific
physical memory ranges (an older soc i know requires all gfx buffers for
display and 2d accel to be inside the first physical 16mb of ram - on even
older hardware before my linux days all gfx primitives, sprites, cursors,
audio data, fb scanout control commands and floppy disk i/o data had to reside
in the same 512kb and if it didn't it was the cpu's job to get it to/from
there).

if clients software rendered, but used drm buffers to render into, then it
might be possible for the compositor (eg weston) if it knows it can, to program
hardware layers or fbs to point directly to these buffers to scan-out from.
this is how you get truly zero-copy display/output, but it would require that
client uses drm directly to allocate buffers, use software to render (or
whatever it likes actually), then sends compositor drm buffers.

as such this is on a eventually we will do this plan for efl, but as it is
not easy to support drm in a universal way to allocate buffers for
scanout/display (not the last time i looked), we've got that on the back-burner.

if one day there are api's we could use where we can allocate drm buffers an
d ensure they are linear (or of a specific format) or query them for the
layouts we do support (tiled vs linear), and can request properties on
allocation - eg can scan out can be used as pointer can be used as
texture etc. then that'd be awesome and we'd use it for our software rendering
(and have a wayland_software_drm engine or something - or maybe make the shm
engine detect this if it is available and auto use if it works). but we don't
have that today because last i looked.. no such thing exists that we can use -
someone correct me if something has changed... please! :)

 Andy
  Date: Tue, 19 Aug 2014 09:44:14 +0300
  From: ppaala...@gmail.com
  To: williamyan...@hotmail.com
  CC: ras...@rasterman.com; wayland-devel@lists.freedesktop.org
  Subject: Re: [Help]Question about graphics architecture for weson/wayland
  
  On Tue, 19 Aug 2014 02:20:58 +
  Yang Andy williamyan...@hotmail.com wrote:
  
   My senario is that my target device do not support hardware
   accelerate.(do not use gpu) But i have to use EFL to develop
   application in wayland/weston platform.
   
   In order to achieve my task,how do i setup weston?
  
  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
  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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

On Mon, 18 Aug 2014 05:32:41 + Yang Andy williamyan...@hotmail.com said:

 Hi Pekka
 
 Thank you very much for your reply.
 
   3.In order to run weston-launch,do i have to use gpu?
  No, you can choose e.g. the fbdev backend for Weston, and so Weston
  will run on the /dev/fb, software rendered. No GPU used there in that
  sense. Software rendering also means that no application under Weston
  can use the GPU for rendering windows.
 
 If i choose fbdev backend for weston,can i use EFL/Evas and EGL/OpenGL for
 draw graphics? I mean that EGL/OpenGL which implement Software rendering.
 
 What the difference between
 drm-backend/fbdbin/eolian/impl_generator.c:ev-backend/wayland-backend/x11-backend?

EFL itself doesn't care what the compositor uses for acceleration. efl supports
either software rendering using shm protocol with wayland that SHOULD work
everywhere on all wayland compositors regardless of any driver infra, types,
acceleration etc. - there is also egl + gles2 rendering support for acelerated
rendering. of course compositor will then need to handle drm buffers etc. to
make this work.

 Best regards.
 
 Andy
  Date: Thu, 14 Aug 2014 16:57:26 +0300
  From: ppaala...@gmail.com
  To: williamyan...@hotmail.com
  CC: wayland-devel@lists.freedesktop.org
  Subject: Re: [Help]Question about graphics architecture for weson/wayland
  
  On Thu, 14 Aug 2014 08:36:43 +
  Yang Andy williamyan...@hotmail.com wrote:
  
   Hi everyone
   
   When i run 3D application through weston-launch, it failed because the
   graphics driver is not right.
  
  weston-launch starts weston, you cannot use it to launch something else.
  
   I have some questions for help.
   
   1.Is there any requirement for Hardware(GPU??) / Drivers?
  
  Yes, see hardware enabling at
  http://wayland.freedesktop.org/architecture.html
  
   2.Is DRM  must for weston(compositor),how to setup DRM?
  
  Weston's DRM backend depends on DRM. Make sure your kernel has a DRM
  driver for your graphics chip.
  
   3.In order to run weston-launch,do i have to use gpu?
  
  No, you can choose e.g. the fbdev backend for Weston, and so Weston
  will run on the /dev/fb, software rendered. No GPU used there in that
  sense. Software rendering also means that no application under Weston
  can use the GPU for rendering windows.
  
  You can also choose Weston's DRM backend with the software (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/(.ko??) and
   of kernel/driver/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.graphics architecture is
   Application⇒EGL/OpenGLES/⇒libDRM⇒DRM_.ko⇒.ko⇒GPU?
  
  Yes, where EGL/OpenGLES is actually Mesa, since you have libdrm there.
  This is specific to the open source drivers.
  
  
  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://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

On Tue, 19 Aug 2014 02:20:58 + Yang Andy williamyan...@hotmail.com said:

 Hi Carsten
 
 Thank you very much for your reply.
 
  EFL itself doesn't care what the compositor uses for acceleration. efl
  supports either software rendering using shm protocol with wayland that
  SHOULD work everywhere on all wayland compositors regardless of any driver
  infra, types, acceleration etc. - there is also egl + gles2 rendering
  support for acelerated rendering. of course compositor will then need to
  handle drm buffers etc. to make this work.
 
 If i choose software rendering using shm protocol,dose weston(compositor)
 use fbdev-backed?

what clients use is not relevant to what weston or the compositor might use.
shm is a universal works everywhere buffer exchange protocol for clients to
server. thus this works regardless what weston or any other compositor might
use to display. or should.

 My senario is that my target device do not support hardware accelerate.(do
 not use gpu) But i have to use EFL to develop application in wayland/weston
 platform.
 
 In order to achieve my task,how do i setup weston?

i can't tell you how to set up weston, but clients are a separate matter and
shm should work just fine.

 Best regards.
 
 Andy
  Date: Mon, 18 Aug 2014 15:02:47 +0900
  From: ras...@rasterman.com
  To: williamyan...@hotmail.com
  CC: ppaala...@gmail.com; wayland-devel@lists.freedesktop.org
  Subject: Re: [Help]Question about graphics architecture for weson/wayland
  
  On Mon, 18 Aug 2014 05:32:41 + Yang Andy williamyan...@hotmail.com
  said:
  
   Hi Pekka
   
   Thank you very much for your reply.
   
 3.In order to run weston-launch,do i have to use gpu?
No, you can choose e.g. the fbdev backend for Weston, and so Weston
will run on the /dev/fb, software rendered. No GPU used there in that
sense. Software rendering also means that no application under Weston
can use the GPU for rendering windows.
   
   If i choose fbdev backend for weston,can i use EFL/Evas and EGL/OpenGL for
   draw graphics? I mean that EGL/OpenGL which implement Software rendering.
   
   What the difference between
   drm-backend/fbdbin/eolian/impl_generator.c:ev-backend/wayland-backend/x11-backend?
  
  EFL itself doesn't care what the compositor uses for acceleration. efl
  supports either software rendering using shm protocol with wayland that
  SHOULD work everywhere on all wayland compositors regardless of any driver
  infra, types, acceleration etc. - there is also egl + gles2 rendering
  support for acelerated rendering. of course compositor will then need to
  handle drm buffers etc. to make this work.
  
   Best regards.
   
   Andy
Date: Thu, 14 Aug 2014 16:57:26 +0300
From: ppaala...@gmail.com
To: williamyan...@hotmail.com
CC: wayland-devel@lists.freedesktop.org
Subject: Re: [Help]Question about graphics architecture for
weson/wayland

On Thu, 14 Aug 2014 08:36:43 +
Yang Andy williamyan...@hotmail.com wrote:

 Hi everyone
 
 When i run 3D application through weston-launch, it failed because the
 graphics driver is not right.

weston-launch starts weston, you cannot use it to launch something else.

 I have some questions for help.
 
 1.Is there any requirement for Hardware(GPU??) / Drivers?

Yes, see hardware enabling at
http://wayland.freedesktop.org/architecture.html

 2.Is DRM  must for weston(compositor),how to setup DRM?

Weston's DRM backend depends on DRM. Make sure your kernel has a DRM
driver for your graphics chip.

 3.In order to run weston-launch,do i have to use gpu?

No, you can choose e.g. the fbdev backend for Weston, and so Weston
will run on the /dev/fb, software rendered. No GPU used there in that
sense. Software rendering also means that no application under Weston
can use the GPU for rendering windows.

You can also choose Weston's DRM backend with the software (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/(.ko??)
 and of kernel/driver/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.graphics architecture is
 Application⇒EGL/OpenGLES/⇒libDRM⇒DRM_.ko⇒.ko⇒GPU?

Yes, where EGL/OpenGLES is actually Mesa, since you have libdrm there.
This is specific to the open source drivers.


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

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten

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

[The Rasterman]

On Mon, 11 Aug 2014 18:05:42 -0400 Jasper St. Pierre jstpie...@mecheye.net
said:

 Rotated windows are not the only reason, but they do contribute. The
 ability to do an arbitrary transformation on the window is a very useful
 feature, for e.g. HiDPI support, and we'd like to expose as little data to
 the client as possible so we can enable better use cases.
 
 The client cannot get or set any transformations on its windows. And it
 will never be able to, as long as Kristian, Pekka, Jason, and I are writing
 the protocols and the code.

totally agree with you on this. there is a danger though. other wl compositors
may add it as an extension of their own and then one toolkit breaks rank and
uses/needs it and before you know it - all toolkits do this and you have a
problem on our hands.

the best is education - for developers and toolkit devs. why manual absolute
positioning is bad. (your hidpi example is a good one- auto scale lo dpi apps
up to 2x2 size or whatever).

 On Mon, Aug 11, 2014 at 5:59 PM, Bill Spitzak spit...@gmail.com wrote:
 
  I don't think rotated windows are the reason they are not supporting
  window position.
 
  Also the corner of the bounding box is a really awful control. Best to
  just use on of the corners, or the center. Assume the client can either get
  or set the rotation so it knows the actual bounding box.
 
 
  On 08/11/2014 09:49 AM, Nils Chr. Brause wrote:
 
  On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo
  giuliocamu...@gmail.com mailto:giuliocamu...@gmail.com wrote:
 
  The problem is that windows don't always have a meaningful position.
  If a window is shown on two outputs at the same time, maybe one of
  which a remote one, what is the window position? And what is the
  position of a window rotated 45 degrees?
 
 
  Since the question about absolute positioning of windows comes up every
  now and then (and probably will continue to do so for the next few
  years), I thought about a possible way to fix this.
 
  We could create a new interface, that puts an unrotated rectangle around
  a window (which could be transformed in whatever way), that is just big
  enough to fit in the whole window. The upper left corner of this
  rectangle could then be defined as its position, which could be read
  and set by the user. The size of this rectangle could also be of
  interest of the user, but of course not be set.
 
  Since a window could be on multiple outputs, there would be the need for
  one instance of this interface for every output and every window. These
  could maybe be created and destroyed with events (whenever a window
  appears or disappears on an output).
 
  This is not 100% thought through, but maybe a starting point.
 
 
 
  ___
  wayland-devel mailing list
  wayland-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/wayland-devel
 
   ___
  wayland-devel mailing list
  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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Question] Z-order management in Wayland

[The Rasterman]

On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com said:

 E.g. When we start a new application on mobile platform, previous running
 application could be hidden and paused to reduce power consuming
 and improve response speed. If we could adjust and get z-order status, we
 could callback application to sleep. And when user restart this
 application, we could just make this slept app waked up.

you do NOT want to do this by raise/lower. even doing this in x11 is just
WRONG. in fact a good mobile wm setup would refuse to allow this. there is a
netwm request netwm activate. this requests the window is activated. this MAY
raise the window. it may switch desktop. it may de-iconify a window. it may
also place focus on the window... unless the wm decides that this is a bad idea
right now.

you do NOT want a raise/lower etc. in wayland. you want xdg shell and an
activate request. the compositor after that decides what is best to do.

 Yan Wang
 
  There is currently no way to influence the stacking order of top-level
  surfaces. Why do you need this?
  On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote:
 
  Hi, All,
 I found X provides raise/lower APIs to manger window Z-order. But
  there
  isn't related APIs in Wayland/Weston.
 May it should be one design idea of Wayland in fact or I could
  achieve
  this  by current Wayland protocol?
 Thanks.
 
  Yan Wang
  ___
  wayland-devel mailing list
  wayland-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/wayland-devel
 
  ___
  wayland-devel mailing list
  wayland-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/wayland-devel
 
 
 ___
 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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Question] Z-order management in Wayland

[The Rasterman]

On Thu, 31 Jul 2014 01:57:44 -0700 (PDT) yan.w...@linux.intel.com said:

 Hi, Carsten,
   Thanks for your comments.
   I check efl code and I found
 _ecore_wl_window_cb_xdg_surface_active/deactivate is empty.
   As your comments, we should add code into them and pop related Ecore
 event out. Is it right?

yes - i don't know if the xdg shell protocol does this request at the moment -
but ultimateley it should as this is part of xdg standards to begin with and is
the right way. it's what apps etc. really want. not a raise or layer change.

   I could also find ecore_wl_window_raise() in ecore_wl_window.c. It
 shouldn't be used?

it'll only end up having an effect between subsurfaces. it won't do what you
want.

   And I am not sure whether USE_XDG_SHELL macro is enabled in current
 Tizen upstream.

i think not. i am not even sure about upstream atm - busy with lots of other
stuff and wayland work is understaffed.

 Yan Wang
 
  On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com said:
 
  E.g. When we start a new application on mobile platform, previous running
  application could be hidden and paused to reduce power consuming and
 improve response speed. If we could adjust and get z-order status, we
  could callback application to sleep. And when user restart this
 application, we could just make this slept app waked up.
 
  you do NOT want to do this by raise/lower. even doing this in x11 is
 just
  WRONG. in fact a good mobile wm setup would refuse to allow this. there
 is
  a
  netwm request netwm activate. this requests the window is activated.
 this MAY
  raise the window. it may switch desktop. it may de-iconify a window. it may
  also place focus on the window... unless the wm decides that this is a
 bad
  idea
  right now.
 
  you do NOT want a raise/lower etc. in wayland. you want xdg shell and an
 activate request. the compositor after that decides what is best to do.
 
  Yan Wang
   There is currently no way to influence the stacking order of
 top-level
   surfaces. Why do you need this?
   On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote:
  
   Hi, All,
  I found X provides raise/lower APIs to manger window Z-order. But
   there
   isn't related APIs in Wayland/Weston.
  May it should be one design idea of Wayland in fact or I could
   achieve
   this  by current Wayland protocol?
  Thanks.
  
   Yan Wang
   ___
   wayland-devel mailing list
   wayland-devel@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/wayland-devel
  
   ___
   wayland-devel mailing list
   wayland-devel@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/wayland-devel
  
  ___
  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
 
 
 
 
 
 ___
 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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Question] Z-order management in Wayland

[The Rasterman]

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. The client has to be able to decide whether a mouse 
 click will raise the window.

no it doesn't. it doesn't work like that in x11 and things work just fine. i've
been doing wm's and toolkits for a long time. wayland is well designed, if
perhaps a little spartan. :)

 The most obvious thing that does not work is drag  drop.

what has that got to do with a click raising or not? dnd is a separate protocol
element with its own semantics.

 It makes it impossible for a click to both raise the window and create a 
 floating window without blinking.

not so. :) as dnd is triggered on a DRAG = the mouse has MOVED beyond a
certain threshold beyond the place that the click happened - the creation of a
dnd icon is long after the click and the raise. this is precisely how it works
in x11 today - the click is intercepted by the wm with a passive grab and an
allow events to hand it on. that click may cause the wm to raise the window.
even the override-redirect window the client makes for dnd is fine...

in wayland dnd is a special thing and the compositor is directly involved

 And unless something MUCH more complicated than the current parent in 
 xdg_shell is used, it makes multiple-window software impossible. At 
 least a full Directed Acyclic Graph of multiple parents for every 
 surface is needed, though I really suspect an entire interpreted 
 language is needed to describe window stacking.
 
 This has to be fixed or you are violating the every frame is perfect 
 design criteria for Wayland.

nope. when a drag starts an icon surface (to be dragged about) it given to the
compositor. the compositor can happily ensure that that surface is at the
correct x/y AND always above everything - like the mouse pointer. lok at the
start_drag protocol request. :)

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

[The Rasterman]

On Thu, 20 Feb 2014 09:12:50 + (GMT) Seema Singh seema.si...@samsung.com
said:

 Hi All,
 
 In our module we have used the below mentioned   ecore_x APIs.
 1.ecore_x_window_focus_get()
 2.ecore_x_netwm_pid_get()
 
 We are planning to move to wayland platform. But  could not find the below
 APIs in ecore_wayland.h file Please let me know if anyone has come across the
 same issue.

first... by module... what does this code do? is it an enlightenment module? or
is it some external client process?

if it's literally a module inside enlightenment... enlightenment knows the
focus already - check other internal api's. you'll want to be looking at git
master to track dev and features there as that is where the most complete
wayland support is. as for pid - that would be something the compositor can get
by interrogating the fd of the client socket connection.

if this is a 3rd party app/process, the answer is the 3rd party process has no
business knowing either of these bits of information for security reasons and
simply 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

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

[The Rasterman]

On Fri, 21 Feb 2014 06:07:59 + (GMT) Seema Singh seema.si...@samsung.com
said:

 Hi Carsten,
 
 Thank you for your response.
 
 first... by module... what does this code do? is it an enlightenment module?
 or is it some external client process?
 
 it's not an enlightenment module. It's an external client process.
 
 
 so maybe you should first explain what you are doing, where and why, and
 then... we can figure out what to do about it. :)
 
 In our NFC module we are trying to do a NFC conditional APP launch.
 Whenever a tag detects, client processes the Tag NDEF data and launch the
 application if its not launched. 
 Focus window pid is used for below check:
 1. If focus window APP is not a NFC APP then launch the NFC APP
 2. If already launched but not in focus then bring it to foreground.

ok. then you're doing it wrong.

if you're planning on this for tizen 3 or have upgraded EFL, then you want to
look at gustavo's app server api. this is available in efl 1.8 and up:

http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server.c
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server.h
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server_eet.c
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server_eet.h

(and look at the elm_app_server api too that it uses).

an alternative for earlier efl is just to ipc to yourself:

http://git.enlightenment.org/apps/terminology.git/tree/src/bin/ipc.c
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/ipc.h

it's pretty simple. app creates a unix socket unique to itself and its
environment, and any new execution of the same binary/app tries to connect to
itself. this is the same case with both app_server and the ipc examples above.
they both work regardless of the display system you use. your app talks to
itself and passes any relevant arguments/info to the existing instance. the
existing instance can do whatever it likes. if you want a window to appear
and/or become focused (become active) use elm_win_activate() on the window.
this will request the wm to make the window active/bring attention to it/focus
it etc slight catch - there is no core wayland protocol for this
currently. this SHOULD be covered in the xdg_shell protocol, but this is new
and i haven't looked at it yet. ecore_evas attracts these things for you and
currently there is no implementation for this because of xdg_shell being new
and shiny and we have not gotten to implementing it all yet, BUT... if you do
what i suggest above, you WILL have an app that is portable and that WILL work
just as soon as the efl bits get hooked together and that the compositor you
have supports the protocols necessary for this.

let me just take the time to advise you to  NOT drop down to layers like
ecore_x in efl *IF* you want to be portable. let the layers that deal with
portability deal with it. if they are currently not, then it's either simply a
missing implementation in efl or maybe entirely missing protocol in wayland
land and working around it in your app will simply waste your time now AND in
future in removing stuff. work with us to ensure you have what you need
implemented. :)


 Regards,
 Seema.
 
 --- Original Message ---
 Sender : Carsten Haitzlerras...@rasterman.com 
 Date   : Feb 20, 2014 18:52 (GMT+09:00)
 Title  : Re: Wayland API to get the id of  focus window  [Seema Singh]
 
 On Thu, 20 Feb 2014 09:12:50 + (GMT) Seema Singh seema.si...@samsung.com
 said:
 
  Hi All,
  
  In our module we have used the below mentioned   ecore_x APIs.
  1.ecore_x_window_focus_get()
  2.ecore_x_netwm_pid_get()
  
  We are planning to move to wayland platform. But  could not find the below
  APIs in ecore_wayland.h file Please let me know if anyone has come across
  the same issue.
 
 first... by module... what does this code do? is it an enlightenment module?
 or is it some external client process?
 
 if it's literally a module inside enlightenment... enlightenment knows the
 focus already - check other internal api's. you'll want to be looking at git
 master to track dev and features there as that is where the most complete
 wayland support is. as for pid - that would be something the compositor can
 get by interrogating the fd of the client socket connection.
 
 if this is a 3rd party app/process, the answer is the 3rd party process has
 no business knowing either of these bits of information for security reasons
 and simply 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
 
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel
 pnbsp;/ppnbsp;/p