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

[Jasper St. Pierre]

Hi,

The trick is a variant of the well-known integer-to-float conversion
trick you do if you don't have dedicated hardware for it [0].

64-bit floats have a 52-bit significand and a floating exponent.
Wayland's 24.8 fixed point format can be thought of as a 32-bit
significand and a fixed exponent of 8. To convert from one to the
other. It's enough to stuff the 32-bit significand into the 52-bit
field without it overflowing, so that gets you *a* number, but you
need to set up the correct exponent. If you just try stuffing "8" in
the field, it won't work, because of the implicit "1" at the start of
the significand -- this is what ensures our exponent "buckets" are
non-overlapping, distinct ranges. We need to find the floating point
bucket that has the same precision as our input value. The correct
bucket is actually (num_bits_in_significand - num_bits_in_fixed_point)
-- so that's (52 - 8), which is 44. In the floating point format,
exponents are also biased by 1023, so that explains the "(1023 + 44)
<< 52". This is placing the right exponent in the exponent field of
the float.

The extra bit at (1 << 51) is a bias to handle signed values correctly
-- this way, adding a signed value to the float won't take us out of
our bucket.

However, because of that implicit 1, our floats are offset to a
different range. That's easy enough, we just need to subtract out the
start of that range. If you interpret ((1023 + 44) << 52) + (1 << 51)
as a double float, you see it ends up with a value of 0x1800,
which is indeed (3 << 43). There's probably a more direct way to
compute that, but I don't know what it is.

No clue if this helped at all, or just made things more confusing. In
any case, the existing code is correct, but a direct port to another
language might be tricky. If you want a portable method, I'd recommend
what Pekka suggests, which is just (v / 256.0f).

[0] https://cr.yp.to/2005-590/powerpc-cwg.pdf#page=104 , "Convert
32-Bit Unsigned Integer to Floating-Point Code Sequence"

On Tue, Jan 17, 2023 at 7:27 AM Pekka Paalanen  wrote:
>
> On Mon, 16 Jan 2023 14:43:43 +0800
> "程安絮"  wrote:
>
> > In file main.go is my implementation of FixedToFloat64 vs
> > wl_fixed_to_double, the comments can help you to understand my codes.
> > Since event wl_touch::orientation's orientation arg is fixed value
> > and can be negative, I think this bug is not acceptable. Besides, I
> > don't understand how wl_fixed_to_double works, can anyone illustrate
> > that for me?
> >
> > 程安絮
>
> Hi,
>
> that wl_fixed_to_double() implementation in C is a far too smart trick
> for no other good reason than trying to be fast in a case where speed
> is not needed.
>
> The human readable conversion would be:
>
> double wl_fixed_to_double(wl_fixed_t f)
> {
> return (double)f / 256.0;
> }
>
> The trick code seems to be just fine through. I've attached a test
> program that iterates through all possible wl_fixed_t values and
> ensures the trivial conversion agrees with the trick conversion.
>
> I cannot explain how it works, but it does seem to work.
>
>
> Thanks,
> pq



-- 
  Jasper

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

[Jasper St. Pierre]

To be clear, the patch does break backwards compatibility with compositor
behavior -- it only weakens a guarantee by saying that transparent
fullscreen content is undefined. Existing compositor behavior is still
allowed.

However, it does mean that clients might not get the output they desire
under new rules. It also does not make any new guarantees for a client -- a
fullscreen transparent terminal might show surfaces underneath, or it might
not. That hardly seems useful to me from a client perspective.

That said, adding a new request does not seem like a good solution to me --
if the user presses a compositor key shortcut, should the app be in
transparent or opaque fullscreen mode? It might make sense to have a
special "set_fullscreen_blend_mode" that clients can use to configure their
fullscreen appearance in all cases. I do not imagine this will change
often, so it likely does not need to be a state.

On Fri, Jun 21, 2019, 8:43 PM Michael Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> Hi,
>
> Some compositors and client toolkits do rely on the existing wording.
> Occlusion culling is used for (obvious) performance reasons in fullscreen
> cases. If the fullscreen surface is not opaque, clients can still rely on
> the compositor's handling of fullscreen states using the current wording
> and prioritize resources for this fullscreen surface even if there are
> other surfaces which are visible behind it. This is especially true for
> embedded cases.
>
> Given that releases and products have already shipped that rely on this
> language, and that the terminology and language used here is a core
> functionality of the feature, it absolutely cannot be changed.
>
>
> Regards,
> Mike
>
> On Fri, 21 Jun 2019 14:32:34 -0400
> "Drew DeVault"  wrote:
>
> > On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:
> > > This changes the semantics in a non-backward compatible way; clients
> > > relying on the currently defined behavior would break, so I'll have to
> > > nack this change. You'd have to add a `set_fullscreen_translucent` or
> > > something like that if the described behavior is needed.
> >
> > To re-use an argument that was brought up in the xdg-decoration
> > discussion: compositors are just going to do whatever they want here,
> > and this sets up expectations accordingly. Wayfire already disregards
> > this clause, and consider this an announcement of Sway's intentions do
> > to the same.
> >
> > In any case, I don't think this grossly affects the behavior clients
> > have come to rely on. I sought some feedback on this patch privately
> > before posting it to consider these concerns upfront. The main use-case
> > for the original wording was found to be media players which rely on
> > this behavior for letterboxing when the aspect ratio between the output
> > and the video differs - which is addressed in the proposed wording.
> >
> > Additionally, the original wording never made any promises as to the
> > relationship between the fullscreened surface and the output its shown
> > on. One notable example is that the unreliability of wl_output's
> > width/height specifications forces (correctly so) users to continue to
> > use configure events to communicate the desired size. This is especially
> > necessary with non-traditional outputs like VR headsets. Implementation
> > details like direct scan-out, which is only possible given the
> > constraints in the original wording, aren't actually guaranteed - but
> > are not ruled out by the new wording.
> >
> > What do you think? Does that rationale make more sense?
> > ___
> > 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jasper St. Pierre]

Hi,

>From IRC conversations with krh a long time ago, this is indeed intentional
and the cursor surface should "lose its role" in modern parlance.

The original intention was to prevent glitching of the cursor surface. e.g.
If the left side of the surface has a resize left cursor, you leave, and
hover over the right, you don't want to see the resize left cursor for a
split second before the resize right cursor appears.

The original implementation of Weston respected this and would only change
the cursor on set_cursor calls and would not even remember a per-client
cursor surface. This behavior has probably been lost in numerous reactors
by now.

On Tue, Jul 24, 2018, 2:52 PM Daniel Stone  wrote:

> Hey,
>
> On Tue, 24 Jul 2018 at 22:45, Derek Foreman
>  wrote:
> > On 2018-07-22 05:55 AM, Daniel Stone wrote:
> > > I take it the problem is that the client sets a particular surface as
> > > the pointer surface, loses focus, sets the same surface as the pointer
> > > surface on re-enter after not changing the content, and then the
> > > content is never shown?
> >
> > That's my understanding of what I'm seeing, yes.
> >
> > Note that it only happens when the cursor can be placed in the cursor
> > plane (ie: it's wayland_shm).
> >
> > The old cursor continues to be shown - if I move into an EFL client from
> > the desktop, the desktop cursor arrow is sometimes unchanged.
> >
> > I do get a surface enter for my pointer surface, though.
> >
> > I'm reasonably confident the first time I saw this I would get no cursor
> > at all on re-enter, but now I get the existing cursor.  Though sometimes
> > it updates to my client cursor, despite no damage or new buffer attach
> > on the surface.
>
> To be fair, this has changed a fair bit with atomic, so I'm not
> surprised it's different in master. But I am a bit disappointed it's
> not perfect yet. ;)
>
> Cheers,
> Daniel
> ___
> 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

Re: Window positioning

[Jasper St. Pierre]

(Please Reply All in the future so that responses go to the mailing list)

Hi Han,

In that case, you should probably use a protocol designed for embedded
surface layout, like ivi-shell, rather than xdg-shell. Embedded,
static-size display is a very different use case than a modern desktop
system which requires hotplug and multimonitor layouts.

On Wed, Jan 3, 2018 at 9:26 AM, Han, Guowei <guowei@johnsonoutdoors.com>
wrote:

> We are not allowing user move position since we are in an embedded system.
> So that’s not an issue for us. We don’t even have a mouse connected.
>
>
>
> *From:* magc...@gmail.com [mailto:magc...@gmail.com] *On Behalf Of *Jasper
> St. Pierre
> *Sent:* Wednesday, January 03, 2018 12:24 PM
> *To:* Han, Guowei <guowei@johnsonoutdoors.com>
> *Cc:* Kai-Uwe <ku.b-l...@gmx.de>; wayland <wayland-devel@lists.
> freedesktop.org>
> *Subject:* Re: Window positioning
>
>
>
> Hi Han,
>
> Allowing yourselves to place multiple windows where you want it then isn't
> going to solve that problem, since users can still drag them around,
> minimize them, etc. Multiprocess rendering is a bit tricksy, and there's no
> standardized way to do it right now. The traditional technique is to build
> your own Wayland compositor inside your application, which is a bit
> heavyweight, and then use wl_subsurface to composite the results. This is
> what e.g. WebKit2's architecture does, and it's something I've tried to
> implement in the past [0]. As the scope of a Wayland compositor becomes
> larger and larger over time, I think this is starting to become a bit
> impractical. It might be worth looking into a multi-process buffer-sharing
> protocol as a Wayland extension, since it's a use case that keeps coming up.
>
>
>
> [0] https://github.com/magcius/wakefield
>
>
>
> On Wed, Jan 3, 2018 at 5:23 AM, Han, Guowei <Guowei.Han@johnsonoutdoors.
> com> wrote:
>
> We are running a multi process application. And GUI is act as a
> transparent top layer. All other process rendering by them self underneath.
> So its important for other process to place the window at right potion.
>
> Sent from my iPhone
>
>
> On Jan 3, 2018, at 2:58 AM, Kai-Uwe <ku.b-l...@gmx.de> wrote:
>
> Maybe you are after a full screen application then. With that you should
> be able to decide about the positioning on the whole output.
>
> Am 03.01.2018 um 02:37 schrieb Han, Guowei:
>
> Thanks Jasper. Do u know if there's a demo i can learn from? Currently i
> am creating a bigger surface bigger than screen size. and make subsurface
> so i can posion them as i want. Really don't think its a good way to do it.
>
> Sent from my iPhone
>
>
> On Jan 2, 2018, at 4:25 PM, Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>
> *EXTERNAL EMAIL*
>
> Hi Han,
>
>
>
> You cannot position surfaces absolutely using the traditional xdg-shell
> protocol. However, for embedded cases, there are protocols like ivi-shell
> which provide that functionality.
>
>
>
> On Fri, Dec 29, 2017 at 10:09 AM, Han, Guowei <Guowei.Han@johnsonoutdoors.
> com> wrote:
>
> Hi,
>
>
>
> Wonder if there’s a way we can position window to anywhere we want using
> wayland or maybe weston?
>
>
>
> Thanks,
>
>
>
> The information in this email and any attachments may contain proprietary
> and confidential information that is intended for the addressee(s) only. If
> you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, retention or use of the contents of this
> information is prohibited. If you have received this email in error, please
> immediately contact the sender and delete the email.
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
>
>
> --
>
>   Jasper
>
>
>
> ___
>
> 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
>
>
>
>
> --
>
>   Jasper
>



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

Re: Window positioning

[Jasper St. Pierre]

Hi Han,

Allowing yourselves to place multiple windows where you want it then isn't
going to solve that problem, since users can still drag them around,
minimize them, etc. Multiprocess rendering is a bit tricksy, and there's no
standardized way to do it right now. The traditional technique is to build
your own Wayland compositor inside your application, which is a bit
heavyweight, and then use wl_subsurface to composite the results. This is
what e.g. WebKit2's architecture does, and it's something I've tried to
implement in the past [0]. As the scope of a Wayland compositor becomes
larger and larger over time, I think this is starting to become a bit
impractical. It might be worth looking into a multi-process buffer-sharing
protocol as a Wayland extension, since it's a use case that keeps coming up.

[0] https://github.com/magcius/wakefield

On Wed, Jan 3, 2018 at 5:23 AM, Han, Guowei <guowei@johnsonoutdoors.com>
wrote:

> We are running a multi process application. And GUI is act as a
> transparent top layer. All other process rendering by them self underneath.
> So its important for other process to place the window at right potion.
>
> Sent from my iPhone
>
> On Jan 3, 2018, at 2:58 AM, Kai-Uwe <ku.b-l...@gmx.de> wrote:
>
> Maybe you are after a full screen application then. With that you should
> be able to decide about the positioning on the whole output.
> Am 03.01.2018 um 02:37 schrieb Han, Guowei:
>
> Thanks Jasper. Do u know if there's a demo i can learn from? Currently i
> am creating a bigger surface bigger than screen size. and make subsurface
> so i can posion them as i want. Really don't think its a good way to do it.
>
> Sent from my iPhone
>
> On Jan 2, 2018, at 4:25 PM, Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>
> *EXTERNAL EMAIL*
>
> Hi Han,
>
> You cannot position surfaces absolutely using the traditional xdg-shell
> protocol. However, for embedded cases, there are protocols like ivi-shell
> which provide that functionality.
>
> On Fri, Dec 29, 2017 at 10:09 AM, Han, Guowei <Guowei.Han@johnsonoutdoors.
> com> wrote:
>
>> Hi,
>>
>>
>>
>> Wonder if there’s a way we can position window to anywhere we want using
>> wayland or maybe weston?
>>
>>
>>
>> Thanks,
>>
>>
>> The information in this email and any attachments may contain proprietary
>> and confidential information that is intended for the addressee(s) only. If
>> you are not the intended recipient, you are hereby notified that any
>> disclosure, copying, distribution, retention or use of the contents of this
>> information is prohibited. If you have received this email in error, please
>> immediately contact the sender and delete the email.
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>
>
> --
>   Jasper
>
>
>
> ___
> wayland-devel mailing 
> listwayland-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


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

Re: Window positioning

[Jasper St. Pierre]

Hi Han,

You cannot position surfaces absolutely using the traditional xdg-shell
protocol. However, for embedded cases, there are protocols like ivi-shell
which provide that functionality.

On Fri, Dec 29, 2017 at 10:09 AM, Han, Guowei <
guowei@johnsonoutdoors.com> wrote:

> Hi,
>
>
>
> Wonder if there’s a way we can position window to anywhere we want using
> wayland or maybe weston?
>
>
>
> Thanks,
>
>
> The information in this email and any attachments may contain proprietary
> and confidential information that is intended for the addressee(s) only. If
> you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, retention or use of the contents of this
> information is prohibited. If you have received this email in error, please
> immediately contact the sender and delete the email.
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


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

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

[Jasper St. Pierre]

Hi,

There's a few reasons that Wayland not to report or allow clients to choose
absolute screen position.

The biggest is that from our experience with X11, it's hard to even
*define* such a space. Laptops plug into external monitors and projectors.
People with differently sized monitors have gaps -- the space isn't as
cleanly defined as a large rectangle. In my experience working on X11 WMs,
clients often "fight" the WM over placement, preferring to request a
position which is now offscreen because the user undocked their computer.
Simply not defining a coordinate space to position windows in is easier
than defining one, with all the complexities and edge cases that arrive
from 30+ years of developments in computer interaction.

One of Wayland's design goals is that where possible, compositors, not
clients, have the final say. While it can be more difficult to program for,
Wayland has concepts based around a relative positioning model. This allows
the compositor to place clients where it sees fit, and allows compositors
to more freely make constrainment choices so that menus don't get stuck
behind taskbar panels, or similar things.

It certainly has made some things more complicated, so it might have been
an overreaction to the complexity we all faced with X11. Hopefully that
gives you some insight into why we chose not to expose positioning to the
client.

On Tue, Nov 21, 2017 at 8:47 AM, Jari Vuomajoki 
wrote:

> Hello!
>
> I have been getting to know the Wayland protocol from the client side for
> only couple of months... So bare with me if my questions sound immature.
>
> It took a while to get going, the documentation is there and it is
> informative enough to build a client. It could be a lot better though or
> maybe I didn't find a proper source for it. Doxygen documentation ended up
> being the most useful.
>
> Here is my list of questions and thoughts. Feel free to anwer or comment
> on any of them.
>
> I want to compose clients based on screen dimensions. I know there are
> fullscreen and maximized options. But I want to have total control of top
> level surface sizes and placements in the screen. Now talking about single
> screen, but this can be extented to multiple screens.
>
> This option is not part of the protocol. I can query the screen size
> through wl_output interface, so why I cannot position a surface in arbitary
> position? Why this option has been left out?
>
> I want to be able to manage the positions of all the top level shell
> surfaces of the client connection.
>
> Ok, so now I asked it in three different ways...
>
> I can naturally extend weston shell and implement this option, but it
> seems a bit overkill for such a simple option to have. What I am not
> getting in the picture?
>
> Best Regards,
> Jari Vuomajoki
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


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

Re: Fragment Shader of FP16 produces incorrect image drawing.

[Jasper St. Pierre]

Hi,

If you're worried about FP16 interpolation accuracy (which, as the vendor
states, only gets you 10 bits of accuracy, so only 1024 different values --
definitely not big enough to drive a maximized window at normal desktop
resolutions), you can try using normalized GL_SHORT texture coordinates
instead. I don't know if the hardware you have supports fixed-point
interpolation for vertex attributes, you would need to ask your vendor
about that. You can also try changing the "precision mediump"s in
gl-renderer.c to "precision highp"s. I would hope a decent GPU would
support at least FP32.

Anything else would require extensive changes to either use texelFetch or
rectangle textures, both of which are things you likely don't want to do.

On Tue, Nov 21, 2017 at 12:08 AM, YoungJun Jo  wrote:

> Hi,
>
> The uploaded image was not capture using the camera or mobile phone.
> I captured image using the screenshot program.
> So that's not related display signals or illusion or the human vision.
> The triangle error is shown in the top-right area when you see the image
> with the original image state of 100% without scaling, that is 1280*720
> size.
> Download image and open with your program, do not resize.
>
> As mentioned in the previous mail, changing the logic to from GL_LINEAR
> to GL_NEAREST in *draw_view()* function, the incorrect drawing
> of the triangle has disappeared. I have done the tests using pixman
> render,
> so all RGB data values ​​are exactly the same.
> I would like to know that this is related to the GPU's fragment shader
> fp16 constraint.
>
> I linked the original image, error image and my analysis as shown below.
> original-image
> 
> error-image
> 
> analysis excel file
> 
>
> If you think that this issue is not related to weston, you can ignore it:-)
>
> Regards,
> yj
>
> 2017-11-20 20:30 GMT+09:00 Christian Stroetmann :
>
>> Am 20.11.2017 09:08, schrieb Pekka Paalanen:
>>
>>> On Sat, 18 Nov 2017 20:42:44 +0900
>>> YoungJun Jo  wrote:
>>>
>>> Hi pq,

 Thank you for your response.

 However, weston_matrix *is* using float instead of double. Is that the
> problem?
>
 No. according to your analysis, it does not seem to be the cause of the
 this
 problem.

 During animations and any transformations that apply scaling, it is
> expected that the result has some sampling artifacts. The gl-renderer
> also has some logic to switch between GL_NEAREST and GL_LINEAR
> interpolation. What kind of animation is it that triggers the problem
> for you?
>
 When I trace it in gl-renderer, the problem occurs in GL_LINEAR filter.
 After changing the logic to GL_NEAREST instead of the GL_LINEAR,
 the incorrect drawing of the triangle has disappeared.
 It seems that there is a problem when interpolation is performed
 because of fp16 limitation.

 In the attached picture, I see not only the triangle you speak of, but
> also a color difference at the topmost horizontal bar. Could you share
> the original full-resolution captures in the web instead of an
> attachment?
>
 The error of the color difference seems to be in the form of a triangle.
 Please refer to the following link for the captured image.
 cycleline-error.png
 

 Hi,
>>>
>>> that is a very interesting image indeed. Is this really the captured
>>> image with the rendering problem?
>>>
>>> If I look at it at 100% or 700% scaling in firefox, I cannot see
>>> anything wrong in it.
>>>
>>> However, if I look at it at 300% and scroll it sideways, I do see the
>>> strange triangle of the top row, and I also see another vertical "edge"
>>> on the same row somewhat past the midpoint. I don't see them if the
>>> image stationary.
>>>
>>> If I look at it at 200% and squint, I can vaguely see the triangle and
>>> the "edge".
>>>
>>> I also tried 'xmag' of the area where I do see the triangle, and the
>>> magnification does not have it.
>>>
>>> Therefore, I don't think this is a misrendering but some other effect
>>> in the display signal, the monitor device, or even human vision.
>>>
>>> I don't know what to do about it.
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>> Regards,
 yj

 2017-11-17 18:56 GMT+09:00 Pekka Paalanen:

 On Fri, 17 Nov 2017 17:30:47 +0900
> YoungJun Jo  wrote:
>
> Dear all,
>>
>> In the weston environment, there is a problem when displaying a
>> specific
>> image using the GPU(Fragment Shader(FS) only supports FP16).
>> In fact, I think it's not common case to 

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

[Jasper St. Pierre]

Then I'd like some stronger wording in this patch that dictates that
unmapping and remapping a surface by either destroying the xdg_surface or
attaching a NULL buffer should be indistinguishable. No "hidden state",
either accessible or inaccessible to the app (such as stacking order,
window position, or user-added hints or settings) should leak through an
unmap/map cycle, if such wording hasn't been added already.

On Sun, Jul 16, 2017 at 11:32 PM, Jonas Ådahl <jad...@gmail.com> wrote:

> On Sun, Jul 16, 2017 at 11:16:25PM -0700, Jasper St. Pierre wrote:
> > (Coming into this one late)
> >
> > When I first wrote xdg-shell, I maintained that attaching a NULL buffer
> > should be illegal since it has no benefit compared to destroying the
> > surface, but compositors might not reset all data attached to the
> surface,
> > making a weird exception where clients depend on bugs where state isn't
> > always reset. And the "resetting of all data" might seem like strange
> > behavior to clients.
> >
> > Has this rationale changed?
>
> Pretty much. It was never specified anywhere so implementations
> differed (weston and mutter implemented it like that but not sure
> anyone else did), it contradicted some wording in wayland.xml and it was
> a behaviour disliked by some, thus a middle ground was reached that
> clearly defines it as no state should be kept. I intend to try to make
> sure at least libweston-desktop and mutter respects this fully.
>
>
> Jonas
>
> >
> > On Tue, Jul 11, 2017 at 8:11 PM, David Edmundson <davidedmund...@kde.org
> >
> > wrote:
> >
> > >
> > >
> > >> The idea is that having unmapped by null-attach means the
> > >> xdg_surface/xdg_toplevel etc is reset to the exact same state that it
> > >> had when first created, thus to map again, one would do what one would
> > >> do the same as when mapping it for the first time: set up the state
> > >> (set_title, (set_maximized?), set_app_id), commit, wait for configure,
> > >> then attach a new buffer given the configure event data.
> > >>
> > >>
> > >> Thanks, I'd totally forgotten the commit as I was only looking in this
> > > interface.
> > > It's clear now.
> > >
> > > David
> > >
> > > ___
> > > wayland-devel mailing list
> > > wayland-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >
> > >
> >
> >
> > --
> >   Jasper
>



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

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

[Jasper St. Pierre]

(Coming into this one late)

When I first wrote xdg-shell, I maintained that attaching a NULL buffer
should be illegal since it has no benefit compared to destroying the
surface, but compositors might not reset all data attached to the surface,
making a weird exception where clients depend on bugs where state isn't
always reset. And the "resetting of all data" might seem like strange
behavior to clients.

Has this rationale changed?

On Tue, Jul 11, 2017 at 8:11 PM, David Edmundson 
wrote:

>
>
>> The idea is that having unmapped by null-attach means the
>> xdg_surface/xdg_toplevel etc is reset to the exact same state that it
>> had when first created, thus to map again, one would do what one would
>> do the same as when mapping it for the first time: set up the state
>> (set_title, (set_maximized?), set_app_id), commit, wait for configure,
>> then attach a new buffer given the configure event data.
>>
>>
>> Thanks, I'd totally forgotten the commit as I was only looking in this
> interface.
> It's clear now.
>
> David
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


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

[Jasper St. Pierre]

On Mon, Apr 11, 2016 at 12:59 AM, Olivier Fourdan  wrote:
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to specify a maximum or
> minimum size.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the client would not allow for the requested size.
>
> Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> the client can tell the compositor what would be its smallest/largest
> acceptable size, and that the compositor can decide if maximize or
> fullscreen is achievable, draw an accurate animation, etc.
>
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> ---
>  v2: Rename the request to "set_preferred_max_size",
>  add "set_preferred_min_size" as well
>  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
>  Rephrase description to clarify the unscaled size and using 0 to
>  reset back the preferred size to an unspecified state
>  v4: Patch the correct xml file (v6, not v5 )
>  Fix multiple mismatch of min/max in the description
>  Remove mention of "unscaled", specify window geometry coordinates
>  and refer to set_window_geometry.
>  v5: Fix typos and remove "preferred" from the name and description as
>  requested by several people on the ML and irc.
>
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60 
> 
>  1 file changed, 60 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 3fc7d42..8ab84f5 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -489,6 +489,66 @@
>
>  
>
> +
> +  
> +   Set a maximum size for the window.
> +
> +   The client can specify a maximum size so that the compositor does
> +   not try to configure the window beyond this size.
> +
> +   The width and height arguments are in window geometry coordinates.
> +   See set_window_geometry.
> +
> +   The compositor can use this information to allow or disallow
> +   different states like maximize or fullscreen and draw accurate
> +   animations.
> +
> +   Similarly, a tiling window manager may use this information to
> +   place and resize client windows in a more effective way.
> +
> +   If never set, the maximum size of the window is not limited by
> +   the client.

Delete this sentence, and merge it into the paragraph below.

> +   A value of zero in the request for either width, height or both
> +   means that the client has no expected maximum size in the given
> +   dimension. As a result, a client wishing to reset the maximum size
> +   to an unspecified state can use zero for width and height in the
> +   request.

If never set, or a value of zero in the request, means that the client
has no expected...

> +  
> +  
> +  
> +
> +
> +
> +  
> +   Set a minimum size for the window.
> +
> +   The client can specify a minimum size so that the compositor does
> +   not try to configure the window below this size.
> +
> +   The width and height arguments are in window geometry coordinates.
> +   See set_window_geometry.
> +
> +   The compositor can use this information to allow or disallow
> +   different states like maximize or fullscreen and draw accurate
> +   animations.
> +
> +   Similarly, a tiling window manager may use this information to
> +   place and resize client windows in a more effective way.
> +
> +   If never set, the minimum size of the window is not limited by
> +   the client.
> +
> +   A value of zero in the request for either width, height or both
> +   means that the client has no expected minimum size in the given
> +   dimension. As a result, a client wishing to reset the minimum size
> +   to an unspecified state can use zero for width and height in the
> +   request.
> +  
> +  
> +  
> +
> +
>  
>
> Maximize the surface.
> --
> 2.5.5
>



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

[Jasper St. Pierre]

I figured min/max would be double-buffered state and require a commit
to take affect. In fact, anything else means that we can't extend with
additional size constraints in the future, since they couldn't be
applied atomically.

