Re: [PATCH weston 7/7 v2] Update the weston man page to include the new Wayland backend options

On Mon, Nov 11, 2013 at 2:12 PM, Jason Ekstrand wrote: > > On Nov 11, 2013 3:18 AM, "Pekka Paalanen" wrote: > > > > On Sun, 10 Nov 2013 17:26:28 -0600 > > Jason Ekstrand wrote: > > > > > Signed-off-by: Jason Ekstrand > > > --- > > > man/weston.man | 20 +++- > > > 1 file change

Re: [RFC v.2] Extend wl_surface protocol

Hi, On 11 November 2013 15:41, Pekka Paalanen wrote: >> >> >> The buffer_queue interface is removed from the buffer_queue-enabled >> surface. > > This could also mention, that the queue is emptied first, and release > and presentation feedback events are emitted as usu

PSA: Chromium Wayland preview

We are happy to announce the first "preview" of Chromium browser with Wayland support, using Ozone-Wayland implementation. Check the announcement and the details here please: https://01.org/ozone-wayland/blogs/tiagovignatti/2013/chromium-browser-wayland-preview-release Tiago

Re: [RFC v.2] Extend wl_surface protocol

Hi, On 11 November 2013 15:52, Pekka Paalanen wrote: > On Fri, 08 Nov 2013 23:49:25 +0100 > Axel Davy wrote: >> Except this problem, I think your protocol proposition is fine. >> I suggest to change the spec >> to include the fact that queue is a more complete commit, >> and will take into accou

Re: [PATCH weston 7/7 v2] Update the weston man page to include the new Wayland backend options

On Nov 11, 2013 3:18 AM, "Pekka Paalanen" wrote: > > On Sun, 10 Nov 2013 17:26:28 -0600 > Jason Ekstrand wrote: > > > Signed-off-by: Jason Ekstrand > > --- > > man/weston.man | 20 +++- > > 1 file changed, 19 insertions(+), 1 deletion(-) > > > > diff --git a/man/weston.man b/man

Re: [PATCH] xdg_shell: Adding a new shell protocol.

Rafael Antognolli wrote: + + + Start a pointer-driven move of the surface. + + 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). +

RE: CI for wayland (buildbot).

Hopefully I didn't come across as trying to discourage you or anyone else from contributing in this realm. I think it's great you're exploring this for Wayland! I look forward to seeing your solution come together and think it'll be very useful ;-). Regards! U. Artie From: Artsiom Anike

Re: [RFC v2] surface crop & scale protocol extension

Pekka Paalanen wrote: Or would you rather have src_x, src_y, src_width, src_height always defined in buffer coordinates, and then buffer_transform and buffer_scale (with their requirement of size being a multiple of buffer_scale) applied to dst_width and dst_height instead? In the latter case,

Re: [PATCH] xdg_shell: Adding a new shell protocol.

Just so we're clear, the goal wasn't to omit them entirely and say "nope" to any future additions. The goal was to prevent stalling with bikeshedding on the list again, and land this *for now*. And you're fully welcome to have any input on how these things should be implemented in xdg_shell when th

Re: [RFC v2] surface crop & scale protocol extension

Pekka Paalanen wrote: Clients will always specify surface content in blocks of buffer_scale x buffer_scale pixels. That is how it was before, and that is how the crop & scale extension uses it. In other words, everything is still in surface coordinate units, just like before. Yes I understand

Re: [PATCH] xdg_shell: Adding a new shell protocol.

On Fri, Nov 8, 2013 at 3:29 PM, Jasper St. Pierre wrote: > . . . > What's going to happen from here is that this is going to land in Weston, > not in Wayland (I hope, at least; the subject doesn't say so!). Rafael > Antognolli is also going to write the Weston/Westoy patches, and I'm going > to wr

Re: [RFC v2] surface crop & scale protocol extension

Pekka Paalanen wrote: Sounds right. My main concern was that the scale width+height completely replaces all uses of the buffer width+height in the visible compositor api (the buffer width+height is needed to figure out where the memory for the crop region is, but should be ignored otherwise)

Re: CI for wayland (buildbot).

Ok, cool then I'll just be working on that letting everyone know about the status (just for fun at least). Regarding your concerns: 1) Time and effort - people will be joining, I'm sure. In the beginning I can handle it. I'll deal with ISP and later on we will be moving of course to some of "offic

RE: CI for wayland (buildbot).

Currently, there is no "official" continuous integration (CI) tool for the Wayland community. However, there are several people and organizations that run Wayland CI on their own, each tailored to their specific tools, needs and environment. If you want to provide a CI service to any community

Re: [RFC v.2] Extend wl_surface protocol

On 11/11/2013, Pekka Paalanen wrote : Hi Axel On Fri, 08 Nov 2013 23:49:25 +0100 Axel Davy wrote: Hello, I've read carefully your new protocol proposition, but I think it doesn't meet the requirements to implement the X Present extension for XWayland. The problem is that I need to be able t

Re: [RFC v.2] Extend wl_surface protocol

Hi Axel On Fri, 08 Nov 2013 23:49:25 +0100 Axel Davy wrote: > Hello, > > I've read carefully your new protocol proposition, > but I think it doesn't meet the requirements to implement > the X Present extension for XWayland. > > The problem is that I need to be able to use the frame > request t

Re: [RFC v.2] Extend wl_surface protocol

Hi, this looks mostly very good. There is one mistake, and some things that need more thought or better wording. On Fri, 08 Nov 2013 06:59:38 -0500 Frederic Plourde wrote: > Hi, > > I have gathered comments and suggestions from colleagues and wayland-devel > reviewers and here is RFC v.2 of

CI for wayland (buildbot).

Hi, guys, Do you have any of those running (I mean CI tools) (I didn't find any links)? If not then I can setup a buildbot . Actually it's already runnig on my home machine. You can access it here . This build indicates 1 fail

Re: [RFC v2] surface crop & scale protocol extension

On Fri, 8 Nov 2013 13:33:22 +0200 Pekka Paalanen wrote: > > > An additional interface to a wl_surface object, which allows the > client to specify the cropping and scaling of the surface > contents. > > This interface allows to define the source rectangle (src_x,

Re: [RFC v2] surface crop & scale protocol extension

Argh, reply-to-all had a bad list address. Sorry for double-posting your personal copies. - pq On Mon, 11 Nov 2013 11:13:48 +0200 Pekka Paalanen wrote: > Hi Rafael, > > btw. if anyone thinks any of my replies should be added to the protocol > specification to clarify it, let me know. If I don't

Re: [PATCH weston 7/7 v2] Update the weston man page to include the new Wayland backend options

On Sun, 10 Nov 2013 17:26:28 -0600 Jason Ekstrand wrote: > Signed-off-by: Jason Ekstrand > --- > man/weston.man | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/man/weston.man b/man/weston.man > index 39d854b..2095819 100644 > --- a/man/weston.man >

Re: Some touchscreen support..

On Sun, 10 Nov 2013 16:09:21 +0200 Oskari Rauta wrote: > > Raspberry Pi version doesn't support currently udev properties, I once > modified evdev, so it accepted touchscreen calibration values from udev.. Really? I see the code reads ID_SEAT. How does that not work for ignoring a device? Gra