On Wed, Jul 8, 2015 at 8:29 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
good point, that does seem to be the best approach here.
the resolution claimed was 800 dpi - 31 u/mm.
I'm a bit worried about doing this though, the reporter in
https://bugs.freedesktop.org/show_bug.cgi?id=90101
All your objections sounds like you are confusing the implementation with
the abstraction that the client program sees. A few examples:
On Wed, Jul 8, 2015 at 4:47 AM, Daniel Stone dan...@fooishbar.org wrote:
Yes this also creates
multiple C structures in the server, to keep track of the
On Tue, Jul 7, 2015 at 11:11 AM, Daniel Stone dan...@fooishbar.org wrote:
More correctly, they are never called (which would happen on receipt
of a server event) because it only ever binds wl_output v1, where the
done/scale events were added in v2, so the server will never send
those events.
On Mon, Jul 6, 2015 at 11:53 PM, Pekka Paalanen ppaala...@gmail.com wrote:
Multiple handles to the same underlying server-side object from
completely asynchronous contexts (different processes). I can't see
that ending well at all, considering that *nothing* we have ever
designed for Wayland
On Fri, Jul 3, 2015 at 3:10 AM, Jonas Ådahl jad...@gmail.com wrote:
This would work, but it still feels wrong to me. It has the same
priority-inversion as before (the less privileged clients gets to see
the more privileged one). It also limits what the open file dialog
client can do. For
On Tue, Jun 30, 2015 at 11:08 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
Not all touchpads provide x/y axis resolution. some of them (apple
touchpads) we fix up in the systemd hwdb but others are harder to detect or
fix in a generic manner. so we set a fake resolution (1 unit/mm), but
In short, instead of
bar = wl_foo_get_bar(foo);
wl_proxy_set_queue((struct wl_proxy *) bar, queue);
wl_bar_add_listener(bar, ...);
with this RFC a client does
foo_wrapper = wl_proxy_create_wrapper((struct
On Mon, Jun 29, 2015 at 2:06 PM, Mario Kleiner mario.kleiner...@gmail.com
wrote:
The bits are not a bit mask where a specific bit position corresponds to a
specific pipe, but those bits encode a 5 bits wide pipe number between 0
and (2^5)-1 ie. 0-31. The comment in the code snippet you show
On Tue, Jun 30, 2015 at 5:22 AM, Hans de Goede hdego...@redhat.com wrote:
+ if (elm-next == NULL elm-prev == NULL)
+ return;
+
elm-prev-next = elm-next;
elm-next-prev = elm-prev;
elm-next = NULL;
I do not think this is a good idea, most list
On Fri, Jun 26, 2015 at 11:34 AM, Derek Foreman der...@osg.samsung.com
wrote:
+static unsigned int drm_waitvblank_pipe(struct drm_output *output)
+{
+ if (output-pipe 1)
+ return (output-pipe DRM_VBLANK_HIGH_CRTC_SHIFT)
+
On Sun, Jun 28, 2015 at 7:32 AM, x414e54 x414...@linux.com wrote:
Clients do not draw the mouse cursor, either the GPU (using hardware
overlays) or the WM does.
Yes, I want to allow clients to use this CPU/WM support. Currently the
client *has* to draw the cursor (and hide the hardware one)
On Sun, Jun 28, 2015 at 8:49 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
+ if (elm-next == NULL elm-prev == NULL)
+ return;
+
elm-prev-next = elm-next;
elm-next-prev = elm-prev;
elm-next = NULL;
You probably don't need to check both
I am very much in favor of this, and posted earlier a further patch that
uses this information to produce better protocol documentation.
The above design is exactly correct (in particular the bitfield indicator
is on the enumeration, not the argument).
On Fri, Jun 26, 2015 at 8:04 AM, Auke
On Thu, Jun 25, 2015 at 9:38 PM, Jonas Ådahl jad...@gmail.com wrote:
This version adds support for changing the lock/confine region after the
lock was created.
For pending wl_confined_pointer lock, the effect is the same as for
wl_locked_pointer. But for an already activated confinement, it
On Thu, Jun 25, 2015 at 9:38 PM, Jonas Ådahl jad...@gmail.com wrote:
A wl_relative_pointer object is an extension to the wl_pointer interface
only used for emitting relative pointer events. It will only emit events
when the parent pointer has focus.
To get a relative pointer object, use the
On Thu, Jun 25, 2015 at 8:52 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
I think you're underestimating the precision of modern touchpads. The T440s
have a resolution of 42 units/mm, the x220 from several years ago had
somewhere around 130. The lowest value I've seen so far was 10.
of the touchpad
in mm instead.
On 06/25/2015 08:06 AM, spit...@gmail.com wrote:
From: Bill Spitzak bill.spit...@dreamworks.com
(changes from previous version: rounds the guess and changes 0 to 1,
removed unused variables)
Instead a default resolution is set if the device does not claim one
On Wed, Jun 24, 2015 at 2:05 AM, Pekka Paalanen ppaala...@gmail.com wrote:
On Wed, 24 Jun 2015 09:40:51 +0200
Christian Hartmann corno...@googlemail.com wrote:
Hi,
is it possible to autostart of app(s) while weston starts ??
Would be nice to have such an feature, if its not present
On Tue, Jun 23, 2015 at 9:55 PM, Jon A. Cruz j...@osg.samsung.com wrote:
Looking into it more, I think I've figured out much of that on my part
comes from C++ and other OO languages I've worked in. Especially with
C++ one should start a class declaration with a single 'public' section
that this needs to be tested!
From f13129154f5820eefc9ca11994fc98b5dec98dbb Mon Sep 17 00:00:00 2001
From: Bill Spitzak bill.spit...@dreamworks.com
Date: Wed, 24 Jun 2015 11:19:50 -0700
Subject: [PATCH] libinput: remove checks for fake_resolution
Instead a default resolution is set if the device does
.
On Wed, Jun 24, 2015 at 11:38 AM, Bill Spitzak spit...@gmail.com wrote:
Searching for uses of fake_resolution and equating the two results gives
scale factors between resolution and the controller range (called width and
height here):
evdev-mt-touchpad-buttons.c:535 bottom_area.top_edge
On Sun, Jun 21, 2015 at 9:54 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
In some applications, notably Inkscape, where it is common to frequently
drag
objects a short distance the default to drag-lock always-on is frustrating
for
users.
Make it configurable, with the current default
On Sun, Jun 21, 2015 at 11:46 PM, x414e54 x414...@linux.com wrote:
Hi I have been away for a while and quite busy so I did not get a
chance to response.
On Tue, Apr 28, 2015 at 3:46 AM, Bill Spitzak spit...@gmail.com wrote:
No, I absolutely 100% disagree.
Synchronized updating so things
On Tue, Jun 23, 2015 at 10:49 AM, Giulio Camuffo giuliocamu...@gmail.com
wrote:
Well, but you are adding weston specific stuff into the backends code,
that is the options handling. In libweston the backends do not parse
the command line or the config file, so all the backend options are
On Tue, Jun 23, 2015 at 4:17 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
Perhaps you are already doing this, but can't you require the mouse to be
held down and/or moved more than some threshold on the first drag to turn
on drag-lock mode?
interesting idea, but I don't think it'll
It seems like prev
On Mon, Jun 22, 2015 at 1:02 PM, Giulio Camuffo giuliocamu...@gmail.com
wrote:
The backends used to have lots of code dealing with weston specific
configs.
To allow them to be used by other compositors with their own configurations
remove all the usage of weston_config
On Thu, Jun 18, 2015 at 12:14 AM, Pekka Paalanen ppaala...@gmail.com
wrote:
Arnaud's code:
surf[BLUE] = surface_create(ctx, NULL, 100, 100, 0, 0, 0xffff);
if (!surf[BLUE])
die(failed to create root surface);
surf[RED] = surface_create(ctx,
On Wed, Jun 17, 2015 at 9:35 AM, Bill Spitzak spit...@gmail.com wrote:
The problem is that the way it works is *not* a tree, but some kind of
list.
As described the following code:
wl_subsurface_place_below(RED-subsurface, GREEN-surface);
wl_subsurface_place_below(GREEN-subsurface, BLUE
The problem is that the way it works is *not* a tree, but some kind of list.
As described the following code:
wl_subsurface_place_below(RED-subsurface, GREEN-surface);
wl_subsurface_place_below(GREEN-subsurface, BLUE-surface);
Produces the order GREEN, RED, BLUE instead.
However if you
14, 2015 at 5:41 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
please fix your email client to not drop CC's on reply.
On Sat, Jun 13, 2015 at 09:30:35AM -0700, Bill Spitzak wrote:
Can you set the fake resolution so that you get the same answer without
having to check if it is fake
Can you set the fake resolution so that you get the same answer
without having to check if it is fake?
It looks like setting tp-device-abs.absinfo_x/y-resolution to
diagonal * 2 / DEFAULT_HYSTERESIS_MARGIN_DENOMINATOR would avoid the if
statement, and I would probably make everything that
On Thu, Jun 11, 2015 at 3:40 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
On Thu, Jun 11, 2015 at 02:37:38PM -0700, Bill Spitzak wrote:
Do you actually need 64 bits or are you just trying to get more than 8
bits
of fraction?
If instead other fixed types were provided, such as 1.30
Do you actually need 64 bits or are you just trying to get more than 8 bits
of fraction?
If instead other fixed types were provided, such as 1.30 or 7.24, etc could
that be used? This could be covered by the existing fixed type by just
defining the argument as being the desired value multiplied
I think everybody is waiting for an explanation as to why one of the
clients cannot choose the action, and instead the compositor does it.
You are defining a function f(S,D,M) that takes three inputs and returns a
selected action. The three inputs are the set of actions from the source
(S), the
Despite the impression you may get from the API, the compositor is able
(and required to implement many designs) to decode keyboard events into
keysyms, using exactly the same xkb code clients would use and thus
arriving at the same answer.
Therefore if there was a key-grab api to the
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.
On 05/25/2015 06:19 AM, nerdopolis wrote:
background-bpp, 16);
+ /* TODO After Weston 1.8, change default to 32 bit bpp on the
wallpaper*/
+ if (background-low_bpp != 32) {
+ window_set_preferred_format(background-window,
+
It can use wayland-0 if $DISPLAY is not set. So the rules programs that
can use both Wayland and X11 but prefer Wayland could be:
Use $WAYLAND_DISPLAY if set
Use $DISPLAY if set
Use wayland-0
On 05/25/2015 01:12 AM, Dima Ryazanov wrote:
Although defaulting to wayland-0 seems convenient, it
On 05/22/2015 12:40 AM, Pekka Paalanen wrote:
On Thu, 21 May 2015 19:20:57 -0700
Bill Spitzak spit...@gmail.com wrote:
This seems like a good idea for consistency as the client and server
protocol should not be treated differently than others. This means the
code will compile even
This seems like a good idea for consistency that the protocol header
is included for any protocols used by the code. This also means the
code will compile with headers generated by wayland-scanner -c.
Fixed to use angle brackets.
---
clients/ivi-shell-user-interface.c |1 +
, Bill Spitzak wrote:
This seems like a good idea for consistency that the protocol header
is included for any protocols used by the code. This also means the
code will compile with headers generated by wayland-scanner -c.
Fixed to use angle brackets.
---
clients/ivi-shell-user-interface.c |1
This seems like a good idea for consistency as the client and server
protocol should not be treated differently than others. This means the
code will compile even if the protocol headers are generated with the
core only (-c) switch.
---
clients/ivi-shell-user-interface.c |1 +
That name is pretty confusing and not what anybody would guess. It
certainly should start with background- so that it matches all the
other switches that control the desktop image.
The fact that it does not always work does NOT have to be part of the name.
Some ideas I prefer:
Please don't duplicate the functions in multiple headers!
You could achieve the same result this way so that there is only one
copy of each function in the headers:
wayland-client-protocol-core.h =
(the same as you have it, generated by wayland-scanner -c)
wayland-client-protocol.h =
On 05/14/2015 07:53 PM, Jonas Ådahl wrote:
but your notes were very misleading.
What notes?
The statement Serials are dropped that was in your header email is the
one that really threw me.
The primary problem I am having is all your description seems to be for
setting up something
I think you sent the wrong patch here
On 05/13/2015 07:19 PM, nerdopolis wrote:
Resolving https://bugs.freedesktop.org/show_bug.cgi?id=73782
udev might be configured to set the permissions on framebuffer devices with the
UACCESS attribute.
Weston currently attempts to reconnect to the
Again this seems excessively complicated, requires lots of communication
long before the lock happens, makes the methods used to trigger the lock
very limited and dependent on compositor features, and it does not look
like it is possible to avoid an unwanted blink in the cursor.
- Client must
On 05/11/2015 06:57 AM, Pekka Paalanen wrote:
How about calling it get_fallback_format_for()?
I think get_ implies that the result depends on something other than
the arguments. For instance the sin of an angle is a function called
sin(x), not get_sin(x). While looking up an environment
On 05/07/2015 06:15 PM, Bryce Harrington wrote:
Extra call to strcpy here:
wl-tty = open(tty, O_RDWR | O_NOCTTY);
+ strcpy(wl-tty_path, tty);
+ if (snprintf(wl-tty_path, PATH_MAX, %s, tty) =
PATH_MAX)
+
On 05/06/2015 09:24 AM, Derek Foreman wrote:
On 05/05/15 03:59 PM, Bill Spitzak wrote:
It sure seems like it would be better to just provide the list of
available keys to the client programs, and let them make up their own
categories of device types.
I think desktop-shell is still going
It sure seems like it would be better to just provide the list of
available keys to the client programs, and let them make up their own
categories of device types.
I'm not sure if requiring every Latin letter is a good test for a
keyboard either. Aren't there some foreign layouts that omit
On 05/01/2015 03:23 PM, Peter Hutterer wrote:
On 2/05/2015 04:21 , Bill Spitzak wrote:
Are you saying the first event is delayed until it knows whether it is
double-tap or not? That is not going to work, it will introduce a huge
annoying latency to interaction.
I suspect I am
On 04/30/2015 11:03 AM, Giulio Camuffo wrote:
Functionally the initial patch and the latest ones are exactly the
same, so not sure what you're talking about
No they are not. The original patch and my proposal has
*-client-protocol.h file including wayland-client-core.h. The latest one
On 04/30/2015 04:49 AM, Pekka Paalanen wrote:
But we have no reason to push people away from the old headers. Those
who need the new headers know already that the old ones are awkward.
Those who don't need the new headers are welcome to keep using the old
ones. That's why we're not adding a
On 04/30/2015 03:33 AM, Pekka Paalanen wrote:
On Wed, 29 Apr 2015 09:17:33 -0700
Bill Spitzak spit...@gmail.com wrote:
On 04/29/2015 03:10 AM, Pekka Paalanen wrote:
Weston had a good reason to not use getopt() I believe: each module
parses its own arguments in turn, so command line options
On 04/30/2015 03:34 AM, Pekka Paalanen wrote:
Just to be clear, my proposal is:
wayland-client.h : hand-written, includes:
wayland-client-core.h
wayland-client-protocol.h
deprecated api
wayland-client-core.h : hand-written, includes
wl_event_queue,
On 04/30/2015 11:08 AM, Giulio Camuffo wrote:
I think you're just not getting the goal of the patches here. The goal
is basically to be able to *not include* indirectly
wayland-client-protocol.h, not to clean up the circular includes or
whatever. Whoever includes directly
On 04/29/2015 09:18 AM, Giulio Camuffo wrote:
You commented it out from the wrong file. Comment it in iirc
desktop-shell-client-protocol.h instead, or some other file generated
from a protocol in weston.
Okay I did this in weston:
make clean
make
Forcing --include-core-only on in wayland-scanner, the attached patch
makes Weston compile. This involved adding two wayland-client-protocol.h
includes.
IMHO it is better to require this small bit of editing than to continue
to include a header with the comment Use of this header file is
On 04/27/2015 01:06 PM, Giulio Camuffo wrote:
2015-04-27 21:53 GMT+03:00 Bill Spitzak spit...@gmail.com:
On 04/26/2015 11:48 PM, Marek Chalupa wrote:
Is the --include-core-headers option necessary? Until now the scanner
included wayland-client/server.h
which included the %-protocol.h
(though it is ok if you don't get the unaccelerated
ones until you turn on grab and it then replays any missing ones since
the grabbing event.
On Sat, Apr 25, 2015 at 5:06 AM, Bill Spitzak spit...@gmail.com wrote:
That is not sufficient as the application may want to put much more complex
On 04/26/2015 11:48 PM, Marek Chalupa wrote:
Is the --include-core-headers option necessary? Until now the scanner
included wayland-client/server.h
which included the %-protocol.h, but since there are inclusion guards,
the protocol header was not
included again - so including
On 04/26/2015 09:01 PM, Peter Hutterer wrote:
I've been ping-ponging between giving deltas or an absolute distance
in mm. I can change the patch-set to report a distance in mm instead
of delta from the previous distance, with the caveat that on some
touchpads we do not know the resolution so
On 04/27/2015 12:05 AM, Pekka Paalanen wrote:
- From the first definition of an interface, specify how unknown values
should be handled. Otherwise users do not expect unknown values to
appear.
The latter case is where you do not want an automatic always-on warning
or error.
This is no
Since all the codegen packages that want to use this enum attribute have
not been written yet I don't think back-compatibility is an issue. They
are not using uint because they do not exist yet!
The C codegen can continue to ignore the enum, or use it in a way that
does not break code that
That is not sufficient as the application may want to put much more
complex rules on how the pointer moves (such as limiting it to a rectangle).
As a practical matter the applications that want a slow scrollbar want
*exactly* the same acceleration as before, just that the resulting
position
On 04/24/2015 02:22 AM, Pekka Paalanen wrote:
If you have the compositor in charge of moving the cursor, and the app
in charge of scrolling and drawing the contents, you would get a lag
between the cursor moving and the content/scrollbar moving. Granted,
this is probably a minor issue and can
On 04/22/2015 11:49 PM, Pekka Paalanen wrote:
Allowing fully qualified names is another thing. Should we allow it? Is
it good practice? Is it useful? How would the fully qualitified names
look like?
Even if it's not used for codegen, you need it for docgen if you want
to be able to reference
I think there may be some confusion about how this would be used by a
language binding, and why bitmap is necessary, and also why it has to be
on the enumeration.
Imagine an interface called Widget, and it has two methods
set_type(Type) and set_flags(Flags). set_type takes an enumeration
On 04/23/2015 11:28 AM, Jeroen Bollen wrote:
Using enum=interfacename.enumname would probably work. The
interfacename. is optional if you are describing a method on the same
interface. Another possibility is to just add interface=interfacename
to the argument along with enum=enumname.
I think this looks like the correct patch.
Only correction is that I would put the enum right after the type=int
consistently. Some of your cases you put the summary between them.
On 04/19/2015 01:30 PM, Auke Booij wrote:
On 19 April 2015 at 14:51, Jeroen Bollen jbin...@gmail.com wrote:
---
doc/publican/protocol-to-docbook.xsl | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/doc/publican/protocol-to-docbook.xsl
b/doc/publican/protocol-to-docbook.xsl
index 7b45969..3c4e140 100644
--- a/doc/publican/protocol-to-docbook.xsl
+++
This improvement to the protocol allows you to refer to the kind of enum you
are expecting.
It also introduces a distinction between enums that are bitfields, ie
that can be OR'ed together.
---
protocol/wayland.dtd |2 ++
protocol/wayland.xml | 32
2 files
This is based on (and includes unchanged) Auke Booij's patch to protocol.xml
to add enum type information. This ignores whether an enumeration is a bitmap,
but that seems to be clear from the summary text.
___
wayland-devel mailing list
, will wayland
still get the mouse position such that it can revoke access when the
cursor moves out of the window?
On 04/20/2015 06:14 PM, x414e54 wrote:
2015/04/21 5:42 Bill Spitzak spit...@gmail.com
mailto:spit...@gmail.com:
On 04/18/2015 03:20 AM, Hans de Goede wrote:
This has been discussed
On 04/18/2015 03:20 AM, Hans de Goede wrote:
This has been discussed before, and as mentioned before I really
believe that we should not define a joystick API at all,
rather we should define an API which will allow an app to:
1) List devices which it can get raw access to
2) Request raw
Even the patches I did to the automatic documentation generation would
benefit greatly from this. There could be a clickable link from the
argument to the enumeration, or (with a good deal more work) it could
detect enums that are used only once and place them right there under
the arg.
And
On 04/18/2015 07:53 AM, Carlos Garnacho wrote:
Let me try to correct this by removing some unnecessary data. In
particular no list of actions is sent by the destination. Also there is
no need for the compositor to echo the selected action back to the
destination. More importantly I have added
On 04/20/2015 04:05 AM, Carlos Garnacho wrote:
- The last touch drags the window, the previous ones remain static and
are eventually lifted. Why do they apply where your finger no longer
is? Why do they apply at all? can one of these touches create an
xdg_popup (and another grab on another
On 04/16/2015 07:51 PM, x414e54 wrote:
Hi,
I am wondering if there has been any recent progress on the stability of
the Wayland relative pointer API?
I had a few ideas on the original December implementation:
Whilst we definitely need the relative event support, I feel that the
client
On 04/17/2015 05:16 AM, Carlos Garnacho wrote:
Let's expand on that example, maybe far-streched, but certainly possible:
- I'm manipulating a client window with 2 fingers on the touchscreen
(say zooming an image)
- Any other interaction on the client makes it pop up an xdg_popup
(say a third
On 04/16/2015 03:55 AM, Carlos Garnacho wrote:
In gtk+/gnome we currently have the following keybindings active during DnD:
- Cursor keys move the drag point, modifiers affect speed
- Esc key cancels drag
- Modifiers alone pick an action from the offered list
The user has to hold the mouse
On 04/14/2015 09:01 PM, Peter Hutterer wrote:
Internal touchpads with trackpoints are either BUS_I8042 or BUS_I2C, but not
BUS_USB. Lenovo sells external keyboards with a trackpoint built-in, make sure
we don't pair that trackpoint with the internal touchpad.
And likewise, the internal
Is this being done for physical mice with two buttons? The comments seem
to indicate not, which seems kind of pointless: if a client has to
emulate it for a physical mouse it will be emulating it for touchpads as
well.
Delaying a press to see if it is a middle click is also probably
On 04/15/2015 02:46 PM, Peter Hutterer wrote:
On Wed, Apr 15, 2015 at 07:32:01AM -0700, Bill Spitzak wrote:
Is this being done for physical mice with two buttons? The comments seem to
indicate not, which seems kind of pointless: if a client has to emulate it
for a physical mouse
On 04/15/2015 03:51 PM, Carsten Haitzler (The Rasterman) wrote:
i was thinking a simplified geometry. then again client toolkits can figure
that out and present a simplified enum or what not to the app too. but yes -
some enumerated type attached to the output would be very nice. smarter
Lots of applications take a long time before they can generate the
initial window image, so they show a splash screen so the user knows
the application started. They are also often required to display
legally-required information (branding, copyright, etc) without
cluttering the main window
On 04/12/2015 11:51 PM, Pekka Paalanen wrote:
I know! We use an arbitrary leave/enter pair to signal pointer location
changes to clients when there is no physical input. That is, the
pointer device doesn't move, but the surface or view moves. We cannot
fake a wl_pointer.motion event, because
On 04/10/2015 02:29 AM, Carlos Garnacho wrote:
However the
compositor could send state along with A to the dest.
This could also work,
Thanks I think I finally made it clear what I am asking for.
So intersection is now f(A,B,state), and what I propose is:
source sends A to compositor
On 04/10/2015 06:45 AM, Marek Chalupa wrote:
When an object asks for creating new object from inert object,
wayland will silently create zombie object without invoking
appropriate handler, so once programmer marks resource as inert,
wayland will take care of the rest.
I think you should use
Will these windows then unmap atomically?
I actually expected the opposite to be allowed and encouraged, as
destroying a parent surface could then guarantee the children disappear
atomically.
On 04/07/2015 05:25 PM, Bryce Harrington wrote:
On Tue, Apr 07, 2015 at 05:01:17PM +0800, Jonas
I think the compositor is allowed to choose a color other than black, right?
On 04/07/2015 07:52 PM, Bryce Harrington wrote:
+If the surface doesn't cover the whole output, the compositor will
+position the surface in the center of the output and compensate with
+black
On 04/08/2015 12:15 AM, Pekka Paalanen wrote:
+ dot_version=`$DOT -V 21|$GREP -o ['[0-9]*\.[0-9]*\.[0-9]*']`
AS_VERSION_COMPARE([$dot_version], [2.26.0],
[AC_MSG_RESULT([no])
AC_MSG_ERROR([Graphviz dot $dot_version too old.
On 04/07/2015 05:03 PM, Bryce Harrington wrote:
I'm sure this is not going to ever be a problem since tty filenames and
paths are on the short side, but since the tty string is an input
parameter to this routine, it would be better defensive programming to
use strncpy.
strncpy is not a fix
On 04/08/2015 02:35 PM, Daniel Stone wrote:
The best solution is to use strlcpy.
If politics make that impossible, use snprintf(dest, len, %s, src)
which is exactly the same as strlcpy, including the return value!
(imagine that...)
It's not the politics, it's that silently
On 04/08/2015 07:46 AM, Carlos Garnacho wrote:
I may be missing something. As far as I can tell your proposal is that
the source and destination send sets of actions to the compositor, the
compositor then intersects the sets, and sends the result of the
intersection to the source and
On 04/07/2015 10:12 AM, Derek Foreman wrote:
- window = hash_table_lookup(wm-window_hash, leave-event);
+ hash_table_lookup(wm-window_hash, leave-event, window);
if (!window || !window-decorate)
return;
Shouldn't all of these patches use the return value,
Oh ok I see you put this in a different patch. I think the patches
should be merged since you have to change all the calls in the first
patch anyway.
I don't like the temporary variable, it seems like you can just put the
call to hash_table_lookup in the if statement and it will be clearer.
Should you remove the unused time argument?
On 04/02/2015 07:14 AM, Derek Foreman wrote:
Makes sense, fixes the problem for me.
Reviewed-by: Derek Foreman der...@osg.samsung.com
On 02/04/15 08:54 AM, Pekka Paalanen wrote:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
Weston running
I can't get either of those to work, but how about this:
dot_version=`$DOT -V 21 | $GREP -o '[0-9]*\.[0-9]*\.[0-9]*'`
That seems to produce 2.26.3 on my machine.
On 03/31/2015 09:17 AM, hector.o...@gmail.com wrote:
From: Hector Oron hector.o...@collabora.co.uk
Hello,
configure uses grep
201 - 300 of 1326 matches
Mail list logo
