Re: [PATCH v3 1/2] config: verify that the config file is not null
Disregard this patch, I sent in another that should handle better the
config file issues.
Alex
On Wed, Sep 25, 2013 at 11:23 PM, Damian, Alexandru
alexandru.dam...@intel.com wrote:
The nice thing was that even if some other code besides the _log tries to
read the file path, that code can expect to open the path and read from it
just fine, instead of receiving a NULL and maybe crashing.
I'm gonna check tomorrow if this happens somewhere else in the code, and
if not, modify _full_path to return NULL and change the log message.
On Wed, Sep 25, 2013 at 9:43 PM, Kristian Høgsberg k...@bitplanet.netwrote:
On Wed, Sep 25, 2013 at 11:07 AM, Alex DAMIAN
alexandru.dam...@intel.com wrote:
From: Alexandru DAMIAN alexandru.dam...@intel.com
weston_config_parse may return NULL,
leading to an ungraceful exit via SIGSEGV if we
try to reference the structure.
Adding a check in weston_config_full_path so that
we return the empty file /dev/null as filename
if we started without a config file.
I think it's ok for weston_config_get_full_path() to crash if passed a
NULL pointer. Returning /dev/null or anything else is a little odd.
Maybe returning NULL would be ok, but I think we can just have an if
statement and log No config file found if config is NULL, and log
the file name if we did get a config.
Kristian
Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
---
shared/config-parser.c | 2 +-
src/compositor.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/shared/config-parser.c b/shared/config-parser.c
index e1bf212..ef5c5b9 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -385,7 +385,7 @@ weston_config_parse(const char *name)
const char *
weston_config_get_full_path(struct weston_config *config)
{
- return config-path;
+ return config == NULL ? /dev/null : config-path;
}
int
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Alex Damian
Yocto Project
SSG / OTC
--
Alex Damian
Yocto Project
SSG / OTC
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] How to distinguish left-shift and right-shift
2013/9/25 Ran Benita ran...@gmail.com: On Tue, Sep 24, 2013 at 08:02:30PM -0300, Wander Lairson Costa wrote: Hi, Hi, I am working for some time porting Blender to wayland [1] and I am now adding keyboard handing support. For that, I am following weston clients code as reference and using libxkbcommon. To make a long history short, I need to differentiate left-shift and right-shift modifiers, but I didn't figure out how to do that with libxkbcommon. I printed all modifiers names and there is just one Shift modifier, there aren't LShift and RShift like there are for control and alt key modifiers. I'm afraid we have no way to do that. We currently only expose the 8 old X11 modifiers, which only have Shift. There are also what's called virtual modifiers, which I have some pending work to expose, but these *too* don't have separate RShift and LShift modifiers (as opposed to e.g. LControl and RControl) - that's in current xkeyboard-config, which is the project where all the keyboard data is maintained. And there was some sensible resistence to addings these, for example here: https://bugs.freedesktop.org/show_bug.cgi?id=50935#c18 Of course, X11/XKB is in exactly the same boat here, so I from a quick look I found that what the blender X11 backend does (as far as I can see), is that it gets the key state with the XQueryKeymap(3) request, and then sees if the left/right *keys* are down. That's not entirely correct purely speaking, but I guess it works in 99.% percent of the cases. So I can only suggest you do the same for now for Wayland. But... xkbcommon doesn't (and prefereably won't) expose an equivalent of XQueryKeymap itself, and the Wayland protocol only provides it on the wl_keyboard enter event (with the 'keys' field). So unfortunatly what you have do is get/reset this array on wl_keyboard enter event, and keep it updated manually on the client side on key events. That should work... Unless someone has a better idea! Initially I thought to handle this in the key event (maybe only for shift key). I just don't which would be the best solution... Sorry! Ran [1] https://github.com/walac/blender-wayland -- Best Regards, Wander Lairson Costa ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Best Regards, Wander Lairson Costa ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] Make C++ happy.
On Thu, Sep 26, 2013 at 09:35:33AM -0300, Wander Lairson Costa wrote:
For most functions taking an enum flags parameter, we use 0 value to
indicate that no flags should be applied.
C++ has a stronger type system than C and will not implicitly convert
int's to enum's. Thus, we create valid 0 enum values for enum types
where it makes sense.
Thanks!
I just made a few changes (see below) and applied; I hope you don't
mind.
Signed-off-by: Wander Lairson Costa wander.lair...@gmail.com
---
xkbcommon/xkbcommon.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/xkbcommon/xkbcommon.h b/xkbcommon/xkbcommon.h
index 1480b1b..4627cea 100644
--- a/xkbcommon/xkbcommon.h
+++ b/xkbcommon/xkbcommon.h
@@ -360,6 +360,8 @@ xkb_keysym_get_name(xkb_keysym_t keysym, char *buffer,
size_t size);
/** Flags for xkb_keysym_from_name(). */
enum xkb_keysym_flags {
+/** Do not apply any flag. */
+XKB_KEYSYM_NO_FLAG = 0,
FLAG - FLAGS
/** Find keysym by case-insensitive search. */
XKB_KEYSYM_CASE_INSENSITIVE = (1 0)
};
@@ -425,6 +427,8 @@ xkb_keysym_to_utf32(xkb_keysym_t keysym);
/** Flags for context creation. */
enum xkb_context_flags {
+/** Do not apply any context flag. */
+XKB_CONTEXT_NO_FLAG = 0,
FLAG - FLAGS
/** Create this context with an empty include path. */
XKB_CONTEXT_NO_DEFAULT_INCLUDES = (1 0),
/** Don't take RMLVO names from the environment. */
@@ -577,6 +581,7 @@ xkb_context_include_path_get(struct xkb_context *context,
unsigned int index);
/** Specifies a logging level. */
enum xkb_log_level {
+XKB_LOG_LEVEL_NO_LOG = 0,/** No log. */
This one's not needed, you can't pass/get that.
XKB_LOG_LEVEL_CRITICAL = 10, /** Log critical internal errors only. */
XKB_LOG_LEVEL_ERROR = 20,/** Log all errors. */
XKB_LOG_LEVEL_WARNING = 30, /** Log warnings and errors. */
@@ -676,6 +681,8 @@ xkb_context_set_log_fn(struct xkb_context *context,
/** Flags for keymap compilation. */
enum xkb_keymap_compile_flags {
+/** Do not apply any flag. */
+XKB_MAP_COMPILE_NO_FLAG = 0,
FLAG - FLAGS
/** Apparently you can't have empty enums. What a drag. */
XKB_MAP_COMPILE_PLACEHOLDER = 0
};
@@ -708,6 +715,8 @@ xkb_keymap_new_from_names(struct xkb_context *context,
/** The possible keymap formats. */
enum xkb_keymap_format {
+/** No format. */
+XKB_KEYMAP_FORMAT_NONE = 0,
This one's not needed, you can't pass/get that.
Ran
/** The current/classic XKB text format, as generated by xkbcomp -xkb. */
XKB_KEYMAP_FORMAT_TEXT_V1 = 1
};
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] How to distinguish left-shift and right-shift
On Thu, Sep 26, 2013 at 08:49:24AM -0300, Wander Lairson Costa wrote: 2013/9/25 Ran Benita ran...@gmail.com: On Tue, Sep 24, 2013 at 08:02:30PM -0300, Wander Lairson Costa wrote: Hi, Hi, I am working for some time porting Blender to wayland [1] and I am now adding keyboard handing support. For that, I am following weston clients code as reference and using libxkbcommon. To make a long history short, I need to differentiate left-shift and right-shift modifiers, but I didn't figure out how to do that with libxkbcommon. I printed all modifiers names and there is just one Shift modifier, there aren't LShift and RShift like there are for control and alt key modifiers. I'm afraid we have no way to do that. We currently only expose the 8 old X11 modifiers, which only have Shift. There are also what's called virtual modifiers, which I have some pending work to expose, but these *too* don't have separate RShift and LShift modifiers (as opposed to e.g. LControl and RControl) - that's in current xkeyboard-config, which is the project where all the keyboard data is maintained. And there was some sensible resistence to addings these, for example here: https://bugs.freedesktop.org/show_bug.cgi?id=50935#c18 Of course, X11/XKB is in exactly the same boat here, so I from a quick look I found that what the blender X11 backend does (as far as I can see), is that it gets the key state with the XQueryKeymap(3) request, and then sees if the left/right *keys* are down. That's not entirely correct purely speaking, but I guess it works in 99.% percent of the cases. So I can only suggest you do the same for now for Wayland. But... xkbcommon doesn't (and prefereably won't) expose an equivalent of XQueryKeymap itself, and the Wayland protocol only provides it on the wl_keyboard enter event (with the 'keys' field). So unfortunatly what you have do is get/reset this array on wl_keyboard enter event, and keep it updated manually on the client side on key events. That should work... Unless someone has a better idea! Initially I thought to handle this in the key event (maybe only for shift key). I just don't which would be the best solution... The information you need, if you want to use the key-down approach (which is the only one I can think of), is whether e.g. the Left Shift key is down at any given moment. This keys-state information is kept on the compositor, but now you need to reconstruct it on the client. The way to do it is as I outlined above, i.e. wl_keyboard.enter event, which gives you a wl_array of all the keys which are pressed + wl_keyboard.key events, which allow you to keep this array in sync. (Though by a quick look at the Weston code, it might be that it sends key-down events for all the keys which are down when the focus is changed, that is, it replays what happened to get to the current state. So maybe you don't need the information in the wl_keyboard.enter after all, only the key events with an initial empty array. It should be easy to check which way is it). Ran Sorry! Ran [1] https://github.com/walac/blender-wayland -- Best Regards, Wander Lairson Costa ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Best Regards, Wander Lairson Costa ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: idle tasks starving in toytoolkit
One idea to fix this might be to make dispatch_queue only ever
dispatch the events that were current when the loop is started. That
way if any further events are added while processing the current
events it will give control back to the main loop before processing
them.
Here's a not-heavily-tested patch that would do that.
Regards,
- Neil
--- 8 --- (use git am --scissors to automatically chop here)
Subject: [PATCH] client: Don't dispatch events that are added while dispatching
Previously wl_display_dispatch_queue would keep dispatching events
until the event queue becomes empty. If more events are queued while
dispatching those events the loop can run indefinitely. This patch
changes it so that instead of iterating the list of events directly in
the queue it steals the list of events before dispatching and iterates
the local list instead. That way it will only iterate the events that
were current before the loop started and if further events are added
the application will drop back to the main loop before processing
them.
---
src/wayland-client.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index a20a71e..ae00ef0 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -918,16 +918,12 @@ decrease_closure_args_refcount(struct wl_closure *closure)
}
static void
-dispatch_event(struct wl_display *display, struct wl_event_queue *queue)
+dispatch_event(struct wl_display *display, struct wl_closure *closure)
{
- struct wl_closure *closure;
struct wl_proxy *proxy;
int opcode;
bool proxy_destroyed;
- closure = container_of(queue-event_list.next,
- struct wl_closure, link);
- wl_list_remove(closure-link);
opcode = closure-opcode;
/* Verify that the receiving object is still valid by checking if has
@@ -1049,19 +1045,36 @@ wl_display_read_events(struct wl_display *display)
static int
dispatch_queue(struct wl_display *display, struct wl_event_queue *queue)
{
- int count;
+ struct wl_closure *closure, *tmp;
+ struct wl_list event_list;
+ int count = 0;
if (display-last_error)
goto err;
- for (count = 0; !wl_list_empty(queue-event_list); count++) {
- dispatch_event(display, queue);
+ /* Steal the list of events from the queue so that if more
+* events are added while dispatching the current ones we
+* won't get stuck in this loop indefinitely */
+ wl_list_init(event_list);
+ wl_list_insert_list(event_list, queue-event_list);
+ wl_list_init(queue-event_list);
+
+ wl_list_for_each_safe(closure, tmp, event_list, link) {
+ wl_list_remove(closure-link);
+ count++;
+
+ dispatch_event(display, closure);
+
if (display-last_error)
- goto err;
+ goto err_queue;
}
return count;
+err_queue:
+ /* Put any remaining events back in the queue */
+ wl_list_insert_list(queue-event_list, event_list);
+
err:
errno = display-last_error;
--
1.8.3.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] compositor-fbdev: drop dependency on libdrm
From: Adrian Negreanu adrian.m.negre...@intel.com Signed-off-by: Adrian Negreanu adrian.m.negre...@intel.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 7c2da44..a43bf5b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,7 +190,7 @@ AM_CONDITIONAL([ENABLE_FBDEV_COMPOSITOR], [test x$enable_fbdev_compositor = xyes]) AS_IF([test x$enable_fbdev_compositor = xyes], [ AC_DEFINE([BUILD_FBDEV_COMPOSITOR], [1], [Build the fbdev compositor]) - PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev = 136 mtdev = 1.1.0 libdrm = 2.4.30]) + PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev = 136 mtdev = 1.1.0]) ]) AC_ARG_ENABLE([rdp-compositor], [ --enable-rdp-compositor],, -- 1.8.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] How to distinguish left-shift and right-shift
2013/9/26 Ran Benita ran...@gmail.com: [snip] The information you need, if you want to use the key-down approach (which is the only one I can think of), is whether e.g. the Left Shift key is down at any given moment. This keys-state information is kept on the compositor, but now you need to reconstruct it on the client. The way to do it is as I outlined above, i.e. wl_keyboard.enter event, which gives you a wl_array of all the keys which are pressed + wl_keyboard.key events, which allow you to keep this array in sync. This is what I was thinking about. (Though by a quick look at the Weston code, it might be that it sends key-down events for all the keys which are down when the focus is changed, that is, it replays what happened to get to the current state. So maybe you don't need the information in the wl_keyboard.enter after all, only the key events with an initial empty array. It should be easy to check which way is it). But this is an weston implementation detail, I guess, other compositors may not have the same behavior. -- Best Regards, Wander Lairson Costa ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] Make C++ happy.
Wander Lairson Costa wrote:
/** Flags for keymap compilation. */
enum xkb_keymap_compile_flags {
+/** Do not apply any flag. */
+XKB_MAP_COMPILE_NO_FLAG = 0,
/** Apparently you can't have empty enums. What a drag. */
XKB_MAP_COMPILE_PLACEHOLDER = 0
};
I think you can remove the PLACEHOLDER
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 3/3 wayland-fits] core: Add a test for multiple pointer and keyboard resources
Series applied. The client keyboard stuff is something I've been
wanting to add for a while. Thanks Neil! I like more tests :-)
U. Artie Eoff
-Original Message-
From: wayland-devel-bounces+ullysses.a.eoff=intel@lists.freedesktop.org
[mailto:wayland-devel-
bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Neil
Roberts
Sent: Wednesday, September 25, 2013 11:07 AM
To: wayland-devel@lists.freedesktop.org
Subject: [PATCH 3/3 wayland-fits] core: Add a test for multiple pointer and
keyboard resources
This adds a test which creates multiple pointer and keyboard resources
for the same client and verifies that they all receive events. It also
tests various combiniations of pointer and keyboard focus and ensures
that for example a keyboard created while the surface already has
focus will correctly get updated about the state.
---
src/test/core/Makefile.am | 1 +
src/test/core/test_multi_resource.cpp | 259
++
2 files changed, 260 insertions(+)
create mode 100644 src/test/core/test_multi_resource.cpp
diff --git a/src/test/core/Makefile.am b/src/test/core/Makefile.am
index 3a93a67..ec7901b 100644
--- a/src/test/core/Makefile.am
+++ b/src/test/core/Makefile.am
@@ -19,6 +19,7 @@ libwfits_core_la_SOURCES = \
test_bind_interface.cpp \
test_cursor.cpp \
test_data.cpp \
+ test_multi_resource.cpp \
test_surface.cpp\
test_dnd.cpp
diff --git a/src/test/core/test_multi_resource.cpp
b/src/test/core/test_multi_resource.cpp
new file mode 100644
index 000..d3fb003
--- /dev/null
+++ b/src/test/core/test_multi_resource.cpp
@@ -0,0 +1,259 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * 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 harness.h
+#include compositor.h
+#include pointer.h
+#include keyboard.h
+#include seat.h
+#include surface.h
+#include shell.h
+#include shell_surface.h
+#include shm.h
+
+namespace wfits {
+namespace test {
+namespace core {
+namespace input {
+
+class DummyClient
+{
+public:
+ DummyClient()
+ : display_()
+ , compositor_(display_)
+ , shell_(display_)
+ , seat_(display_)
+ , surface_(compositor_)
+ , shellSurface_(shell_, surface_)
+ , shm_(display_)
+ , buffer_(shm_, 128, 128)
+ {
+ wl_surface_attach(surface_, buffer_, 0, 0);
+ wl_surface_damage(surface_, 0, 0,
+ buffer_.width(), buffer_.height());
+ surface_.commit();
+ }
+
+private:
+ Display display_;
+ Compositor compositor_;
+ Shell shell_;
+ Seat seat_;
+ Surface surface_;
+ ShellSurface shellSurface_;
+ SharedMemory shm_;
+ SharedMemoryBuffer buffer_;
+};
+
+class MultiResourceTest : public Harness
+{
+public:
+ MultiResourceTest()
+ : Harness::Harness()
+ , compositor_(display())
+ , shell_(display())
+ , seat_(display())
+ , surface_(compositor_)
+ , shellSurface_(shell_, surface_)
+ , shm_(display())
+ , buffer_(shm_, 128, 128)
+ {
+ }
+
+ void setup();
+ void testPointer();
+ void testKeyboard();
+
+ void movePointer(const int32_t x, const int32_t y)
+ {
+ Geometry geometry(getSurfaceGeometry(surface_));
+ setGlobalPointerPosition(geometry.x + x, geometry.y + y);
+ }
+
+ void checkPointer(Pointer *pointer, const int32_t x, const int32_t y)
+ {
+ YIELD_UNTIL(pointer-x() == x and pointer-y() == y);
+ }
+
RE: [PATCH wfits v2] core: Add a wrapper for the keyboard
-Original Message-
From: wayland-devel-bounces+ullysses.a.eoff=intel@lists.freedesktop.org
[mailto:wayland-devel-
bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Neil
Roberts
Sent: Wednesday, September 25, 2013 4:33 PM
To: wayland-devel@lists.freedesktop.org
Subject: [PATCH wfits v2] core: Add a wrapper for the keyboard
Ok, here's a second version of the patch with all of the suggested changes.
So we must only want one xkb context per display. Ok.
Yes, I think we only really want one global xkb context but the
display seemed like a convenient place to attach it and ensure that it
will be destructed.
We should explicitly initialize keys_ here with some default:
Ok
I prefer to always use brackets in all control structures even
if there is only one statement.
Ok. I also changed places where I was using brace hugging because I
had just assumed you were using the Wayland/Linux style.
I don't mind brace hugging. I'm not fully familiar with the
Wayland/Linux style yet; is there a document for it? Either way, it's
probably best if I add a coding style document to this project. I
use the style that I've always been taught... but of course I can't
expect everyone to know what that is ;). I'll try not to be too
critical or picky about style until I get it documented.
But, instead of iterating here why not use std::find(...):
Ok, I changed it to use std::find().
That seems nicer ;)
How about:
if (not keyPressed(key))
{
keys_.push_back(key);
}
Sure.
This is an odd way to remove the key from the vector, and was a bit
hard to understand initially, but I suppose it's faster than
keys_.erase(...).
Yeah, I copied this trick from Weston because I thought it was quite
neat. But in this case I guess there's absolutely no point in
optimising it so let's just use vector::erase() to make it more
readable.
Cool, yeh optimization is not critical here.
Probably prefer const function here:
bool hasFocus(wl_surface*) const;
Ok. You might want to fix the one in pointer.cpp too in that case.
Fair enough, I'll fix that. I'm sure there's likely other places where
const corrections need to be done too.
I'd prefer to see all class scoped typedefs at the top of the class
declaration, just before the public keyword (which effectively
keeps them private by default). Also, for simplicity, we should
typedef the vector, too:
Ok. I've added a typedef for the vector and moved it to the top. I've
removed the iterator types because once you have the typedef for the
vector then typing Keys::iterator doesn't seem such a pain.
Yeh that's not so bad.
Regards,
- Neil
Thanks Neil! I'll get these patches merged.
--- 8 --- (use git am --scissors to automatically chop here)
This adds a wrapper for a wl_keyboard in a similar way to the pointer
wrapper. It keeps track of the keys that are pressed so that they can
be quickly verified. wayland-fits now depends on libxkbcommon so that
the keyboard wrapper can pass the keymap to it and get the modifier
indices.
---
configure.ac | 2 +
src/test/Makefile.am | 2 +
src/test/core/Makefile.am | 3 +
src/test/core/display.cpp | 16
src/test/core/display.h| 3 +
src/test/core/keyboard.cpp | 216
+
src/test/core/keyboard.h | 106 ++
src/test/efl/Makefile.am | 2 +
src/test/gtk+/Makefile.am | 2 +
9 files changed, 352 insertions(+)
create mode 100644 src/test/core/keyboard.cpp
create mode 100644 src/test/core/keyboard.h
diff --git a/configure.ac b/configure.ac
index de84adf..5ad59ca 100644
--- a/configure.ac
+++ b/configure.ac
@@ -61,6 +61,8 @@ PKG_CHECK_MODULES([WAYLAND],
)
PKG_CHECK_MODULES(WAYLAND_SERVER, [wayland-server = wayland_req_version])
+PKG_CHECK_MODULES([XKBCOMMON], xkbcommon)
+
have_weston=no
want_weston_extensions=auto
AC_ARG_ENABLE([weston-extensions],
diff --git a/src/test/Makefile.am b/src/test/Makefile.am
index ba5e5ce..e50c0fc 100644
--- a/src/test/Makefile.am
+++ b/src/test/Makefile.am
@@ -14,6 +14,7 @@ wfits_SOURCES = \
wfits_LDADD =\
core/libwfits-core.la \
$(CHECK_LIBS) \
+ $(XKBCOMMON_LIBS) \
$(WAYLAND_LIBS) \
$(BOOST_LIBS)
@@ -23,6 +24,7 @@ wfits_LDFLAGS = \
wfits_CPPFLAGS = \
-I$(top_srcdir)/src \
$(CHECK_CFLAGS) \
+ $(XKBCOMMON_CFLAGS) \
$(WAYLAND_CFLAGS) \
$(BOOST_CPPFLAGS)
diff --git a/src/test/core/Makefile.am b/src/test/core/Makefile.am
index bff1c5a..3a93a67 100644
--- a/src/test/core/Makefile.am
+++ b/src/test/core/Makefile.am
@@ -3,6
RE: [PATCH 1/1] config: add command line option for config file
This patch only instructs the main compositor process to use the command-line
specified
configuration file. What about the other things that depend on settings from
the configuration
file: window.c, tablet-shell.c, desktop-shell.c, and terminal.c? Those all load
weston.ini using
the default path resolution and therefore won't be loading the settings from
the command-line
specified configuration file.
Also, I think the default resolution for weston.ini is in ${XDG_CONFIG_HOME}/,
${HOME}/.config/, ${XDG_CONFIG_DIRS}/, and finally ${PWD}/. The help message
in this patch
says it defaults to ${PWD}/ which is deceiving.
-- U. Artie
-Original Message-
From: wayland-devel-bounces+ullysses.a.eoff=intel@lists.freedesktop.org
[mailto:wayland-devel-
bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Alex
DAMIAN
Sent: Thursday, September 26, 2013 2:27 AM
To: wayland-devel@lists.freedesktop.org
Cc: Damian, Alexandru
Subject: [PATCH 1/1] config: add command line option for config file
From: Alexandru DAMIAN alexandru.dam...@intel.com
Added an option to specify the weston.ini config file
to be used. Defaults to ${PWD}/weston.ini
Adding a check in weston_config_full_path so that
we don't crash if we started without a config file.
Fixing a typo in help message.
Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
---
shared/config-parser.c | 2 +-
src/compositor.c | 15 +++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/shared/config-parser.c b/shared/config-parser.c
index e1bf212..8defbbb 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -385,7 +385,7 @@ weston_config_parse(const char *name)
const char *
weston_config_get_full_path(struct weston_config *config)
{
- return config-path;
+ return config == NULL ? NULL : config-path;
}
int
diff --git a/src/compositor.c b/src/compositor.c
index f619f82..c073410 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3338,7 +3338,8 @@ usage(int error_code)
-S, --socket=NAME\tName of socket to listen on\n
-i, --idle-time=SECS\tIdle time in seconds\n
--modules\t\tLoad the comma-separated list of modules\n
- --log==FILE\t\tLog to the given file\n
+ --log=FILE\t\tLog to the given file\n
+ --config=FILE\t\tUse specified config file. Defaults to
./weston.ini\n
-h, --help\t\tThis help message\n\n);
fprintf(stderr,
@@ -3429,6 +3430,7 @@ int main(int argc, char *argv[])
int32_t help = 0;
char *socket_name = wayland-0;
int32_t version = 0;
+ char *config_file = weston.ini;
struct weston_config *config;
struct weston_config_section *section;
@@ -3441,6 +3443,7 @@ int main(int argc, char *argv[])
{ WESTON_OPTION_STRING, log, 0, log },
{ WESTON_OPTION_BOOLEAN, help, 'h', help },
{ WESTON_OPTION_BOOLEAN, version, 0, version },
+ { WESTON_OPTION_STRING, config, 'c', config_file },
};
parse_options(core_options, ARRAY_LENGTH(core_options), argc, argv);
@@ -3488,9 +3491,13 @@ int main(int argc, char *argv[])
backend = WESTON_NATIVE_BACKEND;
}
- config = weston_config_parse(weston.ini);
- weston_log(Using config file '%s'\n,
-weston_config_get_full_path(config));
+ config = weston_config_parse(config_file);
+
+ if (config != NULL) {
+ weston_log(Using config file '%s'\n,
weston_config_get_full_path(config));
+ } else {
+ weston_log(Starting with no config file.);
+ }
section = weston_config_get_section(config, core, NULL, NULL);
weston_config_section_get_string(section, modules, modules, );
--
1.8.1.2
___
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: [xkbcommon] How to distinguish left-shift and right-shift
On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: [snip] The information you need, if you want to use the key-down approach (which is the only one I can think of), is whether e.g. the Left Shift key is down at any given moment. This keys-state information is kept on the compositor, but now you need to reconstruct it on the client. The way to do it is as I outlined above, i.e. wl_keyboard.enter event, which gives you a wl_array of all the keys which are pressed + wl_keyboard.key events, which allow you to keep this array in sync. This is what I was thinking about. (Though by a quick look at the Weston code, it might be that it sends key-down events for all the keys which are down when the focus is changed, that is, it replays what happened to get to the current state. So maybe you don't need the information in the wl_keyboard.enter after all, only the key events with an initial empty array. It should be easy to check which way is it). But this is an weston implementation detail, I guess, other compositors may not have the same behavior. Good point, I can't find it specified either. I think whatever the current behavior is, it should be specified in wayland.xml, so people can rely on it. In some cases, such undefined behavior can be a real hinderance, for example if you want to keep a 'press-count' for a key (there can be cases like two keyboards in the same seat, so *two* Left Shift keys can be down at the same time, etc). And since Wayland will have many compositors, you don't have a de facto standard like X server, and they *will* do it differently, I expect... So if you see what happens exactly, it'd be nice if you open a bug, or post back, or send a patch :) Ran ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
conversion from double to fixed and back fails with certain values
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The value 3568.005 is not correctly converted back from fixed. The following patch to tests/fixed-test.c demonstrates. Is this expected behavior? diff --git a/tests/fixed-test.c b/tests/fixed-test.c index 739a3b1..89ec188 100644 - --- a/tests/fixed-test.c +++ b/tests/fixed-test.c @@ -65,6 +65,11 @@ TEST(fixed_double_conversions) d = wl_fixed_to_double(f); fprintf(stderr, fixed %x to double %lf\n, f, d); assert(d == f / 256); + +d = 3568.005; +f = wl_fixed_from_double(d); +fprintf(stderr, fixed %x to double %lf\n, f, d); +assert(d == wl_fixed_to_double(f)); } TEST(fixed_int_conversions) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSRJuxAAoJEPBh3Rt3H/83HkYH/2w1lrzcCNihoPp3zOrLmxao 8CdSvdIHvgAWvC6mnqJx9bL7W6bqI0LrZHRgCJqKFQcvnyQq9k5k+s2Kh1C87SbQ w8KQ3B4bkRl+m4oM4mxmbeQAlHKi0+mcyu8w6bUG/8OZRvGNvfjqUW2p62MHTKUr W9Uw9cq5A30I11LV13G5enFP1JIzVJqjoVykOJd4sSRX5vdPzr+n14ThSFQ/vu8D MjpZgHvKFZ5LPkCWb0MulQc7LXAqpabJTlMlDZ56HcbqevCZ6sg1AEd6DMdKqvXi lm17vVEOOJL6SLiNruTMEyi1TFi0+B06h972VH8x9RKg1LnhLtHsfu9JjiRdLiQ= =96Vx -END PGP SIGNATURE- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] Make C++ happy.
2013/9/26 Bill Spitzak spit...@gmail.com:
Wander Lairson Costa wrote:
/** Flags for keymap compilation. */
enum xkb_keymap_compile_flags {
+/** Do not apply any flag. */
+XKB_MAP_COMPILE_NO_FLAG = 0,
/** Apparently you can't have empty enums. What a drag. */
XKB_MAP_COMPILE_PLACEHOLDER = 0
};
I think you can remove the PLACEHOLDER
Initially I thought that, but this would break the API, and keeping it
there is not harmful.
--
Best Regards,
Wander Lairson Costa
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] How to distinguish left-shift and right-shift
2013/9/26 Ran Benita ran...@gmail.com: On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: [snip] The information you need, if you want to use the key-down approach (which is the only one I can think of), is whether e.g. the Left Shift key is down at any given moment. This keys-state information is kept on the compositor, but now you need to reconstruct it on the client. The way to do it is as I outlined above, i.e. wl_keyboard.enter event, which gives you a wl_array of all the keys which are pressed + wl_keyboard.key events, which allow you to keep this array in sync. This is what I was thinking about. (Though by a quick look at the Weston code, it might be that it sends key-down events for all the keys which are down when the focus is changed, that is, it replays what happened to get to the current state. So maybe you don't need the information in the wl_keyboard.enter after all, only the key events with an initial empty array. It should be easy to check which way is it). But this is an weston implementation detail, I guess, other compositors may not have the same behavior. Good point, I can't find it specified either. I think whatever the current behavior is, it should be specified in wayland.xml, so people can rely on it. In some cases, such undefined behavior can be a real hinderance, for example if you want to keep a 'press-count' for a key (there can be cases like two keyboards in the same seat, so *two* Left Shift keys can be down at the same time, etc). And since Wayland will have many compositors, you don't have a de facto standard like X server, and they *will* do it differently, I expect... This kind of undefined behavior does not happen only on this case. For example, I have been wondering about window decoration. AFAIK, Wayland leaves to the compositor thr decision if window decoration should be client side or server side. In weston, it is client side, KWin will be server side, how an application would know if it has to decorate its own window or not? (This is a more general question that may deserve its own thread) So if you see what happens exactly, it'd be nice if you open a bug, or post back, or send a patch :) Do you mean about the behavior when we have more than one keyboard attached to a seat? -- Best Regards, Wander Lairson Costa ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [[PATCH v3 2/2]] compositor: check if seteuid worked
On Wed, Sep 25, 2013 at 02:47:47PM +0100, Alex DAMIAN wrote:
From: Alexandru DAMIAN alexandru.dam...@intel.com
Checking the return value from seteuid in
order to not launch clients with the wrong effective uid.
Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
---
src/compositor.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index bc4837f..1a85693 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -247,8 +247,11 @@ child_client_exec(int sockfd, const char *path)
sigfillset(allsigs);
sigprocmask(SIG_UNBLOCK, allsigs, NULL);
- /* Launch clients as the user. */
- seteuid(getuid());
+ /* Launch clients as the user. Do not lauch clients with wrong euid.*/
+ if (seteuid(getuid()) == -1) {
+ weston_log(compositor: failed seteuid\n);
+ return;
+ }
Patch applied. How did you hit this?
Kristian
/* SOCK_CLOEXEC closes both ends, so we dup the fd to get a
* non-CLOEXEC fd to pass through exec. */
--
1.8.1.2
___
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] compositor-fbdev: drop dependency on libdrm
On Thu, Sep 26, 2013 at 07:31:32PM +0300, Adrian Negreanu wrote: From: Adrian Negreanu adrian.m.negre...@intel.com Thanks, applied. Kristian Signed-off-by: Adrian Negreanu adrian.m.negre...@intel.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 7c2da44..a43bf5b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,7 +190,7 @@ AM_CONDITIONAL([ENABLE_FBDEV_COMPOSITOR], [test x$enable_fbdev_compositor = xyes]) AS_IF([test x$enable_fbdev_compositor = xyes], [ AC_DEFINE([BUILD_FBDEV_COMPOSITOR], [1], [Build the fbdev compositor]) - PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev = 136 mtdev = 1.1.0 libdrm = 2.4.30]) + PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev = 136 mtdev = 1.1.0]) ]) AC_ARG_ENABLE([rdp-compositor], [ --enable-rdp-compositor],, -- 1.8.0 ___ 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: [xkbcommon] How to distinguish left-shift and right-shift
On Thu, Sep 26, 2013 at 06:27:39PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: [snip] The information you need, if you want to use the key-down approach (which is the only one I can think of), is whether e.g. the Left Shift key is down at any given moment. This keys-state information is kept on the compositor, but now you need to reconstruct it on the client. The way to do it is as I outlined above, i.e. wl_keyboard.enter event, which gives you a wl_array of all the keys which are pressed + wl_keyboard.key events, which allow you to keep this array in sync. This is what I was thinking about. (Though by a quick look at the Weston code, it might be that it sends key-down events for all the keys which are down when the focus is changed, that is, it replays what happened to get to the current state. So maybe you don't need the information in the wl_keyboard.enter after all, only the key events with an initial empty array. It should be easy to check which way is it). But this is an weston implementation detail, I guess, other compositors may not have the same behavior. Good point, I can't find it specified either. I think whatever the current behavior is, it should be specified in wayland.xml, so people can rely on it. In some cases, such undefined behavior can be a real hinderance, for example if you want to keep a 'press-count' for a key (there can be cases like two keyboards in the same seat, so *two* Left Shift keys can be down at the same time, etc). And since Wayland will have many compositors, you don't have a de facto standard like X server, and they *will* do it differently, I expect... This kind of undefined behavior does not happen only on this case. For example, I have been wondering about window decoration. AFAIK, Wayland leaves to the compositor thr decision if window decoration should be client side or server side. In weston, it is client side, KWin will be server side, how an application would know if it has to decorate its own window or not? (This is a more general question that may deserve its own thread) I'm not a Wayland developer, so I can't say with confidence. But I think this choice is deferred to the toolkit layer. In this case both behaviors (server of client side decorations) are potentially useful, so the protocol shouldn't *require* one or the other. Though I guess for the issue you mentioned, maybe there should be some protocol to tell the client whether it should draw decorations or not. But this is not the case for the key-replay behavior. There's nothing to be gained by letting different compositors do different things in this case. Both behaviors are fine IMO, so should just require whatever Weston does currently. So if you see what happens exactly, it'd be nice if you open a bug, or post back, or send a patch :) Do you mean about the behavior when we have more than one keyboard attached to a seat? No, that should work seamlessly. I meant the replay of the key press events (after you manage to implement your stuff in a real world application like Blender). Ran ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] How to distinguish left-shift and right-shift
2013/9/26 Ran Benita ran...@gmail.com: On Thu, Sep 26, 2013 at 06:27:39PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: [snip] The information you need, if you want to use the key-down approach (which is the only one I can think of), is whether e.g. the Left Shift key is down at any given moment. This keys-state information is kept on the compositor, but now you need to reconstruct it on the client. The way to do it is as I outlined above, i.e. wl_keyboard.enter event, which gives you a wl_array of all the keys which are pressed + wl_keyboard.key events, which allow you to keep this array in sync. This is what I was thinking about. (Though by a quick look at the Weston code, it might be that it sends key-down events for all the keys which are down when the focus is changed, that is, it replays what happened to get to the current state. So maybe you don't need the information in the wl_keyboard.enter after all, only the key events with an initial empty array. It should be easy to check which way is it). But this is an weston implementation detail, I guess, other compositors may not have the same behavior. Good point, I can't find it specified either. I think whatever the current behavior is, it should be specified in wayland.xml, so people can rely on it. In some cases, such undefined behavior can be a real hinderance, for example if you want to keep a 'press-count' for a key (there can be cases like two keyboards in the same seat, so *two* Left Shift keys can be down at the same time, etc). And since Wayland will have many compositors, you don't have a de facto standard like X server, and they *will* do it differently, I expect... This kind of undefined behavior does not happen only on this case. For example, I have been wondering about window decoration. AFAIK, Wayland leaves to the compositor thr decision if window decoration should be client side or server side. In weston, it is client side, KWin will be server side, how an application would know if it has to decorate its own window or not? (This is a more general question that may deserve its own thread) I'm not a Wayland developer, so I can't say with confidence. But I think this choice is deferred to the toolkit layer. In this case both behaviors (server of client side decorations) are potentially useful, so the protocol shouldn't *require* one or the other. I fail to see success on this approach. Today you can run kde applications under gnome (and vice versa). What about if, with wayland, KDE does server side decoration and gnome chooses client side decoration, what would a kde application running under gnome look like? Though I guess for the issue you mentioned, maybe there should be some protocol to tell the client whether it should draw decorations or not. Yes, because Blender does not use any toolkit. But this is not the case for the key-replay behavior. There's nothing to be gained by letting different compositors do different things in this case. Both behaviors are fine IMO, so should just require whatever Weston does currently. I hope compositors agree on following the same path for undefined behaviors, otherwise toolkits and applications will have a hard time to come. So if you see what happens exactly, it'd be nice if you open a bug, or post back, or send a patch :) Do you mean about the behavior when we have more than one keyboard attached to a seat? No, that should work seamlessly. I meant the replay of the key press events (after you manage to implement your stuff in a real world application like Blender). Not a problem, I will do that. -- Best Regards, Wander Lairson Costa ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] How to distinguish left-shift and right-shift
On Thu, Sep 26, 2013 at 5:46 PM, Wander Lairson Costa wander.lair...@gmail.com wrote: 2013/9/26 Ran Benita ran...@gmail.com: On Thu, Sep 26, 2013 at 06:27:39PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote: 2013/9/26 Ran Benita ran...@gmail.com: [snip] The information you need, if you want to use the key-down approach (which is the only one I can think of), is whether e.g. the Left Shift key is down at any given moment. This keys-state information is kept on the compositor, but now you need to reconstruct it on the client. The way to do it is as I outlined above, i.e. wl_keyboard.enter event, which gives you a wl_array of all the keys which are pressed + wl_keyboard.key events, which allow you to keep this array in sync. This is what I was thinking about. (Though by a quick look at the Weston code, it might be that it sends key-down events for all the keys which are down when the focus is changed, that is, it replays what happened to get to the current state. So maybe you don't need the information in the wl_keyboard.enter after all, only the key events with an initial empty array. It should be easy to check which way is it). But this is an weston implementation detail, I guess, other compositors may not have the same behavior. Good point, I can't find it specified either. I think whatever the current behavior is, it should be specified in wayland.xml, so people can rely on it. In some cases, such undefined behavior can be a real hinderance, for example if you want to keep a 'press-count' for a key (there can be cases like two keyboards in the same seat, so *two* Left Shift keys can be down at the same time, etc). And since Wayland will have many compositors, you don't have a de facto standard like X server, and they *will* do it differently, I expect... This kind of undefined behavior does not happen only on this case. For example, I have been wondering about window decoration. AFAIK, Wayland leaves to the compositor thr decision if window decoration should be client side or server side. In weston, it is client side, KWin will be server side, how an application would know if it has to decorate its own window or not? (This is a more general question that may deserve its own thread) I'm not a Wayland developer, so I can't say with confidence. But I think this choice is deferred to the toolkit layer. In this case both behaviors (server of client side decorations) are potentially useful, so the protocol shouldn't *require* one or the other. I fail to see success on this approach. Today you can run kde applications under gnome (and vice versa). What about if, with wayland, KDE does server side decoration and gnome chooses client side decoration, what would a kde application running under gnome look like? This question comes up all the time. The simple answer here is that the negotiation protocol hasn't been written yet. Why hasn't it been written? Primarily because it hasn't become an issue yet. The only people really pushing for server-side are the KWin people. However, they are still working on porting to Qt 5 and QtQuick 2. Once they get to implementing the Wayland bits and *if* they still want to do server-side decorations at that point, one of them will probably start working on such a protocol. Though I guess for the issue you mentioned, maybe there should be some protocol to tell the client whether it should draw decorations or not. Yes, because Blender does not use any toolkit. For now, just draw decorations when not fullscreen. Once a negotiation protocol gets developed, you can implement it. But this is not the case for the key-replay behavior. There's nothing to be gained by letting different compositors do different things in this case. Both behaviors are fine IMO, so should just require whatever Weston does currently. I hope compositors agree on following the same path for undefined behaviors, otherwise toolkits and applications will have a hard time to come. 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 make sense to me that you would send the currently depressed keys as an array and then send them again one-at-a-time. So if you see what happens exactly, it'd be nice if you open a bug, or post back, or send a patch :) Do you mean about the behavior when we have more than one keyboard attached to a seat? No, that should work seamlessly. I meant the replay of the key press events (after you manage to implement your stuff in a real world application like Blender). Not a problem, I will do that. In theory, a client should not be able to
Re: conversion from double to fixed and back fails with certain values
Micah, This is because wl_fixed is a fixed-point format. In particular, it is 24.8 fixed point meaning that the top 24 bits represent the integer part. This means that wl_fixed effectively stores n if the number is written as the (possibly improper) fraction n/256. In your example, 3568.005 = 913409.28 / 256. Because wl_fixed only storres the integer n, this gets truncated to 913409/256. When it gets converted back, this obviously does not give you the same floating-point value. I hope that makes sense, --Jason Ekstrand On Thu, Sep 26, 2013 at 3:40 PM, Micah Nordland mpnordl...@gmail.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The value 3568.005 is not correctly converted back from fixed. The following patch to tests/fixed-test.c demonstrates. Is this expected behavior? diff --git a/tests/fixed-test.c b/tests/fixed-test.c index 739a3b1..89ec188 100644 - --- a/tests/fixed-test.c +++ b/tests/fixed-test.c @@ -65,6 +65,11 @@ TEST(fixed_double_conversions) d = wl_fixed_to_double(f); fprintf(stderr, fixed %x to double %lf\n, f, d); assert(d == f / 256); + +d = 3568.005; +f = wl_fixed_from_double(d); +fprintf(stderr, fixed %x to double %lf\n, f, d); +assert(d == wl_fixed_to_double(f)); } TEST(fixed_int_conversions) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSRJuxAAoJEPBh3Rt3H/83HkYH/2w1lrzcCNihoPp3zOrLmxao 8CdSvdIHvgAWvC6mnqJx9bL7W6bqI0LrZHRgCJqKFQcvnyQq9k5k+s2Kh1C87SbQ w8KQ3B4bkRl+m4oM4mxmbeQAlHKi0+mcyu8w6bUG/8OZRvGNvfjqUW2p62MHTKUr W9Uw9cq5A30I11LV13G5enFP1JIzVJqjoVykOJd4sSRX5vdPzr+n14ThSFQ/vu8D MjpZgHvKFZ5LPkCWb0MulQc7LXAqpabJTlMlDZ56HcbqevCZ6sg1AEd6DMdKqvXi lm17vVEOOJL6SLiNruTMEyi1TFi0+B06h972VH8x9RKg1LnhLtHsfu9JjiRdLiQ= =96Vx -END PGP SIGNATURE- ___ 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: conversion from double to fixed and back fails with certain values
OK, I are there any parts of the Wayland spec where this might cause problems/make things interesting? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: conversion from double to fixed and back fails with certain values
Micah, It simply means that you can't assume too much precision. For most things such as pointer movement this isn't a problem because there is no good reason why you would want to know the pointer's position more precicely than in units 1/256 of a pixel. Recently, however, there was some discussion of game controllers and using wl_fixed with the range [0, 1] which is more of a problem because it restricts you to 256 (or 257 depending on how you're looking at it) values. Really, it just means you have to be careful and make sure you think about how much precision you need before writing protocol bits. On the other hand, it means that you *always* know you are working with units of 1/256 and you can always count on it. This can actually make things much simpler in some cases. Also, it means that you don't have to worry about encoding any floating point formats. While standard x86 processors almost all use IEEE floating point, not everything does so what to do on those platforms becomes an issue. Also, floating point arithmetic is fuzzy because different processors may implement rounding in slightly different ways. (There are standards but they frequently get thrown to the wind for efficiency.) By using a fixed point format, you don't have to worry about rounding or anything like that because, if it matters, you can simply specify it in the protocol. In short, floatin-point is nice but provides very few guarantees; fixed-point isn't so nice but you always know exactly what you're working with. --Jason Ekstrand On Thu, Sep 26, 2013 at 6:59 PM, Micah Nordland mpnordl...@gmail.comwrote: OK, I are there any parts of the Wayland spec where this might cause problems/make things interesting? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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
