Hi,
On 3 May 2013 08:17, Pekka Paalanen wrote:
> On Thu, 2 May 2013 19:28:41 +0100
> Daniel Stone wrote:
>> There's one crucial difference though, and one that's going to come up
>> when we address graphics tablets / digitisers too. wl_pointer works
>> as a
Hi,
Again I fear we're drifting massively off-topic, but here we go ...
On 3 May 2013 18:50, Bill Spitzak wrote:
> Daniel Stone wrote:
>> Subsurfaces are being designed for in-process cases, such as a media
>> player inside a browser. Foreign surfaces are intended for
>
Hi,
On 5 May 2013 17:55, Pekka Paalanen wrote:
> On Fri, 3 May 2013 17:42:20 +0100
> Daniel Stone wrote:
>> tl;dr: wl_seat has a very specific meaning of a set of devices with
>> one focus, please don't abuse it.
>
> I'm not too clear on what it is.
>
>
On 6 May 2013 14:48, Todd Showalter wrote:
> On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen wrote:
>> Into wl_seat, we should add a capability bit for gamepad. When the bit
>> is set, a client can send wl_seat::get_gamepad_manager request, which
>> creates a new wl_gamepad_manager object. (Do we
Hi,
On 7 May 2013 16:14, Todd Showalter wrote:
> On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen wrote:
>> Yeah, like Daniel said, there is no concept of a "return value".
>>
>> When a client creates a new object, the server can only either agree,
>> or disconnect the client with a protocol error
Hi,
On 22 April 2013 02:49, Matthias Clasen wrote:
> On Sat, Apr 20, 2013 at 4:53 PM, Ran Benita wrote:
>> On Tue, Apr 09, 2013 at 09:57:29PM -0400, matthias.cla...@gmail.com wrote:
>>> Users of libxkbcommon need these values to iterate over all
>>> keycodes in the keymap.
>>
>> Can you describe
Hi,
On 9 May 2013 11:49, Rick Yorgason wrote:
> But now I'm seriously wondering, does the compositor really need *any*
> protocol support to handle this case? I think we've been assuming that each
> seat will get its own free reign over the desktop, but isn't the compositor
> free to *not* do tha
Hi,
On 12 May 2013 16:54, Kristian Høgsberg wrote:
> I think we can change the interface to int open_config_file(const char
> *), which looks up and opens the config file and returns the fd. We
> can keep that in weston_compositor instead of the config_file path.
> The parse function can then fs
Hi,
On 13 May 2013 07:14, Pekka Paalanen wrote:
> On Mon, 13 May 2013 09:12:03 +1000
> Peter Hutterer wrote:
>> > Those were exactly my thoughts in the beginning, however during the way
>> > long email thread, I got convinced otherwise for now. There are a few
>> > issues that come mind:
>> > -
Hi,
On 13 May 2013 14:43, Todd Showalter wrote:
> On Mon, May 13, 2013 at 2:33 AM, David Herrmann wrote:
>> That is why the kernel provides "PHYS" and "UNIQ" fields for every
>> input device (they might be empty if not implemented, but at least
>> they're supposed to be there..). "PHYS" provides
(Still digesting the rest of the thread.)
On 14 May 2013 08:11, Peter Hutterer wrote:
> the other thing that made me thing about your approach:
> with the gamepad_manager, you've got an extra layer in the tree for gamepads
> that pointers/keyboards don't have. that's not a bad thing and focus
> h
Hi,
On 14 May 2013 05:49, Rick Yorgason wrote:
> Okay, so the most common configuration would be one seat with a mouse,
> keyboard, and gamepad. If you only ever play single player games, this is
> all you would see.
>
> When you have multiplayer games, you just want to be able to launch the game
On 17 May 2013 21:09, Bill Spitzak wrote:
> Is it impossible to change the parent of an existing subsurface?
Yes.
> If this is not possible it seems pretty limiting as clients have to destroy
> and recreate surfaces to make some rearrangements.
No, they only have to destroy and recreate the sub
Hi,
On 23 May 2013 17:38, Sinclair Yeh wrote:
> + /* Only allocate a texture if it doesn't match existing one */
> + if (((wl_shm_buffer_get_stride(buffer) / 4) != gs->pitch) ||
> + (buffer->height != gs->pitch)) {
It seems like this really should be
Hi,
On 31 May 2013 13:08, Rob Bradford wrote:
> +
This needs since="2".
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi,
Looks good to me (pending getting our key in the keyring), but you
probably want to mention that this only works when running as 'pi'.
Cheers,
Daniel
On 3 June 2013 14:50, wrote:
> From: Pekka Paalanen
>
> Signed-off-by: Pekka Paalanen
> Cc: Daniel Ston
Hi,
On 3 June 2013 19:41, Ossama Othman wrote:
> -AM_CONDITIONAL(ENABLE_COLORD,
> - test "x$enable_colord" = "xyes")
> if test x$enable_colord = xyes; then
> - PKG_CHECK_MODULES(COLORD, colord >= 0.1.27)
> + PKG_CHECK_MODULES([COLORD],
> +[colord >= 0.1.27],
>
vices. Run apt-get update, too.
>>
>> Signed-off-by: Pekka Paalanen
>> Cc: Daniel Stone
>> Cc: Alex Bradbury
>> ---
>> raspberrypi.html | 34 --
>> 1 file changed, 32 insertions(+), 2 deletions(-)
>>
>> diff
Hi,
On 7 June 2013 06:33, Marc Chalain wrote:
> A input device could not be not configurated. That should not be an error
> and just an unhandled device.
> On embedded configuration there is different input devices which are not
> used.
The intention of this codepath is to avoid the situation on
Hi,
On 7 June 2013 11:16, Marc Chalain wrote:
> I tried and at now, it seems to add a lot of complexity.
> I solution is to read the weston.ini file inside input.c... but is it
> regular ?
This is the usual solution for now, yes.
> 2013/6/7 Daniel Stone
>>
>> Hi,
&g
Hi Marc,
On 17 June 2013 17:08, Marc Chalain wrote:
> I already wrote an email on this mailing list about the use of xkbcommon for
> embedded solution.
> I had the same problem as Robert, and I disabled the check of the keymap.
> The problem is that we have number of keyboards as input device, on
Hi,
On 14 June 2013 17:42, Rob Bradford wrote:
> In embedded environments, devices that appear as evdev "keyboards" often
> have no resemblence to PC-style keyboards. It is not uncommon for such
> environments to have no concept of modifier keys and no need for XKB key
> mapping; in these cases
On 21 June 2013 23:02, Bill Spitzak wrote:
> If clients use the input method for all the text input, exactly how much is
> left of xkb keyboards? It looks like all this compiling is so that dead keys
> and all the shift states work for producing different characters. That can
> all be done by the
Hi,
Couple of minor nitpicks:
Firstly, it would be nice to see some help text alongside
--disable-xkbcommon, explaining that it's not a thing you generally
want to do.
Also if you moved the use_xkbcommon assignment into
weston_compositor_xkb_init(), and defined that to just do nothing in
the !HAV
Hi,
On 22 June 2013 01:54, Bill Spitzak wrote:
> Daniel Stone wrote:
>> If the only input API you need is the input method API, then you don't
>> need other input APIs.
>>
>> wl_keyboard is pretty much for people who need to support non-textual
>> keybo
On 22 June 2013 03:55, Bill Spitzak wrote:
> Daniel Stone wrote:
>> If you can think of a way to simplify this, please send concrete
>> patches to GTK+, Qt and co., and when they've changed, we can later
>> simplify xkbcommon. But unfortunately in the last however many
desktop-shell for the
sake of it is a fools' game - but it's there as a tech demo rather
than anything else.
Cheers,
Daniel
> [1]
> http://lists.freedesktop.org/archives/wayland-devel/2013-April/008659.html
>
>
> 2013/7/3 Tomeu Vizoso
>>
>> From: Daniel St
Hi,
On 5 July 2013 20:35, Thiago Macieira wrote:
> First, it mentions that Requires.private is *not* used in dynamic linking.
> Then it changes its mind with that last sentence, which is cryptic.
>
> In any case, the actual behaviour is that Requires.private is used in dynamic
> linking. It adds
Hi Yan,
Is this code available somewhere?
Cheers,
Daniel
On 9 July 2013 09:13, wrote:
> Hi,
> I have implemented Wayland buffer sharing mechanism in WebKit2-efl based
> on nested client example. Nested client share buffer from one nested
> client to nesting client which is the Wayland server
ng to guess the magic number.
Cheers,
Daniel
On 3 April 2013 05:17, Daniel Stone wrote:
> Hi Martin,
> By and large this looks good to me, although the main comment I have
> is that this should probably be using the acceleration mechanism in
> src/filter.c.
>
> Cheers,
> Danie
Hi,
On 22 July 2013 11:23, Pekka Paalanen wrote:
> no, not yet, it was just a protocol RFC to get an idea. I may have
> few changes to it not posted to the list, but I won't get to them
> until next week. And the interaction with the surface/output scale
> (HiDPI) really needs to be figured out.
Yep, makes a lot of sense - it was only in there originally due to the
libwayland-server/weston input split.
On 22 July 2013 17:31, Rob Bradford wrote:
> From: Rob Bradford
>
> This removes the use of wl_client_get_display() where the client is
> derived from the focussed resource. This starts t
Hi,
On 22 July 2013 17:31, Rob Bradford wrote:
> The Wayland protocol permits a client to request the pointer, keyboard
> and touch multiple times from the seat global. This is very useful in a
> component like Clutter-GTK where we are combining two libraries that use
> Wayland together.
>
> This
Hi,
On 16 July 2013 09:33, Jonny Lamb wrote:
> weston-compositor and the weston-info client have also been updated to
> pass on and print these values if present. The rate and delay defaults
> originate from X.
This and the protocol patch both look good to me; in particular I
(surprisingly) can'
On 27 July 2013 19:28, Bill Spitzak wrote:
> I think that rather than some trick to fool glib into making the poll return
> immmediately, calling dispatch_pending in a loop until it returns false will
> work better, and the poll can be called normally.
Um, it's not a trick, it's exactly how GSour
On 31 July 2013 03:53, Fu Michael wrote:
> On 7/22/2013 6:43 PM, Daniel Stone wrote:
>> On 22 July 2013 11:23, Pekka Paalanen wrote:
>>> I'm not aware of anyone else working on it, but then I have been
>>> pretty ignorant of Wayland discussions in the recent weeks
Hi Andrew,
Nice to hear from you. :)
Unfortunately, the pretty blunt answer is that it's not the kind of
interface we're intending to support at the moment. There are two
primary reasons behind this: the first is that by design, we tend to
put things like this in private, compositor-led, protocol
Hi,
On 7 August 2013 02:04, Peter Hutterer wrote:
> mtdev as currently used in weston is a noop. mtdev's purpose is to convert
> Protocol A devices (without ABS_MT_SLOT) to Protocol B devices (slots).
> For Protocol B devices mtdev merely routes the events, so checking for
> slots and then using
Hi,
On 7 August 2013 16:02, Armin K wrote:
> warning: "_GNU_SOURCE" redefined [enabled by default]
The _GNU_SOURCE define isn't needed at all, cf. c228e23b.
Cheers,
Daniel
> src/cms-colord.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/cms-colord.c b/src/cms-colord.c
> index
On 14 August 2013 10:03, Rob Bradford wrote:
> On 13 August 2013 20:11, Rob Bradford wrote:
>> +static void
>> +pointer_release(struct wl_client *client, struct wl_resource *resource)
>> +{
>> + wl_resource_destroy(resource);
>> +}
>> +
>
> Wondering if we should also send leave events here
Hi,
On 14 August 2013 22:13, Rusty Lynch wrote:
> I couldn't find a way to determine if the move request was triggered for
> touch or mouse events.
Serial numbers are unique per-display. So there's no possibility for
collision: a serial will either be for a button press, a key press, a
touch do
config.h includes were missing in a few files, including input.c, the
lack of which caused the X11 backend to segfault instantly due to not
having an xkbcommon context.
Signed-off-by: Daniel Stone
---
This is actually against 1.2 branch, but should apply fine to master.
Please apply to unbreak
Hi,
On 30 July 2013 00:15, Kristian Høgsberg wrote:
> On Sat, Jul 20, 2013 at 05:16:45AM +0100, Louis-Francis Ratté-Boulianne wrote:
>> Fix a segfault occuring after the last X window was closed.
>
> Thanks, that looks good.
Did this get lost?
Cheers,
Daniel
>> src/xwayland/window-manager.c |
Hi,
On 15 August 2013 11:52, Peter Hutterer wrote:
> one of the things that should be done is to figure out _where_ features such
> as this are going to be handled. In the compositor, the compositor's input
> module, on the client side, ... ? I'm trying to figure out how to handle
> this correctl
$(datadir) rather than $(libdir), is for architecture-independent data.
pkg-config files should only be installed there if they're shareable
across architectures, e.g. headers/data only, which wayland-scanner is
not. Move it to $(libdir) with the other pkg-config files.
Signed-off-by: D
$(datadir) rather than $(libdir), is for architecture-independent data.
pkg-config files should only be installed there if they're shareable
across architectures, e.g. headers/data only, which wayland-scanner is
not. Move it to $(libdir) with the other pkg-config files.
Signed-off-by: D
Hi,
On 16 August 2013 15:50, David Herrmann wrote:
> On Fri, Aug 16, 2013 at 2:26 PM, Daniel Stone wrote:
>> $(datadir) rather than $(libdir), is for architecture-independent data.
>> pkg-config files should only be installed there if they're shareable
>> across archit
Hi,
On 19 August 2013 23:37, Kristian Høgsberg wrote:
> On Mon, Aug 19, 2013 at 01:00:52PM -0700, Othman, Ossama wrote:
>> That's an implementation-specific preprocessor symbol. Please use the
>> _XOPEN_SOURCE feature test macro instead.
>>
>> The user could also potentially define that feature
Hi,
On 21 August 2013 20:50, Bill Spitzak wrote:
> I think my underlying difficulty is that I have to use the wlshm driver
> rather than the default of wlegl. This requires me to find an xorg.conf file
> setting the driver to wlshm. This requires an environment variable to be
> changed between wh
Hi,
On 30 August 2013 03:56, wrote:
> On 30/08/2013 06:37, Kristian Høgsberg wrote:
>> On Fri, Aug 23, 2013 at 05:15:48PM +0300, Ander Conselvan de Oliveira
>> wrote:
>>> +PKG_CHECK_MODULES(LIBVA, [libva >= 0.34.0 libva-drm >= 0.34.0],
>>> [have_libva=yes], [have_libva=no])
>>> +AS_IF([test "x$h
Hi,
On 9 September 2013 16:51, Quentin Glidic
wrote:
> @@ -79,8 +79,8 @@
> cd ..
>
>
> -git clone git://people.freedesktop.org/~iksaif/xf86-video-wlshm
> -cd xf86-video-wlshm
> +git clone
> git://people.freedesktop.org/xorg/driver/xf86-video-wayland
> +cd xf86-video-waylan
Hi,
On 11 September 2013 14:31, Neil Roberts wrote:
> This reverts commit eccef6aadd142103ed151883e61c0e7a2fd98639.
>
> Queuing the buffer release event instead of posting it immediately
> causes problems if the client is not installing a frame callback and
> instead is waiting for the buffer rel
Hi,
On 11 September 2013 17:15, Kristian Høgsberg wrote:
> On Wed, Sep 11, 2013 at 02:54:47PM -0400, Daniel Stone wrote:
>> Yeah, this is good to me. Media pipelines also really want release
>> events ASAP, so they can reuse hardware-decoder buffers.
>
> The problem is tha
Hi,
You need to install xkeyboard-config into /usr/share.
Cheers,
Daniel
On 20 September 2013 11:18, wrote:
> Hello,
>
> I have built Wayland according to the instructions available on
> http://wayland.freedesktop.org/building.html. Then, as a normal user (member
> of the group
> weston-launch
Hi,
On 27 September 2013 08:31, Micah Nordland wrote:
> The wire format spec includes an array type:
> array
>
> Starts with 32-bit array size in bytes, followed by the array
> contents verbatim, and finally padding to a 32-bit boundary.
>
> What type are the contents? The protocol descriptio
Hi,
On 27 September 2013 05:38, Neil Roberts wrote:
> Pekka Paalanen writes:
>> If not, is there not a possibility to break existing applications by
>> blocking too early?
>
> Yes, you're right, the patch is nonsense because it won't work when the
> application does wl_display_dispatch_pending b
Hi,
On 27 September 2013 03:30, Ran Benita wrote:
> On Thu, Sep 26, 2013 at 06:46:02PM -0500, Jason Ekstrand wrote:
>> Looking at weston's input.c, I am not seeing any evidence that it sends any
>> key events due to an enter. It does resend the modifiers, but that's
>> different. It doesn't mak
Hi,
On 24 September 2013 15:05, Bill Spitzak wrote:
> I really really think this idea should be changed.
With almost zero consideration to the downsides.
> Clients should just be
> prepared for excess up and down events, and excess focus in/out. Avoiding
> them becomes nearly impossible as you
Hi,
On 27 September 2013 17:00, Bill Spitzak wrote:
> Daniel Stone wrote:
>> Yes. If your starting point is that the thing directing your input
>> events and focus shouldn't have to know where to direct its input
>> events or focus, then we disagree on something I
Hi,
On 1 October 2013 05:53, Tomeu Vizoso wrote:
> The EGL implementation on the RPi allocates a front and a back
> DispmanX resources for each EGLSurface, which we composite along
> the others.
> ---
>
> Remaining issues:
>
> * The EGL side isn't sending sync messages from SwapBuffers while wait
Hi,
On 1 October 2013 18:50, Kristian Høgsberg wrote:
> On Tue, Oct 01, 2013 at 12:53:03PM +0200, Tomeu Vizoso wrote:
>> The EGL implementation on the RPi allocates a front and a back
>> DispmanX resources for each EGLSurface, which we composite along
>> the others.
>
> Is this something you want
Hi,
On 4 October 2013 13:09, Wander Lairson Costa wrote:
> The issued raised when I took code from window.c in the weston clients:
>
> mask = xkb_state_serialize_mods(input->xkb.state,
> XKB_STATE_DEPRESSED |
>
Hi,
On 4 October 2013 14:06, Wander Lairson Costa wrote:
> 2013/10/4 Daniel Stone :
>> Well sure, but we took the added benefit of type safety (at least with
>> C compilers) over the the small potential downside. I was fully aware
>> of the technical point there, but don&
Hi,
On 7 October 2013 14:32, Rui Matos wrote:
> @@ -1623,6 +1623,44 @@ weston_compositor_xkb_destroy(struct weston_compositor
> *ec)
> }
> #endif
>
> +WL_EXPORT void
> +weston_seat_update_keyboard(struct weston_seat *seat, struct xkb_keymap
> *keymap)
This should be weston_seat_update_keymap
Hi,
On 7 October 2013 14:32, Rui Matos wrote:
> We'll need something like this in mutter-wayland to allow people to
> add/change their keyboard layouts with gnome-control-center so I
> figured I'd start by implementing the basics in weston first.
>
> There's an implementation for a couple of back
Hi,
On 14 October 2013 01:08, Jason Ekstrand wrote:
> In particular, this gives us a close button on xwayland windows.
>
> Signed-off-by: Jason Ekstrand
> ---
>
> In some applications (specifically GLXGears), the close button does not
> work. Unfortunately, my knowledge of X window managers is
Hi,
On 16 October 2013 17:09, Jonas Kulla wrote:
> it might just be a stupid thought of mine, but it would be kinda cool
> if there was wayland protocol for creating an EGLStream [1] backed
> surface.
It would be nice, but TTBOMK the only EGLStream implementation is in
the Tegra EGL stack, which
Hi,
On 21 October 2013 13:41, Rui Matos wrote:
> These patches add support for changing the X keymap on wayland keymap
> events.
>
> I wonder what we should do for X client requests to change the keymap
> though. We could:
>
> a) somehow try to change the wayland keymap accordingly, possibly
>
ster,
> device->key->xkbInfo->desc))
> FatalError("Couldn't pivot keymap from device to core!\n");
> }
CopyKeyClass is only called when device->key is set.
But for the rest:
Reviewed-by: Daniel Stone
Cheers,
Daniel
_
Hi,
This and the other one look good to me:
Reviewed-by: Daniel Stone
Cheers,
Daniel
On 21 October 2013 13:41, Rui Matos wrote:
> ---
> hw/xfree86/xwayland/xwayland-input.c | 39
> +---
> include/input.h | 2 +-
> 2 fi
Hi,
On 16 October 2013 19:40, Jonas Kulla wrote:
> 2013/10/16 Daniel Stone
>> On 16 October 2013 17:09, Jonas Kulla wrote:
>> > it might just be a stupid thought of mine, but it would be kinda cool
>> > if there was wayland protocol for creating an EGLStream [1] ba
Hi,
On 18 October 2013 11:52, James Courtier-Dutton wrote:
> On 18 October 2013 08:30, Pekka Paalanen wrote:
>> On Thu, 17 Oct 2013 21:34:02 +0100
>> James Courtier-Dutton wrote:
>> > All its prediction calculations will be based on a fixed scanout rate.
>>
>> Why only fixed scanout rate? Why c
On 22 October 2013 21:05, Bill Spitzak wrote:
> Are "latched modifiers" things like the Compose Key and dead-key accent
> prefixes?
No, they're more akin to StickyKeys.
> I think this is usually dropped when the focus changes.
>
> It also seems like these should be handled by the input method. I
Hi,
On 25 October 2013 20:25, Brian Lovin wrote:
> When we would build weston with libxkb 0.2.0 it would succesfully
> compile, but the keybaord and desktop-shell wouldn't load, and
> Weston wouldn't run.
Looks good to me, but out of interest, what was the error?
Cheers,
Daniel
> Signed-off-by
Hi,
On 25 October 2013 22:18, Jonas Ådahl wrote:
> Signed-off-by: Jonas Ådahl
Fine by me.
Cheers,
Daniel
> src/compositor-x11.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/compositor-x11.c b/src/compositor-x11.c
> index ee3df31..73e71ed 100644
> --- a/src/compositor-x11.c
Hi,
On 28 October 2013 11:19, Tomeu Vizoso wrote:
> I'm still concerned about platforms with high resolution displays but
> relatively little memory.
>
> I'm thinking of the RPi, but my understanding is that Android goes to
> great lengths to reduce the number of buffers that clients have to
> ke
Hi,
On 28 October 2013 21:13, Axel Davy wrote:
> On 28/10/2013, Daniel Stone wrote :
>>> For programers having to cope with X and Wayland, and to better support
>>> the
>>> Present extension, I reiterate my suggestion
>>> to do something similar to the
Hi,
On 28 October 2013 15:47, Axel Davy wrote:
> On 28/10/2013, Frederic Plourde wrote :
>> I don't know about current/future driver support for this new GSYNC
>> technology... but you know what, I definitely agree with Pekka as we should
>> get this protocol and basic buffer queuing implementati
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
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
Hi,
On 14 November 2013 20:47, Bill Spitzak wrote:
> Jasper St. Pierre wrote:
>> Transients, as they existed in wl_shell_surface, have been removed from
>> xdg_shell and aren't coming back. There is a new set_transient_for request,
>> but it's more to provide something like the ICCCM WM_TRANSIENT
Hi,
On 21 November 2013 14:23, wrote:
> weston_tests = \
> + bad_client.weston \
> keyboard.weston \
> event.weston\
> button.weston \
I think this would be much better cal
Hi,
On 22 November 2013 15:30, wrote:
> The symbol is needed only for the EGL buffer path. If --disable-egl is
> given to ./configure, there is no need for it, so fix it to actually not
> look for that symbol needlessly.
>
> This should fix the runtime error:
>
> Failed to load module: .
Hi,
On 27 November 2013 20:08, Bill Spitzak wrote:
> On 11/27/2013 12:34 AM, Pekka Paalanen wrote:
>> I have explained all this before. Nothing here has changed.
>
> I realize this but I still have to express my complete dumbfoundment that
> you think this is ok.
You're attempting to design for
Hi,
On 28 November 2013 10:04, Pekka Paalanen wrote:
> On Thu, 28 Nov 2013 10:24:33 +0100
> Benjamin Gaignard wrote:
>> From my point of view wl_drm isn't link to Mesa, it is only about
>> exchange buffers by using a file descriptor and, for example, doesn't
>> rely on EGL.
>>
>> I understand th
Hi,
On 26 November 2013 17:19, Jonny Lamb wrote:
> +
> +
> +
> +
In the same vein as my reply to Bill, I'd really like to see these
changed to int. I have little sympathy for clients which perform
layout such that their buffer_scale doesn't allow them to represent
their s
Pixman's headers include a representation of -1 in fixed-point, which is
-1 << 16. This trips a GCC warning about shifting negative values. As we
can't do much about it, just silence the warning.
Signed-off-by: Daniel Stone
---
configure.ac | 3 ++-
1 file changed, 2 insertion
compositor->config was removed a while ago.
Signed-off-by: Daniel Stone
---
src/screen-share.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/screen-share.c b/src/screen-share.c
index 196173e..c9e7436 100644
--- a/src/screen-share.c
+++ b/src/screen-shar
On 20 June 2016 at 21:18, Tomi Valkeinen wrote:
> At the moment only XRGB is supported when using pixman renderer.
> This patch adds support also for RGB565.
16bpp in 2016? Ouch. :(
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
wayland
Hi Bryce,
All merged, thanks!
Cheers,
Daniel
On 16 June 2016 at 10:36, Bryce Harrington wrote:
> xkb_context_new() returns a xkb_context pointer, so change the variable
> definition to be consistent.
>
> Signed-off-by: Bryce Harrington
> ---
> doc/quick-guide.md | 2 +-
> 1 file changed, 1 ins
n-KMS desktop, rewrite good
chunks of the FAQ to reflect today's reality a little better.
Signed-off-by: Daniel Stone
---
faq.html | 115 ---
1 file changed, 43 insertions(+), 72 deletions(-)
diff --git a/faq.html b/faq.html
ind
Hi,
On 21 June 2016 at 21:23, Quentin Glidic
wrote:
> On 21/06/2016 01:58, Daniel Stone wrote:
>> compositor->config was removed a while ago.
>>
>> Signed-off-by: Daniel Stone
>
> Wrote the same and lazily forget to send it.
> Reviewed-by: Quentin Glidic
Pu
simple.
I can't claim any experience with libweston at all, but it all seems
reasonable on the face of it, so:
Acked-by: Daniel Stone
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi,
On 21 June 2016 at 16:28, Tomi Valkeinen wrote:
> On 21/06/16 04:32, Daniel Stone wrote:
>> 16bpp in 2016? Ouch. :(
>
> Yeah... Well, it cuts the mem bandwidth usage to half, so it's quite a
> nice bonus on low end SoCs.
Pushed with mine & Derek's revie
Hi,
On 23 June 2016 at 08:54, Derek Foreman wrote:
> On 20/06/16 06:57 PM, Daniel Stone wrote:
>> Pixman's headers include a representation of -1 in fixed-point, which is
>> -1 << 16. This trips a GCC warning about shifting negative values. As we
>> can'
Hi Bryce,
On 23 June 2016 at 14:33, Bryce Harrington wrote:
> On Wed, Jun 22, 2016 at 02:44:23PM +0300, Pekka Paalanen wrote:
>> so far only Yong has given a Reviewed-by. Bryce gave a sort-of ok but
>> not an official tag, can I take that as an Acked-by?
>
> I would like to see the Weston patches
Hi Guilio,
On 5 June 2016 at 03:48, Giulio Camuffo wrote:
> @@ -97,8 +97,17 @@ switch_vt_binding(struct weston_keyboard *keyboard,
> uint32_t time, uint32_t key, void *data)
> {
> struct weston_compositor *compositor = data;
> + struct weston_launcher *launcher =
On 19 May 2016 at 05:32, Benoit Gschwind wrote:
> The x11_backend_deliver_button_event can be called with any
> xcb_generic_event. The assert check if the call is done with the
> expected events.
>
> Signed-off-by: Benoit Gschwind
Reviewed-b
On 19 May 2016 at 05:32, Benoit Gschwind wrote:
> The "state" variable in x11_backend_deliver_button_event is basically the
> same as (event->response_type == XCB_BUTTON_PRESS), thus update the code
> to use the last one.
>
> Signed-off-by: Benoit Gschwind
Hi,
On 19 May 2016 at 05:32, Benoit Gschwind wrote:
> In current compositor-x11, the mouse buttons are grabbed and ungrabbed
> manually that may produce weird cases like starting a grab while the
> buttons are already released, due to asynchronous X11 events dispatching.
>
> The patch avoid the i
1301 - 1400 of 2140 matches
Mail list logo
