- Jul 09, 2013
-
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
We can't do that there, we have to make sure it stays a valid fd until the application calls wl_display_disconnect(). Otherwise the application may end up poll()ing on a stale or wrong fd in case another part of the application (or another thread) triggered a fatal error.
-
Kristian Høgsberg authored
Getting no data from the socket is not an error condition. This may happen in case of calling prepare_read() and then read_events() with no other pending readers and no data in the socket. In general, read_events() may not queue up events in the given event queue. From a given threads point of view it doesn't matter whether events were read and put in a different event queue or no events were read at all.
-
Neil Roberts authored
If EOF is encountered while reading from the Wayland socket, make wl_display_read_events() return -1 so that it will be treated as an error. The documentation for this function states that it will set errno when there is an error so it additionally makes up an errno of EPIPE. If we don't do this then when the compositor quits the Wayland socket will be become ready for reading but wl_display_dispatch will do nothing which typically makes the application take up 100% CPU. In particular eglSwapBuffers will likely get stuck in an infinite busy loop because it repeatedly calls wl_display_dispatch_queue while it waits for the frame callback. https://bugzilla.gnome.org/show_bug.cgi?id=703892
-
Kristian Høgsberg authored
This patch introduces wl_global_create() and wl_global_destroy() as replacements for wl_display_add_global() and wl_display_remove_global(). The add/remove_global API did not allow a compositor to indicate the implemented version of a global, it just took the version from the interface meta data. The problem is that the meta data (which lives in libwayland-server.so) can get out of sync with a compositor implementation. The compositor will then advertise a higher version of a global than what it actually implements. The new API lets a compositor pass in a version when it registers a global, which solves the problem. The add/remove API is deprecated with this patch and will be removed.
-
- Jul 03, 2013
-
-
Daiki Ueno authored
To allow user program to include wayland-scanner.m4 in tarball, move the path variables from it into wayland-scanner.pc.
-
Daiki Ueno authored
-
- Jul 02, 2013
-
-
Kristian Høgsberg authored
We need to free the non-legacy resources during client shutdown as well.
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
The wl_client_add/new_object() functions sends out an NO_MEMORY error if the allocation fails. This was convenient in a couple of places where that was all the error handling that was needed. Unfortunately that looks like out-of-memory isn't handled at the call site and set a bad precedent for not cleaning up properly or not handling at all. As we're introducing wl_resource_create() as a replacement for those two functions, let's remove the automatic error event posting and require the caller to do that if necessary. This commit also introduces a new helper, wl_client_post_no_memory() to make it possible to send NO_MEMORY events from bind where we don't have a wl_resource.
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
-
Faith Ekstrand authored
This commit provides a layer of protection for the compositor in the form of message version checking. We track version information in the wl_resource and now use this version information to verify that a request exists in that protocol version before invoking it. This way libwayland won't accidentally invoke a request that does not exist and thereby cause the compositor to crash. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Faith Ekstrand authored
A new function, wl_resource_create(), lets the compositor create a wl_resource for a given version of the interface. Passing 0 for the object ID will allocate a new ID. The implementation, user data and destructor can be set with wl_resource_set_implementation(). These two functions deprecates wl_client_add/new_object and the main difference and motivation is the ability to provide a version number for the resource. This lets the compositor track which version of the interface a client has created and we'll use that to verify incoming requests. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Faith Ekstrand authored
This commit adds version information to wl_message signatures and a wl_message_get_since function to retrieve. The since version comes in the form of a (possible) integer at the begining of the message. If the message starts with an integer, then it specifies the "since" version of that message. Messages present in version one do not get this "since" information. In this way we can run-time detect the version information for a structure on a per-message basis. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Kristian Høgsberg authored
With the work to add wl_resource accessors and port weston to use them, we're ready to make wl_resource and wl_object opaque structs. We keep wl_buffer in the header for EGL stacks to use, but don't expose it by default. In time we'll remove it completely, but for now it provides a transition paths for code that still uses wl_buffer. Reviewed-by: Jason <Ekstrand<jason@jlekstrand.net>
-
- Jun 28, 2013
-
-
Rob Bradford authored
This format is used to specify that the key button events received are not in relation to any key map and that the codes should be interpreted directly. v2: Use zero for the no keymap enum value and enhance the documentation for the enum entry.
-
- Jun 21, 2013
-
-
Faith Ekstrand authored
This commit also has the effect of making wl_shm_buffer no longer a wl_buffer derivative. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Faith Ekstrand authored
This commit does not break ABI. It merely changes the types of some things and adds a wl_shm_buffer_get function. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Faith Ekstrand authored
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
- Jun 20, 2013
-
-
Faith Ekstrand authored
This commit makes wl_resource_destroy automatically free all non-legacy resource structures. Since wl_resource is now an opaque structure it doesn't make sense for the clients to be freeing it. This checks to make sure that it was added through wl_client_add_object or wl_client_new_object and not wl_client_add_resource before it frees it. This way if it is a legacy resources embedded in a structure somewhere we don't have an invalid free. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
- Jun 18, 2013
-
-
Ander Conselvan de Oliveira authored
Document what we expect in terms of commit messages and coding style. New contributors are usually unaware of this, so it is good to have a document to point them too.
-
- Jun 17, 2013
-
-
Kristian Høgsberg authored
The current thread model assumes that the application or toolkit will have one thread that either polls the display fd and dispatches events or just dispatches in a loop. Only this main thread will read from the fd while all other threads will block on a pthread condition and expect the main thread to deliver events to them. This turns out to be too restrictive. We can't assume that there always will be a thread like that. Qt QML threaded rendering will block the main thread on a condition that's signaled by a rendering thread after it finishes rendering. This leads to a deadlock when the rendering threads blocks in eglSwapBuffers(), and the main thread is waiting on the condition. Another problematic use case is with games that has a rendering thread for a splash screen while the main thread is busy loading game data or compiling shaders. The main thread isn't responsive and ends up blocking eglSwapBuffers() in the rendering thread. We also can't assume that there will be only one thread polling on the file descriptor. A valid use case is a thread receiving data from a custom wayland interface as well as a device fd or network socket. The thread may want to wait on either events from the wayland interface or data from the fd, in which case it needs to poll on both the wayland display fd and the device/network fd. The solution seems pretty straightforward: just let all threads read from the fd. However, the main-thread restriction was introduced to avoid a race. Simplified, main loops will do something like this: wl_display_dispatch_pending(display); /* Race here if other thread reads from fd and places events * in main eent queue. We go to sleep in poll while sitting on * events that may stall the application if not dispatched. */ poll(fds, nfds, -1); /* Race here if other thread reads and doesn't queue any * events for main queue. wl_display_dispatch() below will block * trying to read from the fd, while other fds in the mainloop * are ignored. */ wl_display_dispatch(display); The restriction that only the main thread can read from the fd avoids these races, but has the problems described above. This patch introduces new API to solve both problems. We add int wl_display_prepare_read(struct wl_display *display); and int wl_display_read_events(struct wl_display *display); wl_display_prepare_read() registers the calling thread as a potential reader of events. Once data is available on the fd, all reader threads must call wl_display_read_events(), at which point one of the threads will read from the fd and distribute the events to event queues. When that is done, all threads return from wl_display_read_events(). From the point of view of a single thread, this ensures that between calling wl_display_prepare_read() and wl_display_read_events(), no other thread will read from the fd and queue events in its event queue. This avoids the race conditions described above, and we avoid relying on any one thread to be available to read events.
-
- Jun 14, 2013
-
-
Faith Ekstrand authored
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Rob Bradford authored
This event was added in version 2 of the protocol.
-
Rob Bradford authored
-
- Jun 07, 2013
-
-
Kristian Høgsberg authored
-
- Jun 05, 2013
-
-
Faith Ekstrand authored
-
Faith Ekstrand authored
I got a little over-eager with my sanity checks and didn't realize that the client uses wl_map_insert_at to mark objects as zombies when they come from the server-side. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Faith Ekstrand authored
In order to use the second-lowest bit of each pointer in wl_map for the WL_MAP_ENTRY_LEGACY flag, every pointer has to be a multiple of 4. This was a good assumption, except with WL_ZOMBIE_OBJECT. This commit creates an actual static variable to which WL_ZOMBIE_OBJECT now points. Since things are only every compared to WL_ZOMBIE_OBJECT with "==" or "!=", the only thing that matters is that it is unique. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Kristian Høgsberg authored
Missed v2 of Robs patch that already did this based on feedback from Ander and Daniel.
-
Faith Ekstrand authored
This is the first step towards making wl_resource an opaque pointer type. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Faith Ekstrand authored
The implementation in this commit allows for one bit worth of flags. If more flags are desired at a future date, then the wl_map implementation will have to change but the wl_map API will not. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Faith Ekstrand authored
The original wl_map implementation did no checking to ensures that ids fell on the correct side of the WL_SERVER_ID_START line. This meant that a client could send the server a server ID and it would happily try to use it. Also, there was no distinction between server-side and client-side in wl_map_remove. Because wl_map_remove added the entry to the free list regardless of which side it came from, the following set of actions would break the map: 1. Client creates a bunch of objects 2. Client deletes one or more of those objects 3. Client does something that causes the server to create an object Because of the problem in wl_map_remove, the server would take an old client-side id, apply the WL_SERVER_ID_START offset, and try to use it as a server-side id regardless of whether or not it was valid. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
-
Rob Bradford authored
This provides the ability for a client to differentiate events from different seats in a multiple seat environment.
-
Rob Bradford authored
The required flags are relatively new and some older enterprise distributions do not feature them. https://bugs.freedesktop.org/show_bug.cgi?id=63360
-
- May 28, 2013
-
-
Alexander Larsson authored
Modes are mainly meant to be used in coordination with fullscreen in DRIVER mode, by e.g. games. For such games what they generally want is to match some hardware mode and resize their window for that. We don't really need to complicate this with the scaling. So, we keep the resolutions in HW pixels, and drop the SCALED flag (as it is now useless). This lets you just create e.g an 800x600 buffer of scale 1 and fullscreen that, ignoring the output scaling factor (although you can of course also respect it and create a 400x300 surface at scale 2). Conceptually the mode change is treated like a scaling which overrides the normal output scale. The only complexity is the FILL mode where it can happen that the user specifies a buffer of the same size as the screen, but the output has scale 2 and the buffer scale 1. Just scanning out this buffer will work, but effectively this is a downscaling operation, as the "real" size of the surface in pels is twice the size of the output. We solve this by allowing FILL to downscale (but still not upscale).
-
Alexander Larsson authored
We usually use signed ints for things like this, to avoid issues C sign coersion.
-
- May 22, 2013
-
-
Alexander Larsson authored
This adds the wl_surface.set_buffer_scale request, and a wl_output.scale event. These together lets us support automatic upscaling of "old" clients on very high resolution monitors, while allowing "new" clients to take advantage of this to render at the higher resolution when the surface is displayed on the scaled output. It is similar to set_buffer_transform in that the buffer is stored in a transformed pixels (in this case scaled). This means that if an output is scaled we can directly use the pre-scaled buffer with additional data, rather than having to scale it. Additionally this adds a "scaled" flag to the wl_output.mode flags so that clients know which resolutions are native and which are scaled. Also, in places where the documentation was previously not clear as to what coordinate system was used this was fleshed out. It also adds a scaling_factor event to wl_output that specifies the scaling of an output. This is meant to be used for outputs with a very high DPI to tell the client that this particular output has subpixel precision. Coordinates in other parts of the protocol, like input events, relative window positioning and output positioning are still in the compositor space rather than the scaled space. However, input has subpixel precision so you can still get input at full resolution. This setup means global properties like mouse acceleration/speed, pointer size, monitor geometry, etc can be specified in a "mostly similar" resolution even on a multimonitor setup where some monitors are low dpi and some are e.g. retina-class outputs.
-