- Nov 18, 2011
-
-
Pekka Paalanen authored
Since I have commented out all the config structures in glmatrix.c, it was not getting proper default values. Hardcode some default there. Remove glClear from reshape_matrix(), as wscreensaver does not support rendering commands in reshape call. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
Implement all the required support code for running glmatrix.c. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
Copy hacks/glx/glmatrix.c and hacks/images/matrix3.xpm from xscreensaver-5.15 distribution package. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
- Nov 16, 2011
-
-
Pekka Paalanen authored
A copy & paste bug, that resulted setting to NULL something else than shell->lock_surface when that surface was destroyed. The symptom: let compositor lock down, unlock it, let it lock down again, and the unlock dialog is never requested again. This bug was triggered by the previous fix "shell: fix compositor wakeup while locked". Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
Compositor is locked, woken up, unlock dialog is shown; if the compositor does to sleep again, before being unlocked, it will never wake up again, because unlock() becomes a no-op, yet it should wake the compositor up. Fix this by letting unlock() to wake up the compositor, if lock surface is present. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
When the lock surface was map()'d while the compositor was locked, wlsc_surface_configure() was never called for the lock surface. Hence, the surface->output was NULL, and the 'frame' event was never sent, causing desktop-shell to loop in dri2_swap_buffers(). Fix this by calling wlsc_surface_configure() for the lock surface always in map(). Additionally, adjust the comments in map() to make it more readable. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
- Nov 15, 2011
-
-
Kristian Høgsberg authored
This way we can still use surface->link when a surface is not in the main compositor surface list and don't need the hidden_surface wrapper object. Also, setting surface->output to NULL will block the surface frame callback until we put the surface back into the main list. This has the effect of blocking animations while a surface isn't visible.
-
Pekka Paalanen authored
The unclock dialog is just a normal window with a green ball in it. When you click the ball, the screen will be unlocked. Made for testing the screen locking. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
Currently, the way to destroy a window in a response to an event (e.g. button click), is to put a task into the deferred list with display_defer(). The task will then call window_destroy() from outside event handling code. As events are handled, it is possible that the deferred list contains also the redraw task for this window. As the execution order of these tasks is unknown (redrawing a freed window is a bug) and redrawing something that goes away immediately is not useful, the redraw task must be removed on window_destroy(). 'struct input' contains pointers to windows currently in focus for that input device. These pointers must also be cleared on window_destroy(). This fixes a use-after-free bug for the unlock dialog in desktop-shell (future commit). As an irrelevant minor cleanup, window::grab_device member is not used anywhere, and is removed. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
When the compositor is locked, all surfaces are moved from the compositor's list to a private list in the shell plugin. This prevents any of those surfaces from being visible or receiving input. All new surfaces will be moved to the private list, too. The background surface is an exception, it is left to the compositor's list, so the background will be painted. It is assumed that the background surface does not allow any actions while being locked. When desktop-shell announces a lock surface (an unlock dialog), it is added to the compositor's list, so the user can interact with it. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
Check that wlsc_surface::link is part of a list before assuming it is part of the compositor->surface_list list. The shell plugin may want to remove a surface from the compositor's surface list to hide it. Note, that the shell plugin cannot use wlsc_surface::link for its own purposes. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
wlsc_compositor_fade() ends up in wlsc_compositor_schedule_repaint(), which is a no-op if compositor is SLEEPING. On wakeup, first set status to ACTIVE, then call wlsc_compositor_fade() to start and actually show the animation. Before, fade was called first, which reset the animation, but did not cause a repaint. The following wakeup (any input event) would then cause a repaint, showing the animation from the middle or end of it. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
With the idle_inhibit optimization, wlsc_compositor_wake() is a no-op if idle_inhibit > 0. When the shell is waking up the compositor from SLEEPING state as an indirect response to input activity, it does not work. The call path is: notify_key() / notify_button() wlsc_compositor_idle_inhibit() wlsc_compositor_activity() shell->unlock() send prepare_lock_surface event idle_inhibit++ and when the desktop-shell client responds to the event: desktop_shell_set_lock_surface() / desktop_shell_unlock() wlsc_compositor_wake() no-op, because idle_inhibit > 0 Fix this by removing the idle_inhibit check from wlsc_compositor_wake(). The optimization did not work for pointer motion while no keys pressed, anyway, so the performance hit is probably unobservable. Now the compositor wakes up also on key or button press. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Kristian Høgsberg authored
When compositor enters SLEEPING state, the shell plugin goes locked. If compositor wakes up itself, it will fade in while the shell may not yet have a lock surface to show. Fix this by assigning wake-up to be called from the shell, if the compositor is SLEEPING. The shell may wait for the lock surface request, and only then wake up the compositor. The compositor will fade in directly to the lock screen. krh: original patch for compositor.c ppaalanen: integration and shell.c changes Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
Add protocol and functions for supporting screen locking, triggered by activity timeout. After activity timeout, compositor starts the fade to black, and then enters SLEEPING state. At that point it calls lock() in the shell plugin. When input events trigger a wakeup, unlock() in the shell plugin is called. This sends prepare_lock_surface event to the desktop-shell client. The screen stays locked while the compositor starts fade-in. At this point, desktop-shell client usually creates a surface for the unlocking GUI (e.g. a password prompt), and sends it with the set_lock_surface request. The compositor supposedly shows and allows interaction only with the given lock surface (not yet implemented). When desktop-shell has authenticated the user, or instead of issuing set_lock_surface, it sends the unlock request. Upon receiving the unlock request, the shell plugin unlocks the screen. If desktop-shell client dies, the screen is unlocked automatically. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Kristian Høgsberg authored
We can't just throw away the callback, so hold on to the requests until we have an output for the surface.
-
Kristian Høgsberg authored
-
Pekka Paalanen authored
Pass the correct pointer to free(). This is just a cosmetic change, because 'resource' happens to be the first member in wlsc_frame_callback. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
The rest of the line contains the newline, so cannot match simply 'true' or 'false'. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Kristian Høgsberg authored
According to the spec, it's ok for this not to be set and just means that we should default to $HOME/.config.
-
Pekka Paalanen authored
Add a helper function, that constructs a path to a config file from XDG_CONFIG_HOME environment variable, by the rules of http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Make desktop-shell find its config file from XDG_CONFIG_HOME. This allows to have a personal config file without continuously fighting with git about wayland-desktop-shell.ini. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
-
- Nov 14, 2011
-
-
Kristian Høgsberg authored
Drop the MeeGo part of the name.
-
Kristian Høgsberg authored
-
- Nov 11, 2011
-
-
Kristian Høgsberg authored
This is the same as the damage of the top-level surface so just use that. There's a problem that if we change the stacking, the damage layering breaks, but that's a problem we already have.
-
- Nov 09, 2011
-
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
The shell module only needs to deal with attach when it's either the initial attach or when the attach changes the size of the surface. In case of initial attach, the shell needs to pick a position for the surface and a place in the surface stack. We split this case out as a new shell->map callback. The other case is split into the shell->configure callback, where the shell may adjust the surface position or reject the new size.
-
- Nov 06, 2011
-
-
David Herrmann authored
The third parameter of open() is for file-creation modes. File flags are passed in the second paramater. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
-
- Nov 03, 2011
-
-
Pekka Paalanen authored
Check, that only the desktop-shell client spawned by the compositor (desktop-shell plugin) is allowed to bind to desktop_shell interface. Other clients will receive an error like: wl_display@1.error(desktop_shell@20, 0, "permission to bind desktop_shell denied") The error has the proper object id and interface type. Note: desktop-shell cannot be started manually anymore, it has to be started by the compositor automatically. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
Pekka Paalanen authored
Fork and exec desktop-shell in the compositor. This is a way to create an authenticated client. Later, the desktop-shell interface will be reserved for this client only. For exec to work, the compositor should be started from the wayland-demos' root directory. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
-
- Nov 01, 2011
-
-
Ander Conselvan de Oliveira authored
All the compositors are using GLES2 so check for the appropriate surfaceless extension. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
-
- Oct 29, 2011
-
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
The repaint logic breaks when finish_frame is called from the present callback. Ideally we should throttle to vsync (or even better, the compositor repaint cycle, but hey, X is X), but this goes a long way.
-
Kristian Høgsberg authored
-
Kristian Høgsberg authored
-
- Oct 28, 2011
-
-
Ander Conselvan de Oliveira authored
The drm compositor always creates a 64x64 bo for the cursor image regardless of the size of the actual cursor. When the fade animation kicks in it disables the hardware cursor so that it is rendered as a regular surface. This surface is rendered to a 32x32 region but using a 64x64 texture so the cursor gets scaled down. Fix this by making create_cursor_image return the actual size of the image created to the compositor. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
-
Casey Dahlin authored
-
Tiago Vignatti authored
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
-
Tiago Vignatti authored
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
-