On Mon, Apr 11, 2016 at 12:02 PM, Bill Spitzak  wrote:
> Because of the two requests, the compositor can at least momentarily be in a
> state where max < min (otherwise it is impossible for a client to change the
> size range to a new one that does not intersect the old one). May want to
> specify what happens in this case. In particular it is required that setting
> the max does not change the min and vice-versa. And if max as though both values are equal to max, min, (max+min)/2, or what (my
> recommendation is to use min).
>
> Then again the above may be considered obvious and I am worried about
> nothing, in which case the current documentation is just fine.
>
>
> On Mon, Apr 11, 2016 at 5:23 AM, Yong Bakos  wrote:
>>
>> On Apr 11, 2016, at 2:59 AM, Olivier Fourdan  wrote:
>> >
>> > Some application may wish to restrict their window in size, but
>> > xdg-shell has no mechanism for the client to specify a maximum or
>> > minimum size.
>> >
>> > As a result, the compositor may try to maximize or fullscreen a window
>> > while the client would not allow for the requested size.
>> >
>> > Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
>> > the client can tell the compositor what would be its smallest/largest
>> > acceptable size, and that the compositor can decide if maximize or
>> > fullscreen is achievable, draw an accurate animation, etc.
>> >
>> > Signed-off-by: Olivier Fourdan 
>> > Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
>>
>> Looks good to me. (Note: I'm a novice reviewer.)
>>
>> Reviewed-by: Yong Bakos 
>>
>> yong
>>
>>
>> > ---
>> > v2: Rename the request to "set_preferred_max_size",
>> > add "set_preferred_min_size" as well
>> > v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
>> > Rephrase description to clarify the unscaled size and using 0 to
>> > reset back the preferred size to an unspecified state
>> > v4: Patch the correct xml file (v6, not v5 )
>> > Fix multiple mismatch of min/max in the description
>> > Remove mention of "unscaled", specify window geometry coordinates
>> > and refer to set_window_geometry.
>> > v5: Fix typos and remove "preferred" from the name and description as
>> > requested by several people on the ML and irc.
>> >
>> > unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60
>> > 
>> > 1 file changed, 60 insertions(+)
>> >
>> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > index 3fc7d42..8ab84f5 100644
>> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > @@ -489,6 +489,66 @@
>> >   
>> > 
>> >
>> > +
>> > +  
>> > + Set a maximum size for the window.
>> > +
>> > + The client can specify a maximum size so that the compositor does
>> > + not try to configure the window beyond this size.
>> > +
>> > + The width and height arguments are in window geometry coordinates.
>> > + See set_window_geometry.
>> > +
>> > + The compositor can use this information to allow or disallow
>> > + different states like maximize or fullscreen and draw accurate
>> > + animations.
>> > +
>> > + Similarly, a tiling window manager may use this information to
>> > + place and resize client windows in a more effective way.
>> > +
>> > + If never set, the maximum size of the window is not limited by
>> > + the client.
>> > +
>> > + A value of zero in the request for either width, height or both
>> > + means that the client has no expected maximum size in the given
>> > + dimension. As a result, a client wishing to reset the maximum size
>> > + to an unspecified state can use zero for width and height in the
>> > + request.
>> > +  
>> > +  
>> > +  
>> > +
>> > +
>> > +
>> > +  
>> > + Set a minimum size for the window.
>> > +
>> > + The client can specify a minimum size so that the compositor does
>> > + not try to configure the window below this size.
>> > +
>> > + The width and height arguments are in window geometry coordinates.
>> > + See set_window_geometry.
>> > +
>> > + The compositor can use this information to allow or disallow
>> > + different states like maximize or fullscreen and draw accurate
>> > + animations.
>> > +
>> > + Similarly, a tiling window manager may use this information to
>> > + place and resize client windows in a more effective way.
>> > +
>> > + If never set, the minimum size of the window is not limited by
>> > + the client.
>> > +
>> > + 

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

[Jasper St. Pierre]

On Tue, Apr 5, 2016 at 2:36 AM, Olivier Fourdan  wrote:
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to advertise such a maximum
> or minimum size the compositor can use.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the client would not allow for the requested size.
>
> Add new requests "set_preferred_max_size" and "set_preferred_min_size"
> to xdg-shell so that the client can tell the compositor which would be
> its preferred smallest/largest acceptable size, so that he compositor
> can decide if maximize or fullscreen makes sense, draw an accurate
> animation, etc.
>
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> ---
>  v2: Rename the request to "set_preferred_max_size",
>  add "set_preferred_min_size" as well
>
>  unstable/xdg-shell/xdg-shell-unstable-v5.xml | 46 
> 
>  1 file changed, 46 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> index 542491f..9c9b4d2 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> @@ -462,6 +462,52 @@
>
>  
>
> +
> +  
> +Set a preferred maximum size for the surface.
> +
> +The client can specify a maximum width and/or height to tell the
> +compositor what would be the preferred largest size for a surface.
> +
> +The compositor may use this information from the client to allow
> +or disallow different states like maximixe or fullscreen and
> +draw accurate animations.
> +Similarily, a tiling window manager can use this information to
> +place and resize client windows in a more effective layout.
> +
> +If never set, the size of the surface is not limited by the client.
> +
> +A value of zero for either width, height or both means that the
> +client has no preference regarding the maximum size in the given
> +dimension.

Is "zero" the same as "never set"? If so, I would rephrase this so
that it's clearer about that. If not, we need a way of resetting back
to the unspecified state.

> +  
> +  
> +  
> +
> +
> +
> +  
> +Set a preferred minimum size for the surface.
> +
> +The client can specify a minimum width and/or height to tell the
> +compositor what would be the preferable smallest size of a surface.
> +
> +The compositor may use this information from the client to allow
> +or disallow different states like maximixe or fullscreen and
> +draw accurate animations.
> +Similarily, a tiling window manager can use this information to
> +place and resize client windows in a more effective layout.
> +
> +If never set, the size of the surface is not limited by the client.
> +
> +A value of zero for either width, height or both means that the
> +client has no preference regarding the minimum size in the given
> +dimension.
> +  
> +  
> +  
> +
> +
>  
>
>  Maximize the surface.
> --
> 2.5.5
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

[Jasper St. Pierre]

"hint" just means "don't bother setting this flag, since it won't do anything".

If we want min/max size rules, I want them to be enforced. Compositors
SHOULD NOT attempt to configure windows above or below the requested
size.

On Mon, Apr 4, 2016 at 11:58 PM, Olivier Fourdan <ofour...@redhat.com> wrote:
> Hi all,
>
> - Original Message -
>> On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre"
>> <jstpie...@mecheye.net>
>> said:
>>
>> > I think min/max hints are acceptable in xdg-shell.
>>
>> 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.
>
> So, it seems max/min "hints" can be desirable from a window/compositor 
> manager point of view, whereas things like aspect ratio, size steppings, etc. 
> aren't
>
> I'll send an updated patch to:
>
>  - Reword the description and request name to make it clearer that it really 
> is a preference and not a rule (Quentin mentioned that on irc yesterday), 
> without using the word "hint" :)
>  - add a similar "preferable min size" request
>
> Then we can continue discussing from there.
>
> Cheers,
> Olivier
>



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

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

[Jasper St. Pierre]

I think min/max hints are acceptable in xdg-shell.

On Mon, Apr 4, 2016, 12:33 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan 
> wrote:
>
>>
>> Hi Mike,
>>
>> - Original Message -
>> > [...]
>> >
>> > Yes, I know you are not 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
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: history/semantics of uint32_t name

[Jasper St. Pierre]

wl_registry and wl_registry.bind are about globals and creating new
instances of globals.

A compositor can opt to provide a new global interface by using the
wl_global_create API. Immediately, an event is broadcasted to all
clients: the wl_registry.global event, which contains a name (the
uint32_t parameter), an interface (which is a string). If the user
wants to bind such a global, it passes that back to wl_registry.bind,
to get an instance of that global.

Why wasn't the interface used instead? I'm not sure. I imagine it was
to enforce that binding is done through the global event rather than
allowing a client to attempt to bind random objects through strings.

On Thu, Mar 31, 2016 at 4:48 PM, Yong Bakos  wrote:
> Hi,
> I've been investigating the semantics of the name parameter within the 
> wl_registry interface, prompted by a recent dialog regarding my patch of arg 
> summary attributes in wayland.xml.
>
> I've dug around the Weston source to see what values are passed as the name 
> argument, and where it goes... and I'm at a bit of a loss. This argument is 
> always an integer, and seems like it's just passed around and never even used 
> for anything! I feel like I must be missing something, hence this question: 
> what is this `name` argument in wl_registry_bind, wl_registry_send_global, 
> and wl_registry_send_global_remove? Why is it called name when it is merely a 
> numeric identifier? Shouldn't it be called `id`?
>
> I'd love to see where this argument is used within the weston source, so if 
> you know a file:line you can point me to, I'll add one beer to your queue.
>
> Thank you,
> yong
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: Collaboration on standard Wayland protocol extensions

[Jasper St. Pierre]

On Tue, Mar 29, 2016 at 5:24 AM, Drew DeVault  wrote:
>> Thirdly, it's important to take a step back. 'Wayland doesn't support
>> middle-button primary selections' is a feature gap compared to X11;
>> 'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
>> the forest of user-visible behaviour for the trees of creating
>> protocol.
>
> I think you're missing what users are actually using. You'd be surprised
> at how many power users are comfortable working with tools like xrandr
> and scripting their environments.

I've removed myself from the protocol talk so far, but I have to call
this one out. XRandR might be one of the most unfortunate APIs I have
ever dealt with, on both sides of the equation.

* It deals with "outputs" by "index", implying that outputs are static
and ordered. This is not the case in today's equipment with laptop
lids and docks and tons of ports.

* There's *no* way to specify whether something is a temporary display
configuration or should be saved. I plug and unplug external monitors
on my laptop every day, but I don't want a second output to always
behave the same way. Projectors should be in mirror mode. So already
you have multiple configurations, keyed by EDIDs.

* The authors wanted to make hotplug work even when nothing was poking
XRandR, but this just meant that desktops that do store complex
configuration had to wait until XRandR auto-reconfigured before saying
"no, bad computer" and overwriting any configuration it wanted. Two
mode-sets for the price of one.

* The command-line tool made it easy for users to poke the X server
directly, bypassing the DE entirely, leading to cases where the
Settings panel showed bizarre, inconsistent results because the
intended configuration wasn't updated for the manual changes the user
made.

* In some cases, like touchscreens, you *need* input to be mapped to
screen rotation and orientation. Input mapping was half-bolted onto
XInput and XRandR as an after-thought.

* Games which wanted to change the resolution often did it through
XRandR. These rarely worked if users had a complex configuration that
used rotated outputs, etc., or even just had more than one monitor,
leaving users with broken configurations. If the game crashed, users
were stuck with a permanently small screen.

* Similarly to the above, applications which want to react to
resolution changes (e.g. a window manager which wants to resize
windows, or a desktop that wants to reorder desktop icons) is unaware
if such a change is temporary or permanent. The result is that all
your desktop icons got put in a 640x480 box after you launched a game.

* Not to mention that the only event you get out of XRandR is an
all-encompassing "quick! something changed!!" event, which doesn't
even tell if you if it was simply accepting that the configuration you
just made went through successfully, whether it was an auto-configure
from a hotplug, or whether it was some other program poking the API.

* A partial repeat of the above, XRandR was intended for a low-level
"mechanism, not policy" API, but quickly got policy bolted on
after-the-fact because users weren't running tools which actually
supplied the policy. I am very skeptical of users who try to
lego-brick their way through DEs because "it's all bloat, I don't
really need a window manager, I can just skirt along with raw X11"
(because we committed ourselves to making it half-work) and I don't
want to encourage this behavior in Wayland. Let's do it right and
mandate real policy.

(This also doesn't even touch the incredible unfortunate hacks [0] we
have had to do at Endless to support HDMI TVs that need underscan
support, which work by changing the mode-list at runtime based on a
configurable border... which is specified in the mode's XSkew field,
because we didn't have any better place to put it)

We can talk about independent protocols and APIs for each of these use
cases (with no guarantee that Wayland is the IPC mechanism at hand),
but let's not bolt on a "wl_randr" that doesn't even begin to solve
the basic problems at hand because users run xrandr today and we have
to support that use case

[0] 
https://github.com/endlessm/xf86-video-intel/commit/391771f1652477863ece6da90b81dddb3ecb148a

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



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

Re: Collaboration on standard Wayland protocol extensions

[Jasper St. Pierre]

On Sun, Mar 27, 2016 at 7:33 PM, Drew DeVault <s...@cmpwn.com> wrote:
> On 2016-03-27  4:41 PM, Jasper St. Pierre wrote:
>
> What are your specific concerns with it? I would tend to agree. I think
> that it's not bad as an implementation of this mechanic, but I agree
> that it's approaching the problem wrong. I think it would be wiser to
> start with how clients ask the compositor for permissions and how they
> receive them, then leave the details libwsm implements up to the
> compositors.
>
> I think a protocol extension would work just fine to implement a
> permission requesting/granting dialogue between clients and compositors.

That's what we should be doing, and that's why I'm not a huge fan of
WSM -- it provides a solution for the stuff that doesn't matter, and
doesn't make any progress on the part we need to tackle. I won't enjoy
using libwsm because it adds complexity and error cases (e.g. what
happens with no modules, like on a misconfigured system?), without
solving the actual problem.

Also, as I've mentioned in my emails before, APIs aren't exclusively
used through Wayland, they might also be on other systems like DBus,
which already has its own confusing policy system. It gets even worse
when protocols might cross both systems. So libwsm is already far in
the negative points bucket to me -- a Wayland-protocol centric
solution that ignores other IPCs and APIs, is configurable for no
purpose as far as I can tell, and still doesn't have an approachable
story about how it provides more security to the user.

I would rather the effort be spent making secure interfaces, exactly
as you've described.

> --
> Drew DeVault



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

Re: Collaboration on standard Wayland protocol extensions

[Jasper St. Pierre]

You're probably referring to my response when you say "GNOME does not
care about cross-platform apps doing privileged operations". My
response wasn't meant to be speaking on behalf of GNOME. These are my
opinions and mine alone.

My opinion is still as follows: having seen how SELinux and PAM work
out in practice, I'm skeptical of any "Security Module" which
implements policy. The "module" part of it rarely happens, since
people simply gravitate towards a standard policy. What's interesting
to me isn't a piece of code that allows or rejects operations, it's
the resulting UI *around* those operations and managing them, since
that's really, at the end of the day, all the user cares about.

It would be a significant failure to me if we didn't have a standard
way for a user to examine or recall the policy of an application,
using whatever API they wanted. If every module implements its own
policy store separately, such a UI would be extremely difficult to
build.

From what I read, Wayland Security Modules didn't seem to even provide
that as a baseline, which is why I believe they're tackling the
problem from the wrong angle.

On Sun, Mar 27, 2016 at 1:50 PM, Martin Peres  wrote:
> On 27/03/16 23:34, Drew DeVault wrote:
>>
>> Greetings! I am the maintainer of the Sway Wayland compositor.
>>
>> http://swaywm.org
>>
>> It's almost the Year of Wayland on the Desktop(tm), and I have
>> reached out to each of the projects this message is addressed to (GNOME,
>> Kwin, and wayland-devel) to collaborate on some shared protocol
>> extensions for doing a handful of common tasks such as display
>> configuration and taking screenshots. Life will be much easier for
>> projects like ffmpeg and imagemagick if they don't have to implement
>> compositor-specific code for capturing the screen!
>>
>> I want to start by establishing the requirements for these protocols.
>> Broadly speaking, I am looking to create protocols for the following
>> use-cases:
>>
>> - Screen capture
>> - Output configuration
>> - More detailed surface roles (should it be floating, is it a modal,
>>does it want to draw its own decorations, etc)
>> - Input device configuration
>>
>> I think that these are the core protocols necessary for
>> cross-compositor compatability and to support most existing tools for
>> X11 like ffmpeg. Considering the security goals of Wayland, it will also
>> likely be necessary to implement some kind of protocol for requesting
>> and granting sensitive permissions to clients.
>>
>> How does this list look? What sorts of concerns do you guys have with
>> respect to what features each protocol needs to support? Have I missed
>> any major protocols that we'll have to work on? Once we have a good list
>> of requirements I'll start writing some XML.
>>
>> --
>> Drew DeVault
>
>
> We had discussions about it years ago and here are the results of them:
> http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
> http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
>
> And here is the software we created, under the name "Wayland Security
> Modules":
> http://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/xorg-talk.pdf
> https://github.com/mupuf/libwsm
>
> This approach has generally be liked by KDE, but not by Gnome who, last i
> heard, did not care about cross-platform apps doing privileged operations.
> This may have changed since they also decided to work on sandboxing
> (xdg-app) and implemented something like the following approach when they
> said they would never do because it changed the API:
> http://mupuf.org/blog/2014/05/14/introducing-sandbox-utils-0-6-1/
>
> I really wish we can have everyone onboard on one solution to get these
> cross-platform apps and so far, I do not see any better solution than WSM.
>
> Martin
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

I think this should be done at the application level. If an
application is running, it has many other ways to fingerprint your
computer, including listing the files in your homedir, checking cpuid,
MAC address, etc. The issue here is that there is an application
platform that runs untrusted user code, which has tried hard to get
rid of fingerprinting identifiers (however, I believe window size,
installed fonts and GPU rendering differences remain the primary
fingerprint identifiers at this point for ad networks). The randomness
in the event stream should be done in the air-gap between the trusted
code and the untrusted code.

Too many other use cases require completely accurate timing, and I'm
not convinced a generic solution for defeating trusted code is a good
idea. Perhaps a library can be shared between implementations.

On Thu, Mar 24, 2016 at 6:18 AM,   wrote:
> On 2016-03-24 12:45, Pekka Paalanen wrote:
>>
>>
>> Hi,
>>
>> that's interesting. Sounds like you are looking for volunteers to
>> implement what you want, right?
>
>
> Yes please. Unfortunately I don't know C or have the skill to code something
> like this myself.
>
>>
>> I skimmed through [3], and I got the impression that what the software
>> does is to round key press and release times to the nearest multiple of
>> 50ms or something along those lines.
>>
>> I can immediately see one problem with that approach: key repeat.
>>
>> Key repeat is based on a timer. On Wayland, that timer is currently in
>> the application, not in the kernel nor even in the display server. If
>> you skew the timings, you may screw up the repeats. For the record, it
>> seems the default repeat on Weston is 40 Hz, which means 25 ms period.
>> Rounding to nearest 50 ms sounds like a pretty big difference.
>
>
> I originally proposed this on the QEMU/Libvirt lists and we reached the
> conclusion that the Display-server or kernel is the best place for this to
> benefit as many people as possible.
>
> Someone replied with ideas about what an implementation would look like and
> he covers some of the problems you bring up:
> https://lists.nongnu.org/archive/html/qemu-discuss/2016-03/msg00024.html
>
>>
>> Another issue are gamers, who are going to hate you for messing up
>> their key timings, so this system must be user-controlled.
>
>
> Yes having this as an option people can change for specific usecases is the
> way to go. Per app or a global setting - which ever possible could work
> here.
>
>>
>> I suppose there is also a practical issue of synchronizing key events
>> to other input events. E.g. if you want to ctrl+click something, you
>> have to synchronize multiple input event streams under the same timing
>> fudging system to avoid the case where sometimes the key is not
>> accounted for when clicking.
>>
>> All that makes me wonder if the kernel is a sensible place for this.
>> For a machine specifically built to be more secure at the expence of
>> usability by ignoring all the above issues, then perhaps.
>>
>
> I posted on lkml but no one seems to show interest and within a few hours my
> message is already buried.
>
>>
>> Thanks,
>> pq
>>
>>>
>>> [1]
>>>
>>> http://arstechnica.com/security/2015/07/how-the-way-you-type-can-shatter-anonymity-even-on-tor/
>>>
>>> [2] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7358795
>>>
>>> [3] https://archive.is/vCvWb
>>>
>>> [4]
>>>
>>> https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166
>>>
>>> [5] https://trac.torproject.org/projects/tor/ticket/16110
>>>
>>> [6] https://trac.torproject.org/projects/tor/ticket/1517
>>>
>>>
>>> ___
>>> 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
>>
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
> ___
> 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



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

Re: Introduction and updates from NVIDIA

[Jasper St. Pierre]

On Thu, Mar 24, 2016 at 10:06 AM, Andy Ritger  wrote:

... snip ...

> eglstreams or gbm or any other implementation aside, is it always _only_
> the KMS driver that knows what the optimal configuration would be?
> It seems like part of the decision could require knowledge of the graphics
> hardware, which presumably the OpenGL/EGL driver is best positioned
> to have.

Why would the OpenGL driver the best thing to know about display
controller configuration? On a lot of ARM SoCs, the two are separate
modules, often provided by separate companies. For instance, the Mali
GPUs don't have display controllers, and the Mali driver is often
provided as a blob to vendors, who must use it with their custom-built
display controller.

Buffer allocation is currently done through DRI2 with the Mali blob,
so it's expected that the best allocation is done server-side in your
xf86-video-* driver.

I agree that we need somewhere better to hook up smart buffer
allocation, but OpenGL/EGL isn't necessarily the best place. We
decided a little while ago that a separate shared library and
interface designed to do buffer allocation that can be configured on a
per-hardware basis would be a better idea, and that's how gbm started
-- as a generic buffer manager.

> For that aspect: would it be reasonable to execute hardware-specific
> driver code in the drmModeAtomicCommit() call chain between the
> application calling libdrm to make the atomic update, and the ioctl
> into the kernel?  Maybe that would be a call to libgbm that dispatches to
> the hardware-specific gbm backend.  However it is structured, having
> hardware-specific graphics driver code execute as part of the flip
> request might be one way let the graphics driver piece and the display
> driver piece coordinate on hardware specifics, without polluting the
> application-facing API with hardware-specifics?

Wait a minute. Once you're in commit, isn't that far too late for
hardware specifics? Aren't we talking about buffer allocation and
such, which would need to happen far, far before the commit? Or did I
miss something here?

>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

I have to bring this up, because it's not necessarily true. There's
something you're missing. After working on embedded SoCs, I realize
that a lot of them put the YUV video plane *behind* the main RGB
plane. This allows them to do subtitles and OSD controls over the
video without stacking it RGB -> YUV -> RGB, as you might imagine.

Thankfully, some of these systems allow you to put the video on top of
RGB, but not all. Some even just have two YUV planes (for
picture-in-picture) and one RGB plane on top, not even a cursor plane.

On embedded systems where they have fullscreen control, they simply
render alpha-graphics into the RGB window, and then stack a YUV plane
behind it to blend against.

Wayland, in its current subsurface architecture, can't support this
system, unfortunately. The best thing I could think of here was to
have Wayland consider a punch-through when it sees a YUV plane stacked
under an RGB one from the same client, and it knows the scanout is
ARGB. But maybe that's too auto-magical.

I think that could work, but the implementation would need to be
tricky about all the special cases, if we cared enough to make those
work, e.g. surfaces under the punch-through need to be knocked out,
but surfaces above can't be, since they're stacked on top. And that
implies surfaces under the punch-through can't themselves use
overlays, etc.

On Tue, Feb 23, 2016 at 1:29 AM, Pekka Paalanen  wrote:
> On Tue, 23 Feb 2016 10:11:39 +0900
> YoungJun Jo  wrote:
>
>> Hello,
>>
>> Thanks for your reply.
>>
>> What i want is alpha blending for my chips.
>> As i mentioned, My chips have four independent H/W overlays.
>>
>> For example,
>> H/W Overlay 1 => Weston, Applications, etc..
>> H/W Overlay 2 => Video play.
>> H/W Overlay 3 = > Empty.
>> H/W Overlay 4 = > Empty.
>>
>> I also know that weston don't know H/W Overlays above mentioned.
>
> Hi,
>
> ok. The current state of Weston is slightly sad, as the support for
> hardware overlays is disabled by default, because enabling it causes
> performance problems. All that will be fixed once the patch series to
> support atomic/nuclear KMS in the DRM backend by Daniel Stone will
> land. I think Daniel is polishing it for submission whenever he has
> time for it.
>
> I would expect the situation to improve for Weston 1.11, but that's no
> promise.
>
> Btw. if you are using an fbdev backed, you have already lost: it will
> never support hardware overlays. Use the DRM-backend instead. It is
> possible to activate overlay support already with the debug key binding
> Mod+Shift+space, v.
>
>> Scenario:
>> 1. If i click play button on my video application, it will be call alpha
>> blending API.
>> 2. When weston receives alpha blending api, weston background will be
>> transparent.
>> 3. And i could see video playing from H/W Layer 2.(Still H/W Layer1 shows
>> GUI of video control buttons)
>>
>> So i want really alpha blending of weston background.
>
> I suppose you could do it like that, assuming that:
> - you will only ever support your one special video player
> - your video player is not cooperating with the display server, but it
>   is bypassing the display server instead and holding the display
>   server as a hostage (otherwise the display server, e.g. weston, can
>   mess up your video view)
> - your video player is likely specific to your hardware and cannot work
>   elsewhere
> - you will have to use a modified Weston, as upstream will never accept
>   what you would need for this
> - you will need to create a protocol extension for the "alpha blending
>   API" or whatever to tell weston to get out of the way
> - you won't have any application window mapped while playing e.g.
>   fullscreen video
> - you will waste power by always having to have a fullscreen completely
>   transparent overlay on top the video overlay, rather than having the
>   video on the top-most overlay
>
> and probably many more limitations that make the approach very painful
> to use in anything but a simple single-purpose device with a throw-away
> software stack.
>
> Essentially, you are using a display server (weston) to get a window
> system, and then your aim is to remove the window system and bypass the
> display server, telling weston to not mess with your video player.
>
> Btw. I forgot a few things earlier. Not only you need to have the
> backend tell the renderer use an alpha-capable framebuffer format, you
> also need to hack clients/desktop-shell.c to not force the background
> to be opaque. I'm not sure, but there might also be further things to
> adjust in a backend to make sure the alpha bits actually get into the
> hardware.
>
>
> The proper solution using Wayland and Weston as they are intended would
> involve the following:
> - ensure your display hardware has proper DRM drivers supporting atomic
>   KMS
> - wait for the atomic support to land in Weston, which...
> - puts Weston in control of all hardware planes, so that...
> - 

Re: Question regarding joystick/gamepad support in wayland

[Jasper St. Pierre]

There's other reasons, too.

Mice and keyboards need to be demulitplexed --you have one mouse
cursor on the screen, and you can move it between applications. You
select keyboard focus, and the compositor needs to figure out which
window to deliver key events to.

Joypads tend to be exclusive control, with one game majorly in charge.
There's rarely any reason to demultiplex joypad input, so it's
definitely not as strongly needed in the protocol.

There is one reason to perhaps support joypads in Wayland that I see,
and that's simply so the compositor resets your idletime when gamepad
buttons are pressed, but I hope most games would inhibit screensavers
anyway.

On Wed, Mar 2, 2016 at 3:42 PM, Peter Hutterer  wrote:
> On Wed, Mar 02, 2016 at 11:11:06PM +, 박성진 wrote:
>> Dear all,
>> I would like to get your opinions regarding joystick/gamepad support in 
>> wayland.
>> What's the desirable way to support joystick/gamepad both in wayland and in 
>> linux ?
>> Plz kindly let me know if there is any previous discussion about this. :)
>>
>> Linux supports both joydev(e.g. /dev/input/js0) and evdev(e.g. 
>> /dev/input/event0) for joysticks/gamepads.
>> As far as I know, many games in linux open js node directly within the 
>> process itself and read/handle joystick events by itself.
>> Under Xorg window system, without having X events and X input extension 
>> events, why are the games opening joystick nodes directly ?
>> Are there any reason for doing that ? Are there any performance issues ? 
>> Otherwise, is it originated from the lack of X events for joystick?
>> Lastly, what the most desirable way to support joysticks/gamepads in wayland 
>> ?
>
> couple of things here:
> * joystick events require relatively little processing, they are mapped to a
>   function and that's about it. compare that with e.g. touchpads where a lot
>   of stuff is required before we know whether we should send a motion,
>   button or scroll event
> * joysticks do not have a standard set of functionality. they're all buttons
>   and axes but the layout changes, the functionality differs per device, etc.
>   this makes it really hard to come up with a generic library that handles
>   joysticks. and when you do, it'll likely look like evdev anyway
> * X hasn't really had joystick support, so now you have the inertia of
>   "everyone is doing it this way already". Couple this with the fact that
>   joysticks aren't used in the normal UI, they're dedicated devices that
>   have a different functionality per application.
>
> As for the most desirable way to support joysticks in Wayland - we don't
> quite know, it'll depend on developers coming and saying "we need this and
> that", then we can start a conversation on what to do. But right now it
> seems a logind-like approach to allow an application to open js0 or the
> event node is quite sufficient.
>
> Cheers,
>Peter
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

https://cgit.freedesktop.org/~krh/weston/?h=remote

:)

On Tue, Feb 9, 2016 at 5:57 PM, Jason Ekstrand  wrote:
> On Tue, Feb 9, 2016 at 8:55 AM, Derek Foreman 
> wrote:
>>
>> I saw a presentation once where someone said that even the simplest
>> implementation of wayland network transparency that just pushed the
>> existing protocol over tcp/ip would still be better than X.
>>
>> Let's test that theory.
>> Hint - application startup time is shockingly fast due to wayland's
>> excellent protocol design, but my poor damage tracking and lack of
>> compression hurts.  Damage tracking is especially bad for anything
>> that doesn't use wl_surface.damage_buffer() - so weston-terminal may
>> be rough but terminology is much snappier.
>
>
> Kristian came up with a very nifty little image diffing algorithm based on a
> rolling hash that's used to provide compression for the screen recorder.
> (The actual video recorder, not screenshooter.)  You might want to check
> that out.
>
>>
>>
>> To try it out (and open a gaping security hole because I've punted on
>> kind of authentication), just add:
>> wl_display_add_remote_socket(display, "foo");
>> to weston right before load_modules in main.  Use at your own risk.
>>
>> That's a literal "foo" because I haven't bothered defining how that
>> name string changes the port.
>>
>> I've written up a short blog post over here:
>> http://blogs.s-osg.org/wow-wayland-over-wire/
>>
>> (It lists other decisions I haven't bothered to make for this trial
>> run.)
>>
>> For those of you that want to view PDF files over the network, EFL's
>> etui viewer comes highly recommended. ;)
>>
>> Derek Foreman (17):
>>   os-compatability: Allow creation of 0 byte anonymous files
>>   os: make set_cloexec_or_close private instead of static
>>   cursor: use wl_os_set_cloexec_or_close instead of local copy
>>   os-compatability: Remove cursor's private os compat stuff entirely
>>   client: Check remaining connection buffer status after each
>> queue_event()
>>   protocol: Add fd_static type
>>   protocol: Use new fd_static type for keymaps
>>   os: Add wl_os_resize_file()
>>   scanner: Add the concept of "pre hooks"
>>   os: Add wl_os_read() and wl_os_write()
>>   os: Add a wl_os_socket_reuseaddr
>>   connections: Add remote sockets
>>   shm: properly resize remote buffers
>>   connection: support sending the contents of fds as bulk data
>>   connection: Use bulk transfers for fd_static on remote connections
>>   protocol: Add a wl_buffer.transmit
>>   protocol: Add hooks for network transparency
>>
>> Giulio Camuffo (1):
>>   shm: add getters for the fd and offset
>>
>>  Makefile.am   |   5 +-
>>  cursor/os-compatibility.c | 148 -
>>  cursor/os-compatibility.h |  34 --
>>  cursor/wayland-cursor.c   |  15 +--
>>  protocol/wayland.dtd  |   1 +
>>  protocol/wayland.xml  |  40 ---
>>  src/connection.c  | 150 +-
>>  src/network-client.c  | 269
>> ++
>>  src/scanner.c | 117 ++--
>>  src/wayland-client-core.h |  10 ++
>>  src/wayland-client.c  | 120 +
>>  src/wayland-os.c  | 162 ++--
>>  src/wayland-os.h  |  19 
>>  src/wayland-private.h |  13 +++
>>  src/wayland-server-core.h |  13 +++
>>  src/wayland-server.c  | 146 +++--
>>  src/wayland-shm.c |  63 ++-
>>  17 files changed, 1045 insertions(+), 280 deletions(-)
>>  delete mode 100644 cursor/os-compatibility.c
>>  delete mode 100644 cursor/os-compatibility.h
>>  create mode 100644 src/network-client.c
>>
>> --
>> 2.7.0
>>
>> ___
>> 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
>



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

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

[Jasper St. Pierre]

The existing surface. Perhaps this "get_" naming is a bit confusing,
and should be renamed to "create_tooltip" or "make_tooltip" or
similar. The intended client flow is:

toplevel_wl_surface = wl_compositor.create_surface()
toplevel_xdg_surface = xdg_shell.get_xdg_surface(toplevel_wl_surface)
toplevel_xdg_toplevel = toplevel_xdg_surface.get_toplevel()

tooltip_wl_surface = wl_compositor.create_surface()
tooltip_xdg_surface = xdg_shell.get_xdg_surface(tooltip_wl_surface)
tooltip_xdg_tooltip =
tooltip_xdg_surface.get_tooltip(toplevel_xdg_toplevel, 150, 150)

Attach main buffers to toplevel_wl_surface and tooltip buffers to
tooltip_wl_surface. tooltip_xdg_tooltip is a tooltip surface attached
to the toplevel.

