Re: Axis events to keyboard focus (Re: Input and games.)
On Thu, May 09, 2013 at 05:41:23PM -0700, Bill Spitzak wrote: Peter Hutterer wrote: assuming we have two clients C1, C2, and C1 has the gamepad open, what is the behaviour of the gamepad and the shared pointer: - when the gp-controlled pointer enters/leaves C1's surface - when the gp-controlled pointer enters and clicks inside the surface - when the compositor changes the keyboard and/or gamepad focus to C1's surface while the gp-controlled pointer is inside or outside the surface, respectively Because C1 has the gamepad open, the pointer is no longer shared, and it thus acts exactly like the pointer is only controlled by the mouse. There is no gp-controlled pointer. this makes C1 a pointer-trap, similar to qemu's behaviour under X. if you accidentally move onto the surface, you cannot escape unless you change the physical device to move the pointer. less than ideal, imo - when the mouse-controlled pointer enters and/or clicks C1's surface C1 gets enter and button events just like normal. - when the mouse-controlled pointer leaves the surface while a gamepad button is held down I think it may be desirable to have any buttons on any devices (ie keyboard keys as well) perform a temporary-grab much like mouse buttons so the pointer focus does not change until all the buttons are released. In this case C1 will get the mouse-move events and any buttons until it gets the release of all of them. If there is no such multi-device button grab, then C1 sees a mouse-leave event. It will also get the up event for the gamepad button since it still has the gamepad focus. this is a weird disconnect then. I can control the pointer until I move into a client that uses the gamepad. then the gamepad won't control the pointer, but it will still effectively _block_ the pointer from leaving the window if a button is pressed. very inconsistent. - when the gamepad presses a button after the mouse-controlled pointer has left the surface The gamepad entries still go to the gamepad focus which is C1 with this, if I move the pointer outside of the window while a GP button is down, I can't click anywhere. if I release the button, I can click anywhere but the GP button still goes to the old client. or not - depending on whether the GP has control over the pointer again. Cheers, Peter - if a keyboard event triggers a compositor shortcut immediately followed by a gamepad button event (e.g. alt-tab followed by gamepad button 1 press, does this select the window currently underneath the pointer?) If this moves the gamepad focus to another client that has not opened the gamepad, I think it does restore the control of the pointer. So the click does go to the window under the pointer. - what is the position of the cursor between the gamepad detached and reattached to pointer mode If follows the mouse only. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
On Thu, 9 May 2013 16:44:09 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote: [...] I had a private chat with Daniel, and we came to an understanding, which I try to describe below. The interface names below are more like placeholders for now. 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 actually need a capability bit?) A wl_gamepad_manager will send an event for each physical gamepad (as it dynamically appears, if hotplugged later) associated with this particular wl_seat, creating a wl_gamepad object for each. A wl_gamepad object will send an event about the player id as the first thing, and also if it later changes. do you expect the player ID to be exposed on the protocol? what does it contain and who manages the association? is it related to any physical ID of the gamepad, and if not, can such ID be provided (if the device supports it)? I imagined the player ID to be sent explicitly in the protocol, with its very own event. The server would manage the association between physical devices and the player ID, according to built-in heuristics and user preferences. E.g. if one goes from 0 gamepads to 1 gamepad, it will always be player 1; or maybe take the first player slot that does not have a gamepad, unless we identify the device as the same that was recently unplugged in which case take the player slot that it used to have. Or something, with user preferences, and some UI to fix the association in the rare case when the heuristics choose wrong. Recognizing a gamepad could be done via physical identification, if one is available, or by usb port/hub, or whatever platform specific way. The clients would not have to care, they would only work with unique player IDs, which are integers created in sequence starting from 1 (or 0). Using integers starting from 1 makes it trivial for the server to update the player ID display on the gamepads, if they have one. The server could also implement a global UI to reassing gamepads. For instance, press the famous home button for 5 secs on any gamepad, get some gamepad controllable GUI to reassing them, or maybe just a request to press the home button again on each gamepad in sequence. Doing all this client side would mean we need to find a way to communicate all the device and platform specific hints for the gamepad assignment heuristics somehow, and each client instance would have its own gamepad assignments. is the player ID not better represented through a wl_seat? - if you're playing a full-screen game, both seats can safely have the same focus, otherwise, players can play games independently. plus, if both players have a separate seat, they can use their keyboard independently for data entry. 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: - how to know, when one seat should follow the keyboard(?) focus of another seat? - a client still needs to map seats into players; how? does it need an UI to fix it in case a user is not happy with the result? Also, allowing multiple gamepads in one seat does not exclude the seat approach. A server could still assign every gamepad to a different seat, provided it had some way to solve the focus assignment. In any case, I think the player ID assigned to each gamepad by the server is useful, since it would solve the seat-player mapping, too. Although, in a strict one gamepad per seat setting it would be better suited as a seat event than a gamepad event, perhaps. Thanks, pq If a gamepad is hot-unplugged, a wl_gamepad event will notify about that, and the wl_gamepad object becomes inert (does not send any events, ignores all but the destroy request). Associating physical devices into wl_seats is left as a server detail. The only rule is, that a physical device can appear at most in one wl_seat at a time. The server is free to move e.g. gamepads from one seat to another at runtime, clients will just see one gamepad hot-unplugged, and one hotplugged later under a different seat. Gamepad input events are delivered according to the keyboard focus of the related wl_seat. If there is no keyboard to focus, then use the pointer focus, or something. It doesn't really affect the protocol design how the focus is assigned. However, would we need a wl_gamepad::enter,leave events? Probably, along with events for initial state. Or maybe enter/leave should be wl_gamepad_manager events? This design allows several gamepads associated with one wl_seat, and thus one focus. It also allows gamepads to be assigned to different seats, but then we will have more problems on managing the foci, not unlike with keyboards.
Re: Additional pixel formats for wl_shm
On Wed, 8 May 2013 12:22:10 -0400 Kristian Høgsberg hoegsb...@gmail.com wrote: On Wed, May 08, 2013 at 10:29:21AM +0300, Pekka Paalanen wrote: On Thu, 2 May 2013 10:23:04 +0300 Pekka Paalanen pekka.paala...@collabora.co.uk wrote: On Wed, 1 May 2013 21:38:48 -0400 Kristian Høgsberg hoegsb...@gmail.com wrote: On Fri, Apr 26, 2013 at 04:08:01PM +0300, Pekka Paalanen wrote: Hi Kristian, I'm working on Raspberry Pi, where the VideoCore can deal directly with a large number of pixel formats. However, wl_shm only exposes ARGB and XRGB 32-bit per pixel formats, which on such tiny devices are very wasteful. Would it be acceptable to add more formats to the wl_shm formats enum? I have happily forgot all the previous discussions about the topic, and a quick search into the mailing list archives didn't turn up much. We are especially interested in 16-bit per pixel formats to save memory and bandwidth, and if I am reading the GLESv2 specification right, RGB565, RGBA and RGBA5551 should be directly supported, so at least those could be uploaded into textures without manual conversion. Of course, the new rpi-renderer I am working on does not use GL for compositing anymore, but it should be able to use those formats directly, too. I have also another proposition: an extension to let wl_shm support custom pixel formats outside of the core protocol listed formats. It would have a new global interface, which when bound, would advertise additional pixel formats as a (string, uint) tuple, where the string describes the pixel format, and the uint is the corresponding format name to pass into wl_shm_pool.create_buffer as the format argument. wl_shm would not advertise these format names itself. We would need to define a WL_SHM_FORMAT_CUSTOM_BASE to reserve some name space for the custom formats. Or something along those lines. Of course, this is just working around the pixel format enum wl_shm has anyway, so if you would be willing to take more exotic pixel formats into the wl_shm format enum, this extension would not be needed. Does any of this sound acceptable for upstream Wayland, or do you think we'd better just write a new wl_buffer factory with everything we need? There's no reason not to just copy over the drm formats (which wl_drm already uses) to the wl_shm enum. I don't think we need an elaborate scheme for work-in-progress formats, lets just add the full list and then just advertise the ones the compositor supports. The main reason for not doing that originally was that I didn't want to overwhelm clients with a huge list of formats that they would have to pick and choose from. But as long as ARGB32 is always available, I don't see a problem in advertising extra formats. Ok, cool. And we can just document for wl_shm, that pre-multiplied ARGB 32-bit-per-pixel, and XRGB, should always be present, and others are optional, right? Yes. How do we define pre-multiplied alpha or not? Does it work to say that everything having an alpha channel is pre-multiplied, including ayuv? I'm sure there are cases where one would prefer non-pre-multiplied due to practical considerations, but do we care? Or should we go with the fourcc definition, which I guess would not have pre-multiplied? We did have non-premultiplied in the past, but it's a really awkward way to store transparent pixels and not worth the complexity. So all alpha formats are (continue to be) pre-multiplied. I don't know about AYUV, let's figure out what that means when we hit that case. Alright. And how about the conflicts? The current wl_shm formats named argb and xrgb are also used in the wl_drm set but with different numerical value. And maybe also conflicting on pre-multiplication? We'll just accept both the current 0 and 1 values as well as the fourcc values for the formats. There's no overlap. Yeah, but there is overlap in the names. Should the protocol definition of argb and xrgb stay as 0 and 1, and add new names for the fourcc variants; or should argb and xrgb values in the protocol be changed into the fourcc values? And if we do the latter, should we add the 0 and 1 values with new names like argb_wl and xrgb_wl, or should we only document, that compositors should also accept 0 and 1, and map them to the argb and xrgb formats? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
On Thu, 9 May 2013 10:49:03 + (UTC) Rick Yorgason r...@firefang.com wrote: Pekka Paalanen ppaalanen@... writes: From the game's point of view, it will need to iterate over all wl_seats. For each seat with the gamepad capability bit set, create a wl_gamepad_manager, receive all wl_gamepad objects, and for each wl_gamepad receive the player id. Create your surfaces, wait for foci to arrive, and fire away. So, the purpose of wl_gamepad_manager is to allow multiple gamepads to share one application focus. That seemed weird to me (why is it only gamepads that would want that ability?) which is why I started thinking about wl_seat parenting, and I apologize if that caused more heat than light. 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 that? And instead to have some seats which only interact with the focused application? We could have one wl_gamepad per wl_seat, just like wl_pointer, wl_keyboard, or wl_touch, put the player ID in wl_seat instead of wl_gamepad, and give compositor writers a few suggestions: * Not all seats need to have a desktop pointer or the ability to control their own focus. It can be useful to allow second class seats which follow the focus of another seat, in which case neither the pointer nor any other event from that seat should be allowed outside of the focused application. * Each gamepad should automatically be put in a separate seat, either by putting it in an existing seat without a gamepad, or automatically creating a new seat. * If a seat is automatically created for a gamepad, it should ideally be of the second class type by default. Users can always reconfigure their seat if they want control over the desktop. Wouldn't that allow everything we want? It allows every user to have a full set of devices, and users don't have to worry about focus issues unless they want to. It also means the protocol doesn't need the contrivances of wl_gamepad_manager or seat parenting. Yes. If I recall correctly, I originally started with a similar scheme, but Daniel did not like it. Daniel? Thanks, pq ps. please don't cut the cc list unless explicitly requested. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Axis events to keyboard focus (Re: Input and games.)
Peter Hutterer peter.hutterer@... writes: assuming we have two clients C1, C2, and C1 has the gamepad open, what is the behaviour of the gamepad and the shared pointer: - when the gp-controlled pointer enters/leaves C1's surface - when the gp-controlled pointer enters and clicks inside the surface - when the compositor changes the keyboard and/or gamepad focus to C1's surface while the gp-controlled pointer is inside or outside the surface, respectively Because C1 has the gamepad open, the pointer is no longer shared, and it thus acts exactly like the pointer is only controlled by the mouse. There is no gp-controlled pointer. this makes C1 a pointer-trap, similar to qemu's behaviour under X. if you accidentally move onto the surface, you cannot escape unless you change the physical device to move the pointer. less than ideal, imo The answer to the first scenario depends on the compositor's focus model: if it has focus follows mouse, I suppose Bill's answer is right, but with click to focus I would expect the gamepad to continue controlling the pointer until you click on the surface. Everywhere else, though, you're too worried about pointer traps. Remember, you would still be able to move the pointer with the mouse, and what's more, more often than not games are *expected* to trap the pointer. Kristian even implemented a pointer lock feature at the protocol level specifically so that you *can* trap the pointer. However, if any compositors add this feature, I would hope it's not enabled by default. Consider the Guitar Hero controller. Every feature on the Guitar Hero controller maps to a button or axis on the 360 controller. One of those features is the tilt sensor, which fires off an axis message when the guitar isn't in its expected orientation. So if your guitar is lying down on your desk, it would cause your cursor to automatically slide to one direction. -Rick- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
Hi, On 9 May 2013 11:49, Rick Yorgason r...@firefang.com 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 that? And instead to have some seats which only interact with the focused application? Yes, the mechanics of how focus is set and transferred are unspecified, thankfully. We could have one wl_gamepad per wl_seat, just like wl_pointer, wl_keyboard, or wl_touch, put the player ID in wl_seat instead of wl_gamepad, and give compositor writers a few suggestions: * Not all seats need to have a desktop pointer or the ability to control their own focus. Seats without wl_pointer already don't have a desktop pointer, and seats don't necessarily control their own focus. What happens when the compositor transfers focus is very well-defined. But nowhere in the protocol does it specify when focus is transferred, because without a view of the full window tree, clients don't have enough context to know what would happen anyway. So this is a moot point. It can be useful to allow second class seats which follow the focus of another seat, in which case neither the pointer nor any other event from that seat should be allowed outside of the focused application. That's not the point of a seat right now. But this is totally doable without any compositor changes if you want, and the client doesn't ever need to know about it. * Each gamepad should automatically be put in a separate seat, either by putting it in an existing seat without a gamepad, or automatically creating a new seat. Why put it in a seat, then? If it's not going to go in with a keyboard, mouse or touch device, don't bother with the seats, just keep it as a separate object. The purpose of seats was to aggregate and relate input devices. If all you're doing with wl_seat is using it as a shim to carry one (_exactly_ one) object, why bother? * If a seat is automatically created for a gamepad, it should ideally be of the second class type by default. Users can always reconfigure their seat if they want control over the desktop. Again, doesn't require protocol changes. Wouldn't that allow everything we want? It allows every user to have a full set of devices, and users don't have to worry about focus issues unless they want to. It also means the protocol doesn't need the contrivances of wl_gamepad_manager or seat parenting. I don't see what it brings us, if I'm honest. I guess it all hinges on how the focus model is implemented, and to what extent we want to express that through the protocol. *shrug* Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
Pekka Paalanen ppaalanen@... writes: Also, allowing multiple gamepads in one seat does not exclude the seat approach. A server could still assign every gamepad to a different seat, provided it had some way to solve the focus assignment. Unfortunately, that comes at the expense of requiring clients to support two code paths. For better or worse, a lot of game developers prefer to write close to the metal, so if their compositor of choice prefers one method, there's a very real chance that the game developer will forget to support the other method. is the player ID not better represented through a wl_seat? - if you're playing a full-screen game, both seats can safely have the same focus, otherwise, players can play games independently. plus, if both players have a separate seat, they can use their keyboard independently for data entry. 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: - how to know, when one seat should follow the keyboard(?) focus of another seat? - a client still needs to map seats into players; how? does it need an UI to fix it in case a user is not happy with the result? You would definitely need a UI for corner cases and advanced users, but I think you could design a heuristic that's good enough for games most of the time. Here's an example heuristic: A) Whenever a keyboard or mouse is plugged into the system, it gets added to the first seat. B) Whenever a gamepad is plugged into the system, it gets added to the first seat without a gamepad. If all the seats already have a gamepad assigned, a new seat is automatically created. C) If a user explicitly creates a seat, that seat gets full access to the desktop by default, including their own desktop-level cursor. (I call this collaboration below.) D) If the compositor has to automatically create a new seat to deal with a new gamepad, that seat has collaboration turned off, and follows the first seat's focus. E) If a keyboard, mouse, or touch screen is attached or plugged into the gamepad, it goes in the same seat as the gamepad. This does not override rule D. F) There must always be at least one seat. G) At least one seat must be in collaborative mode. I've put together an example scenario below. Excuse the ASCII art :) -Rick- 1) The users plug two keyboards and two mice into the computer. They all get assigned to seat 1. 2) The users open a seat configuration dialogue. They see this: Seat 1 [Configure] [Renumber] [Add a new seat] 3) They click Configure. They see this: Seat 1 -- Choose the devices you want in this seat: [X] Keyboard 1 [X] Keyboard 2 [X] Mouse 1 [X] Mouse 2 [X] This seat can collaboratively share the desktop (disabled) Derive focus from [N/A] (disabled) 4) They go back and click Add a new seat. They see this: Seat 2 -- Choose the devices you want in this seat: [ ] Keyboard 1 [ ] Keyboard 2 [ ] Mouse 1 [ ] Mouse 2 [X] This seat can collaboratively share the desktop (disabled) Derive focus from [Seat 1] 5) They reconfigure it like so: Seat 2 -- Choose the devices you want in this seat: [ ] Keyboard 1 [X] Keyboard 2 [ ] Mouse 1 [X] Mouse 2 [X] This seat can collaboratively share the desktop Derive focus from [N/A] (disabled) 6) This automatically removes Keyboard 2 and Mouse 2 from Seat 1. It also un-disables the collaborative line. If they go back to Seat 1's configuration screen, they'll see this: Seat 1 -- Choose the devices you want in this seat: [X] Keyboard 1 [ ] Keyboard 2 [X] Mouse 1 [ ] Mouse 2 [X] This seat can collaboratively share the desktop Derive focus from [N/A] (disabled) 7) They plug a gamepad into the computer. It automatically gets assigned to seat 1: Seat 1 -- Choose the devices you want in this seat: [X] Keyboard 1 [ ] Keyboard 2 [X] Mouse 1 [ ] Mouse 2 [X] Gamepad 1 [X] This seat can collaboratively share the desktop Derive focus from [N/A] (disabled) 8) They plug another gamepad into the computer. It automatically gets assigned to seat 2: Seat 2 -- Choose the devices you want in this seat: [ ] Keyboard 1 [X] Keyboard 2 [ ] Mouse 1 [X] Mouse 2 [ ] Gamepad 1 [X] Gamepad 2 [X] This seat can collaboratively share the desktop Derive focus from [N/A] (disabled) 9) They plug a third gamepad into the computer. The compositor automatically creates a seat with collaboration turned off. The seat list now looks like this: Seat 1 [Configure] [Renumber] [Delete] Seat 2 [Configure] [Renumber] [Delete] Seat 3 [Configure] [Renumber] [Delete] [Add a new seat] 10) They configure seat 3, and see this: Seat 3 -- Choose the devices you want in this seat: [ ] Keyboard 1 [ ] Keyboard 2 [ ] Mouse 1 [ ] Mouse 2 [ ] Gamepad 1 [ ] Gamepad 2 [X] Gamepad 3 [ ] This seat can collaboratively share the desktop Derive focus from [Seat 1] 11) The users decide that player 3 should follow player
Re: Gamepad focus model (Re: Input and games.)
Daniel Stone daniel@... writes: Why put it in a seat, then? If it's not going to go in with a keyboard, mouse or touch device, don't bother with the seats, just keep it as a separate object. The purpose of seats was to aggregate and relate input devices. If all you're doing with wl_seat is using it as a shim to carry one (_exactly_ one) object, why bother? For the same reason you would put a keyboard in a seat by itself: just because it's the only device in that seat right now, doesn't mean it will always be the only device in its seat. Hopefully my last email with the scenario makes this more clear. Keep in mind that both the OUYA and PS4 controllers are coming with touch pads built in. Seats would be a perfect way of grouping the two devices together. Also, while we're talking about aggregation, earlier in the thread we were assuming that it never makes sense to aggregate controllers, but now I think it's safer to say that it *rarely* makes sense to aggregate controllers. Consider a scenario where a user has a really nice wireless controller, but they also have a crappy controller that's plugged directly into their computer which they only use when they run out of batteries. This is advanced user territory, but it's conceivable to think that the user would want to permanently assign both gamepads to the same seat. The only tricky part about aggregating gamepads is dealing with the axes, but all you really have to do is add each axis component together and ensure that the component doesn't go beyond the max size. -Rick- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Add initial color management framework code
On Thu, May 09, 2013 at 08:31:09PM +0100, Richard Hughes wrote:
ICC profiles can now be specified in weston.ini for each output, or a CMS
implementation can optionally loaded from a pluggable module.
---
Excellent, thanks for revising. Committed and pushed.
Kristian
configure.ac | 7 ++
src/Makefile.am | 12 +++
src/cms-helper.c | 134
src/cms-helper.h | 70 +
src/cms-static.c | 211
+++
src/compositor-drm.c | 3 +
src/compositor.h | 1 +
weston.ini | 3 +-
8 files changed, 440 insertions(+), 1 deletion(-)
create mode 100644 src/cms-helper.c
create mode 100644 src/cms-helper.h
create mode 100644 src/cms-static.c
diff --git a/configure.ac b/configure.ac
index c535b28..b71038d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,13 @@ AC_MSG_NOTICE([Weston's native backend:
$WESTON_NATIVE_BACKEND])
AC_DEFINE_UNQUOTED([WESTON_NATIVE_BACKEND], [$WESTON_NATIVE_BACKEND],
[The default backend to load, if not wayland nor x11.])
+PKG_CHECK_MODULES(LCMS, lcms2,
+ [have_lcms=yes], [have_lcms=no])
+if test x$have_lcms = xyes; then
+ AC_DEFINE(HAVE_LCMS, 1, [Have lcms support])
+fi
+AM_CONDITIONAL(HAVE_LCMS, [test x$have_lcms = xyes])
+
WAYLAND_SCANNER_RULES(['$(top_srcdir)/protocol'])
AC_CONFIG_FILES([Makefile
diff --git a/src/Makefile.am b/src/Makefile.am
index d33ebc5..92d9e38 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -94,6 +94,7 @@ moduledir = $(libdir)/weston
module_LTLIBRARIES = \
$(desktop_shell)\
$(tablet_shell) \
+ $(cms_static) \
$(x11_backend) \
$(drm_backend) \
$(wayland_backend) \
@@ -251,6 +252,17 @@ tablet_shell_la_SOURCES =\
tablet-shell-server-protocol.h
endif
+if HAVE_LCMS
+cms_static = cms-static.la
+cms_static_la_LDFLAGS = -module -avoid-version
+cms_static_la_LIBADD = $(COMPOSITOR_LIBS) $(LCMS_LIBS) ../shared/libshared.la
+cms_static_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LCMS_CFLAGS)
+cms_static_la_SOURCES = \
+ cms-static.c\
+ cms-helper.c\
+ cms-helper.h
+endif
+
BUILT_SOURCES = \
screenshooter-server-protocol.h \
screenshooter-protocol.c\
diff --git a/src/cms-helper.c b/src/cms-helper.c
new file mode 100644
index 000..2c7b57f
--- /dev/null
+++ b/src/cms-helper.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright © 2013 Richard Hughes
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stdlib.h
+#include string.h
+#include stdio.h
+
+#ifdef HAVE_LCMS
+#include lcms2.h
+#endif
+
+#include compositor.h
+#include cms-helper.h
+
+#ifdef HAVE_LCMS
+static void
+weston_cms_gamma_clear(struct weston_output *o)
+{
+ int i;
+ uint16_t *red;
+
+ if (!o-set_gamma)
+ return;
+
+ red = calloc(o-gamma_size, sizeof(uint16_t));
+ for (i = 0; i o-gamma_size; i++)
+ red[i] = (uint32_t) 0x * (uint32_t) i / (uint32_t)
(o-gamma_size - 1);
+ o-set_gamma(o, o-gamma_size, red, red, red);
+ free(red);
+}
+#endif
+
+void
+weston_cms_set_color_profile(struct weston_output *o,
+ struct weston_color_profile *p)
+{
+#ifdef HAVE_LCMS
+ cmsFloat32Number in;
+ const cmsToneCurve **vcgt;
+ int i;
+ int size;
+
Re: [PATCH] Add initial color management framework code
On Fri, May 10, 2013 at 11:03:30AM -0400, Kristian Høgsberg wrote: On Thu, May 09, 2013 at 08:31:09PM +0100, Richard Hughes wrote: ICC profiles can now be specified in weston.ini for each output, or a CMS implementation can optionally loaded from a pluggable module. --- Excellent, thanks for revising. Committed and pushed. With a few changes... there were a few crashers in here, some of which I triggered because I happen to have both eDP1 and LVDS output sections in my weston.ini. We talked about using wl_list_for_each_safe for destroying the outputs and configured outputs in irc. Beyond that, there's also a problem with the config API (and I'll concede that that API is very awkward): after handling a section_done callback, you have to set the output_name and output_icc_profile variables back to NULL, otherwise when you get the next section_done callback you can't reliably test for NULL or not. I had two configured_outputs get the same icc profile because of this, which is how we ended up with the double free. Finally the destroy order of outputs and compositor is a little counter-intuitive: we emit the compositor destroy signal first and then the output destroy signals. We probably want to switch that around, but as it is, iterating cms-output_list from the output destroy handler fails because cms is alread destroyed here. What I did instead was to just remove struct cms_output, since we don't use it for anything. We may want to bring them back so that we can reset gamma on shutdown (right now I end up with a bluish kms console when I exit weston), or maybe compositor-drm.c should make a copy of the current ramp on start up and restore from that on shutdown. Next, we should fix compositor-drm.c to make a copy of the current gamma ramps so that it can reset it on vt-enter. Right now, if you vt switch away to X and back, the gamma ramps are reset. Kristian Kristian configure.ac | 7 ++ src/Makefile.am | 12 +++ src/cms-helper.c | 134 src/cms-helper.h | 70 + src/cms-static.c | 211 +++ src/compositor-drm.c | 3 + src/compositor.h | 1 + weston.ini | 3 +- 8 files changed, 440 insertions(+), 1 deletion(-) create mode 100644 src/cms-helper.c create mode 100644 src/cms-helper.h create mode 100644 src/cms-static.c diff --git a/configure.ac b/configure.ac index c535b28..b71038d 100644 --- a/configure.ac +++ b/configure.ac @@ -315,6 +315,13 @@ AC_MSG_NOTICE([Weston's native backend: $WESTON_NATIVE_BACKEND]) AC_DEFINE_UNQUOTED([WESTON_NATIVE_BACKEND], [$WESTON_NATIVE_BACKEND], [The default backend to load, if not wayland nor x11.]) +PKG_CHECK_MODULES(LCMS, lcms2, + [have_lcms=yes], [have_lcms=no]) +if test x$have_lcms = xyes; then + AC_DEFINE(HAVE_LCMS, 1, [Have lcms support]) +fi +AM_CONDITIONAL(HAVE_LCMS, [test x$have_lcms = xyes]) + WAYLAND_SCANNER_RULES(['$(top_srcdir)/protocol']) AC_CONFIG_FILES([Makefile diff --git a/src/Makefile.am b/src/Makefile.am index d33ebc5..92d9e38 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -94,6 +94,7 @@ moduledir = $(libdir)/weston module_LTLIBRARIES = \ $(desktop_shell)\ $(tablet_shell) \ + $(cms_static) \ $(x11_backend) \ $(drm_backend) \ $(wayland_backend) \ @@ -251,6 +252,17 @@ tablet_shell_la_SOURCES = \ tablet-shell-server-protocol.h endif +if HAVE_LCMS +cms_static = cms-static.la +cms_static_la_LDFLAGS = -module -avoid-version +cms_static_la_LIBADD = $(COMPOSITOR_LIBS) $(LCMS_LIBS) ../shared/libshared.la +cms_static_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LCMS_CFLAGS) +cms_static_la_SOURCES =\ + cms-static.c\ + cms-helper.c\ + cms-helper.h +endif + BUILT_SOURCES =\ screenshooter-server-protocol.h \ screenshooter-protocol.c\ diff --git a/src/cms-helper.c b/src/cms-helper.c new file mode 100644 index 000..2c7b57f --- /dev/null +++ b/src/cms-helper.c @@ -0,0 +1,134 @@ +/* + * Copyright © 2013 Richard Hughes + * + * 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
Re: Axis events to keyboard focus (Re: Input and games.)
Peter Hutterer wrote: Because C1 has the gamepad open, the pointer is no longer shared, and it thus acts exactly like the pointer is only controlled by the mouse. There is no gp-controlled pointer. this makes C1 a pointer-trap, similar to qemu's behaviour under X. if you accidentally move onto the surface, you cannot escape unless you change the physical device to move the pointer. less than ideal, imo I think you are confused about what I am proposing. Imagine there is a mouse and a gamepad. During normal use the user can take either device and move the pointer, and all buttons on them which are reported to the client with pointer focus. Then client C1 opens the gamepad somehow. Now only the mouse moves the pointer, the gamepad does not move it. Buttons on the mouse are reported to the pointer focus, but buttons on the gamepad are reported to C1. Moving the pointer around with the mouse does not cause a pointer-trap, the mouse will work exactly as though there was no gamepad at all. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable
Search for a given config file in the directories listed in
$XDG_CONFIG_DIRS if it wasn't found in $XDG_CONFIG_HOME or ~/.config.
This allows packages to install custom config files in
/etc/xdg/weston, for example, thus allowing them to avoid dealing with
home directories.
Signed-off-by: Ossama Othman ossama.oth...@intel.com
---
shared/config-parser.c | 125
+++-
1 file changed, 102 insertions(+), 23 deletions(-)
diff --git a/shared/config-parser.c b/shared/config-parser.c
index 10ff86a..34c16a6 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -25,6 +25,7 @@
#include stdlib.h
#include assert.h
#include ctype.h
+#include unistd.h
#include config-parser.h
@@ -95,6 +96,9 @@ parse_config_file(const char *path,
const struct config_section *current = NULL;
int i;
+ if (path == NULL)
+ return -1;
+
fp = fopen(path, r);
if (fp == NULL) {
fprintf(stderr, couldn't open %s\n, path);
@@ -151,37 +155,112 @@ parse_config_file(const char *path,
return 0;
}
+static char *
+config_file_path_xdg_config_home(const char *name)
+{
+ const char *config_dir = getenv(XDG_CONFIG_HOME);
+
+ if (config_dir) {
+ size_t size = strlen(config_dir) + 1 + strlen(name) + 1;
+ char *path = malloc(size);
+
+ /* TOCTOU race here. Ideally we should open the file
+ * and return a handle to it. */
+ if (path
+snprintf(path, size, %s/%s, config_dir, name) 0
+access(path, R_OK) == 0)
+ return path;
+
+ free(path);
+ }
+
+ return NULL;
+}
+
+static char *
+config_file_path_home(const char *name)
+{
+ const char *home_dir = getenv(HOME);
+
+ if (home_dir) {
+ const char dotconf[] = /.config/;
+
+ size_t size = strlen(home_dir) + sizeof dotconf + strlen(name);
+ char *path = malloc(size);
+
+ if (path
+snprintf(path, size, %s%s%s,
+ home_dir, dotconf, name) 0
+access(path, R_OK) == 0)
+ return path;
+
+ free(path);
+ }
+
+ return NULL;
+}
+
+static char *
+config_file_path_xdg_config_dirs(const char *name)
+{
+ const char *config_dirs = getenv(XDG_CONFIG_DIRS);
+
+ if (config_dirs) {
+ const char weston_dir[] = /weston/;
+ char *config_dir, *saveptr, *dirs;
+ char *path = NULL;
+ size_t size;
+
+ size = strlen(config_dirs) + 1;
+ dirs = malloc(size);
+ if (!dirs)
+ return NULL;
+
+ /* strtok_r() modifies the first argument. Avoid
+ * clobbering the process environment. */
+ strncpy(dirs, config_dirs, size);
+
+ for (config_dir = strtok_r(dirs, :, saveptr);
+ config_dir != NULL;
+ config_dir = strtok_r(NULL, :, saveptr)) {
+ size = strlen(config_dir) +
+ sizeof weston_dir + strlen(name);
+ path = realloc(path, size);
+
+ if (path
+snprintf(path, size, %s%s%s,
+ config_dir, weston_dir, name) 0
+access(path, R_OK) == 0)
+ return path;
+ }
+
+ free(path);
+ }
+
+ return NULL;
+}
+
char *
config_file_path(const char *name)
{
- const char dotconf[] = /.config/;
- const char *config_dir;
- const char *home_dir;
char *path;
- size_t size;
-
- config_dir = getenv(XDG_CONFIG_HOME);
- if (!config_dir) {
- home_dir = getenv(HOME);
- if (!home_dir) {
- fprintf(stderr, HOME is not set, using cwd.\n);
- return strdup(name);
- }
- size = strlen(home_dir) + sizeof dotconf + strlen(name);
- path = malloc(size);
- if (!path)
- return NULL;
+ /* Precedence is given to config files in the home directory,
+ * and then to directories listed in XDG_CONFIG_DIRS. */
- snprintf(path, size, %s%s%s, home_dir, dotconf, name);
- return path;
- }
+ path = config_file_path_xdg_config_home(name);
+
+ if (!path)
+ path = config_file_path_home(name);
+
+ if (!path)
+ path = config_file_path_xdg_config_dirs(name);
- size = strlen(config_dir) + 1 + strlen(name) + 1;
- path = malloc(size);
if (!path)
- return NULL;
+ fprintf(stderr,
+ config file \%s\ not found in
+ $XDG_CONFIG_{HOME,DIRS} or ~/.config\n,
+ name);
- snprintf(path, size, %s/%s, config_dir, name);
return path;
}
--
1.7.10.4
0001-config-parser-Honor-the-XDG_CONFIG_DIRS-environment-.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v3 00/13] Sub-surfaces v3
On Thu, Apr 25, 2013 at 01:57:40PM +0300, Pekka Paalanen wrote: Hi all, this is the v3 of the sub-surfaces patch series, and it is no longer an RFC. This means that I consider this series ready for merging into Weston. The server side sub-surface protocol implementation is feature complete. Once the protocol is deemed stable, we will move it into Wayland core. Until then, you need to copy protocol/subsurface.xml if you want to use it in other projects. Pekka, Great work, I've merged it to master. I reviewed the protocol and weston implementation and skimmed the toytoolkit stuff, and it all looks good. We still have quirks to work out, but that'll be easier with the core functionality merged. I think I saw a crash and there's the missing unlock dialog, but we'll figure that out. On the protocol level, I'm not sure about the eglSwapInterval requirement, I feel like there's a better solution - maybe commit on the async (is 'async' better than 'desync'?) subsurface can still send a frame event even if the parent surface hasn't committed yet? Thanks for driving this work, Kristian The previous series, v2, was announced in http://lists.freedesktop.org/archives/wayland-devel/2013-February/007590.html Personally, I believe that all the previously open issues are now sufficiently explored, that there should not be any big surprises. The major changes in v3 are: - Improved protocol object destruction rules: wl_subsurface simply becomes inert, if the corresponding wl_surface is destroyed. - Added support for nested sub-surfaces. You can now have sub-sub-surfaces, and so on. - Renamed the commit modes, and adjusted their behaviour to support nested sub-surfaces better. If a sub-surface is synchronized, all its children will act synchronized, too. - Completed the server side protocol implementation with sub-surface nesting support, and double-buffered sub-surface z-order updates. And of course bug fixes, and a rebase on top of the current upstream master branch. The following changes since commit 2e437207435a1b8720b5c623ccfc773e171ccf68: window: Add a log handler for window.c clients (2013-04-16 20:46:59 -0400) are available in the git repository at: git://git.collabora.co.uk/git/user/pq/weston.git subsurface-v3 for you to fetch changes up to 098b2911ead4ad0d9726d1bc192a87ca8ad9295d: window: add DBG code for leaf management and redraws (2013-04-25 12:10:18 +0300) Giulio Camuffo (2): shell: enable moving and resizing of a surface when clicking on a subsurface shell: account for the subsurfaces when going fullscreen or maximizing Pekka Paalanen (11): protocol: add sub-surfaces compositor: introduce sub-surfaces tests: add sub-surface protocol tests shell: keyboard focus and restacking fixes for sub-surfaces window: implement shm triple-buffering window: create sub-surfaces window: implement per-surface redraws clients: add subsurfaces demo window: prevent EGL sub-surface deadlock window: throttle resizing to the main surface window: add DBG code for leaf management and redraws clients/.gitignore | 3 + clients/Makefile.am | 12 + clients/subsurfaces.c | 792 clients/window.c| 460 clients/window.h| 19 ++ configure.ac| 3 + protocol/subsurface.xml | 236 +++ src/.gitignore | 3 + src/Makefile.am | 4 + src/compositor.c| 747 - src/compositor.h| 58 src/shell.c | 172 --- tests/.gitignore| 3 + tests/Makefile.am | 9 +- tests/subsurface-test.c | 325 15 files changed, 2732 insertions(+), 114 deletions(-) create mode 100644 clients/subsurfaces.c create mode 100644 protocol/subsurface.xml create mode 100644 tests/subsurface-test.c This patch series applies on top of the current upstream master branch without any additional patches. The series is browsable in cgit: http://cgit.collabora.com/git/user/pq/weston.git/log/?h=subsurface-v3 To do (free to take, not necessarily me): - A Weston demo client with window decorations stitched from 4 sub-surfaces, handling input in all sub-surface. (Giulio already has an example in Qt.) - Nested sub-surface tests and a demo. Nesting is currently untested. - Fix full-surface alpha for windows that have sub-surfaces. - Investigate if the shell black surfaces could be implemented as server-side sub-surfaces more easily than they are now. I have not forgotten about the clipping scaling protocol extension, and I have some ideas for it, but it is free for taking, too. If you're interested in taking a shot at any of these items, let me know so we can avoid overlapping work. When you build this series, remember
Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable
Othman, Ossama wrote: Hi, Minor correction to my previous patch. This revision corrects a small leak in config_file_path_xdg_config_dirs(). Rather than have all these functions try to open the file, why not just build a list of all the possible filenames and then try to open them in order until one works. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
