This fixes an uninitialized serial error, were we could send out the
modifier event even if the client didn't have a pointer resource. We
send out the modifier event to let clients know the modifer mask when
they receive a pointer button event. Thus, if the client doesn't have
a pointer we don't need to send the modifier event.
Additionally we would send out the modifier event with an
uninitialized serial number.
Finally, this commit restores the order of sending the modifier event
before the enter, like it used to be. Not likely to be an issue,
since the client will always receive the modifier event before any
button event, but it's a little nicer to give the client the modifier
events before it receives any pointer events.
weston-launch has two supported use cases now: either launch from
and VT login as a regular user (running within that session) or
from an init script (systemd or such) with the -u option to create
a session for the specified user. Running from within X or ssh is
not possible. It's still possible to run weston as root from X or ssh
but that's strictly a development/debug/test feature.
https://bugs.freedesktop.org/show_bug.cgi?id=69727
This is only available when running weston directly as root typically for
ssh logins. It's a somewhat destructive option, as it will take over any
existing VT completely, unless there's already an display server running
there.
https://bugs.freedesktop.org/show_bug.cgi?id=69731
The wake handler set up by the shell will try to unlock the screen
which works by setting up an animation which fades in the display. The
animation is started by first scheduling a repaint. Subsequent
repaints are scheduled whenever the previous frame is finished.
However in the case of the wake up signal the state is still
WESTON_COMPOSITOR_SLEEPING when the animation is started.
weston_output_schedule_repaint() ignores attempts to schedule a
repaint if the compositor is sleeping which means the animation never
gets run and will never complete.
The animation gets unstuck and continues if anything else schedules a
repaint after the state has been changed so the bug only gets hit in
certain conditions. The first wake up creates the lock surface which
causes a redraw when the first buffer is attached so the first wake up
is always ok. A redraw can be triggered in the subsequent wake ups
just by moving the mouse.
A good way to trigger the bug is to try to wake up the compositor by
pressing the shift key. If you let the compositor go back to sleep
after waking it up without unlocking it, the second press of the shift
key will not cause a redraw so the animation will not run and it won't
fade in.
https://bugs.freedesktop.org/show_bug.cgi?id=69719
Add drm_set_master and drm_drop_master
as wrappers for drm(Set|Drop)Master, when building compositor-drm
or as empty functions otherwise.
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Adding a check in weston_config_full_path so that
we don't crash if we started without a config file.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@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.damian@intel.com>
We'll add the GBM format code as the native visual ID for EGLConfigs
when running on GBM. This patch lets the drm backend pass in the
format code it's using with KMS and make sure we get a confing that
matches. In the future, mesa will add support for 10 bpc configs
which will match the "at least 8 color bits" requirement. By also
matching the native visual ID, we avoid rendering XRGB2101010 into a
XRGB8888 KMS framebuffer.
Previously only the touch up key event was used for single-touch
devices and the touch down event was generated on the first motion
event. This was breaking if the touch up and down events were sent
without a motion in-between because the evdev driver wouldn't generate
a touch down event and Weston would lose track of the number of touch
points that are down. This patch changes it to track the up and down
key events as pending events similar to how it does for multi-touch
devices.
https://bugs.freedesktop.org/show_bug.cgi?id=69759
Instead of having a mask of pending events there is now an enum with a
single value to represent the one pending event. The event gets
flushed explicitly as part of the handling code for each event type
rather than in the outer event reading loop. The pending event is used
so that we can combine multiple motion events into one and to make
sure that we have recieved the latest position before sending a touch
up or down event. This should fix the following problems with the old
approach:
• If you release a finger and press it down again quickly you could
get the up and down events in the same batch. However the pending
events were always processed in the order down then up so it would
end up notifying two down events and then an up. The pending event
is now always flushed when there is a new up or down event so they
will always be in the right order.
• When it got a slot event it would immediately change the slot number
and then set the pending event. Then when it flushed the events it
would use the new slot number to flush the old pending event so the
events could have the wrong finger. The pending event is now
immediately flushed when a slot event is received so it will have
the right finger.
• If you get more than 32 events in one read then it was resetting the
pending events before processing the next batch in
evdev_process_events. If four fingers were pressed down at once then
it ended up with more than 32 events and the sync message would be
in the second batch. The pending flag for the last finger was
getting cleared so it never got emitted. In this patch the pending
event is no longer reset after reading nor is it explicitly flushed.
Instead it is flushed when we receive a EV_SYN event or a different
pending event needs to replace it.
The touchpad handling code was trying to use the pending event
mechanism to notify the relative motion events. I'm not sure why it
was doing this because it looks the event would effectively get
emitted as soon as the touchpad_process function is finished anyway
and it wasn't accumulating the values. Instead I've just changed it to
emit the event directly.
https://bugs.freedesktop.org/show_bug.cgi?id=67563
Here too we must make sure the surface has a valid resource, as
there are some (xwayland, surfaces created by the shell) that
don't have it.
Fix a Weston crash when setting a mpv window fullscreen on drm.
If two fingers are released almost simultaneously then evdev can send
the touch up events in one bunch without sending a sync event
in-between. However, the evdev_device struct only keeps track of one
pending touch up event so in this case the second touch up event would
override the first and it would be lost. This patch changes it to also
flush the events whenever the slot changes so that it will flush the
previous touch up event before trying to queue the next one.
https://bugs.freedesktop.org/show_bug.cgi?id=67563
compositor.surface_list is recreated every redraw with the mapped
surfaces, but if a surface gets unmapped and then in the same frame
weston_compositor_pick_surface() is called we must make sure it
does not pick the unmapped surface, since it traverses the
surface_list to find one.
If after the unmap the surface gets also deleted it's even more
important, as it must not pick a destroyed surface.
When unmap and destroy a surface we need to make sure we don't pick it
before we rebuild the new surface list. Currently we ensure this
by rebuilding the surface list when destroying a surface, but just
removing the surface should be enough.
The Wayland protocol permits a client to request the pointer, keyboard
and touch multiple times from the seat global. This is very useful in a
component like Clutter-GTK where we are combining two libraries that use
Wayland together.
This change migrates the weston input handling code to emit the
events for all the resources for the client by using the newly added
wl_resource_for_each macro to iterate over the resources that are
associated with the focused surface's client.
We maintain a list of focused resources on the pointer and keyboard
which is updated when the focus changes. However since we can have
resources created after the focus has already been set we must add the
resources to the right list and also update any state.
Additionally when setting the pointer focus it will now send the
keyboard modifiers regardless of whether the focused client has a
pointer resource. This is important because otherwise if the client
gets the pointer later than you getting the keyboard then the
modifiers might not be up-to-date.
Co-author: Neil Roberts <neil@linux.intel.com>
This patch implements the notification of clients during mode_switch.
As discussed on IRC, clients are notified of mode_switch only when the
"native" mode is changed and activated. That means that if the native
mode is changed and the compositor had activated a temporary mode for
a fullscreen surface, the clients will be notified only when the native
mode is restored.
The scaling factor is treated the same way as modes.
the unmap event will be followed by the deletion of the weston_surface,
so the shell_surface will also be deleted by the shell. Having removed
the surface_destroy_listener, the surface_destroy callback doesn't
get called, so reset the value of shsurf here.
After the fade or zoom effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.
This patch add a reset function in weston_surface_animation to reset
some variables the effects affect.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
The struct weston_launcher object will now either handle tty and vt switching
details in-process (when running weston directly as root) or talk to
the weston-launch process.
Previously, vaapi_recorder_frame() would wait until the encoded
contents for a frame is written to the output file descriptor. This
delayed the repainting of the next frame, and affected frame rate
when capturing with high resolutions. Instead, wait only if there is
and attempted to encode two frames at the same time.
Increases framerate from 30 to 60 fps when capturing at 1920x1200 on
my SandryBridge system, although there are periodic slowdowns due to
disk writes.
it uses the Android fbdev HAL[1] (through libhybris[2])
and the libhybris implementation of wayland-egl.
Configure flags:
cairo:
--enable-glesv2=yes --enable-egl=yes
weston:
--with-cairo-glesv2 --enable-fbdev-compositor
hybris:
--enable-wayland --enable-arch=x86
--with-android-headers=<android-headers> --enable-alinker=jb
The android headers are extracted from an AOSP tree,
using hybris/utils/extract-headers.sh
[1]:
https://github.com/android/platform_hardware_libhardware/blob/master/include/hardware/fb.h
[2]: https://github.com/libhybris/libhybris
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Kristian Høgsberg
Tomeu Vizoso
Neil Roberts
Aaron Faanes
Adrian Negreanu
Alexandru DAMIAN
Pier Luigi Fiorini
Giulio Camuffo
Hardening
Axel Davy
Stefan Schmidt
Sam Spilsbury
Rob Bradford
Ander Conselvan de Oliveira
Adrian Negreanu