On Wed, Feb 3, 2016 at 1:02 AM, Giulio Camuffo <giuliocamu...@gmail.com> wrote:
> 2016-02-03 11:00 GMT+02:00 Jasper St. Pierre <jstpie...@mecheye.net>:
>> No? The parent is the surface the tooltip is laid on top of.
>
> So where do the contents of the tooltip come from?
>
>>
>> On Wed, Feb 3, 2016 at 12:59 AM, Giulio Camuffo <giuliocamu...@gmail.com> 
>> wrote:
>>> 2016-02-03 10:39 GMT+02:00 Jonas Ådahl <jad...@gmail.com>:
>>>> An xdg_tooltip is a new window type used to implement tooltip like
>>>> surfaces. See the interface documentation for details.
>>>>
>>>> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
>>>> ---
>>>>
>>>> Changes since v1:
>>>>
>>>> Various wording changes as suggested by Mike.
>>>>
>>>> Added missing version attribute and .
>>>>
>>>>
>>>>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 41 
>>>> 
>>>>  1 file changed, 41 insertions(+)
>>>>
>>>> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
>>>> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>>>> index f2eba64..a164bd6 100644
>>>> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>>>> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>>>> @@ -168,6 +168,20 @@
>>>>
>>>>  
>>>>
>>>> +
>>>> +  
>>>> +   This creates an xdg_tooltip for the given xdg_surface and gives the
>>>> +   associated wl_surface the xdg_tooltip role.
>>>> +
>>>> +   See the documentation of xdg_tooltip for more details about what an
>>>> +   xdg_tooltip is and how it is used.
>>>> +  
>>>> +  
>>>> +  
>>>> +  
>>>> +  
>>>> +
>>>
>>> Hi, I have just a comment here:
>>>
>>> I understand that 'parent' here is the actual tooltip surface, right?
>>> The description of the zxdg_tooltip_v6 interface below uses parent to
>>> refer to another surface, and that's i suppose the surface set with
>>> xdg_surface.set_parent(), right? I find that confusing, i would rename
>>> 'parent' in get_tooltip to 'surface', and maybe clarify in the
>>> description what is the actual parent.
>>>
>>>
>>> Cheers,
>>> Giulio
>>>
>>>
>>>> +
>>>>  
>>>>
>>>> The window geometry of a surface is its "visible bounds" from the
>>>> @@ -650,4 +664,31 @@
>>>>
>>>>
>>>>
>>>> +  
>>>> +
>>>> +  This interface defines an xdg_tooltip role that provides 
>>>> functionality
>>>> +  related to tooltip like surfaces.
>>>> +
>>>> +  An xdg_tooltip is a temporary surface which is displayed over its 
>>>> parent
>>>> +  xdg_surface. The last-created xdg_tooltip surface will always be the
>>>> +  top-most child of the parent xdg_surface.
>>>> +
>>>> +  The parent surface must either have the surface role xdg_toplevel,
>>>> +  xdg_popup or xdg_tooltip.
>>>> +
>>>> +  An xdg_tooltip does not take an active grab while mapped. 
>>>> xdg_tooltip
>>>> +  surfaces are either directly unmapped by clients using the
>>>> +  xdg_tooltip.destroy request or indirectly unmapped when their parent
>>>> +  surface is unmapped.
>>>> +
>>>> +  An xdg_tooltip obeys normal input region semantics.
>>>> +
>>>> +
>>>> +
>>>> +  
>>>> +   Unmap the tooltip surface and destroy the object.
>>>> +  
>>>> +
>>>> +  
>>>> +
>>>>  
>>>> --
>>>> 2.4.3
>>>>
>>>> ___
>>>> wayland-devel mailing list
>>>> wayland-devel@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>>
>> --
>>   Jasper



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

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

[Jasper St. Pierre]

No? The parent is the surface the tooltip is laid on top of.

On Wed, Feb 3, 2016 at 12:59 AM, Giulio Camuffo  wrote:
> 2016-02-03 10:39 GMT+02:00 Jonas Ådahl :
>> An xdg_tooltip is a new window type used to implement tooltip like
>> surfaces. See the interface documentation for details.
>>
>> Signed-off-by: Jonas Ådahl 
>> ---
>>
>> Changes since v1:
>>
>> Various wording changes as suggested by Mike.
>>
>> Added missing version attribute and .
>>
>>
>>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 41 
>> 
>>  1 file changed, 41 insertions(+)
>>
>> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
>> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> index f2eba64..a164bd6 100644
>> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> @@ -168,6 +168,20 @@
>>
>>  
>>
>> +
>> +  
>> +   This creates an xdg_tooltip for the given xdg_surface and gives the
>> +   associated wl_surface the xdg_tooltip role.
>> +
>> +   See the documentation of xdg_tooltip for more details about what an
>> +   xdg_tooltip is and how it is used.
>> +  
>> +  
>> +  
>> +  
>> +  
>> +
>
> Hi, I have just a comment here:
>
> I understand that 'parent' here is the actual tooltip surface, right?
> The description of the zxdg_tooltip_v6 interface below uses parent to
> refer to another surface, and that's i suppose the surface set with
> xdg_surface.set_parent(), right? I find that confusing, i would rename
> 'parent' in get_tooltip to 'surface', and maybe clarify in the
> description what is the actual parent.
>
>
> Cheers,
> Giulio
>
>
>> +
>>  
>>
>> The window geometry of a surface is its "visible bounds" from the
>> @@ -650,4 +664,31 @@
>>
>>
>>
>> +  
>> +
>> +  This interface defines an xdg_tooltip role that provides functionality
>> +  related to tooltip like surfaces.
>> +
>> +  An xdg_tooltip is a temporary surface which is displayed over its 
>> parent
>> +  xdg_surface. The last-created xdg_tooltip surface will always be the
>> +  top-most child of the parent xdg_surface.
>> +
>> +  The parent surface must either have the surface role xdg_toplevel,
>> +  xdg_popup or xdg_tooltip.
>> +
>> +  An xdg_tooltip does not take an active grab while mapped. xdg_tooltip
>> +  surfaces are either directly unmapped by clients using the
>> +  xdg_tooltip.destroy request or indirectly unmapped when their parent
>> +  surface is unmapped.
>> +
>> +  An xdg_tooltip obeys normal input region semantics.
>> +
>> +
>> +
>> +  
>> +   Unmap the tooltip surface and destroy the object.
>> +  
>> +
>> +  
>> +
>>  
>> --
>> 2.4.3
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

On Wed, Feb 3, 2016 at 1:00 PM, Bill Spitzak <spit...@gmail.com> wrote:
>
>
> On Wed, Feb 3, 2016 at 11:36 AM, Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>>
>> set_parent was moved to xdg_toplevel. Perhaps that's a good idea,
>> perhaps it's not. This does mean that a tooltip's parent can never
>> change, and a popup's parent can never change. That can help for
>> getting grab semantics right, though it might be an idea if we say
>> that set_parent on a popup / tooltip simply emit error if a parent is
>> already set. I'm -1 to that, though.
>
>
> xdg_toplevel *must* support the ability to change the parent.

Somehow I get the feeling you're not even reading the words I'm
writing. xdg_toplevel still has a set_parent method, I said it was
moved *to* xdg_toplevel.

... snip rant-y dialogue ...

> The toolkits will hide this. I would agree that defining the delta to be
> from 0,0 for the initial attach, in cases where the position is usable on
> first attach, is a good idea.

Toolkits now have additional state they have to keep track of -- where
the compositor thinks their surface is, relative to themselves. As
mentioned, I'm +0 on the idea. I'll leave it up to Jonas, Guilio and
Mike -- the people actually writing the toolkits in question -- to
determine whether they want it.

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

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

[Jasper St. Pierre]

set_parent was moved to xdg_toplevel. Perhaps that's a good idea,
perhaps it's not. This does mean that a tooltip's parent can never
change, and a popup's parent can never change. That can help for
getting grab semantics right, though it might be an idea if we say
that set_parent on a popup / tooltip simply emit error if a parent is
already set. I'm -1 to that, though.

Some think that wl_surface.attach's coordinates are confusing and
built poorly, and I am inclined to agree, however, when I wrote the
original get_xdg_popup, I simply forgot about them. It might be that
we do positioning on first-attach, and we say that the tooltip is
defined to be 0,0 relative to the surface. That is an idea, though I'm
+0 on it.

On Wed, Feb 3, 2016 at 11:08 AM, Bill Spitzak <spit...@gmail.com> wrote:
>
>
> On Wed, Feb 3, 2016 at 1:06 AM, Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>>
>> The existing surface. Perhaps this "get_" naming is a bit confusing,
>> and should be renamed to "create_tooltip" or "make_tooltip" or
>> similar. The intended client flow is:
>>
>> toplevel_wl_surface = wl_compositor.create_surface()
>> toplevel_xdg_surface = xdg_shell.get_xdg_surface(toplevel_wl_surface)
>> toplevel_xdg_toplevel = toplevel_xdg_surface.get_toplevel()
>>
>> tooltip_wl_surface = wl_compositor.create_surface()
>> tooltip_xdg_surface = xdg_shell.get_xdg_surface(tooltip_wl_surface)
>> tooltip_xdg_tooltip =
>> tooltip_xdg_surface.get_tooltip(toplevel_xdg_toplevel, 150, 150)
>>
>> Attach main buffers to toplevel_wl_surface and tooltip buffers to
>> tooltip_wl_surface. tooltip_xdg_tooltip is a tooltip surface attached
>> to the toplevel.
>
>
> But I thought there already was an api to set the parent of a xdg_surface!
>
> I do not think there should be redundancy in ways to get things done, it
> makes it painful for toolkit implementations. It looks to me that if a
> toolkit makes a tooltip the same class structure as a normal window, and the
> user calls the generic setParent on that class, the tooltip is going to have
> to lookup the setParent result just so it can pass it *again* in the
> get_tooltip request. Or I suppose you could use null to mean "leave the
> parent as-is".
>
> There already is relative positioning for child surfaces, that should be
> reused as well, rather than passing the xy here. In fact there is quite a
> lot of api for figuring out relative positioning and it is silly that this
> request makes all that useless by overwriting it. Again if you insist I
> guess you can use 0,0 as an indication of "leave it as-is".
>
>



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

Re: Moving bugs to Phabricator

[Jasper St. Pierre]

The current major issue with Phabricator for me currently is that it
doesn't support patch-based code review, unless this has changed in
the meantime: 
http://stackoverflow.com/questions/20756320/how-to-prevent-phabricator-from-eating-my-commit-history

( The linked article has since moved to
https://secure.phabricator.com/book/phabflavor/article/recommendations_on_revision_control/
, but it still contains mostly the same text. )

On Tue, Feb 2, 2016 at 7:43 AM, Daniel Stone  wrote:
> Hi,
> As previously discussed with a few people (when it was much more in
> its infancy than now), I'd like to move our bug tracking from Bugzilla
> to Phabricator.
>
> There's a few reasons behind this. Phabricator is actually a pretty
> decent suite of utilities, including repository browsing and code
> review (Gerrit-style, including iterative revisions of patches,
> line-by-line comments, etc), and having our bugs in that would allow
> us better integration between the two. For instance, putting
> 'Maniphest Tasks: T1234' in a commit message when uploading a diff
> automatically links the commit and the bug, and similarly it also gets
> closed when pushing commits.
>
> We can push this out further as well, including automatically
> triggering CI from commits sent for review. I actually had this
> working last year (running distcheck for every commit), but am in the
> middle of rejigging my setup for a few things and haven't yet fixed
> that to happen again yet.
>
> Personally, just the improved UI (BZ is a nightmare) is enough for me,
> but in terms of what we can do with it in future, I think it's got a
> much better model than Bugzilla. The data store in Phabricator is very
> important to their upstream, and is sensible and extensible. Whilst
>
> We've had an instance at fd.o for a while, which has been used to
> varying degrees by projects such as PiTiVi, GStreamer, et al. Also, we
> use it internally for everything at Collabora, so the tree we maintain
> for use there also gets pushed to fd.o.
>
> In terms of what this would mean mechanically, we already have a
> fairly mature suite of scripts which have been used to do imports for
> quite a few projects. Using this would mirror all the Bugzilla bugs to
> Phabricator, add a link from the existing Bugzilla bugs to their
> replacements on Phabricator, and then redirect all new bug-filers to
> Phabricator. The import process also creates accounts for everyone, so
> once they'd recovered their passwords, so no data will be lost. It
> also ports attachments over.
>
> Beyond that, we can start using code review for it as and when people
> feel comfortable, particularly using git-phab, which submits patchsets
> to Phabricator for review. I'm probably most excited about getting
> review on there, though also fairly cautious; while Bugzilla is just
> trading one antiquated web tool which no-one uses for a nice modern
> one which equally few people will probably look at, review is a bigger
> part. Nonetheless, having things like concrete review approval status,
> line-by-line review separated from wider/conceptual review,
> at-a-glance review status, etc, I think is valuable enough that I
> think it's worth shifting things over at some point.
>
> Anyone have any thoughts/opinions/fears/encouragement?
>
> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

It would help if you actually read the spec that was there before
commenting. The difference between toplevels and popups is not whether
they have a parent (toplevels indeed have a set_parent method), but
that popups take an implicit pointer and keyboard grab, e.g. menus and
comboboxes. They have well-defined surface lifetime semantics.

Dialog boxes are not considered popups. They are toplevels with
set_parent called on them.

Perhaps the names were chosen poorly. Better suggestions for names are
very welcome.

We tried to make this very clear in the specification. If it was
confusing to read, please let us know and we'll try to make it
clearer.

On Tue, Jan 12, 2016 at 3:13 PM, Bill Spitzak  wrote:
>
>
> On Tue, Jan 12, 2016 at 12:16 AM, Jonas Ådahl  wrote:
>>
>> Hi,
>>
>> These patches turns xdg_surface into a generic base interface that other
>> xdg_*
>> roles would then extend. The point of this is to unify some concepts
>> common to
>> all surfaces related to xdg_shell. The parts related to toplevel window
>> management was moved out to a new "xdg_toplevel" interface. xdg_popup was
>> changed to extend xdg_surface instead of being stand alone.
>
>
> There must be an ability to set the parent after the surface has been
> created: It is necessary to get a child that stays above more than one
> surface, since some of those surfaces may not exist at the moment the child
> is shown (imagine a dialog box that remains above all open documents, and
> the user opens a new document).
>
> It is also necessary to set the parent to none. Imagine if the last document
> is closed, but the application keeps the dialog up.
>
> I think this removes any difference between "toplevel" and non-toplevel
> surfaces. It is simply whether the parent is non-null. You seem to be
> sending different configure events to them, but the inability to full-screen
> a dialog box may be considered a bug by some, and clients already have the
> ability to ignore configure requests, so I see no reason for this
> difference.
>
> It is ok if some roles (like tooltip) require a parent. If the parent is
> missing it could be an error, or the surface just never appears
>
>> 2.4.3
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>



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

Re: kernel level window management

[Jasper St. Pierre]

I don't quite understand the need, want, or mechanism for this.

For high performance or VR systems where context switch overhead would be
too much (and I don't believe this, since they tend to use separate
acceleration chips for real-time work), the answer would not be to move
from userspace to the kernel -- kernel threads are like any other and have
context switch penalties.

If you have real performance issues with Wayland's architecture, let's
discuss that and try to solve it. There's probably a lot there that's slow,
but I doubt context switches are the bottleneck.

On Wed, Dec 30, 2015, 11:56 AM   wrote:

> Hi.
>
> On 29.12.15 20:09, Dimitri Nüscheler wrote:
> > Hello everyone
> >
> > I sometimes wonder where people talk about concept level and philosophy.
> > At least Wayland has a big philosophy part - and it uses it to explain
> > itself in contrast to X.
> > I'm not much involved into it, but I think I understand some vital parts.
> > So far I understand it as a "graphics buffer and input redirection
> > protocol" and that's a very concept level perspective. The routers in
> > this "redirection network" are obviously the compositors.
>
> I can't comment on Wayland itself. Philosophy does not have a monopoly
> on concepts. Abstract mathematics has concepts too. This is what I
> prefer because mathematical definitions are precise. Philosophical
> definitions are not, so reasoning with them does no good.
> ___
> 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

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

[Jasper St. Pierre]

The first thing I thought about with full-window is how, in fullscreen
mode, Firefox puts up a status bar when you put your mouse to the top
of the window, assuming there's a screen edge there.

You are totally allowed to lie -- and that doesn't really need to be
"proposed" at all -- you just have to write a compositor to let you do
that. But you have to be prepared to deal with the consequences --
applications may rely on assumed behavior or placement.

On Tue, Dec 22, 2015 at 4:43 AM, Coroutines  wrote:
> # Summary
>
> Wayland compositors like weston have the freedom to display
> 'fullscreen'-selected content in 3 ways (that I can think of):
>
> - full-window
> - fullscreen
> - multi-display fullscreen
>
> # The Problem
>
> Something that I've always wanted to have control over is how an
> application is shown in in its fullscreen state.  Typically when I'm
> watching a video on youtube in a web browser I want the player to
> instead fill the existing window dimensions and not the screen.  In
> this example I am looking for full-window behavior.  I can of course
> propose this to Google's devs, but I'd have to do this for every app
> where I want full-window.  I'd much rather have a wayland compositor
> that gives me this ability to 'abuse' the fullscreen state.
>
> # What I propose:
>
> The compositor has the freedom with xdg-shell to "lie" to the client
> about the geometry of the screen in the configure event, when a
> surface sets itself as fullscreen.
>
> In this way, the compositor can show the surface in 3 modes that give
> the user more choice/convenience:
>
> - fullscreen (traditional)
> - full-window (same size, placed at the same x, y)
> - multi-display "fullscreen" (think Far Cry playing across 3 displays)
>
> I also imagined the compositor would have options for dimming the
> areas between fullscreen clients (think theater-mode).  Or immediately
> turn off all other displays ~
>
> # Why abuse fullscreen?
>
> 1) It seems perfectly legal per xdg-shell with no bad side-effects.
>
> 2) I was thinking about something said over and over in #wayland, that
> xdg-shell is not about providing mechanisms/primitive operations like
> X.  It's about providing requests for clients to convey intent.  In my
> opinion, the intent of fullscreen behavior is to enlarge and focus
> content.  To display specific content from a window in a way that the
> user will not be distracted by other apps and activities they're
> doing.
>
> If I want to convey "intent" I'm bringing *select* content to the
> forefront of what the user has open on screen.
>
> In my opinion, the user should be the one choosing how large this
> selected content appears and where - and if other clients are still
> visible.
>
> I avoided calling this 'focused' content, if not 'fullscreen'.  I was
> thinking maybe it could be called a 'forefront' or 'foreground' state
> - or even just 'closer'.  From a protocol perspective, if wayland
> compositors were to support this greater level of control over the
> fullscreen state, I think it should be renamed in the future.
>
> Anyway, I just wanted to write about this and put the idea in the
> heads of people shaping our future desktop experience on Linux.  If
> you work on mutter or kde plasma, or shape xdg-shell's mechanics...
> This is something we can't do on Mac/Windows (across all clients), and
> imo it'd be pretty cool. :>  I personally wish I were prompted by the
> compositor to confirm which fullscreen mode I want a client to conform
> to, but others might want a default of the 3 modes ~
>
> Thanks for reading ~
>
> Disclaimer?: I don't expect anyone to do anything for me.  I think I
> come up with original ideas so I'm simply trying to share it.
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: inserting a "wl_display" object

[Jasper St. Pierre]

Yeah. wl_display is the "bootstrap" phase on which everything else
rests. In the protocol, it's implicit knowledge that there is always
an wl_display object with ID 1. It never gets created or destroyed,
you just start using ID 1.

On Tue, Dec 22, 2015 at 4:55 AM, Pekka Paalanen  wrote:
> On Tue, 22 Dec 2015 14:34:08 +0200
> m...@beroal.in.ua wrote:
>
>> Hello, I'm new to Wayland. I need a "wl_display" object in order to
>> insert "wl_registry" and start working. I see no means of inserting it.
>> (I want to know how to do that in the Wayland protocol, not in the C
>> binding to it.)
>
> Hi,
>
> wl_display is implicitly constructed with ID 1 on both sides when a
> connection is created. It "just exists", there is no protocol to create
> it.
>
>
> Thanks,
> pq
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



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

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

[Jasper St. Pierre]

For future reference, I would like carve-outs to be assigned and
pushed as soon as possible, just to prevent issues with two teams
taking the same carve-out.

I don't think they should be controversial in the slightest. Even if
we allocate 0x1000 per carve-out, we'll still have room for 1,048,575
groups of people taking carve-outs.

On Fri, Dec 4, 2015 at 4:50 PM, Bryce Harrington <br...@osg.samsung.com> wrote:
> On Fri, Dec 04, 2015 at 12:41:16PM -0500, Mike Blumenkrantz wrote:
>> Reviewed-by: Jasper St. Pierre <jstpie...@mecheye.net>
>
> Reviewed-by: Bryce Harrington <br...@osg.samsung.com>
>
>> ---
>>  unstable/xdg-shell/xdg-shell-unstable-v5.xml | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
>> b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> index 127992b..542491f 100644
>> --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> @@ -338,6 +338,7 @@
>>
>>  0x - 0x0FFF: xdg-shell core values, documented below.
>>  0x1000 - 0x1FFF: GNOME
>> +0x2000 - 0x2FFF: EFL
>>
>>
>>   
>> --
>> 2.4.3
>>
>> ___
>> 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jasper St. Pierre]

While we're doing this, can we remove the use_unstable_version request?

On Wed, Dec 2, 2015 at 5:06 PM, Mike Blumenkrantz <zm...@samsung.com> wrote:
> This copies the version 5 of the XML to a new version 6 version, while
> at the same time the interface names are changed to use the unstable
> naming convention.
>
> A whitespace cleanup was done as no git-blame:ability would be lost
> anyway.
>
> Reviewed-by: Mike Blumenkrantz <zm...@osg.samsung.com>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  Makefile.am  |   1 +
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624 
> +++
>  2 files changed, 625 insertions(+)
>  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 5926a41..4a2974d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5,6 +5,7 @@ unstable_protocols =  
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> +   unstable/xdg-shell/xdg-shell-unstable-v6.xml  
>   \
> $(NULL)
>
>  nobase_dist_pkgdata_DATA =   
>   \
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> new file mode 100644
> index 000..196c332
> --- /dev/null
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -0,0 +1,624 @@
> +
> +
> +
> +  
> +Copyright © 2008-2013 Kristian Høgsberg
> +Copyright © 2013  Rafael Antognolli
> +Copyright © 2013  Jasper St. Pierre
> +Copyright © 2010-2013 Intel Corporation
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  xdg_shell allows clients to turn a wl_surface into a "real window"
> +  which can be dragged, resized, stacked, and moved around by the
> +  user. Everything about this interface is suited towards traditional
> +  desktop environments.
> +
> +
> +
> +  
> +   The 'current' member of this enum gives the version of the
> +   protocol.  Implementations can compare this to the version
> +   they implement using static_assert to ensure the protocol and
> +   implementation versions match.
> +  
> +  
> +
> +
> +
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> +   Destroy this xdg_shell object.
> +
> +   Destroying a bound xdg_shell object while there are surfaces
> +   still alive created by this xdg_shell object instance is illegal
> +   and will result in a protocol error.
> +  
> +
> +
> +
> +  
> +   Negotiate the unstable version of the interface.  This
> +   mechanism is in place to ensure client and server agree on the
> +   unstable versions of the protocol that they speak or exit
> +   cleanly if they don't agree.  This request will go away once
> +   the xdg-shell protocol is stable.
> +  
> +  
> +
> +
> +
> +  
> +   This creates an xdg_surface for the given surface and gives it the
> +   xdg_surface role. A wl_surface can only be given an xdg_surface role
> +   once. If get_xd

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

[Jasper St. Pierre]

I don't see where. I see eglSwapBuffersWithDamage still looking like
it shoves the rects across the wire in buffer space, without any
modification.

http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c#n705

I checked the Mali driver implementation I have, and it does something similar.

On Sat, Nov 7, 2015 at 2:32 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> On 6 November 2015 at 19:08, Jasper St. Pierre <jstpie...@mecheye.net> wrote:
>> To help clear things up, I think we should deprecate the
>> wl_surface.damage request and document that the coordinates are
>> effectively undefined -- for legacy reasons, if you see
>> wl_surface.damage, it should be considered a damage for the entire
>> surface.
>
> Why? Mesa fixed that bug two years ago, I don't know of a non-Mesa EGL
> implementation with that bug, and non-EGL clients are perfectly
> capable of implementing it correctly themselves. Whilst introducing
> buffer_damage, we could obliterate surface damage out of spite, but
> that seems like a giant middle finger to everyone who wrote conformant
> and performant apps, and now gets their entire buffer smashed through
> TexImage2D every time they want to blink a cursor.
>
> Cheers,
> Daniel



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

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

[Jasper St. Pierre]

OK. So the bug *wasn't* fixed two years ago like you were saying, and
under transformations, mesa is still wrong.

So we fix the bug by adding wl_surface.buffer_damage, since it's
impossible for Mesa to know about buffer transformations... and then
what?

The only way we can properly interpret the wl_surface.damage event is
it being correct under no buffer transformations. Which is fine to me.
And in any other case, we effectively have to treat it as a
full-surface damage, since the coordinates are junk.

And technically, it doesn't matter which of the two you pick -- it's
an optimization for the compositor to redraw less. At that point, I
think it makes more sense to say that we should just treat every
wl_surface.damage event as redrawing the full surface.

Given how surprising and unintuitive the rectangles behavior is (and
given how it only says it in passing in the spec), I personally don't
believe many 2D clients went through the trouble to make sure their
rectangles were correct in all cases. Given that the error case is
"app gets tearing and then when you click on it and switches away from
the backdrop theme, it works fine", I think many people probably just
blamed cairo and got on with it. Especially when it remained wrong in
Weston's own clients for a few years as well until somebody spotted
it.

Yes, this is what happens wheny ou introduce a broken protocol and let
it stay there in the name of stability -- you get nonsense results and
have to throw it out.

On Sat, Nov 7, 2015 at 9:41 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi,
>
> On 7 November 2015 at 16:59, Jasper St. Pierre <jstpie...@mecheye.net> wrote:
>> I don't see where. I see eglSwapBuffersWithDamage still looking like
>> it shoves the rects across the wire in buffer space, without any
>> modification.
>>
>> http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c#n705
>
> A bug which should be fixed ...
>
>> I checked the Mali driver implementation I have, and it does something 
>> similar.
>
> Mali 6xx doesn't do that.
>
> Cheers,
> Daniel
>
>> On Sat, Nov 7, 2015 at 2:32 AM, Daniel Stone <dan...@fooishbar.org> wrote:
>>> On 6 November 2015 at 19:08, Jasper St. Pierre <jstpie...@mecheye.net> 
>>> wrote:
>>>> To help clear things up, I think we should deprecate the
>>>> wl_surface.damage request and document that the coordinates are
>>>> effectively undefined -- for legacy reasons, if you see
>>>> wl_surface.damage, it should be considered a damage for the entire
>>>> surface.
>>>
>>> Why? Mesa fixed that bug two years ago, I don't know of a non-Mesa EGL
>>> implementation with that bug, and non-EGL clients are perfectly
>>> capable of implementing it correctly themselves. Whilst introducing
>>> buffer_damage, we could obliterate surface damage out of spite, but
>>> that seems like a giant middle finger to everyone who wrote conformant
>>> and performant apps, and now gets their entire buffer smashed through
>>> TexImage2D every time they want to blink a cursor.
>>>
>>> Cheers,
>>> Daniel
>>
>>
>>
>> --
>>   Jasper



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

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

[Jasper St. Pierre]

To help clear things up, I think we should deprecate the
wl_surface.damage request and document that the coordinates are
effectively undefined -- for legacy reasons, if you see
wl_surface.damage, it should be considered a damage for the entire
surface.

On Fri, Nov 6, 2015 at 10:55 AM, Derek Foreman  wrote:
> wl_surface.damage uses surface local co-ordinates.
>
> Buffer scale and buffer transforms came along, and EGL surfaces
> have no understanding of them.
>
> Theoretically, clients pass damage rectangles - in Y-inverted surface
> co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation
> passed them on to wayland.  However, for this to work the EGL
> implementation must be able to flip those rectangles into the space
> the compositor is expecting, but it's unable to do so because it
> doesn't know the height of the transformed buffer.
>
> So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers
> has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function.
>
> wl_surface.buffer_damage allows damage to be registered on a surface
> in buffer co-ordinates, avoiding this problem.
>
> Credit where it's due, these ideas are not entirely my own:
> Over a year ago the idea of changing damage co-ordinates to buffer
> co-ordinates was suggested (by Jason Ekstrand), and it was at least
> partially rejected and abandoned.  At the time it was also suggested
> (by Pekka Paalanen) that adding a new wl_surface.buffer_damage request
> was another option.
>
> Signed-off-by: Derek Foreman 
> ---
>
> Necro-posting on:
> http://lists.freedesktop.org/archives/wayland-devel/2014-February/013440.html
> and
> http://lists.freedesktop.org/archives/wayland-devel/2014-February/013442.html
>
> This came up on IRC again the other day, and it's still an unsolved problem...
> I'm posting this as RFC to see if anyone's interested in it - I'll do an
> implementation if we can get an agreement on the protocol text.
>
>  protocol/wayland.xml | 44 ++--
>  1 file changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 9c22d45..1cb2f66 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -176,7 +176,7 @@
>  
>
>
> -  
> +  
>  
>A compositor.  This object is a singleton global.  The
>compositor is in charge of combining the contents of multiple
> @@ -986,7 +986,7 @@
>  
>
>
> -  
> +  
>  
>A surface is a rectangular area that is displayed on the screen.
>It has a location, size and pixel contents.
> @@ -1327,6 +1327,46 @@
>
>
>  
> +
> +
> +
> +  
> +   This request is used to describe the regions where the pending
> +   buffer is different from the current surface contents, and where
> +   the surface therefore needs to be repainted. The pending buffer
> +   must be set by wl_surface.attach before sending damage. The
> +   compositor ignores the parts of the damage that fall outside of
> +   the surface.
> +
> +   Damage is double-buffered state, see wl_surface.commit.
> +
> +   The damage rectangle is specified in buffer coordinates.
> +
> +   The initial value for pending damage is empty: no damage.
> +   wl_surface.damage adds pending damage: the new pending damage
> +   is the union of old pending damage and the given rectangle.
> +
> +   wl_surface.commit assigns pending damage as the current damage,
> +   and clears pending damage. The server will clear the current
> +   damage as it repaints the surface.
> +
> +   This request differs from wl_surface.damage in only one way - it
> +   takes damage in buffer co-ordinates instead of surface local
> +   co-ordinates.  This is desirable because EGL implementations
> +   are unaware of buffer scale and buffer transform and can only
> +   provide damage in buffer co-ordinates.  Damage in buffer
> +   co-ordinates is required for EGLSwapBuffersWithDamage to work
> +   efficiently.
> +
> +   Mixing wl_surface.buffer_damage and wl_surface.damage requests
> +   on the same surface will result in undefined behaviour.
> +  
> +
> +  
> +  
> +  
> +  
> +
> 
>
>
> --
> 2.6.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

Out of curiosity, why do you require that we don't switch VTs in Weston?

On Tue, Oct 27, 2015, 8:23 AM Vikas Patil Gmail 
wrote:

> Hi Daniel,
>
> Thanks for your comment and suggestions. I will surely ask to freesacle
> regarding it.
>
> I was thinking VTs sharing don't have dependencies on GAL2D. Is possible
> could you point me the hack you mentioned so I can give try?
>
> Is VT sharing possible if I use GLES renderer with fbdev backend?
>
> I am trying splash screen and want to avoid flicker/screen clear. Using
> fb0 for splash and fb1 for Weston.
>
> Thanks & Regards,
> Vikash
> --
> From: Daniel Stone 
> Sent: ‎10/‎27/‎2015 7:43 PM
> To: Vikas Patil 
> Cc: wayland mailing list 
> Subject: Re: Is VT sharing possbile with weston 1.8.0 with fbdev backend?
>
> Hi,
>
> On 27 October 2015 at 13:12, Vikas Patil  wrote:
> > Does anyone know here if weston switches between VTs (Virtual Terminal)
> > while starting weston using "fbdev" backend and GLA2D (Freescale specific
> > renderer)? If yes then is there any way
> > to stop switching between VTs and still star it successfully?
> >
> > I am using weston 1.8.0 on iMX platform with linux 3.14.28 (framebuffer
> > console with logo, Virtual Terminal enabled).
> >
> > I used to do this with X11 using option called "sharedvt" (-sharevts:
> share
> > VTs with another X server) to avoid the flicker/screen clear displayed
> due
> > to without using this option.
>
> The GAL2D backend is maintained completely separately by Freescale,
> and has never been sent upstream. Unfortunately due to this (the hacks
> in the code make it impossible to merge in its current form), we
> cannot support the patches you have. Please get in touch with
> Freescale and request support from them.
>
> Alternately, there is support developing in Mesa for using the etnaviv
> (Vivante 3D GPU) and imx-drm (Freescale 2D-ACE engine) open-source
> drivers on i.MX6. If you are not able to get help from Vivante, this
> could be a good option to pursue, as it has far better support.
>
> Cheers,
> Daniel
> ___
> 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

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

[Jasper St. Pierre]

Agreed. Absolute input needs to be handled separately. The usage pattern on
an absolute input device is that the cursor warps to the new position, it
didn't simply move from the old to the new.

As an example, pointer barriers shouldn't take effect on absolute input.

On Tue, Oct 27, 2015, 10:40 AM Daniel Stone  wrote:

> Hi Jonas,
>
> On 13 May 2015 at 11:26, Jonas Ådahl  wrote:
> > @@ -3182,18 +3182,20 @@ popup_grab_focus(struct weston_pointer_grab
> *grab)
> >
> >  static void
> >  popup_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
> > - wl_fixed_t x, wl_fixed_t y)
> > + struct weston_pointer_motion_event *event)
> >  {
> > struct weston_pointer *pointer = grab->pointer;
> > struct wl_resource *resource;
> > +   wl_fixed_t x, y;
> > wl_fixed_t sx, sy;
> >
> > if (pointer->focus) {
> > +   weston_pointer_motion_to_abs(pointer, event, , );
> > weston_view_from_global_fixed(pointer->focus, x, y,
> >   >sx,
> >sy);
> > }
> >
> > -   weston_pointer_move(pointer, x, y);
> > +   weston_pointer_move(pointer, event);
> >
> > wl_resource_for_each(resource, >focus_resource_list) {
> > weston_view_from_global_fixed(pointer->focus,
> > diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
> > index bad2418..5cd5ac9 100644
> > --- a/ivi-shell/hmi-controller.c
> > +++ b/ivi-shell/hmi-controller.c
> > @@ -1360,16 +1360,19 @@ layer_set_pos(struct ivi_layout_layer *layer,
> wl_fixed_t pos_x,
> >
> >  static void
> >  pointer_move_grab_motion(struct weston_pointer_grab *grab, uint32_t
> time,
> > -wl_fixed_t x, wl_fixed_t y)
> > +struct weston_pointer_motion_event *event)
> >  {
> > struct pointer_move_grab *pnt_move_grab =
> > (struct pointer_move_grab *)grab;
> > -   wl_fixed_t pointer_pos[2] = {x, y};
> > +   wl_fixed_t pointer_pos[2] = {
> > +   wl_fixed_from_double(event->x),
> > +   wl_fixed_from_double(event->y),
> > +   };
>
> Should this also be weston_pointer_motion_to_abs()?
>
> > diff --git a/src/compositor-x11.c b/src/compositor-x11.c
> > index 5129e85..57a7d11 100644
> > --- a/src/compositor-x11.c
> > +++ b/src/compositor-x11.c
> > @@ -1105,8 +1106,14 @@ x11_compositor_deliver_motion_event(struct
> x11_compositor *c,
> >
> wl_fixed_from_int(motion_notify->event_y),
> >, );
> >
> > +   event = (struct weston_pointer_motion_event) {
> > +   .mask = WESTON_POINTER_MOTION_REL,
> > +   .dx = wl_fixed_to_double(x - c->prev_x),
> > +   .dy = wl_fixed_to_double(y - c->prev_y)
> > +   };
> > +
>
> To be honest, I'm somewhat skeptical of faking relative motion from
> abs in general.
>
> Cheers,
> Daniel
> ___
> 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

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

[Jasper St. Pierre]

I'm struggling to understand the motivation for this patch.

krh has always said that you need to think of uint and int as two
entirely separate types -- mixing both in math will likely screw up.
You can see this in other places -- widths are often expressed as
signed ints in the protocol, not unsigned ints.

On Fri, Oct 23, 2015 at 11:53 PM, Giulio Camuffo
 wrote:
> 2015-10-24 1:29 GMT+03:00 Bryce Harrington :
>> Signed-off-by: Bryce Harrington 
>> ---
>>  src/compositor.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/compositor.h b/src/compositor.h
>> index 6bb6222..4443c72 100644
>> --- a/src/compositor.h
>> +++ b/src/compositor.h
>> @@ -619,9 +619,9 @@ enum weston_capability {
>>   */
>>  struct weston_backend_output_config {
>> uint32_t transform;
>> -   int32_t width;
>> -   int32_t height;
>> -   int scale;
>> +   uint32_t width;
>> +   uint32_t height;
>> +   uint32_t scale;
>>  };
>
> Reviewed-by: Giulio Camuffo 
>
>>
>>  /* Configuration struct for a backend.
>> --
>> 1.9.1
>>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: Unstable protocol name breakage

[Jasper St. Pierre]

On Mon, Oct 19, 2015 at 7:22 PM, Jonas Ådahl  wrote:
> Hi again,

... snip ...

> xdg-shell.xml: Should we bite the bullet and rename this one, or just continue
> letting its stability state be non-discoverable? It's clearly already used, 
> and
> renaming it will be painful, so not sure about this one.

People are clearly unhappy with the status quo, so I'd be fine to
rename this one to zxdg_shell.

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



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

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

[Jasper St. Pierre]

Most desktop CRTCs support a XOR key in their ROP, since it was
required by Windows for such a long time. I don't think Linux has
support for that in KMS, nor for similar things like alpha keying as
well. Perhaps we'll get it as a plane property at some point.

I don't know of any mobile/embedded chipsets that support XOR keying,
since it's not 1996.

On Thu, Oct 15, 2015 at 8:30 AM, Bill Spitzak  wrote:
> That's xor of the color bits. The blue/red is due to xor'ing with the
> subpixel antialiasing. It is more obvious if you put the cursor over a solid
> colored area where you will see strange colors.
>
> It cannot be achieved with Porter-Duff combinations. I am not sure if OpenGL
> or DirectX supports it. I am also suspicious that overlay hardware designed
> for cursors may not support it either.
>
> This would either require adding something to Wayland to enable xor of a
> cursor, or (more likely) you will have to just set the cursor to blank and
> draw the desired graphics yourself.
>
> Linux programs seem to use a white insertion bar with a black outline, so it
> is visible against all backgrounds. This is despite the fact that X11 still
> supports xor cursors, everybody dropped that as obsolete. OS/X appears to
> use a black insertion bar with a very thin white outline (ie
> partially-transparent white pixels). Both of these work with normal
> compositing.
>
>
> On 10/14/2015 06:13 AM, John Doerthy wrote:
>>
>> Hi,
>> Could you please comment on this issue, if you are currently working on
>> the Windows-like implementation of the I-beam cursor (cursor for text
>> selection) in the graphical interface?
>> In Windows, the I-beam cursor, change color based on the background. So,
>> most of the time it's black, but when you are on the dark background its
>> color cahnges and not only that, but if part of the cursor is on the
>> white background and part on the dark background, only the affected
>> areas of teh I-beam cursor change the color. Plus if you are over a text
>> the part of the cursor that overlays some character has a slightly blue
>> or red color (as you can see in the screenshots below)
>> Here are some real world examples(screenshots) from Windows 7:
>> http://imgur.com/a/IxG7w
>> Thank for your response how far are you guys in implementing this feature.
>> John
>>
>>
>> ___
>> 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jasper St. Pierre]

Agreed. It should be possible to pop up windows from the keyboard.

On Tue, Oct 13, 2015 at 8:41 AM, Bill Spitzak  wrote:
> On 10/06/2015 02:48 PM, Ben Hummon wrote:
>>
>> Weston does not allow popup menus initiated by keyboard. Remove the
>> broken keyboard shorcut for a popup from the stacking demo.
>>
>> Signed-off-by: Ben Hummon 
>> ---
>>   clients/stacking.c | 8 ++--
>>   1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/clients/stacking.c b/clients/stacking.c
>> index 6748576..f90243a 100644
>> --- a/clients/stacking.c
>> +++ b/clients/stacking.c
>> @@ -150,10 +150,6 @@ key_handler(struct window *window,
>> new_window(stacking, NULL);
>> break;
>>
>> -   case XKB_KEY_p:
>> -   show_popup(stacking, input, time, window);
>> -   break;
>> -
>
>
> Wouldn't it be better to make Weston work with this? Otherwise it will never
> get debugged.
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

The goal of focus-stealing prevention isn't to prevent hostile clients
from stealing the focus. It's to allow friendly clients to upgrade the
experience if they can track the originating event that originally
opened a window. For instance, if I launch GIMP but then go back to
typing in a terminal, after GIMP launches, it shouldn't steal the
focus, because I've interacted with another window since then.

We've tried turning off focus-stealing prevention for all new windows
without a timestamp, and it provided a very unfun experience. Lots of
applications either don't have an originating user action when they
pop up a window, or they don't track it thoroughly.

Perhaps GUI applications have gotten substantially better in the 6
years ago since we tried it -- I'd be willing to run the experiment
again. But I don't expect much changing.

On Tue, Oct 13, 2015 at 9:48 AM, Bill Spitzak  wrote:
> On 10/08/2015 01:00 PM, Daniel Stone wrote:
>>
>> Hi,
>>
>> On 8 October 2015 at 08:27, Jonas Ådahl  wrote:
>>>
>>> On Mon, Oct 05, 2015 at 12:04:49PM -0500, Derek Foreman wrote:

 There are cases in weston where it would be quite nice to have a
 sentinel value to use instead of having to have a bool for "this serial
 number is legit" too.
>>>
>>>
>>> Even though probably unlikely, for clients unaware of a possible 0 == no
>>> serial, this would mean that they would suddenly start to be killed when
>>> when they before worked just fine.
>
>
> Clients cannot be killed when they pass bad serial numbers. They don't
> really know what events the compositor accepts for a present request, so
> passing the wrong one cannot kill it.
>
> I suppose a compositor could record the serial number of every event sent to
> the client so it could make sure the request only contained actual ones, but
> I don't think anybody is going to implement a compositor that way. I expect
> compositors will check to see if the event is the last mouse-down or
> mouse-up sent to the client and not remember any other history.
>
>>> Is it really a big deal to have to multiple requests that do things
>>> differently?
>>
>>
>> Let's try to solve this empirically, then - which optional-serial
>> requests do we have apart from present/needs-attention here, and what
>> does/would the difference look like semantically?
>
>
> I agree that if there really is different behavior then there should be two
> requests.
>
> But, do you really, really, really believe that any actual usable compositor
> is going to treat the no-event present differently than a serial for an
> event that should not raise the window (such as a mouse enter event)?
>
> If you think so, please describe carefully exactly why. Since hostile
> clients can call the no-event request, stopping them is not a reason.
> Non-hostile clients will avoid sending nonsense events to the present
> request.
>
> I don't think this will happen, therefore the need for two calls here is
> false.
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

In one case, an invalid serial dictates that the window should have it's
focus attempts prevented. In the no-serial case, focus world be stolen.

On Tue, Oct 13, 2015, 10:25 AM Bill Spitzak <spit...@gmail.com> wrote:

> On 10/13/2015 09:53 AM, Jasper St. Pierre wrote:
> > The goal of focus-stealing prevention isn't to prevent hostile clients
> > from stealing the focus. It's to allow friendly clients to upgrade the
> > experience if they can track the originating event that originally
> > opened a window. For instance, if I launch GIMP but then go back to
> > typing in a terminal, after GIMP launches, it shouldn't steal the
> > focus, because I've interacted with another window since then.
> >
> > We've tried turning off focus-stealing prevention for all new windows
> > without a timestamp, and it provided a very unfun experience. Lots of
> > applications either don't have an originating user action when they
> > pop up a window, or they don't track it thoroughly.
> >
> > Perhaps GUI applications have gotten substantially better in the 6
> > years ago since we tried it -- I'd be willing to run the experiment
> > again. But I don't expect much changing.
>
> Yes but this is still not answering my question.
>
> Can you describe a design where no-event is treated *differently* than
> an unknown or disallowed event in the _present request?
>
> You are describing how they would be treated identically. I suspect that
> will always happen, but the idea that they can be treated differently is
> being used as an excuse to not add the special no-event serial of zero
> and reduce the number of _present messages from 2 to 1.
>
>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC 1/2] Introduce wl_probe_visible protocol

[Jasper St. Pierre]

Mir seems to be pushing forward with their compositor-based attachment
protocol, and if they've analyzed it and established that it covers
most cases, I'm totally fine with us taking that.

Descriptive, not prescriptive :)

On Thu, Oct 8, 2015 at 1:16 PM, Daniel Stone  wrote:
> Hi,
>
> On 1 October 2015 at 07:51, Jonas Ådahl  wrote:
>> The are a few problems with this approach, such as:
>>
>> 1) It requires an extra roundtrip to create a popup/tooltip (not that
>> big of a deal though, I'd say).
>> 2) When the parent surface has non-trivial transformations (non-90
>> degree rotation etc), a resulting rectangle is ambigous. This could be
>> made implementation specific or with some required semantics (such as
>> prefer rectangles where more corners are untouched, prefer larger
>> rectangle etc).
>> 3) It may be abused to get an (incorrect) absolute surface position.
>> 4) It is racy - for a moving surface, the visibility will change as it
>> moves.
>
> Not to sound too dismissive, but if you're trying to open a pop-up on
> a window which is also actively moving at that exact moment, you're
> never going to get a good result. So I don't think that makes much
> odds, though the rest of your reasoning is good.
>
>> A different approach of solving the same issue is to shift the
>> responsibility for positioning popups from the client to the
>> compositor. This requires a more complex protocol allowing the client
>> describing the expected semantics, as well as a roundtrip then the
>> client needs to know how the compositor positioned a given rectangle.
>> For the position readback case, this approach has the same racyness as
>> the approach in this patch, and adding a new kind of positioning logic
>> would need changing the protocol. This approach is what Mir is taking.
>>
>> Personally, I'm not completely convinced a "wl_probe" way of improving
>> the menu positioning is the better option here, and would like to hear
>> what other think about this.
>
> Speaking as the guy who suggested reviving it - because it seemed to
> be the last vague consensus - I'm totally ambivalent. It does seem
> like compositor positioning could be quite helpful in the complex
> corner cases, though it does add a little more complication to the
> compositor than previously.
>
> I'm fine with whatever you and Carlos think is best; seems like at
> this stage what we need is a compositor/toolkit implementation to
> prove the concept. If compositor positioning does seem best, then a
> quick pass through the Enlightenment/KWin guys to check that it's not
> too onerous for them to implement would be great. But overall I trust
> your judgement a lot more than I do mine.
>
> Cheers,
> Daniel
>
>>  Makefile.am|   3 ++
>>  protocol/probe-visible.xml |  91 +
>>  src/compositor.c   | 125 
>> +
>>  3 files changed, 219 insertions(+)
>>  create mode 100644 protocol/probe-visible.xml
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 1900390..00f3ad2 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -125,6 +125,8 @@ nodist_weston_SOURCES =  
>>\
>> protocol/workspaces-server-protocol.h   \
>> protocol/presentation_timing-protocol.c \
>> protocol/presentation_timing-server-protocol.h  \
>> +   protocol/probe-visible-protocol.c   \
>> +   protocol/probe-visible-server-protocol.h\
>> protocol/scaler-protocol.c  \
>> protocol/scaler-server-protocol.h   \
>> protocol/linux-dmabuf-protocol.c\
>> @@ -1345,6 +1347,7 @@ EXTRA_DIST += \
>> protocol/xdg-shell.xml  \
>> protocol/fullscreen-shell.xml   \
>> protocol/presentation_timing.xml\
>> +   protocol/probe-visible.xml  \
>> protocol/scaler.xml \
>> protocol/ivi-application.xml\
>> protocol/ivi-hmi-controller.xml \
>> diff --git a/protocol/probe-visible.xml b/protocol/probe-visible.xml
>> new file mode 100644
>> index 000..0af9ed7
>> --- /dev/null
>> +++ b/protocol/probe-visible.xml
>> @@ -0,0 +1,91 @@
>> +
>> +
>> +
>> +  
>> +Copyright © 2013  Intel Corporation
>> +Copyright © 2015  Red Hat Inc.
>> +
>> +Permission is hereby granted, free of charge, to any person obtaining a
>> +copy of this software and associated documentation files (the 
>> "Software"),
>> +to deal in the Software without restriction, including without 
>> limitation
>> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> +and/or sell copies of the Software, and to permit persons to whom the
>> +Software is furnished to do so, subject to the following conditions:
>> +
>> +The 

Re: State of Wayland protocol development

[Jasper St. Pierre]

... snip ...

On Thu, Oct 8, 2015 at 12:56 PM, Daniel Stone  wrote:
> Hi,
>
> That's a fair (and accurate) criticism, but again I don't think that
> needs one big cheese. There are quite a few people here who I think
> are fairly empowered to shut down discussions that rathole into
> totally unrelated topics - I (try to) do it on a semi-regular basis,
> and I don't see why any current active developer shouldn't feel
> empowered to, either. I think we all need to do a much better job at
> enforcing S:N ratios. For my part, I'll try to be more proactive with
> our primary source of noise - who is capable of producing excellent
> signal at times, but ...
>
>> One of the reasons I don't hack on xdg-shell is because new features I
>> want to propose would be stuck in the bikeshed forever.
>
> Fair enough, but again I think we can do that without a designated big
> cheese. I think it's pretty rare that core developers have endless
> bikeshed disagreements; they seem to mostly be random drive-by
> disagreements on the list.
>
>> This is what I believe we lost when Kristian stepped down, not just a
>> gatekeeper. Someone who can help model solutions and solve problems.
>>
>> I would love to be that person for xdg-shell, of course, but you guys
>> likely wouldn't trust me.
>
> I assume you mean me here, and that's not actually as true as you
> think it is ...
>
> The issues I had with earlier xdg-shell development mostly centred
> around your frustration with bikeshedding leading to pulling out of
> all discussion and just periodically pushing changes to a GitHub
> branch literally no-one knew about, with no plan to push it upstream.
> I think it's fairly obvious that that isn't a sustainable approach for
> a maintainer. There were a couple of others, but after our discussion
> the other day I'm much more relaxed about that, and if you (or someone
> else nominated) wanted to step up and actively push and proactively
> steer xdg-shell maintenance in a way which was transparent to the
> community, I'd be thrilled.

This is correct. A large amount of xdg-shell came out of one-on-one's
with Kristian. Talking about the race conditions I was hitting, about
experiences with wl_shell, things that made me uncomfortable, and
possible solutions.

I doubt the same protocol, something we are both very proud of, would
have arisen through design by committee^W ML discussion.

> Part of my frustration with that was entangled with xdg-shell itself, which:
>   - is lacking a clear path (at least, a clear documented path) to 1.0

My path, from a year ago, was in the form of "xdg-shell: Make stable".
I thought it was ready at the time.

http://lists.freedesktop.org/archives/wayland-devel/2014-July/016056.html

Several people had excellent editorial concerns, which we've since
fixed. At some point, the consensus was that is that it's too early to
make stable, and requires feedback from other communities like KDE,
XFCE, and EFL.

Recently (meaning earlier today) an EFL developer has gotten back to
me with some feedback. What we've decided might entail a more complex
and breaking set of changes to xdg-shell to meet new requirements.
Talk about adding new roles like tooltips and dialogs, and adding the
configure event to xdg_popup as well.

We'll see what these entail in the long run. These are sometimes
fairly big hard-to-justify shifts, and I'm not sure if a mailing list
is the best place to ask about them. I'm tempted it's a big too
heavy-weight for trying out changes like this.

There was talk about a "present" request, which has been floating
around the ML. I'd be happy to see it incorporated, but I don't have
any power over the patch landing.

>   - is still using an unstable version mechanism which thwarts every
> attempt at client discovery

Sure, I think a lot of us have been unhappy with the unstable version
mechanism, me included. We have been discussing alternate ways to
develop distribute incomplete and WIP protocols in this very thread.
That unfortunately doesn't *do* anything. Somebody wants to step up,
do the work, make the repos, and shepherd things going forward. I
would bite the bullet and do it, except I don't have permissions to
create new repos or push to the Weston repo.

I would be super happy to fix this, but I don't have the privilege to.
Do you want to volunteer?

>   - was being developed out-of-tree with little review, having new
> versions parachuted in as a fait accompli since it was already pushed
> to Mutter and GTK+ (but again, to be fair, this only happened once and
> hasn't since)

This is unfair. With every protocol change, the Weston implementations
were developed before the mutter and GTK+ ones. But Weston is a toy --
the clients are not real applications, and the compositor isn't a
complete window manager. mutter was hitting race conditions and
problems that Weston didn't hit, because it didn't have the same
expanded feature set.

xdg-shell was developed in close coordination 

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

[Jasper St. Pierre]

I imagine get/put is named after the kernel style. I typically see
ref/unref for userspace names (or ref/destroy, but nobody likes that).

On Sun, Oct 4, 2015 at 8:34 AM, Giulio Camuffo  wrote:
> 2015-07-18 0:30 GMT+03:00 Derek Foreman :
>> Sometimes the compositor wants to make sure a shm pool doesn't disappear
>> out from under it.
>>
>> For example, in Enlightenment, rendering happens in a separate thread
>> while the main thread can still dispatch events.  If a client is destroyed
>> during rendering, all its resources are cleaned up and its shm pools are
>> unmapped.  This causes the rendering thread to segfault.
>>
>> This patch adds a way for the compositor to increment the refcount of the
>> shm pool so it can't disappear, and decrement it when it's finished.
>
> I don't like much the names of these new functions, i wouldn't expect
> a function named get_something() to have side effects. Also,
> wl_shm_buffer_put_pool() doesn't take a wl_shm_buffer, but the
> wl_shm_pool.
> What about wl_shm_buffer_ref_pool(buffer) and
> wl_shm_pool_deref(pool)/wl_shm_buffer_deref_pool(buffer)?
>
>
> --
> Giulio
>
>>
>> Signed-off-by: Derek Foreman 
>> ---
>>  src/wayland-server-core.h |  7 +++
>>  src/wayland-shm.c | 15 +++
>>  2 files changed, 22 insertions(+)
>>
>> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
>> index e605432..a4a04fc 100644
>> --- a/src/wayland-server-core.h
>> +++ b/src/wayland-server-core.h
>> @@ -362,6 +362,7 @@ wl_resource_get_destroy_listener(struct wl_resource 
>> *resource,
>>  resource = tmp, 
>>\
>>  tmp = 
>> wl_resource_from_link(wl_resource_get_link(resource)->next))
>>
>> +struct wl_shm_pool;
>>  struct wl_shm_buffer;
>>
>>  void
>> @@ -388,6 +389,12 @@ wl_shm_buffer_get_width(struct wl_shm_buffer *buffer);
>>  int32_t
>>  wl_shm_buffer_get_height(struct wl_shm_buffer *buffer);
>>
>> +struct wl_shm_pool *
>> +wl_shm_buffer_get_pool(struct wl_shm_buffer *buffer);
>> +
>> +void
>> +wl_shm_buffer_put_pool(struct wl_shm_pool *pool);
>> +
>>  int
>>  wl_display_init_shm(struct wl_display *display);
>>
>> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
>> index 5c419fa..48b5140 100644
>> --- a/src/wayland-shm.c
>> +++ b/src/wayland-shm.c
>> @@ -412,6 +412,21 @@ wl_shm_buffer_get_height(struct wl_shm_buffer *buffer)
>> return buffer->height;
>>  }
>>
>> +WL_EXPORT struct wl_shm_pool *
>> +wl_shm_buffer_get_pool(struct wl_shm_buffer *buffer)
>> +{
>> +   assert(buffer->pool->refcount);
>> +
>> +   buffer->pool->refcount++;
>> +   return buffer->pool;
>> +}
>> +
>> +WL_EXPORT void
>> +wl_shm_buffer_put_pool(struct wl_shm_pool *pool)
>> +{
>> +   shm_pool_unref(pool);
>> +}
>> +
>>  static void
>>  reraise_sigbus(void)
>>  {
>> --
>> 2.1.4
>>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

I imagine it's sampling from shared memory owned by the client during
its own rendering.

On Sun, Oct 4, 2015 at 11:21 AM, Bill Spitzak  wrote:
> On 10/04/2015 08:34 AM, Giulio Camuffo wrote:
>>
>> 2015-07-18 0:30 GMT+03:00 Derek Foreman :
>>>
>>> Sometimes the compositor wants to make sure a shm pool doesn't disappear
>>> out from under it.
>>>
>>> For example, in Enlightenment, rendering happens in a separate thread
>>> while the main thread can still dispatch events.  If a client is
>>> destroyed
>>> during rendering, all its resources are cleaned up and its shm pools are
>>> unmapped.  This causes the rendering thread to segfault.
>
>
> Why is Enlightenment rendering into shared memory owned by the client?
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: Enums, bitfields and wl_arrays

[Jasper St. Pierre]

We have a few constraints. First off, not all enums are closed. Some
are intentionally open, like xdg_shell.state. So we definitely need a
distinction between a closed enum and an open enum. I'm not familiar
enough with Rust to be able to apply something to that.

Second, I think we need to make a big effort to map out how the XML
converts to a wire format. For the most part, it's obvious, except for
the n -> sun hack we apply when we don't have an interface name. We
should probably specify that somewhere.

There's also a compatibility issue that has been brought up, but I
never understood that one. Somebody else would be able to talk about
that better.

On Thu, Oct 1, 2015 at 10:49 AM, Bryce Harrington  wrote:
> The topic of adding better enum/bitfield support to the protocol has
> come up a few[0] times[1] in the past, and again more recently[2].  We
> also have several proposed patches in patchwork, but I'm not sure they
> reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].
>
> From what I gather of the discussions, no one is really against this
> feature conceptually, and impementationally the discussions appear to
> have moved further afield.  It feels like we're real close to having
> something that could be landed, but it's not 100% clear to me what
> exactly to land.  Since it's a protocol types change I would prefer to
> make sure it has a strong consensus before landing it.
>
> I know that several people have proposed patches on this - Bill, Nils
> and Auke at least.  Since there's a definite need for this, and since
> agreement appears to be not far off, I would like to get this landed
> this release.  And ideally I'd like to get this landed early in the
> release so we give plenty of time for testing.
>
> Since Auke's patchset proposalis the most recent, let's take that one as
> the candidate for landing.  Gentlemen, I'd like to ask you to review
> these three patches [5,6,7] and either give your Reviewed-by's or flag
> specific improvements needed.  If you have a more conceptual
> disagreement, and don't think the patchset is landable as implemented,
> please raise that issue asap too.
>
> Bryce
>
> 0: http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html
> 1: http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html
> 2: 
> http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html
>
> 3: http://patchwork.freedesktop.org/patch/47726/
> 4: http://patchwork.freedesktop.org/patch/47727/
> 5: http://patchwork.freedesktop.org/patch/53018/
> 6: http://patchwork.freedesktop.org/patch/53019/
> 7: http://patchwork.freedesktop.org/patch/53020/
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

As I mentioned on your post on Reddit [0], SDL2's video mode hooks are
no-ops, which explains why SDL isn't changing the resolution. You
could change SDL's code to use a different fullscreen mode. I am still
struggling why you need to change the resolution with a modeset.

[0] 
https://www.reddit.com/r/wayland/comments/3mkhlf/weston_outputs_monitor_preferred_resolution/

On Thu, Oct 1, 2015 at 8:12 AM, Robert Folland  wrote:
>
>> On 01 Oct 2015, at 17:08, Giulio Camuffo  wrote:
>>
>> 2015-10-01 18:03 GMT+03:00 Robert Folland :
>>> On 01 Oct 2015, at 16:47, Giulio Camuffo  wrote:

 2015-10-01 16:40 GMT+03:00 Robert Folland :
> Hi,
>
> I need to display video in different resolutions (the resolution of the 
> recording), but with weston/wayland I always end up with the resolution 
> preferred by the monitor (1920x1080 in my current setup).
>
> SDL2 thinks it is producing e.g. 1280x720, but that is not the real 
> output to screen. This is probably due to weston scaling this to 
> 1920x1080 for the monitor, intstead of doing a mode switching, which is 
> what I require for my application.

 Why do you need a mode switch? Unless you're using a CRT the monitor
 will scale the image up internally, and usually weston can do it
 better.
 Anyway, I assume SDL uses wl_shell, not xdg_shell, and
 wl_shell_surface.set_fullscreen accepts several modes, and one of them
 asks the compositor to perform a mode switch. Note that it *asks* to,
 there is no way to force it, and that's by design.

>>>
>>> I’ve set up a box to be an input source to other equipment. So it is 
>>> providing input to another box instead of e.g cameras, playing out 
>>> uncompressed video.
>>> So, it will not be displaying to monitors directly, but to a camera input 
>>> on another box. And that camera input is accepting a range of resolutions.
>>>
>>> When I check the resolution actually asked for from within SDL it says it 
>>> is producing my wanted resolution, but is is not actually apparing on the 
>>> output. So I suspect it is not able to force it to weston.
>>>
>>> The monitor/camera input receiving the signal is providing a list of 
>>> resolutions in its EDID data, and I guess one is preferred as a native 
>>> resolution. But as long as there are more entries in that EDID list, would 
>>> it not be a good idea to allow these to be “forced” through weston?
>>
>> It's not a good idea to let clients force modes, but it seems like you
>> just want weston to always use that resolution, am i right? If so you
>> can tell it to do so by setting the correct resolution in weston.ini.
>> Check "man weston.ini" for details.
>>
>
> Not really, this is a tool where users can change resolutions (actually 
> change video sequences) on the fly. But, it may work to restart weston on 
> every change, I can try that… thanks!
>
> -Robert
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



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

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

[Jasper St. Pierre]

For the present case, present_with_event will support focus-stealing
prevention if the serial is garbage or not up to date, whereas present
should always steal focus.

The garbage serial and don't-have-a-serial cases are different, so I
believe we should have two different methods in that case for
different behavior.

On Thu, Oct 1, 2015 at 12:52 PM, Bill Spitzak <spit...@gmail.com> wrote:
> The no-serial value really really really needs to be zero. Otherwise you get
> all kinds of annoyances with many language wrappers which map zero to false
> and all other values to true. I think most will have to resort to xor'ing
> the value with the no-serial value, meaning the numerical values are all
> different.
>
>
>
> On Wed, Sep 30, 2015 at 1:23 PM, Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>>
>>
>> In cases where we have two behaviors for serial-aware and
>> non-serial-aware operations, I would rather have two different client
>> requests.
>
>
> Absolutely wrong. One of the main reasons for the no-serial value is so that
> it is encouraged that unrecognized serial numbers act exactly like the
> no-serial case. If sending garbage to the serial-taking message has some
> useful result that is not achieved by the no-serial version, then clients
> are going to do this. Having a no-serial value avoids this design mistake.
>
>
>



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

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

[Jasper St. Pierre]

I don't necessarily like this. The absence of a serial can have
radical meanings on behavior. Being able to pass 0 to mean "no serial"
anywhere we currently rely on a serial seems like poor design to me,
and can easily be done by mistake.

In cases where we have two behaviors for serial-aware and
non-serial-aware operations, I would rather have two different client
requests.

On Wed, Sep 30, 2015 at 12:47 PM, Daniel Stone  wrote:
> Hi,
>
> On 30 September 2015 at 16:59, Derek Foreman  wrote:
>> Having an invalid serial number is quite useful - for example, we can
>> have protocol requests that optionally take a serial number or 0
>> instead of having two similar requests.
>>
>> Signed-off-by: Derek Foreman 
>> ---
>>
>> Well, let's see where this goes ;)
>>
>> I've seen a few times now when having an invalid serial number would be
>> helpful, is it too late to do this?  Are we going to break anything?
>>
>> Anything currently doing math on serial numbers can be wrong by one if one
>> of the serial numbers has wrapped around - this probably doesn't matter?
>>
>> I do wonder if we should have a wl_serial_compare() as part of wayland
>> but the semantics are tricky (a big serial and a small serial may actually
>> have happened quite close to eachother if the small happened after a
>> wrap around).
>>
>> I think the usual comparisons of interest are equality and "is A less than B
>> within (arbitrary distance to compensate for wrap-around)".  I think strcmp()
>> like semantics won't necessarily be good here because we don't usually need
>> something to tell us "b happened before a", more "these almost certainly
>> happened in the order specified in the function call".
>>
>> Where do we go from here?
>
> From the IRC discussion way back when:
> 20:27 < krh> if we do need to make a new serial, I'd much prefer to
> have it be 1 << 31
> 20:27 < krh> and then just restrict normal serial numbers space to 0 -
> (1<<31 - 1)
> 20:28 < krh> so that serial number increment is just serial = (serial
> + 1) & 0x7fff
>
> I have no relevant opinion on the matter, but I guess that 0x8000
> (or 0x) is a much more obviously invalid serial number than 0,
> which could also just be the victim of something uninitialised.
>
> A helper would be nice, though like you say I think it has to be
> directional/multi-return (older inc. wraparound? identical?
> newer/error? invalid?). It'd probably be best to do that inside an
> active user and only then shuffle it into Wayland.
>
> So, with the change to a different serial, and a note in documentation
> somewhere that any extension relying on the invalid-serial behaviour
> must itself explicitly document that:
> Acked-by: Daniel Stone 
>
> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: random window position with desktop shell

[Jasper St. Pierre]

To be honest, the more I think about it, the more likely I am to just
want to add back in a global coordinate system. There's too many
problems that GNOME is having by omitting it. For starters, menu and
tooltip positioning that works correctly. Saving and restarting window
positions is something that I've desperately missed ever since I
started using Linux on my multimonitor desktop rig again.

I don't see many of the advantages of omitting a global coordinate
system anymore, and I don't see many downsides, and a lot of issues
we're having seem to be predicated by this. I want Wayland to succeed,
and that might mean that we go back to a simpler idea.

On Mon, Sep 28, 2015 at 2:13 AM, Daniel Stone  wrote:
> On 25 September 2015 at 18:46, Bill Spitzak  wrote:
>> On Fri, Sep 25, 2015 at 1:37 AM, Pekka Paalanen  wrote:
>>> It is a design decision in Wayland/desktop to not expose absolute
>>> window positions to clients at all. This means that you simply cannot
>>> know where a top-level window is precisely, you can only know which
>>> outputs it overlaps with.
>>
>> This is an interesting experiement but I believe it is doomed in the long
>> run. I would try it
>
> We have, ever since Wayland's creation. It works.
>
>> but I think the end result is that every single desktop
>> environment will add this as an "extension"
>
> None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
> digital signage, not video walls, not set-top boxes, not smart TVs,
> not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.
>
>> because so much software will not work without it.
>
> It does.
>
>> You have to realize that X and Windows and OSX all use
>> 2 numbers to describe the location of a window
>
> Yeah, I'm well aware of how the X input stack works.
>
>> and thus getting software to
>> stop assuming that is probably a Sisyphean task.
>
> It hasn't been.
>
>>> Windows that are not top-level can often be placed relative to another
>>> wl_surface. This is the only form of precise positioning supported on
>>> desktops.
>>
>> This is correct and could make it work in the vast majority of cases, but
>> supporting portable programs is going to be difficult and hacky. Qt code,
>> for instance, calculate QPoint objects (which contain 2 numbers) and assume
>> the result fully defines where a menu will pop up. Now they usually
>> calculate these by asking for the position of existing widgets and adding
>> offsets, so if the returned coordinates are in a space such that the future
>> parent is at 0,0 then this will work acceptably. But I fully expect Qt to
>> first look for the window-position extension and use that if possible, with
>> this hack as a rarely-used fallback.
>
> Your expectations are wrong. Look at how Qt has worked just fine (and
> shipped in many environments) without it for years.
>
> This is another dead end of a thread. It's been this way for years
> because of very valid reasons, it works (despite you being convinced
> that it could never work) fine, and it's not changing.
>
> If you'd like to productively contribute to this, perhaps you could
> pick up the surface position negotiation protocol, which would allow
> clients to guarantee that menus would not be positioned off-screen.
>
> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

Nope. Why would it be? Also, please CC wayland-de...@freedesktop.org
in the future.

On Sun, Sep 27, 2015 at 8:31 PM, Bryce Harrington  wrote:
> On Mon, Sep 28, 2015 at 09:00:04AM +0530, vlse wrote:
>> As per this weston git commit ae5df83f8e029e427f5d587622b3d25b3d1b4964
>>
>> You say: launcher-logind: Remove old VT switching code, move to 
>> SwitchTo/Activate
>>
>> Does it means that from now systemd is a hard dependency for weston.
>
> No
>
>> Kindly, don't make systemd a hard dependency for weston.
>>
>> Yours Truly
>>
>> vlse
>> http://www.veera.biz



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

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

[Jasper St. Pierre]

We're refactoring this to have multiple launcher "implementations".
---
 Makefile.am   |   4 +-
 src/launcher-logind.c | 940 ++
 src/launcher-logind.h | 123 +++
 src/launcher-util.c   |   2 +-
 src/logind-util.c | 940 --
 src/logind-util.h | 123 ---
 6 files changed, 1066 insertions(+), 1066 deletions(-)
 create mode 100644 src/launcher-logind.c
 create mode 100644 src/launcher-logind.h
 delete mode 100644 src/logind-util.c
 delete mode 100644 src/logind-util.h

diff --git a/Makefile.am b/Makefile.am
index 62719c9..79a442c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -138,8 +138,8 @@ if HAVE_SYSTEMD_LOGIN
 libsession_helper_la_SOURCES +=\
src/dbus.h  \
src/dbus.c  \
-   src/logind-util.h   \
-   src/logind-util.c
+   src/launcher-logind.h   \
+   src/launcher-logind.c
 libsession_helper_la_CFLAGS += $(SYSTEMD_LOGIN_CFLAGS) $(DBUS_CFLAGS)
 libsession_helper_la_LIBADD += $(SYSTEMD_LOGIN_LIBS) $(DBUS_LIBS)
 endif
diff --git a/src/launcher-logind.c b/src/launcher-logind.c
new file mode 100644
index 000..4fab9a4
--- /dev/null
+++ b/src/launcher-logind.c
@@ -0,0 +1,940 @@
+/*
+ * Copyright © 2013 David Herrmann
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "compositor.h"
+#include "dbus.h"
+#include "launcher-logind.h"
+
+#define DRM_MAJOR 226
+
+#ifndef KDSKBMUTE
+#define KDSKBMUTE  0x4B51
+#endif
+
+struct weston_logind {
+   struct weston_compositor *compositor;
+   bool sync_drm;
+   char *seat;
+   char *sid;
+   unsigned int vtnr;
+   int vt;
+   int kb_mode;
+   int sfd;
+   struct wl_event_source *sfd_source;
+
+   DBusConnection *dbus;
+   struct wl_event_source *dbus_ctx;
+   char *spath;
+   DBusPendingCall *pending_active;
+};
+
+static int
+weston_logind_take_device(struct weston_logind *wl, uint32_t major,
+ uint32_t minor, bool *paused_out)
+{
+   DBusMessage *m, *reply;
+   bool b;
+   int r, fd;
+   dbus_bool_t paused;
+
+   m = dbus_message_new_method_call("org.freedesktop.login1",
+wl->spath,
+"org.freedesktop.login1.Session",
+"TakeDevice");
+   if (!m)
+   return -ENOMEM;
+
+   b = dbus_message_append_args(m,
+DBUS_TYPE_UINT32, ,
+DBUS_TYPE_UINT32, ,
+DBUS_TYPE_INVALID);
+   if (!b) {
+   r = -ENOMEM;
+   goto err_unref;
+   }
+
+   reply = dbus_connection_send_with_reply_and_block(wl->dbus, m,
+ -1, NULL);
+   if (!reply) {
+   r = -ENODEV;
+   goto err_unref;
+   }
+
+   b = dbus_message_get_args(reply, NULL,
+ DBUS_TYPE_UNIX_FD, ,
+ DBUS_TYPE_BOOLEAN, ,
+ DBUS_TYPE_INVALID);
+   if (!b) {
+   r = -ENODEV;
+   goto err_reply;
+   }
+
+   r = fd;
+   if (paused_out)
+   *paused_out = paused;
+
+err_reply:
+   dbus_message_unref(reply);
+err_unref:
+   dbus_message_unref(m);
+   return r;
+}
+
+static void
+weston_logind_release_device(struct weston_logind *wl, uint32_t major,
+uint32_t 

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

[Jasper St. Pierre]

t;tty, KDSETMODE, KD_TEXT))
+   weston_log("failed to set KD_TEXT mode on tty: %m\n");
+
+   /* We have to drop master before we switch the VT back in
+* VT_AUTO, so we don't risk switching to a VT with another
+* display server, that will then fail to set drm master. */
+   drmDropMaster(launcher->drm_fd);
+
+   mode.mode = VT_AUTO;
+   if (ioctl(launcher->tty, VT_SETMODE, ) < 0)
+   weston_log("could not reset vt handling\n");
+}
+
+static int
+launcher_direct_activate_vt(struct weston_launcher *launcher_base, int vt)
+{
+   struct launcher_direct *launcher = wl_container_of(launcher_base, 
launcher, base);
+   return ioctl(launcher->tty, VT_ACTIVATE, vt);
+}
+
+static int
+launcher_direct_connect(struct weston_launcher **out, struct weston_compositor 
*compositor,
+   int tty, const char *seat_id, bool sync_drm)
+{
+   struct launcher_direct *launcher;
+
+   if (geteuid() != 0)
+   return -EINVAL;
+
+   launcher = zalloc(sizeof(*launcher));
+   if (launcher == NULL)
+   return -ENOMEM;
+
+   launcher->base.iface = _direct_iface;
+   launcher->compositor = compositor;
+
+   if (setup_tty(launcher, tty) == -1) {
+   free(launcher);
+   return -1;
+   }
+
+   * (struct launcher_direct **) out = launcher;
+   return 0;
+}
+
+static void
+launcher_direct_destroy(struct weston_launcher *launcher_base)
+{
+   struct launcher_direct *launcher = wl_container_of(launcher_base, 
launcher, base);
+
+   launcher_direct_restore(>base);
+   wl_event_source_remove(launcher->vt_source);
+
+   if (launcher->tty >= 0)
+   close(launcher->tty);
+
+   free(launcher);
+}
+
+struct launcher_interface launcher_direct_iface = {
+   launcher_direct_connect,
+   launcher_direct_destroy,
+   launcher_direct_open,
+   launcher_direct_close,
+   launcher_direct_activate_vt,
+   launcher_direct_restore,
+};
diff --git a/src/launcher-impl.h b/src/launcher-impl.h
new file mode 100644
index 000..742721b
--- /dev/null
+++ b/src/launcher-impl.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright © 2015 Jasper St. Pierre
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission.  The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "config.h"
+
+#include "compositor.h"
+
+struct weston_launcher;
+
+struct launcher_interface {
+   int (* connect) (struct weston_launcher **launcher_out, struct 
weston_compositor *compositor,
+int tty, const char *seat_id, bool sync_drm);
+   void (* destroy) (struct weston_launcher *launcher);
+   int (* open) (struct weston_launcher *launcher, const char *path, int 
flags);
+   void (* close) (struct weston_launcher *launcher, int fd);
+   int (* activate_vt) (struct weston_launcher *launcher, int vt);
+   void (* restore) (struct weston_launcher *launcher);
+};
+
+struct weston_launcher {
+   struct launcher_interface *iface;
+};
+
+extern struct launcher_interface launcher_logind_iface;
+extern struct launcher_interface launcher_weston_launch_iface;
+extern struct launcher_interface launcher_direct_iface;
diff --git a/src/launcher-logind.c b/src/launcher-logind.c
index 4fab9a4..c148b24 100644
--- a/src/launcher-logind.c
+++ b/src/launcher-logind.c
@@ -44,7 +44,7 @@
 
 #include "compositor.h"
 #include "dbus.h"
-#include "launcher-logind.h"
+#include "launcher-impl.h"
 
 #define DRM_MAJOR 226
 
@@ -52,7 +52,8 @@
 #define KDSKBMUTE  0x4B51
 #endif
 
-struct weston_logind {
+struct launcher_logind {
+   struct weston_launcher base;
struct weston_compositor *compositor;
bool sync_drm;
char *seat;
@@ -70,7 +71,7 @@ struct w

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

[Jasper St. Pierre]

In the time since this code was written, logind has gained new APIs to
handle VT switching automatically and activate sessions. Switch to that.
---
 src/launcher-logind.c | 219 +-
 1 file changed, 40 insertions(+), 179 deletions(-)

diff --git a/src/launcher-logind.c b/src/launcher-logind.c
index c148b24..f755ec3 100644
--- a/src/launcher-logind.c
+++ b/src/launcher-logind.c
@@ -27,17 +27,12 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -48,10 +43,6 @@
 
 #define DRM_MAJOR 226
 
-#ifndef KDSKBMUTE
-#define KDSKBMUTE  0x4B51
-#endif
-
 struct launcher_logind {
struct weston_launcher base;
struct weston_compositor *compositor;
@@ -61,8 +52,6 @@ struct launcher_logind {
unsigned int vtnr;
int vt;
int kb_mode;
-   int sfd;
-   struct wl_event_source *sfd_source;
 
DBusConnection *dbus;
struct wl_event_source *dbus_ctx;
@@ -242,27 +231,37 @@ launcher_logind_close(struct weston_launcher *launcher, 
int fd)
 static void
 launcher_logind_restore(struct weston_launcher *launcher)
 {
-   struct launcher_logind *wl = wl_container_of(launcher, wl, base);
-   struct vt_mode mode = { 0 };
-
-   ioctl(wl->vt, KDSETMODE, KD_TEXT);
-   ioctl(wl->vt, KDSKBMUTE, 0);
-   ioctl(wl->vt, KDSKBMODE, wl->kb_mode);
-   mode.mode = VT_AUTO;
-   ioctl(wl->vt, VT_SETMODE, );
 }
 
 static int
 launcher_logind_activate_vt(struct weston_launcher *launcher, int vt)
 {
struct launcher_logind *wl = wl_container_of(launcher, wl, base);
+   DBusMessage *m;
+   bool b;
int r;
 
-   r = ioctl(wl->vt, VT_ACTIVATE, vt);
-   if (r < 0)
-   return -1;
+   m = dbus_message_new_method_call("org.freedesktop.login1",
+"/org/freedesktop/login1/seat/self",
+"org.freedesktop.login1.Seat",
+"SwitchTo");
+   if (!m)
+   return -ENOMEM;
 
-   return 0;
+   b = dbus_message_append_args(m,
+DBUS_TYPE_UINT32, ,
+DBUS_TYPE_INVALID);
+   if (!b) {
+   r = -ENOMEM;
+   goto err_unref;
+   }
+
+   dbus_connection_send(wl->dbus, m, NULL);
+   r = 0;
+
+ err_unref:
+   dbus_message_unref(m);
+   return r;
 }
 
 static void
@@ -678,157 +677,6 @@ launcher_logind_release_control(struct launcher_logind 
*wl)
 }
 
 static int
-signal_event(int fd, uint32_t mask, void *data)
-{
-   struct launcher_logind *wl = data;
-   struct signalfd_siginfo sig;
-
-   if (read(fd, , sizeof sig) != sizeof sig) {
-   weston_log("logind: cannot read signalfd: %m\n");
-   return 0;
-   }
-
-   if (sig.ssi_signo == (unsigned int)SIGRTMIN)
-   ioctl(wl->vt, VT_RELDISP, 1);
-   else if (sig.ssi_signo == (unsigned int)SIGRTMIN + 1)
-   ioctl(wl->vt, VT_RELDISP, VT_ACKACQ);
-
-   return 0;
-}
-
-static int
-launcher_logind_setup_vt(struct launcher_logind *wl)
-{
-   struct stat st;
-   char buf[64];
-   struct vt_mode mode = { 0 };
-   int r;
-   sigset_t mask;
-   struct wl_event_loop *loop;
-
-   snprintf(buf, sizeof(buf), "/dev/tty%u", wl->vtnr);
-   buf[sizeof(buf) - 1] = 0;
-
-   wl->vt = open(buf, O_RDWR|O_CLOEXEC|O_NONBLOCK);
-
-   if (wl->vt < 0) {
-   r = -errno;
-   weston_log("logind: cannot open VT %s: %m\n", buf);
-   return r;
-   }
-
-   if (fstat(wl->vt, ) == -1 ||
-   major(st.st_rdev) != TTY_MAJOR || minor(st.st_rdev) <= 0 ||
-   minor(st.st_rdev) >= 64) {
-   r = -EINVAL;
-   weston_log("logind: TTY %s is no virtual terminal\n", buf);
-   goto err_close;
-   }
-
-   /*r = setsid();
-   if (r < 0 && errno != EPERM) {
-   r = -errno;
-   weston_log("logind: setsid() failed: %m\n");
-   goto err_close;
-   }
-
-   r = ioctl(wl->vt, TIOCSCTTY, 0);
-   if (r < 0)
-   weston_log("logind: VT %s already in use\n", buf);*/
-
-   if (ioctl(wl->vt, KDGKBMODE, >kb_mode) < 0) {
-   weston_log("logind: cannot read keyboard mode on %s: %m\n",
-  buf);
-   wl->kb_mode = K_UNICODE;
-   } else if (wl->kb_mode == K_OFF) {
-   wl->kb_mode = K_UNICODE;
-   }
-
-   if (ioctl(wl->vt, KDSKBMUTE, 1) < 0 &&
-   ioctl(wl->vt, KDSKBMODE, K_OFF) < 0) {
-   r = -errno;
-   weston_log("logind: cannot set K_OFF KB-mode on %s: %m\n",
-  buf);
-   goto err_close;
-   }
-
-   if (ioctl(wl->vt, 

Re: wl_surface.attach with NULL wl_buffer behaviour

[Jasper St. Pierre]

Destroying the xdg_surface is absolutely OK. I'm not sure why the Qt
people consider it wrong.

On Wed, Sep 2, 2015 at 11:38 AM, Prabhu S <prabhusun...@gmail.com> wrote:
> With the below change in simple-shm.c, weston+fbdev backend will be stuck
> and other compositors may work. It depends on compositor implementation and
> the actual behavior supposed to be is not clearly defined. I'm still trying
> to identify fix in weston, it looks like state information is overwritten
> before idle_repaint is being called.
>
> window->callback = wl_surface_frame(window->surface);
> wl_callback_add_listener(window->callback, _listener, window);
> wl_surface_commit(window->surface);
>
>+ wl_surface_attach(window->surface, 0, 0, 0);
> +wl_surface_damage(window->surface,
>   0, 0, 0, 0);
>+ wl_surface_commit(window->surface);
>
> But the cause is wl_buffer set to null from the client and as per
> discussions it is not recommended. So we are trying to get this issue fixed
> in the QTWayland plugin.
> https://bugreports.qt.io/browse/QTBUG-47902
>
> Some proposal to hide the surface would be greatly appreciated.
> Below the discussion in the thread.
>
> "I did a quick check on gtk+ and it seems that in:
> gdk_wayland_window_hide_surface (GdkWindow *window)
> they actually destroy* the surface ... which sounds wrong as well?
>
> I tried to dig into EFL code as well .. but gave up due to not finding the
> implementation of efl_gfx_visible_set (if someone can either point to that
> or find the actual function to look at, that would be nice)"
>
>
>
> On Mon, Aug 24, 2015 at 4:35 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
>>
>> On Fri, 21 Aug 2015 19:04:11 -0500
>> Prabhu S <prabhusun...@gmail.com> wrote:
>>
>> > Below is the case where I'm getting stuck with the actual test case.
>> > Wondering why there is no callback wl_callb...@25.done or
>> > wl_buffer@29.release
>> > The EGL implementation depends on these callback/buffer release.
>>
>> You will not get wl_callb...@25.done, because the NULL wl_buffer has
>> overwritten the other wl_buffer, leaving the wl_surface without any
>> content, which makes it disappear from screen. Frame callbacks are not
>> intended to be posted for non-visible wl_surfaces.
>>
>> You should get wl_buffer@29.release though. I bet you actually do get
>> it, but something else is stopping the incoming Wayland events from
>> being dispatched. See:
>> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014121.html
>> and "protocol dumpers" on:
>> http://wayland.freedesktop.org/extras.html
>>
>> My wild guess would be that something is blocking, waiting on the frame
>> callback, likely EGL. It's not really EGL's bug but the application's
>> (or Qt).
>>
>> > Also noticed if the valid buffer is attached immediately after null
>> > buffer,
>> > everything is fine, so most of the time it is unnoticed. If the frame is
>>
>> Hmm, no, things should not be fine in that case. Well, it depends on
>> what role the wl_surface you are committing on has, but the very least
>> it may cause flicker.
>>
>> You definetely want to get rid of that null attach. You do not want to
>> just ignore it.
>>
>> > complex, egl will attach after null frame.
>> >
>>
>> It sounds like your application is committing to the wl_surface behind
>> Qt's back somehow, and it only works occasionally by luck.
>>
>> > I will keep debug if any other race conditions in my implementation.
>> >
>> > [3741557.293]  -> wl_surface@20.frame(new id wl_callback@25)
>> > [3741557.476]  -> wl_surface@20.attach(wl_buffer@29, 0, 0)
>> > [3741557.676]  -> wl_surface@20.damage(0, 0, 800, 480)
>> > [3741557.906]  -> wl_surface@20.commit() <=EGL
>> > [3741558.500]  -> wl_surface@20.attach(nil, 0, 0) <=QTWayland
>> > [3741558.604]  -> wl_surface@20.commit() <=QTWayland
>> > stuck
>> >
>> >
>> > On Fri, Aug 21, 2015 at 12:16 PM, Jasper St. Pierre
>> > <jstpie...@mecheye.net>
>> > wrote:
>>
>> ...
>>
>> > > However crazy it is, the logic sort of makes sense -- the "frame"
>> > > event is guaranteed to be called once a frame when the surface content
>> > > is painted and shown on the screen. When there's no surface content,
>> > > it isn't painted, so the frame event isn't called.
>> > >
>> > > I'm not sure what you mean about a

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

[Jasper St. Pierre]

Reviewed-by: Jasper St. Pierre <jstpie...@mecheye.net>

On Tue, Sep 1, 2015 at 8:32 AM, Derek Foreman <der...@osg.samsung.com> wrote:
> Right now many toolkits (toytoolkit, gtk+ and EFL) will send an
> ack_configure request immediately in response to a configure event,
> even if they're not immediately committing the surface at that time.
>
> This leads to a situation where multiple configures receive ack_configure
> before any commit happens.
>
> There's really no reason for that sequence of events to bother a compositor,
> so this just clarifies the language to make it ok.
>
> Signed-off-by: Derek Foreman <der...@osg.samsung.com>
> ---
>  protocol/xdg-shell.xml | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> index f98e760..1d37e36 100644
> --- a/protocol/xdg-shell.xml
> +++ b/protocol/xdg-shell.xml
> @@ -398,8 +398,8 @@
>
>  When a configure event is received, if a client commits the
>  surface in response to the configure event, then the client
> -must make a ack_configure request before the commit request,
> -passing along the serial of the configure event.
> +must make an ack_configure request sometime before the commit
> +request, passing along the serial of the configure event.
>
>  For instance, the compositor might use this information to move
>  a surface to the top left only when the client has drawn itself
> @@ -407,6 +407,14 @@
>
>  If the client receives multiple configure events before it
>  can respond to one, it only has to ack the last configure event.
> +
> +A client is not required to commit immediately after sending
> +an ack_configure request - it may even ack_configure several times
> +before its next surface commit.
> +
> +The compositor expects that the most recently received
> +ack_configure request at the time of a commit indicates which
> +configure event the client is responding to.
>
>
>  
> --
> 2.5.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: wl_surface.attach with NULL wl_buffer behaviour

[Jasper St. Pierre]

We need to fix that documentation, then, along with fixing Weston.
mutter will give you an error with this event stream, since attaching
a NULL buffer for an xdg_surface is invalid.

This behavior is one of the reasons why I removed this ability from
xdg_surface and instead made it an error -- the semantics were
extremely unclear, and practically the same as destroying and
recreating the xdg_surface. Please do that instead.

However crazy it is, the logic sort of makes sense -- the frame
event is guaranteed to be called once a frame when the surface content
is painted and shown on the screen. When there's no surface content,
it isn't painted, so the frame event isn't called.

I'm not sure what you mean about a buffer release event -- you never
attached a buffer to begin with, so I can't imagine how you'll get an
event on it.

On Fri, Aug 21, 2015 at 10:03 AM, Prabhu S prabhusun...@gmail.com wrote:
 Hi,
 Based on the wayland protocol specification for wl_surface::attach
If wl_surface.attach is sent with a NULL wl_buffer, the following
 wl_surface.commit will remove the surface content.

 Wondering if wl_surface_attach called with wl_buffer=NULL, will there be any
 wl_buffer release event or frame callbacks?

 Modified the redraw in simple-shm.c as below and not receiving any callback
 or buffer release. It just got stuck.
 The same thing is being done in qtwayland to hide the surface and it is
 getting stuck. Some help to check this case would be helpful.

 static int odd = 1;
 if(odd == 1){
 wl_surface_attach(window-surface, buffer-buffer, 0, 0);
 wl_surface_damage(window-surface,
   20, 20, window-width - 40, window-height - 40);
 odd = 0;
 }
 else{
 wl_surface_attach(window-surface, 0, 0, 0);
 wl_surface_damage(window-surface,
   0, 0, 0, 0);
 odd=1;
 }



 [823379.816]  - wl_compositor@4.create_surface(new id wl_surface@3)
 [823379.949]  - xdg_shell@6.get_xdg_surface(new id xdg_surface@7,
 wl_surface@3)
 [823380.120]  - xdg_surface@7.set_title(simple-shm)
 [823380.244]  - wl_surface@3.damage(0, 0, 250, 250)
 [823381.333]  - wl_shm@5.create_pool(new id wl_shm_pool@8, fd 5, 25)
 [823381.561]  - wl_shm_pool@8.create_buffer(new id wl_buffer@9, 0, 250,
 250, 1000, 1)
 [823381.870]  - wl_shm_pool@8.destroy()
 [823384.880]  - wl_surface@3.attach(wl_buffer@9, 0, 0)
 [823385.095]  - wl_surface@3.damage(20, 20, 210, 210)
 [823385.317]  - wl_surface@3.frame(new id wl_callback@10)
 [823385.443]  - wl_surface@3.commit()
 [823388.852] wl_display@1.delete_id(8)
 [823388.979] xdg_surface@7.configure(0, 0, array, 4)
 [823389.238]  - xdg_surface@7.ack_configure(4)
 [823401.773] wl_display@1.delete_id(10)
 [823401.908] wl_buffer@9.release()
 [823401.991] wl_callb...@10.done(4056537)
 [823404.239]  - wl_surface@3.attach(nil, 0, 0)
 [823404.442]  - wl_surface@3.damage(0, 0, 0, 0)
 [823404.663]  - wl_surface@3.frame(new id wl_callback@10)
 [823404.792]  - wl_surface@3.commit()
 [823406.292] xdg_surface@7.configure(0, 0, array, 5)
 [823406.524]  - xdg_surface@7.ack_configure(5)


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




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

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

[Jasper St. Pierre]

If the client still has key focus, then it should get the key release.
That sounds like a compositor bug to me.

On Thu, Jul 16, 2015 at 10:28 AM, Arnaud Vrac raw...@gmail.com wrote:
 On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org
 wrote:
  On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
  What is the value of clients having this information?
 
  The same there is in having wl_touch.cancelled. See the cases in the
  original email in the thread.
 
  I think we've
  tried to hide grab semantics from the point of view of the client and
  simply say we can revoke input at any time, including in response to
  a request you make, which gives us, the compositor, a lot more
  leeway
  with future possibilities.
 
  Sure, I'm all for that. What I'd really want is having a way to tell
  clients we do so. I'm totally fine with documenting the places where
  this potentially happens on a per-case basis, even if the final wording
  is compositor dependent, same as for seat.release_input emission.
 
  That said, toolkits/clients will surely expect some consistence across
  compositors, so the leeway is relative.
 
 
  Grabs were a major pain point in X11 since they were overspecified,
  so
  we're trying to not fall into that same trap again.
 
  I'm sure there is a lot of ground between let's not overspecify and
  let's go shopping.
 
  It would be convenient first to identify what are the sore points with
  X grabs. AFAICT, most of these come from grabs not being easily
  transferred, and the WM/screensaver/etc not being more of a client to
  revoke/break grabs. On wayland the compositor is completely free to do
  as it pleases, with and without this change I'm proposing.

 Yeah, transferring grabs race-free, a lack of being able to override
 or revoke grabs are the top two. But focus management + grabs in X11
 is tricksy and sort of awkward: if I take a keyboard grab, key focus
 can still navigate around as usual, we'll just get NotifyWhileGrabbed
 as our detail.

  However, one thing that X did well is defining a consistent event
  delivery model when grabs were being taken (well, except for touch
  events...), so both the grabbing and the pre-grab windows are well
  aware of what's going on, I think one is due in wayland, at least face
  to clients.

 Did it? I don't know of any model that lets me know when a client has
 taken a grab or ungrabs their existing grab. The exception is that I
 believe if I'm the key or pointer focus, I'll get a FocusOut / Leave
 event with the NotifyGrabbed detail, and when the grab is dropped
 (and I am still the key focus / pointer focus, which is not
 guaranteed!), we'll get the reverse event with NotifyUngrabbed.

 And in X11, this is actually good, because such an event would be
 racy: some other client might have taken a grab in such a time. And it
 happens all the time because of passive grabs, including X11's own
 implicit passive grab on the pointer.

 Anyway, this model matches well with wl_keyboard.leave /
 wl_pointer.leave being sent at the start of device grabs.

 
  For instance, if the user is in a game that has a keyboard grab and
  presses Alt-Tab to switch out, the client should just have its
  keyboard grab revoked without having to have that as a possibility in
  the protocol spec. Same thing with tray icon behavior, etc.
 
  sure, in that case you'd still get wl_keyboard.leave and the client can
  properly undo the key press / mods. But notice there is always a need
  to know when to undo (eg. in your example above, the game might have
  bound Alt to release flares, if you first press Alt and then Tab, and
  the client doesn't get the Alt key release, you don't want to leave
  that stuck when you focus back)

 The client gets a wl_keyboard.leave. Is that not good enough? What use
 cases does this new event solve?


 There's a case where that doesn't happen: if the key press triggers the
 activation of an input method, which grabs the keyboard. The client still
 keeps the focus and has no way to know if has to stop generating key repeats
 for the key that triggered the activation.

 I'm getting exactly this issue, the keyboard grab is needed in the virtual
 keyboard to be usable with the arrow keys.



  Clients need to cope with losing mouse and keyboard focus at any
  time,
  and with seats going away at any time. It's just how it is.
 
  Toolkits are nothing else than giant state machines, they rely on a
  meaningful event order, or some proper notification when things go
  south. If you mess with that, you'll get clients in inconsistent
  states, including:
 
  - stuck buttons
  - gestures listening to vanished touch sequences, unable to trigger
  anymore
  - stuck repeat keys


 --
 Arnaud



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

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

[Jasper St. Pierre]

The shell is a client. Both are technically correct, but I'm fine with
this change if it makes things easier to read. We do use the terms
shell and client way too much. :)

On Thu, Jul 9, 2015 at 10:07 AM, Christopher Michael
cpmich...@osg.samsung.com wrote:
 Documentation for the prepare_lock_surface event description
  is incorrect as it says to tell the client to create... however it is
  actually the shell which creates the lock surface.


 Signed-off-by: Chris Michael cp.mich...@samsung.com
 ---
  protocol/desktop-shell.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
 index fb0b748..147e50d 100644
 --- a/protocol/desktop-shell.xml
 +++ b/protocol/desktop-shell.xml
 @@ -43,7 +43,7 @@
  /event

  event name=prepare_lock_surface
 -  description summary=tell the client to create, set the lock
 surface
 +  description summary=tell the shell to create, set the lock
 surface
 Tell the shell we want it to create and set the lock surface, which
 is
 a GUI asking the user to unlock the screen. The lock surface is
 announced with 'set_lock_surface'. Whether or not the shell actually
 --
 2.4.4
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: cross-client surface references

[Jasper St. Pierre]

No, it's not the same thing. You want an xdg_surface interface exposed
on both sides. We don't want that. The resulting derail was us
collectively ramming our heads straight into the wall trying to figure
out any way that having the same interface exposed on both sides could
make any sense.

xdg_surface was not designed as an API to be used by multiple
consumers. There would be *no* way to make it work. None. Stop trying.

This is why I'm proposing a new API to be used in its stead.

On Thu, Jul 9, 2015 at 8:55 AM, Bill Spitzak spit...@gmail.com wrote:
 On 07/09/2015 02:21 AM, Jonas Ådahl wrote:

 That is more or less what was the idea before the thread derailed.


 I have no idea why you think my proposal derailed this when I was
 attempting to describe EXACTLY the same thing you are, except I replaced
 fd with a key which I figured is a 128-bit random number or a text
 representation of that number.

 Something like:

 low-priv-client:

 xdg_surf = xdg_shell.get_xdg_surface
 fd = export(xdg_surf)
 * pass fd to high-priv-client via dbus *


 In my version:

   key = export(xdg_surf)
   * pass key to high-priv-client via any mechanism that can send a 128-bit
 number, such as using argv.

 high-priv-client:

 * receive fd from low-priv-client via dbus *
 xdg_foreign = import(fd)


 In my version
   * recieve key by whatever mechanism
   xdg_foreign = import(key, xdg_surface)

 I think the import needs to indicate the interface it expects. This allows
 the child to use a different version of the api, and insure the correct
 wl_proxy is created.

 xdg_surf = xdg_shell.get_xdg_surface
 xdg_surf.set_parent(xdg_foreign)

 I think that if we clarify what happens if the exported surfaces
 disappears (which is the race you are referring to I suppose),


 That is why I said there would need to be a destroy event.

 if
 we force the set_parent(foreign) to always stack above the foreign tree
 (similar to how subsurfaces stacking works), what would the security
 implications be?


 Arrgh! As I have posted about 10 times now, it is EXACTLY how subsurface
 stacking works, and it should be using the SAME api! The only difference
 between a child window and a subsurface is that the compositor is allowed to
 insert other surfaces between a child and it's parent.

 I'm sorry I'm being abrasive in my posts but it seems I am hitting a brick
 wall. I try really hard to describe an idea, and then EXACTLY the same idea
 is posted as here is what we want before Bill derailed it!


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



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

Re: cross-client surface references

[Jasper St. Pierre]

My issue with this is that you're tying two things together. You want
access to a surface, and you think you can do this by having
global cross-client objects and handles and such. I don't see a need
for this. We can just add a new protocol that does what we want.

We have a few requirements:

1. We want to be able to refer to another surface for the point of
establishing parent-child modal dialog relationships. This is
important for sandboxing work.

2. We want to be able to pass this reference to a parent into a
subprocess, and perhaps not necessarily over the Wayland protocol. For
instance, it might want to be passed through DBus, or passed through a
command-line argument or environment variable somehow.

Let's do this by adding a new protocol: sandboxed_surface_manager.

(I didn't want to give it the name sandboxed_shell -- shell is overrated)

Here's what we get:

   sandboxed_surface *
sandboxed_surface_manager.get_surface_reference(xdg_surface *surface);
   sandboxed_surface * sandboxed_surface_manager.get_surface_for_id(string id);
   string sandboxed_surface.serialize_to_id();
   void sandboxed_surface.set_as_a_child(xdg_surface *surface);

Calling sandboxed_surface.serialize_to_id(); gives you an ID you can
shove through some other system. That ID should be unguessable.
Calling sandboxed_surface_manager.get_surface_for_id(); retrieves that
surface and deletes the ID from the global namespace.

(If you want to, replace the global ID namespace with an fd -- I can't
think of any way of having a compositor create an fd for an object and
have it still be understood for as the same object after it's passed
through a few clients without kernel support, but perhaps there's some
eventfd trick I'm missing?)

The things you can do with a sandboxed_surface are very limited. You
can set a new surface as a child (we could, I suppose, extend
xdg_surface.set_parent to take this new sandboxed_surface object as
well). You could perhaps do other things as well.

But the idea here is that we stay in object space as much as possible,
and we don't have an arbitrary way of fetching an xdg_surface on the
other side of a pipe and dealing with the resulting synchronization
issues. That's just asking for danger-town-USA.

Basically, as krh once told me, any time you think about using global
IDs in Wayland, it's probably a bad idea. Think in terms of objects
instead.

On Thu, Jul 9, 2015 at 1:44 AM, Alexander Larsson al...@redhat.com wrote:
 On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
 Hi,

 None of them will really work.

 This thread has sadly degenerated into: 'what if Wayland's object
 model was totally different? what if some of its explicit core design
 principles were thrown out the window?'. Realistically, that is not
 something that will happen in the Wayland 1.x timeframe, if ever.
 Where this thread started was, 'what's a good sandboxing model for
 clients which must be explicitly separated for security reasons?',
 and
 the answer to that is the same answer to the same issue within WebKit
 2 (UI process distrusts render processes), which is that your more
 trusted client itself becomes a Wayland compositor. Which is exactly
 what Jasper did with Wakefield, almost exactly for this usecase, a
 few
 months ago. If there are issues with that design, then great, let's
 chase that up.

 I'm not at all interested in the change that bill is talking about, and
 I think it is unfortunate that it takes this thread off-topic, but this
 is a mischaracterization of the problem.

 Yes, using a subcompositor is a good idea for the case where a more
 privileged process needs to contain some subclient. In fact, I took
 Jaspers wakefield work and extended it for use in the case of e.g.
 embedding a file previewer out of process.

 However, the problem I have now is different, in that it involves an
 existing, less privileged client initiating a higher privileged
 operation (in a controlled fashion) and the higher privileged client
 needing to refer to the lower privileged one. In particular, I need the
 compositor to get toplevel parenting right (higher priv dialog has a
 parent that is a lower priv toplevel).

 This case can not really be solved using subcompositors.
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

Wacky. In any case, NULL is not a valid listener, which is sort of
terrible, but it is how it is. You need to create an empty function
that does nothing.

On Tue, Jul 7, 2015 at 10:17 AM, Christopher Michael
cpmich...@osg.samsung.com wrote:
 On 07/07/2015 01:15 PM, Jasper St. Pierre wrote:

 Shouldn't missing fields in structs be auto-initialized to 0 / NULL? I
 thought that was part of the C specification.


 I thought so also however when compiling some other code which was also
 creating a wl_output_listener, I uncovered the warnings about missing field
 initializers. When I looked/referenced the existing screenshooting code I
 noticed that they were missing from there also, so I just made a quick patch
 to address that.

 Cheers,
 Chris


 On Tue, Jul 7, 2015 at 8:52 AM, Christopher Michael
 cpmich...@osg.samsung.com wrote:

 This patch adds missing placeholders for the wl_output listener
 functions 'done' and 'scale. Currently these placeholders are being
 set to NULL as the done and scale callbacks are not used in the
 screenshot client.

 Signed-off-by: Chris Michael cp.mich...@samsung.com
 ---
   clients/screenshot.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/clients/screenshot.c b/clients/screenshot.c
 index f11e3ba..0d9b320 100644
 --- a/clients/screenshot.c
 +++ b/clients/screenshot.c
 @@ -114,7 +114,9 @@ display_handle_mode(void *data,

   static const struct wl_output_listener output_listener = {
   display_handle_geometry,
 -display_handle_mode
 +display_handle_mode,
 +NULL,
 +NULL,
   };

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








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

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

[Jasper St. Pierre]

Shouldn't missing fields in structs be auto-initialized to 0 / NULL? I
thought that was part of the C specification.

On Tue, Jul 7, 2015 at 8:52 AM, Christopher Michael
cpmich...@osg.samsung.com wrote:
 This patch adds missing placeholders for the wl_output listener
 functions 'done' and 'scale. Currently these placeholders are being
 set to NULL as the done and scale callbacks are not used in the
 screenshot client.

 Signed-off-by: Chris Michael cp.mich...@samsung.com
 ---
  clients/screenshot.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/clients/screenshot.c b/clients/screenshot.c
 index f11e3ba..0d9b320 100644
 --- a/clients/screenshot.c
 +++ b/clients/screenshot.c
 @@ -114,7 +114,9 @@ display_handle_mode(void *data,

  static const struct wl_output_listener output_listener = {
  display_handle_geometry,
 -display_handle_mode
 +display_handle_mode,
 +NULL,
 +NULL,
  };

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



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

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

[Jasper St. Pierre]

I'm for it as well.

On Wed, Jun 24, 2015 at 9:53 AM, Dima Ryazanov d...@gmail.com wrote:
 Bringing this up again. What do you guys think? Does it make sense to push
 this change?

 On Wed, May 27, 2015 at 1:50 AM, Dima Ryazanov d...@gmail.com wrote:

 (Oops, sent too soon by accident.)

 Yep, DISPLAY always needs to be set - and I figured, there's a reason it
 is that way, so that's actually why I thought it made sense to use the same
 convention for WAYLAND_DISPLAY.

 Also, regarding Bill's first comment: yeah, that certainly works, but it
 feels like a workaround. It only gets more complicated if the app supports
 more backends - framebuffer, etc.

 On Wed, May 27, 2015 at 1:45 AM, Dima Ryazanov d...@gmail.com wrote:

 Yep, DISPLAY always needs to be set - and I figured, there's a reason

 On Tue, May 26, 2015 at 2:59 AM, Pekka Paalanen ppaala...@gmail.com
 wrote:

 On Tue, 26 May 2015 10:40:15 +0100
 Daniel Stone dan...@fooishbar.org wrote:

  Hi,
 
  On 26 May 2015 at 10:26, Giulio Camuffo giuliocamu...@gmail.com
  wrote:
   2015-05-26 12:21 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
   I have a vague recollection this has been proposed before, but I
   can't
   remember if there was any interest or discussion, nor what was the
   original intent behind defaulting to wayland-0.
 
  Probably to match X11's behaviour of using :0 in the absence of a
  $DISPLAY.

 Really? ;-)

 $ export -n DISPLAY
 $ xterm
 xterm: Xt error: Can't open display:
 xterm: DISPLAY is not set

 Geany and gqview fail to start, and konsole segfaults (lol).


 Thanks,
 pq





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




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

Re: Stacking subsurface siblings

[Jasper St. Pierre]

Why can't you use the video as the main surface and an OSD as a subsurface?

On Tue, Jun 16, 2015 at 11:09 AM, Arnaud Vrac raw...@gmail.com wrote:
 I'm not sure, but I find it very useful for a video player. The video is
 stacked under the OSD and to be able to use hardware planes, the only viable
 option with wayland is to have a surface for the OSD and a subsurface for
 the video which is stacked under.

 On Tue, Jun 16, 2015 at 5:02 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 I was not aware you could stack subsurfaces under a parent surface at
 all. Is this intended protocol behavior? The fact that you might be
 able to do that at all in Weston might be a bug.

 On Tue, Jun 16, 2015 at 7:46 AM, Arnaud Vrac raw...@gmail.com wrote:
  Hi,
 
  I'm wondering if a behaviour of weston related to subsurfaces is either
  a
  bug or intended. The protocol description is not clear on what happens
  in
  the following cases:
 
  Suppose I have a shell surface (BLUE) and two subsurfaces (RED, GREEN).
  I
  want to stack them to I get RED, GREEN, BLUE from bottom to top.
 
  If I do:
 
  wl_subsurface_place_below(GREEN-subsurface, BLUE-surface);
  wl_subsurface_place_below(RED-subsurface, GREEN-surface);
 
  It works, but if I do:
 
  wl_subsurface_place_below(RED-subsurface, GREEN-surface);
  wl_subsurface_place_below(GREEN-subsurface, BLUE-surface);
 
  The order is GREEN, RED, BLUE instead.
 
  Logically the sibling relative order should be kept in the second case,
  but
  it's not. The protocol is not clear on what should happen, what is the
  expected result ?
 
  I have attached a small sample to test easily.
 
  --
  Arnaud
 
  ___
  wayland-devel mailing list
  wayland-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/wayland-devel
 



 --
   Jasper




 --
 Arnaud Vrac



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

Re: Stacking subsurface siblings

[Jasper St. Pierre]

I was not aware you could stack subsurfaces under a parent surface at
all. Is this intended protocol behavior? The fact that you might be
able to do that at all in Weston might be a bug.

On Tue, Jun 16, 2015 at 7:46 AM, Arnaud Vrac raw...@gmail.com wrote:
 Hi,

 I'm wondering if a behaviour of weston related to subsurfaces is either a
 bug or intended. The protocol description is not clear on what happens in
 the following cases:

 Suppose I have a shell surface (BLUE) and two subsurfaces (RED, GREEN). I
 want to stack them to I get RED, GREEN, BLUE from bottom to top.

 If I do:

 wl_subsurface_place_below(GREEN-subsurface, BLUE-surface);
 wl_subsurface_place_below(RED-subsurface, GREEN-surface);

 It works, but if I do:

 wl_subsurface_place_below(RED-subsurface, GREEN-surface);
 wl_subsurface_place_below(GREEN-subsurface, BLUE-surface);

 The order is GREEN, RED, BLUE instead.

 Logically the sibling relative order should be kept in the second case, but
 it's not. The protocol is not clear on what should happen, what is the
 expected result ?

 I have attached a small sample to test easily.

 --
 Arnaud

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




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

Re: Stacking subsurface siblings

[Jasper St. Pierre]

I was imagining that this was a fullscreen mode, given that you had no
UI stacked under the video.

The thing about surfaces is that you can configure them as you like
every frame. If you have a browser playing multiple videos, each video
can be a subsurface, and then when you transition to a fullscreen
playback with OSD, you can reconfigure your main surface to be playing
the video, and add a single OSD subsurface on top in the right
location.

Your main surface can transition between being a UI layer and a video
layer when it's needed.

On Tue, Jun 16, 2015 at 8:31 AM, Arnaud Vrac raw...@gmail.com wrote:
 It's possible, but the OSD is usually longer lived than the video surfaces,
 which might be transient. For example in an HTML browser, a declarative UI,
 etc, multiple video surfaces could be created for some pages and then
 destroyed when the page is closed.

 On Tue, Jun 16, 2015 at 5:11 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Why can't you use the video as the main surface and an OSD as a
 subsurface?

 On Tue, Jun 16, 2015 at 11:09 AM, Arnaud Vrac raw...@gmail.com wrote:
  I'm not sure, but I find it very useful for a video player. The video is
  stacked under the OSD and to be able to use hardware planes, the only
  viable
  option with wayland is to have a surface for the OSD and a subsurface
  for
  the video which is stacked under.
 
  On Tue, Jun 16, 2015 at 5:02 PM, Jasper St. Pierre
  jstpie...@mecheye.net
  wrote:
 
  I was not aware you could stack subsurfaces under a parent surface at
  all. Is this intended protocol behavior? The fact that you might be
  able to do that at all in Weston might be a bug.
 
  On Tue, Jun 16, 2015 at 7:46 AM, Arnaud Vrac raw...@gmail.com wrote:
   Hi,
  
   I'm wondering if a behaviour of weston related to subsurfaces is
   either
   a
   bug or intended. The protocol description is not clear on what
   happens
   in
   the following cases:
  
   Suppose I have a shell surface (BLUE) and two subsurfaces (RED,
   GREEN).
   I
   want to stack them to I get RED, GREEN, BLUE from bottom to top.
  
   If I do:
  
   wl_subsurface_place_below(GREEN-subsurface, BLUE-surface);
   wl_subsurface_place_below(RED-subsurface, GREEN-surface);
  
   It works, but if I do:
  
   wl_subsurface_place_below(RED-subsurface, GREEN-surface);
   wl_subsurface_place_below(GREEN-subsurface, BLUE-surface);
  
   The order is GREEN, RED, BLUE instead.
  
   Logically the sibling relative order should be kept in the second
   case,
   but
   it's not. The protocol is not clear on what should happen, what is
   the
   expected result ?
  
   I have attached a small sample to test easily.
  
   --
   Arnaud
  
   ___
   wayland-devel mailing list
   wayland-devel@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/wayland-devel
  
 
 
 
  --
Jasper
 
 
 
 
  --
  Arnaud Vrac



 --
   Jasper




 --
 Arnaud Vrac



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

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

[Jasper St. Pierre]

On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho carl...@gnome.org wrote:
 On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
 What is the value of clients having this information?

 The same there is in having wl_touch.cancelled. See the cases in the
 original email in the thread.

 I think we've
 tried to hide grab semantics from the point of view of the client and
 simply say we can revoke input at any time, including in response to
 a request you make, which gives us, the compositor, a lot more
 leeway
 with future possibilities.

 Sure, I'm all for that. What I'd really want is having a way to tell
 clients we do so. I'm totally fine with documenting the places where
 this potentially happens on a per-case basis, even if the final wording
 is compositor dependent, same as for seat.release_input emission.

 That said, toolkits/clients will surely expect some consistence across
 compositors, so the leeway is relative.


 Grabs were a major pain point in X11 since they were overspecified,
 so
 we're trying to not fall into that same trap again.

 I'm sure there is a lot of ground between let's not overspecify and
 let's go shopping.

 It would be convenient first to identify what are the sore points with
 X grabs. AFAICT, most of these come from grabs not being easily
 transferred, and the WM/screensaver/etc not being more of a client to
 revoke/break grabs. On wayland the compositor is completely free to do
 as it pleases, with and without this change I'm proposing.

Yeah, transferring grabs race-free, a lack of being able to override
or revoke grabs are the top two. But focus management + grabs in X11
is tricksy and sort of awkward: if I take a keyboard grab, key focus
can still navigate around as usual, we'll just get NotifyWhileGrabbed
as our detail.

 However, one thing that X did well is defining a consistent event
 delivery model when grabs were being taken (well, except for touch
 events...), so both the grabbing and the pre-grab windows are well
 aware of what's going on, I think one is due in wayland, at least face
 to clients.

Did it? I don't know of any model that lets me know when a client has
taken a grab or ungrabs their existing grab. The exception is that I
believe if I'm the key or pointer focus, I'll get a FocusOut / Leave
event with the NotifyGrabbed detail, and when the grab is dropped
(and I am still the key focus / pointer focus, which is not
guaranteed!), we'll get the reverse event with NotifyUngrabbed.

And in X11, this is actually good, because such an event would be
racy: some other client might have taken a grab in such a time. And it
happens all the time because of passive grabs, including X11's own
implicit passive grab on the pointer.

Anyway, this model matches well with wl_keyboard.leave /
wl_pointer.leave being sent at the start of device grabs.


 For instance, if the user is in a game that has a keyboard grab and
 presses Alt-Tab to switch out, the client should just have its
 keyboard grab revoked without having to have that as a possibility in
 the protocol spec. Same thing with tray icon behavior, etc.

 sure, in that case you'd still get wl_keyboard.leave and the client can
 properly undo the key press / mods. But notice there is always a need
 to know when to undo (eg. in your example above, the game might have
 bound Alt to release flares, if you first press Alt and then Tab, and
 the client doesn't get the Alt key release, you don't want to leave
 that stuck when you focus back)

The client gets a wl_keyboard.leave. Is that not good enough? What use
cases does this new event solve?

 Clients need to cope with losing mouse and keyboard focus at any
 time,
 and with seats going away at any time. It's just how it is.

 Toolkits are nothing else than giant state machines, they rely on a
 meaningful event order, or some proper notification when things go
 south. If you mess with that, you'll get clients in inconsistent
 states, including:

 - stuck buttons
 - gestures listening to vanished touch sequences, unable to trigger
 anymore
 - stuck repeat keys

 Cheers,
   Carlos



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

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

[Jasper St. Pierre]

What is the value of clients having this information? I think we've
tried to hide grab semantics from the point of view of the client and
simply say we can revoke input at any time, including in response to
a request you make, which gives us, the compositor, a lot more leeway
with future possibilities.

Grabs were a major pain point in X11 since they were overspecified, so
we're trying to not fall into that same trap again.

For instance, if the user is in a game that has a keyboard grab and
presses Alt-Tab to switch out, the client should just have its
keyboard grab revoked without having to have that as a possibility in
the protocol spec. Same thing with tray icon behavior, etc.

Clients need to cope with losing mouse and keyboard focus at any time,
and with seats going away at any time. It's just how it is.

On Tue, Jun 9, 2015 at 10:30 AM, Carlos Garnacho carl...@gnome.org wrote:
 A good piece of this commit is actually defining as protocol
 documentation the de-facto behavior in weston and other compositors.

 Additionally, a wl_seat.release_input event is being added, and
 the cases where it should be emitted has been added in the relevant
 places. In short, the compositor should emit it on all surfaces
 where there was any input interaction that is being redirected
 away by any means, although some degree of sloppyness is allowed
 here, and clients are recommended to expect it on surfaces there's
 nothing really going on.

 With this event in place, we can define further how do the
 different input interfaces deal at either side of the input
 redirection induced by grabs. Taking this out of undefined or
 compositor dependent land is the final goal of this commit.

 Signed-off-by: Carlos Garnacho carl...@gnome.org
 ---
  protocol/wayland.xml | 77 
 +++-
  1 file changed, 76 insertions(+), 1 deletion(-)

 diff --git a/protocol/wayland.xml b/protocol/wayland.xml
 index c3b8ae4..3017ff0 100644
 --- a/protocol/wayland.xml
 +++ b/protocol/wayland.xml
 @@ -668,6 +668,16 @@
 wl_surface is no longer used as the icon surface. When the use
 as an icon ends, the current and pending input regions become
 undefined, and the wl_surface is unmapped.
 +
 +   After this call, the compositor will consume events from all
 +   input capabilities, compositors are free to implement additional
 +   behavior with other input than the pointer/touch sequence driving
 +   the drag-and-drop operation.
 +
 +   This request should trigger the emission of seat.release_input
 +   events on, at least, the surfaces that are currently being
 +   interacted with, the surface passed in the origin argument
 +   is implicitly included there.
/description
arg name=source type=object interface=wl_data_source 
 allow-null=true/
arg name=origin type=object interface=wl_surface/
 @@ -890,6 +900,9 @@
 This request must be used in response to a button press event.
 The server may ignore move requests depending on the state of
 the surface (e.g. fullscreen or maximized).
 +
 +   This request will trigger the emission of seat.release_input
 +   events on all interacted surfaces, including this one.
/description
arg name=seat type=object interface=wl_seat summary=the 
 wl_seat whose pointer is used/
arg name=serial type=uint summary=serial of the implicit grab on 
 the pointer/
 @@ -901,6 +914,9 @@
 is being dragged in a resize operation. The server may
 use this information to adapt its behavior, e.g. choose
 an appropriate cursor image.
 +
 +   This request will trigger the emission of seat.release_input
 +   events on all interacted surfaces, including this one.
/description
entry name=none value=0/
entry name=top value=1/
 @@ -1478,7 +1494,7 @@
  /request
 /interface

 -  interface name=wl_seat version=4
 +  interface name=wl_seat version=5
  description summary=group of input devices
A seat is a group of keyboards, pointer and touch devices. This
object is published as a global during start up, or when such a
 @@ -1549,6 +1565,34 @@
arg name=name type=string/
  /event

 +!-- Version 5 additions --
 +event name=release_input
 +  description summary=release all input
 +   This events notifies that the given surface will temporarily or
 +   permanently stop receiving input from the given capabilities, so
 +   it should prepare to undo any interaction with these.
 +
 +   The situations where this event may be emitted are variated, some
 +   examples are:
 +   - When a popup is shown by this or other client.
 +   - When a drag-and-drop operation is initiated from this or
 + any other surface.
 +
 +   The common denominator in these situations is that input is being
 +   redirected partly or entirely somewhere else, so 

Re: Wayland Compatibility for arm 64-bit?

[Jasper St. Pierre]

ARM is still little-endian. I can't imagine that there are any
compatibility issues with ARM 64-bit and Wayland.

On Mon, Jun 8, 2015 at 9:51 AM, Pekka Paalanen ppaala...@gmail.com wrote:
 On Mon, 8 Jun 2015 19:49:15 +0300
 Pekka Paalanen ppaala...@gmail.com wrote:

 On Thu, 28 May 2015 11:35:46 +
 Sumadhurakalyan Singamchetti sumadhurakalya...@hcl.com wrote:

  Hi
  Can I download and compile wayland for 64-bit arm processor?
  what if it is not supporting for 64-bit arm , what are necessary changes I 
  have to made.
 

 Hi,

 what are you actually trying to ask?

 Many people test both Wayland and Weston on x86_64 every day. I'd be
 surprised if Weston had any bugs with respect to 64-bit. There is
 nothing architecture specific in Wayland or Weston AFAIK.

 Oh, unless you are on big-endian, or anything that is not
 little-endian. There could be some bugs for architectures that are
 not little-endian.


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



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

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

[Jasper St. Pierre]

Note that there are non-obvious consequences to this. The keymap is
hierarchical upon layouts and levels. You can either do a depth-first
search, or a breadth-first search. This can change behavior.
XKeysymToKeycode is documented as doing a breadth-first search. This can
have consequences in behavior. See:

https://git.gnome.org/browse/mutter/commit/src/core/keybindings.c?id=60c22b62366d737f7f6eabe7d46fa682c6f400d7

I'd highly recommend doing keygrabs on keysyms if you do want to let your
clients do key grabs at all.

On Mon, Jun 1, 2015 at 6:02 AM, Daniel Stone dan...@fooishbar.org wrote:

 Hi,

 On 1 June 2015 at 12:22, 박성진 sj76.p...@samsung.com wrote:

  Actually, we'd like to provide a key grab protocol to wayland client(s)

 with which each client can make request to grab a key to wayland
 compositor.

 To use the protocol, we need to provide one or more keycodes associated
 with a given keysym to the compositor as an argument.

 At this moment we would like to call the following API to get keycode(s)
 from a keysym if exist.

 Could you share your opinion ?


 You might be better off asking to grab on a particular keysym instead,
 since the compositor always needs to track the current state so can
 trivially extract the keysym.


 /**

  @param[in] keymap : xkb_keymap pointer

  @param[in] keysym : xkb_keysym_t keysym

  @param[out] keycodes array : xkb_keycode_t pointer

  @return number of keycodes found on success, otherwise -1

 */

 XKB_EXPORT int xkb_keycodes_from_keysym(struct xkb_keymap *keymap,
 xkb_keysym_t keysym, xkb_keycode_t *keycodes);

 or XKB_EXPORT int xkb_keymap_keycodes_from_keysym(struct xkb_keymap
 *keymap, xkb_keysym_t keysym, xkb_keycode_t *keycodes);

 On the face of it, this seems okay, except you might want to document that
 0 is a valid, non-error, return code; presumably in order to deal with
 keycode allocation, you would have to do something like:
 xkb_keycode_t *keycodes;
 int num_keycodes;

 num_keycodes = xkb_keymap_keycodes_from_keysym(keymap, keysym, NULL);
 if (num_keycodes == -1)
 return -1;
 else if (num_keycodes == 0)
 return 1; /* still succeeded, just don't have any keycodes */

 keycodes = malloc(num_keycodes * sizeof(*keycodes));
 num_keycodes = xkb_keymap_keycodes_from_keysym(keymap, keysym, keycodes);

 Cheers,
 Daniel


 Thanks and regards,

 Sung-Jin Park



 --- *Original Message* ---

 *Sender* : Daniel Stonedan...@fooishbar.org

 *Date* : 2015-06-01 18:57 (GMT+09:00)

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


 Hi Sung-Jin,

 On 1 June 2015 at 07:16, Sung-Jin Park sj76.p...@samsung.com wrote:

  I'd like to ask how to get keycode(s) from keysym using libxkbcommon
 API.
 Is there any API in libxkbcommon ?


 The short answer is, no.

 The long answer is, look through the keymap and find every keycode which
 produces that keysym, which may be on various layouts (groups) or shift
 levels.

 If you can share more details of what you actually want to achieve, that
 might be helpful.

 Cheers,
 Daniel







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




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

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

[Jasper St. Pierre]

I can't find any standard for asprintf outside of the glibc library,
which doesn't mention anything about undefined behavior. Am I missing
something?

http://www.gnu.org/software/libc/manual/html_node/Dynamic-Output.html

On Fri, May 29, 2015 at 10:29 AM, Jon A. Cruz j...@osg.samsung.com wrote:
 Well, no.

 It is clearly documented to be undefined, so it is completely within
 spec for it to be just about anything. One of the more likely bad
 scenarios is that the call internally allocates a buffer, starts to use
 it, hits some problem, then frees the buffer while leaving its address
 in place. Use of stale pointers should always be avoided.

 On 05/29/2015 09:48 AM, Bill Spitzak wrote:
 I'm pretty certain the only two things that can happen is that str is
 unchanged or it is set to NULL. So presetting it to NULL would work.


 On Thu, May 28, 2015 at 7:01 PM, Jon A. Cruz j...@osg.samsung.com wrote:

 If asprintf fails for any reason, the contents of the pointer
 are undefined. While some platforms set it to NULL, there is no
 guarantee that all will.

 This change adds a simple wrapper to ensure proper NULL results
 on failure.

 Signed-off-by: Jon A. Cruz j...@osg.samsung.com
 ---
  src/evdev-middle-button.c   |  2 ++
  src/evdev-mt-touchpad-buttons.c |  2 ++
  src/evdev-mt-touchpad-edge-scroll.c |  2 ++
  src/libinput-util.h | 30 ++
  src/timer.c |  2 ++
  test/litest.c   |  2 +-
  tools/libinput-list-devices.c   | 14 +++---
  7 files changed, 46 insertions(+), 8 deletions(-)

 diff --git a/src/evdev-middle-button.c b/src/evdev-middle-button.c
 index 903fa4d..c989486 100644
 --- a/src/evdev-middle-button.c
 +++ b/src/evdev-middle-button.c
 @@ -20,6 +20,8 @@
   * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
   */

 +#include config.h
 +
  #include stdint.h

  #include evdev.h
 diff --git a/src/evdev-mt-touchpad-buttons.c
 b/src/evdev-mt-touchpad-buttons.c
 index 64e9d28..4b1d6ab 100644
 --- a/src/evdev-mt-touchpad-buttons.c
 +++ b/src/evdev-mt-touchpad-buttons.c
 @@ -20,6 +20,8 @@
   * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
   */

 +#include config.h
 +
  #include errno.h
  #include limits.h
  #include math.h
 diff --git a/src/evdev-mt-touchpad-edge-scroll.c
 b/src/evdev-mt-touchpad-edge-scroll.c
 index 585c764..2302d2c 100644
 --- a/src/evdev-mt-touchpad-edge-scroll.c
 +++ b/src/evdev-mt-touchpad-edge-scroll.c
 @@ -20,6 +20,8 @@
   * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
   */

 +#include config.h
 +
  #include errno.h
  #include limits.h
  #include math.h
 diff --git a/src/libinput-util.h b/src/libinput-util.h
 index 732f813..7d5651a 100644
 --- a/src/libinput-util.h
 +++ b/src/libinput-util.h
 @@ -26,6 +26,8 @@

  #include unistd.h
  #include math.h
 +#include stdarg.h
 +#include stdio.h
  #include string.h
  #include time.h

 @@ -230,6 +232,34 @@ matrix_to_farray6(const struct matrix *m, float
 out[6])
 out[5] = m-val[1][2];
  }

 +/**
 + * Simple wrapper for asprintf that ensures the passed in pointer is set
 + * to NULL upon error.
 + * The standard asprintf() call does not guarantee the passed in pointer
 + * will be NULL'ed upon failure, whereas this wrapper does.
 + *
 + * @param strp pointer to set to newly allocated string.
 + * This pointer should be passed to free() to release when done.
 + * @param fmt the format string to use for printing.
 + * @return The number of bytes printed (excluding the null byte
 terminator)
 + * upon success or -1 upon failure. In the case of failure the pointer is
 set
 + * to NULL.
 + */
 +static inline int
 +xasprintf(char **strp, const char *fmt, ...)
 +{
 +   int rc = 0;
 +   va_list args;
 +
 +   va_start(args, fmt);
 +   rc = vasprintf(strp, fmt, args);
 +   va_end(args);
 +   if ((rc == -1)  strp)
 +   *strp = NULL;
 +
 +   return rc;
 +}
 +
  enum ratelimit_state {
 RATELIMIT_EXCEEDED,
 RATELIMIT_THRESHOLD,
 diff --git a/src/timer.c b/src/timer.c
 index dbd3894..1e507df 100644
 --- a/src/timer.c
 +++ b/src/timer.c
 @@ -20,6 +20,8 @@
   * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
   */

 +#include config.h
 +
  #include assert.h
  #include errno.h
  #include inttypes.h
 diff --git a/test/litest.c b/test/litest.c
 index 53c441b..b3410bd 100644
 --- a/test/litest.c
 +++ b/test/litest.c
 @@ -876,7 +876,7 @@ litest_init_udev_rules(struct litest_test_device *dev)
 ck_abort_msg(Failed to create udev rules directory
 (%s)\n,
  strerror(errno));

 -   rc = asprintf(path,
 +   rc = xasprintf(path,
   %s/%s%s.rules,
   UDEV_RULES_D,
   UDEV_RULE_PREFIX,
 diff --git a/tools/libinput-list-devices.c b/tools/libinput-list-devices.c
 index 6625173..68ddb61 100644
 --- a/tools/libinput-list-devices.c
 +++ 

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

[Jasper St. Pierre]

I'm planning on removing this hook and just make compositors deal with
the fallout. Unfortunately, it hasn't been merged yet.

http://patchwork.freedesktop.org/patch/43021/

On Wed, May 27, 2015 at 9:42 AM, Carlos Garnacho carl...@gnome.org wrote:
 For these, we must first lookup the DIX sequence from the Sprite, we can
 then lookup the DDX ID/xwl_touch from xwayland's touch device.

 Signed-off-by: Carlos Garnacho carl...@gnome.org
 ---
  hw/xwayland/xwayland-input.c | 68 
 +++-
  1 file changed, 55 insertions(+), 13 deletions(-)

 diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
 index 3229c54..9d554a8 100644
 --- a/hw/xwayland/xwayland-input.c
 +++ b/hw/xwayland/xwayland-input.c
 @@ -818,29 +818,71 @@ DDXRingBell(int volume, int pitch, int duration)
  {
  }

 -static WindowPtr
 -xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)
 +static int32_t
 +lookup_sprite_touch_client_id (SpritePtr sprite)
  {
 -struct xwl_seat *xwl_seat = NULL;
  DeviceIntPtr device;
 +int i;

  for (device = inputInfo.devices; device; device = device-next) {
 -if (device-deviceProc == xwl_pointer_proc 
 -device-spriteInfo-sprite == sprite) {
 -xwl_seat = device-public.devicePrivate;
 -break;
 +if (!device-touch)
 +continue;
 +
 +for (i = 0; i  device-touch-num_touches; i++) {
 +TouchPointInfoPtr ti = device-touch-touches + i;
 +
 +if (sprite == ti-sprite)
 +return ti-client_id;
  }
  }

 -if (xwl_seat == NULL) {
 -/* XTEST device */
 -sprite-spriteTraceGood = 1;
 -return sprite-spriteTrace[0];
 +return 0;
 +}
 +
 +static struct xwl_touch *
 +xwl_touch_lookup_from_client_id (struct xwl_seat *xwl_seat, int32_t 
 client_id)
 +{
 +DeviceIntPtr touch = xwl_seat-touch;
 +int i;
 +
 +for (i = 0; i  touch-last.num_touches; i++) {
 +DDXTouchPointInfoPtr ddx_ti = touch-last.touches + i;
 +
 +if (ddx_ti-client_id == client_id)
 +return xwl_seat_lookup_touch(xwl_seat, ddx_ti-ddx_id);
 +}
 +
 +return NULL;
 +}
 +
 +static WindowPtr
 +xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)
 +{
 +struct xwl_screen *xwl_screen;
 +struct xwl_seat *xwl_seat = NULL;
 +struct xwl_window *xwl_window = NULL;
 +struct xwl_touch *xwl_touch;
 +int32_t client_id;
 +
 +xwl_screen = xwl_screen_get(screen);
 +
 +xorg_list_for_each_entry(xwl_seat, xwl_screen-seat_list, link) {
 +if (xwl_seat-pointer-spriteInfo-sprite == sprite) {
 +xwl_window = xwl_seat-focus_window;
 +} else if ((client_id = lookup_sprite_touch_client_id (sprite)) != 
 0) {
 +xwl_touch = xwl_touch_lookup_from_client_id (xwl_seat, 
 client_id);
 +
 +if (xwl_touch)
 +xwl_window = xwl_touch-window;
 +}
 +
 +if (xwl_window)
 +break;
  }

 -if (xwl_seat-focus_window) {
 +if (xwl_window) {
  sprite-spriteTraceGood = 2;
 -sprite-spriteTrace[1] = xwl_seat-focus_window-window;
 +sprite-spriteTrace[1] = xwl_window-window;
  return miSpriteTrace(sprite, x, y);
  }
  else {
 --
 2.4.1

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



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

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

[Jasper St. Pierre]

This makes sense to me.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Mon, May 25, 2015 at 12:15 PM, Rui Matos tiagoma...@gmail.com wrote:
 In some extreme cases with animated cursors at a high frame rate we
 could end up filling the wl_display outgoing buffer and end up with
 wl_display_flush() failing.

 In any case, using the frame callback to throttle ourselves is the
 right thing to do.

 Signed-off-by: Rui Matos tiagoma...@gmail.com
 ---
  hw/xwayland/xwayland-cursor.c | 20 
  hw/xwayland/xwayland-input.c  |  2 ++
  hw/xwayland/xwayland.h|  1 +
  3 files changed, 23 insertions(+)

 diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
 index 5a9d1fe..3ba5ad6 100644
 --- a/hw/xwayland/xwayland-cursor.c
 +++ b/hw/xwayland/xwayland-cursor.c
 @@ -82,6 +82,19 @@ xwl_unrealize_cursor(DeviceIntPtr device, ScreenPtr 
 screen, CursorPtr cursor)
  return xwl_shm_destroy_pixmap(pixmap);
  }

 +static void
 +frame_callback(void *data,
 +   struct wl_callback *callback,
 +   uint32_t time)
 +{
 +struct xwl_seat *xwl_seat = data;
 +xwl_seat-cursor_frame_cb = NULL;
 +}
 +
 +static const struct wl_callback_listener frame_listener = {
 +frame_callback
 +};
 +
  void
  xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  {
 @@ -98,6 +111,9 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  return;
  }

 +if (xwl_seat-cursor_frame_cb)
 +return;
 +
  cursor = xwl_seat-x_cursor;
  pixmap = dixGetPrivate(cursor-devPrivates, xwl_cursor_private_key);
  stride = cursor-bits-width * 4;
 @@ -117,6 +133,10 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  wl_surface_damage(xwl_seat-cursor, 0, 0,
xwl_seat-x_cursor-bits-width,
xwl_seat-x_cursor-bits-height);
 +
 +xwl_seat-cursor_frame_cb = wl_surface_frame(xwl_seat-cursor);
 +wl_callback_add_listener(xwl_seat-cursor_frame_cb, frame_listener, 
 xwl_seat);
 +
  wl_surface_commit(xwl_seat-cursor);
  }

 diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
 index 5230d8c..a3142f4 100644
 --- a/hw/xwayland/xwayland-input.c
 +++ b/hw/xwayland/xwayland-input.c
 @@ -586,6 +586,8 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
  RemoveDevice(xwl_seat-keyboard, FALSE);
  wl_seat_destroy(xwl_seat-seat);
  wl_surface_destroy(xwl_seat-cursor);
 +if (xwl_seat-cursor_frame_cb)
 +wl_callback_destroy(xwl_seat-cursor_frame_cb);
  wl_array_release(xwl_seat-keys);
  free(xwl_seat);
  }
 diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
 index bfffa71..92d6d6e 100644
 --- a/hw/xwayland/xwayland.h
 +++ b/hw/xwayland/xwayland.h
 @@ -116,6 +116,7 @@ struct xwl_seat {
  struct wl_keyboard *wl_keyboard;
  struct wl_array keys;
  struct wl_surface *cursor;
 +struct wl_callback *cursor_frame_cb;
  struct xwl_window *focus_window;
  uint32_t id;
  uint32_t pointer_enter_serial;
 --
 2.4.0

 ___
 xorg-de...@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



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

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

[Jasper St. Pierre]

Expecting anything atomic from X11 in the first place is a wrong assumption.

On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa mchqwe...@gmail.com wrote:
 Hi,

 On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov d...@gmail.com wrote:

 Add the output to the list when it's created rather than when its
 properties
 change (as pointed out by Marek Chalupa).
 Remove the output from the list when it's destroyed.

 Signed-off-by: Dima Ryazanov d...@gmail.com
 ---
  hw/xwayland/xwayland-output.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
 index 155cbc1..9baf4eb 100644
 --- a/hw/xwayland/xwayland-output.c
 +++ b/hw/xwayland/xwayland-output.c
 @@ -120,8 +120,6 @@ output_handle_done(void *data, struct wl_output
 *wl_output)
  struct xwl_screen *xwl_screen = xwl_output-xwl_screen;
  int width, height;

 -xorg_list_append(xwl_output-link, xwl_screen-output_list);
 -


 As I pointed out in the other e-mail: I don't think this is right. The
 append is here on purpose to make the output update atomic.
 But maybe somebody more erudated should review it :)


  width = 0;
  height = 0;
  xorg_list_for_each_entry(xwl_output, xwl_screen-output_list, link)
 {
 @@ -177,6 +175,8 @@ xwl_output_create(struct xwl_screen *xwl_screen,
 uint32_t id)
  xwl_output-randr_crtc = RRCrtcCreate(xwl_screen-screen,
 xwl_output);
  xwl_output-randr_output = RROutputCreate(xwl_screen-screen, name,
strlen(name), xwl_output);
 +xorg_list_append(xwl_output-link, xwl_screen-output_list);
 +
  RRCrtcGammaSetSize(xwl_output-randr_crtc, 256);
  RROutputSetCrtcs(xwl_output-randr_output, xwl_output-randr_crtc,
 1);
  RROutputSetConnection(xwl_output-randr_output, RR_Connected);
 @@ -190,6 +190,7 @@ xwl_output_destroy(struct xwl_output *xwl_output)
  wl_output_destroy(xwl_output-output);
  RRCrtcDestroy(xwl_output-randr_crtc);
  RROutputDestroy(xwl_output-randr_output);
 +xorg_list_del(xwl_output-link);
  free(xwl_output);
  }

 --
 2.4.0



 ___
 xorg-de...@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



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

Re: EGL-X Applications on XWayland

[Jasper St. Pierre]

Currently, EGL-X applications will fall back to software rendering,
assuming you're using a mesa-based GL, simply because mesa doesn't
have support for DRI3 in its EGL layer, and Xwayland doesn't have
support for DRI2.

Either of those can be fixed, it's just that nobody has tried yet.

On Tue, May 19, 2015 at 10:06 AM, Prabhu S prabhusun...@gmail.com wrote:
 Hi All,
 Wondering whether possible to run EGL-X on Xwayland?

 If my understanding correct EGL applications need be built natively with
 wayland-egl/EGL?

 Thanks
 Prabhu

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




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

Re: Proposal for better collaboration on xdg-shell

[Jasper St. Pierre]

Yeah. I think some people were assuming xdg-shell was final, and I was
its gatekeeper, and it's what GNOME wants and you have to fight to get
other things in.

That wasn't my intention at all! My goal was to build a solid base for
the rest of the DEs to eventually work more like how Bryce wants, but
I was imagining it would work a lot more informally, sort of like how
wm-spec-list works.

If there are *any* controversial features in xdg-shell that you don't
like, please let me know! The goal here is to make sure that it's a
good base for everybody, so by the time you roll around to
implementing it, xdg-shell is exactly what you want, and you can start
with custom extensions to implement stuff that's specific to your DE.
Even GTK+ has plenty of features in a custom gtk-shell that other DEs
probably don't care about.

On Mon, May 11, 2015 at 12:38 AM, Pekka Paalanen ppaala...@gmail.com wrote:
 On Mon, 20 Apr 2015 17:10:08 -0700
 Bryce Harrington br...@osg.samsung.com wrote:

 A while back Pekka asked if I'd help look at xdg-shell and how we can
 ensure it really does become a cross-desktop standard.  I promised to
 engage with the EFL folks and get their feedback, which I posted
 recently.

 snip
 http://lists.freedesktop.org/archives/wayland-devel/2015-April/021465.html


 Hi all,

 Bryce wrote a good and essentially simple proposal for getting things
 rolling again. However, it turns out that my and his underlying
 assumptions were not exactly true. We assumed that desktop projects
 want to go forward all the time, on their own schedule. To support
 that, Bryce wrote this proposal.

 Since then in IRC, GNOME (with Jasper's voice) has said they can
 actually wait for other DEs, especially KDE, to get on board.

 So it seems the current plan is to keep xdg-shell in limbo at least
 until KDE people can focus on it properly. And other DE projects, too.
 In other words, not to hurry, but think things through with all major
 players.

 Just letting you all know and collecting a hopefully good selection of
 CCs to get the teams covered.


 Thanks,
 pq



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

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

[Jasper St. Pierre]

If there's an application that wants a move indicator, we could
provide a moving state, but since the application doesn't get any
feedback about the move, ever, I'm not sure this is useful.

On Thu, Apr 30, 2015 at 7:36 AM, Pekka Paalanen ppaala...@gmail.com wrote:
 On Tue, 7 Apr 2015 18:40:03 -0700
 Bryce Harrington br...@osg.samsung.com wrote:

 On Tue, Apr 07, 2015 at 05:01:23PM +0800, Jonas Ådahl wrote:
  Signed-off-by: Jonas Ådahl jad...@gmail.com
  ---
   protocol/xdg-shell.xml | 13 +++--
   1 file changed, 11 insertions(+), 2 deletions(-)
 
  diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
  index d013803..46775fe 100644
  --- a/protocol/xdg-shell.xml
  +++ b/protocol/xdg-shell.xml
  @@ -233,10 +233,19 @@
  Start an interactive, user-driven move of the surface.
 
  This request must be used in response to some sort of user action
  -   like a button press, key press, or touch down event.
  +   like a button press, key press, or touch down event. The passed
  +   serial is used to determine what type of interactive move (touch,
  +   pointer, etc) is.

 ...us used to determine the type of interactive move (e.g. touch,
 pointer, etc.)

  The server may ignore move requests depending on the state of
  -   the surface (e.g. fullscreen or maximized).
  +   the surface (e.g. fullscreen or maximized), or if the passed serial
  +   is no longer valid.
  +
  +   If triggered, the surface will loose the focus of the device
 s/loose/lose/

  +   (wl_pointer, wl_touch, etc) used for the move. It is up to the
  +   compositor display any indications, such as updating a pointer cursor,

 ...compositor *to* display... ?

 And is 'indications' the right word?  I don't understand the meaning of
 this sentence.

 It tries to say that the compositor should visually indicate, that the
 user is now indeed moving the window.

  +   during the move. There is no guarantee that the device focus will
  +   return when the move is completed.
 /description
 arg name=seat type=object interface=wl_seat summary=the 
  wl_seat of the user event/
 arg name=serial type=uint summary=the serial of the user 
  event/
  --

 This does make me wonder, though. Doing a window move will then switch
 from app cursors to compositor cursors. It also doesn't allow the app
 to show the move-indicators itself, because it doesn't know when the
 move ends? Do these matter? I don't even pretend to be suggesting
 answers here.

 Anyway, no reason hold up this patch.
 Acked-by: Pekka Paalanen pekka.paala...@collabora.co.uk

 And if this is how it has already been implemented, then this is no
 reason to bump the experimental version either.


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



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

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

[Jasper St. Pierre]

Oh, nice catch, that's a typo. The expected behavior here is that you
cannot change from xdg_surface to xdg_popup or cursor surface or
anything.

You should be able to destroy and recreate the xdg_surface without
destroying the wl_surface.

On Thu, Apr 30, 2015 at 7:08 AM, Giulio Camuffo giuliocamu...@gmail.com wrote:
 2015-04-07 12:01 GMT+03:00 Jonas Ådahl jad...@gmail.com:
 Document that a wl_surface can only be assigned either a xdg_popup or
 xdg_surface once and that if the client still stries to do that an error
 is raised.

 Signed-off-by: Jonas Ådahl jad...@gmail.com
 ---
  protocol/xdg-shell.xml | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

 diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
 index 09ce019..9dbf193 100644
 --- a/protocol/xdg-shell.xml
 +++ b/protocol/xdg-shell.xml
 @@ -79,7 +79,12 @@
  request name=get_xdg_surface
description summary=create a shell surface from a surface
 This creates an xdg_surface for the given surface and gives it the
 -   xdg_surface role. See the documentation of xdg_surface for more 
 details.
 +   xdg_surface role. A wl_surface can only be given an xdg_surface role
 +   once. If get_xdg_surface is called with a wl_surface that was 
 previously
 +   an xdg_surface or if it had any other role, an error is raised.

 This surprises me a bit. My understanding was that the consensus about
 surface roles is that you cannot change them but you can destroy and
 request again the same role. I don't see what is the reason to
 disallow that, and on the other hand, with the qtwayland hat on, that
 would be annoying when hiding/showing windows.


 Thanks,
 Giulio

 +
 +   See the documentation of xdg_surface for more details about what an
 +   xdg_surface is and how it is used.
/description
arg name=id type=new_id interface=xdg_surface/
arg name=surface type=object interface=wl_surface/
 @@ -88,10 +93,15 @@
  request name=get_xdg_popup
description summary=create a popup for a surface
 This creates an xdg_popup for the given surface and gives it the
 -   xdg_popup role. See the documentation of xdg_popup for more details.
 +   xdg_popup role. A wl_surface can only be given an xdg_popup role
 +   once. If get_xdg_popup is called with a wl_surface that was 
 previously
 +   an xdg_popup or if it had any other role, an error is raised.

 This request must be used in response to some sort of user action
 like a button press, key press, or touch down event.
 +
 +   See the documentation of xdg_popup for more details about what an
 +   xdg_popup is and how it is used.
/description
arg name=id type=new_id interface=xdg_popup/
arg name=surface type=object interface=wl_surface/
 --
 2.1.4

 ___
 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EFL/Wayland and xdg-shell

[Jasper St. Pierre]

Yeah, that was extremely uncalled for. Was a difficult day at work,
and I was already cranky. I messed up, that was my fault, and I
apologize.

On Wed, Apr 15, 2015 at 12:31 PM, Daniel Stone dan...@fooishbar.org wrote:
 On 14 April 2015 at 04:19, Jasper St. Pierre jstpie...@mecheye.net wrote:
 Boo hoo.

 you're the only ones who want physically-based rendering raytraced
 desktops.

 Enlightenment is absolutely nothing like my desktop environment of
 choice either, but this is staggeringly unnecessary. If you want
 xdg_shell to actually just be gtk_shell_base, and be totally
 unencumbered by the shackles of ever having to work with anyone else,
 this is definitely the way to go about it. But core protocol
 development is not that.

 Be nice.



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

Re: EFL/Wayland and xdg-shell

[Jasper St. Pierre]

On Mon, Apr 13, 2015 at 5:02 PM, Bryce Harrington br...@osg.samsung.com wrote:
 A couple weeks ago I gave a talk on Wayland to the EFL folks at the
 Enlightenment Developer Day in San Jose.  They've already implemented a
 Wayland compositor backend, so my talk mainly speculated on Wayland's
 future and on collecting feature requests and feedback from the EFL
 developers.  Below is my summary of some of this feedback; hopefully if
 I've mischaracterized anything they can jump in and correct me.


 For the presentation, I identified Wayland-bound bits currently
 gestating in Weston, listed features currently under review in
 patchwork, itemized feature requests in our bug tracker, and summarized
 wishlists from other desktop environments.  Emphasis was given to
 xdg-shell and the need for EFL's feedback and input to help ensure
 Wayland's first revision of it truly is agreed-on cross-desktop.


 Considering KDE's feedback, a common theme was that xdg-shell should not
 get in the way of allowing for advanced configuration, since
 configurability is one of that D-E's key attributes.  The theme I picked
 up talking with EFL emphasized being able to provide extreme UI
 features.  For them, the important thing was that the protocol should
 not impose constraints or assumptions that would limit this.

 For purposes of discussion, an example might be rotated windows.  The
 set geometry api takes x, y, height, and width.  How would you specify
 rotation angle?

I'm confused by this. set_window_geometry takes an x, y, width and
height in surface-local coordinates, describing the parts of the
surface that are the user-understood effective bounds of the surface.

In a client-decorated world, I might have shadows that extend outside
of my surface, or areas outside of the solid frame for resizing
purposes, but these should not be counted as part of the window for
edge resistance, maximization, tiling, etc.

So, if I have a surface that is 120x120 big, and 20px of it are
shadows or resize borders, then the client should call
set_window_geometry(20, 20, 100, 100)

Additionally, the size in the configure event is in window geometry
coordinates, meaning that window borders are excluded. So, if I
maximize the window and get configure(200, 200), then I am free to
attach a 300x300 surface as long as I call set_window_geometry(50, 50,
200, 200).

If the compositor rotates the window, the window geometry remains the
same, but the compositor has the responsibility of properly rotating
the window geometry rectangle for the purposes of e.g. edge
resistance.

So, if I have a window with a window geometry of 0,0,100,100, and the
user rotates it by 45 degrees, then the effective window geometry the
compositor snaps to -42,-42,142,142. Correct me if my high school trig
is wrong :)

The window is never aware of its local rotation transformation.

Does that make sense? Is this not explained correctly?

 While window rotation was used more as an example of how built-in
 assumptions in the API could unintentionally constrain D-E's, than as a
 seriously needed feature, they did describe a number of ideas for rather
 elaborate window behaviors:

   * Rotation animations with frame updates to allow widget re-layouts
 while the window is rotating.

Why does xdg-shell / Wayland impede this?

   * Arbitrary shaped (non-rectangular) windows.  Dynamically shaped
 windows.

I don't understand this. Any shape always has an axis-aligned bounding
box. Using ARGB, you can craft windows of any shape.

   * Non-linear surface movement/resizing animations and transition
 effects.

Why does xdg-shell / Wayland impede this?

 There was lots of interest in hearing more about Wayland's plans for
 text-cursor-position and input-method, which are necessary for Asian
 languages.  A particular question was how clients could coordinate with
 the virtual keyboard input window so that it doesn't overlay where text
 is being inserted.  Security is also a top concern here, to ensure
 unauthorized clients can't steal keyboard input if (when) the virtual
 keyboard client crashes.

The solution GNOME takes, which is admittedly maybe too unrealistic,
is that IBus is our input method framework, and thus our compositor
has somewhat tight integration with IBus. I don't think input methods
need to be part of the core Wayland protocol.

 Regarding splitting out libweston, they suggested looking if a
 finer-grained split could be done.  For example, they would be
 interested in utilizing a common monitor configuration codebase rather
 than maintaining their own.  OTOH, I suspect we can do a better
 (simpler) API than RANDR, that doesn't expose quite so many moving parts
 to the D-E's, which may better address the crux of the problem here...

 One area we could improve on X for output configuration is in how
 displays are selected for a given application's surface.  A suggestion
 was type descriptors for outputs, such as laptop display,
 television, projector, 

Re: EFL/Wayland and xdg-shell

[Jasper St. Pierre]

On Mon, Apr 13, 2015 at 7:59 PM, Derek Foreman der...@osg.samsung.com wrote:

... snip ...

 That all makes sense - set_window_geometry() was a bit of a red herring
 here.

 Some EFL developers want the application to have a way to know its
 rotation so it can, for example, render drop shadows correctly.

 Take a window in weston and rotate it 90 or 180 degrees and the drop
 shadow is wrong.

Boo hoo. While you're at it, why don't you also write a proper
implementation of shadows that takes the alpha channel into account,
so every single letter on your transparent terminal casts a shadow on
the underlying content, leaving it an unreadable mess?

 Drop shadows are just the easy example, there's also a desire to have
 the applications react to the rotation in some way so the usual EFL
 bling can take place during a a smooth rotation from 0-90 degrees, for
 example.

Use a custom protocol for this. I don't think any other client has
ever cared. UI elements are caricatures for clarity, drop shadows are
used to establish focus and layering, and you're the only ones who
want physically-based rendering raytraced desktops.

 I do wonder if drop shadows really should be the client's responsibility
 at all.  If completely non-interactive eye-candy was left to the
 compositor, would we still need set_window_geometry() at all?

Yes. First of all, invisible borders are still a use case, unless you
think those should be provided by the compositor as well (which means
that the compositor must be more complex and handle fancy events
itself). And when using subsurfaces, you need an understanding of
whether it's the union of the surfaces or one specific surface that's
the main window.

 While window rotation was used more as an example of how built-in
 assumptions in the API could unintentionally constrain D-E's, than as a
 seriously needed feature, they did describe a number of ideas for rather
 elaborate window behaviors:

   * Rotation animations with frame updates to allow widget re-layouts
 while the window is rotating.

 Why does xdg-shell / Wayland impede this?

 It's not directly impeded I suppose - it's just not currently possible?
  The client doesn't know it's being rotated (at least when talking about
 arbitrary rotations, as opposed to the right angle transforms)

Good. Window rotation is a gimmick feature designed to show off that
Wayland can transform input directly without having to send a
transformation mesh to the X server.

 The solution GNOME takes, which is admittedly maybe too unrealistic,
 is that IBus is our input method framework, and thus our compositor
 has somewhat tight integration with IBus. I don't think input methods
 need to be part of the core Wayland protocol.

 That may be in line with the current thinking in the EFL camp.

 Does that mean the input-method and text protocol files in weston are of
 no use at all to gnome?

These are currently unused by GNOME. They were written by Openismus,
the company that wrote Maliit, that has shut down now. In my opinion,
it's too complicated, mandates a split where the keyboard needs to be
replaceable.

I'm not sure the text-protocol has any value at all, but I'll let Rui
Matos, our input method expert, answer.

 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?

 It's an idea that's being thrown around.  We would like to have the
 ability to put outputs to sleep independently... If the surface is
 dragged from one output to another the blanker inhibition would move
 with it without the client having to do anything.

Ah, that's an interesting idea. I'd be fine with that, but I'd much
prefer experimentation in a private protocol first. There's plenty of
usage issues I can imagine running into (e.g. I press Alt-Tab, and
since the surface appears on the other output for a split-second, it
wakes back up.  Or my mouse is suddenly invisible, etc. Or I have my
presentation running and the presentation window is on the monitor
with inhibit, and my notes suddenly fall asleep).

 Is gtk-shell intended to be a test bed for things that will eventually
 be in xdg-shell?  Or are divergent standards a guarantee at this point?

Either that, or, more hopefully, for stuff that is so GTK+ specific
that there's no value in standardization. The equivalent of a _GTK_*
property on an X11 window.

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

Re: xdg-shell and always centered surfaces

[Jasper St. Pierre]

Hi.

set_window_geometry is about the window geometry of a surface,
relative to the overall surface. It's a difficult concept to explain,
but I feel the docs do a good enough job.

Currently it's not possible to specify initial window location. Can
you give your exact use case here so we can think about how it would
work? Is it centering dialogs? You mentioned something about splash
screens, but I'm not sure what that means.

On Sat, Mar 21, 2015 at 4:34 AM, x414e54 x414...@linux.com wrote:
 I have been working on a GUI toolkit and looking to experiment porting it to
 wayland.

 Currently I am using a wl_shell_surface and have dialogs, tooltips, etc.
 working fine, just waiting on relative mouse for implementing spinners,
 rotations etc.

 However I am looking at positioning the initial parent surfaces, for uses
 such as splash screens. These need to be centered (if the WM supports this).

 I noticed that the xdg-shell protocol is available but currently only has
 set_window_geometry which takes an x and y co-ordinates.
 I have no idea what x and y are supposed to be relative to?

 In CSS to create a centered element you would use margin: auto and even if
 the browser was resized it would still stay centered.
 Setting fixed x and y co-ordinates in CSS is never going to work.

 How are you supposed to tell the WM you would like an always centered shell
 surface?

 Thank you for the help

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




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

Re: Xfig menus don't appear - bug?

[Jasper St. Pierre]

Menus appear fine on my machine. I assume it's the recent Xwayland
bugs. Try weston from master combined with:

http://lists.freedesktop.org/archives/xorg-devel/2015-February/045701.html

On Mon, Apr 6, 2015 at 10:27 AM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
 No, sorry. I'll take a look today.

 On Mon, Apr 6, 2015 at 10:22 AM, Felix E. Klee felix.k...@inka.de wrote:
 Should I report this somewhere?
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel



 --
   Jasper



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

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

[Jasper St. Pierre]

On Tue, Apr 7, 2015 at 6:03 PM, Bryce Harrington br...@osg.samsung.com wrote:
 On Tue, Apr 07, 2015 at 05:01:21PM +0800, Jonas Ådahl wrote:
 Require the client to have attached (either previously committed, or
 newly) a buffer to the corresponding wl_surface, and that the window
 will not be potentially mapped until calling wl_surface.commit after
 having created the window. This is required to make valid double
 buffered xdg_surface state possible when creating a window.

 Currently there is no double buffered state in xdg_popup, but it should
 behave the same as xdg_surface, and for making it future proof in case
 we want to add double buffered state to xdg_popup.

 Signed-off-by: Jonas Ådahl jad...@gmail.com
 ---
  protocol/xdg-shell.xml | 8 
  1 file changed, 8 insertions(+)

 diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
 index 0b6c999..d316e06 100644
 --- a/protocol/xdg-shell.xml
 +++ b/protocol/xdg-shell.xml
 @@ -149,6 +149,10 @@
It provides requests to treat surfaces like windows, allowing to set
properties like maximized, fullscreen, minimized, and to move and 
 resize
them, and associate metadata like title and app id.
 +
 +  For a xdg_surface to be mapped by the compositor, the wl_surface must
 +  have a buffer attached to it, and wl_surface.commit must have been 
 called
 +  after having created the xdg_surface object.

 That reads a bit awkward to me; could it be improved with the following?

 In order for the compositor to map a created xdg_surface object, a
 buffer must first be attached to the wl_surface and
 wl_surface.commit called.

It doesn't describe the full story. wl_surface.commit needs to be
called *after* the xdg_surface is created.

I believe the wl_surface.attach and get_xdg_surface can happen in
either order, though it might be nice to establish some form of
standard order for that.

  /description

  request name=destroy type=destructor
 @@ -473,6 +477,10 @@
The x and y arguments specify where the top left of the popup
should be placed, relative to the local surface coordinates of the
parent surface.
 +
 +  For a xdg_popup to be mapped by the compositor, the wl_surface must
 +  have a buffer attached to it, and wl_surface.commit must have been
 +  called after having created the xdg_popup object.
 As above

  /description

  request name=destroy type=destructor
 --
 2.1.4

 ___
 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jasper St. Pierre]

It's described as murky because it is super murky.

In the brave new world, apps are supposed to be D-Bus Activatable.
That means setting DBusActivatable=true in their desktop file. A
requirement for this is that desktop file name needs to match their
bus name. D-Bus doesn't require this -- the desktop file specification
does.

If you don't follow that convention, you don't have one app ID you can
pass to this. You have multiple. In the X11 world, this includes your
resource and application class you set with the WM_CLASS property,
your Exec line / prgname, your bus name, your PID, and plenty more
(startup-notification ID, _GTK_APPLICATION_ID, your ICCCM window group
leader, X11 Client ID).

The best way to not be in that situation is to not be in it: you have
one app ID, and that's it. That's what I was trying to say in the
original specification.

If you don't have that, there's no great answer for what to say your
ID is. GNOME would prefer what matches your .desktop filename. I don't
know what other DEs might prefer.

On Tue, Apr 7, 2015 at 7:01 PM, Bryce Harrington br...@osg.samsung.com wrote:
 On Tue, Apr 07, 2015 at 05:01:25PM +0800, Jonas Ådahl wrote:
 Signed-off-by: Jonas Ådahl jad...@gmail.com
 ---
  protocol/xdg-shell.xml | 12 
  1 file changed, 12 insertions(+)

 diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
 index 3db76ab..c2e1443 100644
 --- a/protocol/xdg-shell.xml
 +++ b/protocol/xdg-shell.xml
 @@ -197,6 +197,18 @@
   the surface belongs. The compositor can use this to group multiple
   surfaces together, or to determine how to launch a new application.

 + When applicable, a client should set the app ID to the basename of the
 + .desktop file associated with the application, for example
 + org.freedesktop.FooViewer where the .desktop file is
 + org.freedesktop.FooViewer.desktop.
 +
 + For D-Bus activatble applications, this will also be D-Bus service

 typo

 Also:  'be *the* D-Bus service'

 + name used for activation of the application.

 Does D-Bus depend on having the service name constructed to match the
 .desktop file name?  If not, perhaps this paragraph should be moved
 ahead of the prior one.  I'm guessing the intention is that we're trying
 to say that the D-Bus service name will be the same as the app ID.

 used for activation of the application sounds redundant.

 + It is not a hard requirement to specify a well formed (as described
 + above) app ID, but the compositor shell may group the surface
 + inadequately if the client fail to do so.

 s/fail/fails/

 The way this is written it sounds like a requirement, that's optional,
 but has weird side effects if you don't follow it.  So it's a bit
 ambiguous whether you really do need to follow it or not.
 You might want to elaborate a bit on the implications of not having
 things grouped properly, so it's clear what the trade-off is.

 It might help if it was expressed as optional, but with extra features
 if you follow it.  Maybe something like:

 The app ID identifies the general class of applications to which
 the surface belongs. The compositor can use this to group multiple
 applications together, or to determine how to launch a new
 application.

 For D-Bus activatable applications, the app ID is used as the D-Bus
 service name.

 The compositor shell will try to group application surfaces together
 by their app ID.  As a best practice, it is suggested to select app
 ID's that match the basename of the application's .desktop file.
 For example, org.freedesktop.FooViewer where the .desktop file is
 org.freedesktop.FooViewer.desktop.

 See the desktop-entry specification [0] for more details on
 application identifiers and how they relate to well-known DBus
 names and .desktop files.


   See the desktop-entry specification [0] for more details on
   application identifiers and how they relate to well-known D-Bus
   names and .desktop files.
 --
 2.1.4

 ___
 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Xfig menus don't appear - bug?

[Jasper St. Pierre]

No, sorry. I'll take a look today.

On Mon, Apr 6, 2015 at 10:22 AM, Felix E. Klee felix.k...@inka.de wrote:
 Should I report this somewhere?
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Jasper St. Pierre]

It's because there are multiple windows, and window is ambiguous.
First of all, there's the actual window that the event was generated
on. That isn't actually sent to you. When the event bubbles up, you
get three windows:

root, which is the root window of the source window. Used for
finding the correct screen and tons of other things.

Then there's event, which is the window you selected on. It might be
the source window, it might not be. Depends how the event bubbled.

Then there's the incomprehensible child: the immediate child of
event that either is or contains the source window as an ancestor. I
don't think anybody has ever found a use case for this one.

On Mon, Mar 30, 2015 at 2:02 PM, Bill Spitzak spit...@gmail.com wrote:
 Interesting. A bit odd because looking in xproto.h I can see that the same
 offset in the structure is called window or drawable in many other
 events. I guess this is because it is generated from xprotocol descriptions
 and the terminology cannot be changed there? But kind of unclear why such a
 wrong name would have been chosen there...

 Anyway probably another indication of what a mess X is.


 On 03/30/2015 11:53 AM, Daniel Stone wrote:

 Is the window id really stored in focus-event?


 Yeah, the 'event' field of many X11 events (including literally all
 the input events) is set to the window the event was delivered to.

 Cheers,
 Daniel

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



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

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

[Jasper St. Pierre]

Now that we've removed the XYToWindow handler in Xwayland, we actually
have to stack windows properly. This stacks windows on top when
activating them.

Note that for a fully robust Xwayland implementation, we'll need a
complete stack tracker implementation, unfortunately.
---
 xwayland/window-manager.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 59cf39a..8698744 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -708,6 +708,8 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
}
 
if (window) {
+   uint32_t values[1];
+
if (window-override_redirect)
return;
 
@@ -724,6 +726,10 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
 
xcb_set_input_focus (wm-conn, XCB_INPUT_FOCUS_POINTER_ROOT,
 window-id, XCB_TIME_CURRENT_TIME);
+
+   values[0] = XCB_STACK_MODE_ABOVE;
+   xcb_configure_window (wm-conn, window-frame_id,
+ XCB_CONFIG_WINDOW_STACK_MODE, values);
} else {
xcb_set_input_focus (wm-conn,
 XCB_INPUT_FOCUS_POINTER_ROOT,
-- 
2.1.0

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

[PATCH weston] xwayland: Correct input for undecorated clients

[Jasper St. Pierre]

We were correctly handling decorated and fullscreen clients, but left
uninitialized values in the input region for undecorated clients. Fix
this behavior.
---
 xwayland/window-manager.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index ad608b7..59cf39a 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1039,14 +1039,14 @@ weston_wm_window_draw_decoration(void *data)
 
pixman_region32_fini(window-surface-pending.input);
 
-   if (window-fullscreen) {
-   input_x = 0;
-   input_y = 0;
-   input_w = window-width;
-   input_h = window-height;
-   } else if (window-decorate) {
+   if (window-decorate  !window-fullscreen) {
frame_input_rect(window-frame, input_x, input_y,
 input_w, input_h);
+   } else {
+   input_x = x;
+   input_y = y;
+   input_w = width;
+   input_h = height;
}
 
pixman_region32_init_rect(window-surface-pending.input,
-- 
2.1.0

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

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

[Jasper St. Pierre]

Yeah, this is obviously correct.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Wed, Mar 18, 2015 at 9:16 AM, Derek Foreman der...@osg.samsung.com
wrote:

 Now clamping width and height to a minimum of 1, 1 when drag resizing.

 Signed-off-by: Derek Foreman der...@osg.samsung.com
 ---
  desktop-shell/shell.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
 index 826692f..aca91eb 100644
 --- a/desktop-shell/shell.c
 +++ b/desktop-shell/shell.c
 @@ -1838,6 +1838,10 @@ resize_grab_motion(struct weston_pointer_grab
 *grab, uint32_t time,
 height += wl_fixed_to_int(to_y - from_y);
 }

 +   if (width  1)
 +   width = 1;
 +   if (height  1)
 +   height = 1;
 shsurf-client-send_configure(shsurf-surface, width, height);
  }

 --
 2.1.4

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




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

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

[Jasper St. Pierre]

In the time since this code was written, logind has gained new APIs to
handle VT switching automatically and activate sessions. Switch to that.
---
 src/launcher-logind.c | 219 +-
 1 file changed, 40 insertions(+), 179 deletions(-)

diff --git a/src/launcher-logind.c b/src/launcher-logind.c
index 56c0944..fdf268a 100644
--- a/src/launcher-logind.c
+++ b/src/launcher-logind.c
@@ -24,17 +24,12 @@
 
 #include errno.h
 #include fcntl.h
-#include linux/vt.h
-#include linux/kd.h
-#include linux/major.h
 #include signal.h
 #include stdarg.h
 #include stdbool.h
 #include stdio.h
 #include stdlib.h
 #include string.h
-#include sys/ioctl.h
-#include sys/signalfd.h
 #include sys/stat.h
 #include systemd/sd-login.h
 #include unistd.h
@@ -45,10 +40,6 @@
 
 #define DRM_MAJOR 226
 
-#ifndef KDSKBMUTE
-#define KDSKBMUTE  0x4B51
-#endif
-
 struct launcher_logind {
struct weston_compositor *compositor;
bool sync_drm;
@@ -57,8 +48,6 @@ struct launcher_logind {
unsigned int vtnr;
int vt;
int kb_mode;
-   int sfd;
-   struct wl_event_source *sfd_source;
 
DBusConnection *dbus;
struct wl_event_source *dbus_ctx;
@@ -254,27 +243,37 @@ launcher_logind_close(void *launcher_pimpl, int fd)
 static void
 launcher_logind_restore(void *launcher_pimpl)
 {
-   struct launcher_logind *wl = launcher_pimpl;
-   struct vt_mode mode = { 0 };
-
-   ioctl(wl-vt, KDSETMODE, KD_TEXT);
-   ioctl(wl-vt, KDSKBMUTE, 0);
-   ioctl(wl-vt, KDSKBMODE, wl-kb_mode);
-   mode.mode = VT_AUTO;
-   ioctl(wl-vt, VT_SETMODE, mode);
 }
 
 static int
 launcher_logind_activate_vt(void *launcher_pimpl, int vt)
 {
struct launcher_logind *wl = launcher_pimpl;
+   DBusMessage *m;
+   bool b;
int r;
 
-   r = ioctl(wl-vt, VT_ACTIVATE, vt);
-   if (r  0)
-   return -1;
+   m = dbus_message_new_method_call(org.freedesktop.login1,
+/org/freedesktop/login1/seat/self,
+org.freedesktop.login1.Seat,
+SwitchTo);
+   if (!m)
+   return -ENOMEM;
 
-   return 0;
+   b = dbus_message_append_args(m,
+DBUS_TYPE_UINT32, vt,
+DBUS_TYPE_INVALID);
+   if (!b) {
+   r = -ENOMEM;
+   goto err_unref;
+   }
+
+   dbus_connection_send(wl-dbus, m, NULL);
+   r = 0;
+
+ err_unref:
+   dbus_message_unref(m);
+   return r;
 }
 
 static void
@@ -690,157 +689,6 @@ launcher_logind_release_control(struct launcher_logind 
*wl)
 }
 
 static int
-signal_event(int fd, uint32_t mask, void *data)
-{
-   struct launcher_logind *wl = data;
-   struct signalfd_siginfo sig;
-
-   if (read(fd, sig, sizeof sig) != sizeof sig) {
-   weston_log(logind: cannot read signalfd: %m\n);
-   return 0;
-   }
-
-   if (sig.ssi_signo == (unsigned int)SIGRTMIN)
-   ioctl(wl-vt, VT_RELDISP, 1);
-   else if (sig.ssi_signo == (unsigned int)SIGRTMIN + 1)
-   ioctl(wl-vt, VT_RELDISP, VT_ACKACQ);
-
-   return 0;
-}
-
-static int
-launcher_logind_setup_vt(struct launcher_logind *wl)
-{
-   struct stat st;
-   char buf[64];
-   struct vt_mode mode = { 0 };
-   int r;
-   sigset_t mask;
-   struct wl_event_loop *loop;
-
-   snprintf(buf, sizeof(buf), /dev/tty%d, wl-vtnr);
-   buf[sizeof(buf) - 1] = 0;
-
-   wl-vt = open(buf, O_RDWR|O_CLOEXEC|O_NONBLOCK);
-
-   if (wl-vt  0) {
-   r = -errno;
-   weston_log(logind: cannot open VT %s: %m\n, buf);
-   return r;
-   }
-
-   if (fstat(wl-vt, st) == -1 ||
-   major(st.st_rdev) != TTY_MAJOR || minor(st.st_rdev) = 0 ||
-   minor(st.st_rdev) = 64) {
-   r = -EINVAL;
-   weston_log(logind: TTY %s is no virtual terminal\n, buf);
-   goto err_close;
-   }
-
-   /*r = setsid();
-   if (r  0  errno != EPERM) {
-   r = -errno;
-   weston_log(logind: setsid() failed: %m\n);
-   goto err_close;
-   }
-
-   r = ioctl(wl-vt, TIOCSCTTY, 0);
-   if (r  0)
-   weston_log(logind: VT %s already in use\n, buf);*/
-
-   if (ioctl(wl-vt, KDGKBMODE, wl-kb_mode)  0) {
-   weston_log(logind: cannot read keyboard mode on %s: %m\n,
-  buf);
-   wl-kb_mode = K_UNICODE;
-   } else if (wl-kb_mode == K_OFF) {
-   wl-kb_mode = K_UNICODE;
-   }
-
-   if (ioctl(wl-vt, KDSKBMUTE, 1)  0 
-   ioctl(wl-vt, KDSKBMODE, K_OFF)  0) {
-   r = -errno;
-   weston_log(logind: cannot set K_OFF KB-mode on %s: %m\n,
-  buf);
-   goto err_close;
-   }
-
-   if 

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

[Jasper St. Pierre]

We're refactoring this to have multiple launcher implementations.
---
 Makefile.am   |   4 +-
 src/launcher-logind.c | 953 ++
 src/launcher-logind.h | 120 +++
 src/launcher-util.c   |   2 +-
 src/logind-util.c | 953 --
 src/logind-util.h | 120 ---
 6 files changed, 1076 insertions(+), 1076 deletions(-)
 create mode 100644 src/launcher-logind.c
 create mode 100644 src/launcher-logind.h
 delete mode 100644 src/logind-util.c
 delete mode 100644 src/logind-util.h

diff --git a/Makefile.am b/Makefile.am
index c509f6e..a00ccbc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -115,8 +115,8 @@ if HAVE_SYSTEMD_LOGIN
 libsession_helper_la_SOURCES +=\
src/dbus.h  \
src/dbus.c  \
-   src/logind-util.h   \
-   src/logind-util.c
+   src/launcher-logind.h   \
+   src/launcher-logind.c
 libsession_helper_la_CFLAGS += $(SYSTEMD_LOGIN_CFLAGS) $(DBUS_CFLAGS)
 libsession_helper_la_LIBADD += $(SYSTEMD_LOGIN_LIBS) $(DBUS_LIBS)
 endif
diff --git a/src/launcher-logind.c b/src/launcher-logind.c
new file mode 100644
index 000..e4e7b1c
--- /dev/null
+++ b/src/launcher-logind.c
@@ -0,0 +1,953 @@
+/*
+ * Copyright © 2013 David Herrmann
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission.  The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose.  It is provided as is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include config.h
+
+#include errno.h
+#include fcntl.h
+#include linux/vt.h
+#include linux/kd.h
+#include linux/major.h
+#include signal.h
+#include stdarg.h
+#include stdbool.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include sys/ioctl.h
+#include sys/signalfd.h
+#include sys/stat.h
+#include systemd/sd-login.h
+#include unistd.h
+
+#include compositor.h
+#include dbus.h
+#include launcher-logind.h
+
+#define DRM_MAJOR 226
+
+#ifndef KDSKBMUTE
+#define KDSKBMUTE  0x4B51
+#endif
+
+struct weston_logind {
+   struct weston_compositor *compositor;
+   bool sync_drm;
+   char *seat;
+   char *sid;
+   unsigned int vtnr;
+   int vt;
+   int kb_mode;
+   int sfd;
+   struct wl_event_source *sfd_source;
+
+   DBusConnection *dbus;
+   struct wl_event_source *dbus_ctx;
+   char *spath;
+   DBusPendingCall *pending_active;
+};
+
+static int
+weston_logind_take_device(struct weston_logind *wl, uint32_t major,
+ uint32_t minor, bool *paused_out)
+{
+   DBusMessage *m, *reply;
+   bool b;
+   int r, fd;
+   dbus_bool_t paused;
+
+   m = dbus_message_new_method_call(org.freedesktop.login1,
+wl-spath,
+org.freedesktop.login1.Session,
+TakeDevice);
+   if (!m)
+   return -ENOMEM;
+
+   b = dbus_message_append_args(m,
+DBUS_TYPE_UINT32, major,
+DBUS_TYPE_UINT32, minor,
+DBUS_TYPE_INVALID);
+   if (!b) {
+   r = -ENOMEM;
+   goto err_unref;
+   }
+
+   reply = dbus_connection_send_with_reply_and_block(wl-dbus, m,
+ -1, NULL);
+   if (!reply) {
+   r = -ENODEV;
+   goto err_unref;
+   }
+
+   b = dbus_message_get_args(reply, NULL,
+ DBUS_TYPE_UNIX_FD, fd,
+ DBUS_TYPE_BOOLEAN, paused,
+ DBUS_TYPE_INVALID);
+   if (!b) {
+   r = -ENODEV;
+   goto err_reply;
+   }
+
+   r = fd;
+   if (paused_out)
+   *paused_out = paused;
+
+err_reply:
+   dbus_message_unref(reply);

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

[Jasper St. Pierre]

-tty, VT_SETMODE, mode)  0)
+   weston_log(could not reset vt handling\n);
+}
+
+static int
+launcher_direct_activate_vt(void *launcher_pimpl, int vt)
+{
+   struct launcher_direct *launcher = launcher_pimpl;
+   return ioctl(launcher-tty, VT_ACTIVATE, vt);
+}
+
+static int
+launcher_direct_connect(void **out, struct weston_compositor *compositor,
+   int tty, const char *seat_id, bool sync_drm)
+{
+   struct launcher_direct *launcher;
+
+   if (geteuid() != 0)
+   return -EINVAL;
+
+   launcher = zalloc(sizeof(*launcher));
+   if (launcher == NULL)
+   return -ENOMEM;
+
+   launcher-compositor = compositor;
+
+   if (setup_tty(launcher, tty) == -1) {
+   free(launcher);
+   return -1;
+   }
+
+   * (struct launcher_direct **) out = launcher;
+   return 0;
+}
+
+static void
+launcher_direct_destroy(void *launcher_pimpl)
+{
+   struct launcher_direct *launcher = launcher_pimpl;
+
+   launcher_direct_restore(launcher);
+   wl_event_source_remove(launcher-vt_source);
+
+   if (launcher-tty = 0)
+   close(launcher-tty);
+
+   free(launcher);
+}
+
+struct launcher_interface launcher_direct_iface = {
+   launcher_direct_connect,
+   launcher_direct_destroy,
+   launcher_direct_open,
+   launcher_direct_close,
+   launcher_direct_activate_vt,
+   launcher_direct_restore,
+};
diff --git a/src/launcher-impl.h b/src/launcher-impl.h
new file mode 100644
index 000..53ced0e
--- /dev/null
+++ b/src/launcher-impl.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright © 2015 Jasper St. Pierre
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission.  The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose.  It is provided as is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include config.h
+
+#include compositor.h
+
+struct launcher_interface {
+int (* connect) (void **launcher_out, struct weston_compositor *compositor,
+ int tty, const char *seat_id, bool sync_drm);
+void (* destroy) (void *launcher);
+int (* open) (void *launcher, const char *path, int flags);
+void (* close) (void *launcher, int fd);
+int (* activate_vt) (void *launcher, int vt);
+void (* restore) (void *launcher);
+};
+
+extern struct launcher_interface launcher_logind_iface;
+extern struct launcher_interface launcher_weston_launch_iface;
+extern struct launcher_interface launcher_direct_iface;
diff --git a/src/launcher-logind.c b/src/launcher-logind.c
index e4e7b1c..56c0944 100644
--- a/src/launcher-logind.c
+++ b/src/launcher-logind.c
@@ -41,7 +41,7 @@
 
 #include compositor.h
 #include dbus.h
-#include launcher-logind.h
+#include launcher-impl.h
 
 #define DRM_MAJOR 226
 
@@ -49,7 +49,7 @@
 #define KDSKBMUTE  0x4B51
 #endif
 
-struct weston_logind {
+struct launcher_logind {
struct weston_compositor *compositor;
bool sync_drm;
char *seat;
@@ -67,7 +67,7 @@ struct weston_logind {
 };
 
 static int
-weston_logind_take_device(struct weston_logind *wl, uint32_t major,
+launcher_logind_take_device(struct launcher_logind *wl, uint32_t major,
  uint32_t minor, bool *paused_out)
 {
DBusMessage *m, *reply;
@@ -119,7 +119,7 @@ err_unref:
 }
 
 static void
-weston_logind_release_device(struct weston_logind *wl, uint32_t major,
+launcher_logind_release_device(struct launcher_logind *wl, uint32_t major,
 uint32_t minor)
 {
DBusMessage *m;
@@ -141,7 +141,7 @@ weston_logind_release_device(struct weston_logind *wl, 
uint32_t major,
 }
 
 static void
-weston_logind_pause_device_complete(struct weston_logind *wl, uint32_t major,
+launcher_logind_pause_device_complete(struct launcher_logind *wl, uint32_t 
major,
uint32_t minor)
 {
DBusMessage *m;
@@ -162,10 +162,10 @@ weston_logind_pause_device_complete(struct weston_logind 
*wl, uint32_t major

[PATCH weston 0/3] Rework the launcher infrastructure

[Jasper St. Pierre]

Since the time that the logind launcher integration was written, it has
since gained a lot of features that mean that we don't have to touch
the TTY or VT ioctls ourselves.

Refactor the launcher system so that we have three different
implementations of the launcher system, tried in this order:

  1. logind, which uses the systemd-logind APIs to manage VTs and TTYs
 and devices for us cooperatively.

  2. weston-launch, which uses our legacy setuid helper to manage the
 same devices.

  3. Direct, which is only used when you are root, for small embedded
 systems.

The first two patches in this series should not have any major changes
in behavior, but is simply a giant refactor to make this code more
understandable and maintainable.

The third patch upgrades our logind launcher to the latest APIs.
Switching to the new logind APIs on logind also adds the new ability
that a smoother handover can be done from display managers like gdm,
where we can have a VT allocated to us instead of requiring that we're
opened on our own VT.

There should not be any regressions in existing behavior.

Cc: David Herrmann dh.herrm...@gmail.com
Cc: Ray Strode rstr...@redhat.com

Jasper St. Pierre (3):
  launcher: Rename logind-util to launcher-logind
  launcher: Split out launcher implementations into three distinct ones
  launcher-logind: Remove old VT switching code, move to
SwitchTo/Activate

 Makefile.am  |   9 +-
 src/launcher-direct.c| 313 ++
 src/launcher-impl.h  |  39 ++
 src/launcher-logind.c| 850 ++
 src/launcher-util.c  | 447 ++--
 src/launcher-util.h  |   5 +-
 src/launcher-weston-launch.c | 300 ++
 src/logind-util.c| 953 ---
 src/logind-util.h| 120 --
 9 files changed, 1553 insertions(+), 1483 deletions(-)
 create mode 100644 src/launcher-direct.c
 create mode 100644 src/launcher-impl.h
 create mode 100644 src/launcher-logind.c
 create mode 100644 src/launcher-weston-launch.c
 delete mode 100644 src/logind-util.c
 delete mode 100644 src/logind-util.h

-- 
2.1.0

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