this commit introduces the setting of the index. Setting the index here
means that the layout with the id 0..n, out of the compiled keymap file
will be used. After a new index is set the modifiers are updated, that
the client are aware of the new resulting group.
If the api is called before the compositor is inited (this can happen
in e_xkb, so the drm can use the keymap at startup) then the index is
saved in between and will be flushed once the compositor does the init.
This adds compositor handling of DMABuf buffers. DMAbuf capabilities
are advertised for the drm back-ends, and DMAbuf buffers are handled
as native surfaces.
When running as a wayland compositor connected to another wayland
compositor, we don't want to advertise dmabuf capabilities if the
parent compositor doesn't support them.
If it does, we'll want to proxy dmabuf requests to it instead of handling
them ourselves.
Expose this as new bools in e_comp_wl.
- remove (wrong) global variables which tracked client-specific resources
- start ping upon creating a shell surface
- track client-specific shell resources on a per-client basis
maximize is client-initiated and compositor-enforced in wayland, meaning that a
maximize should only be acted upon in the compositor after the client has
acknowledged that it has transitioned into the maximized state (likely removing
part of its csd region) and has resized itself to match the expected maximize
size
fix T3297
xdg shell configure states (maximize, fullscreen) return a client ack when the
client has applied the state. the ack, followed by the next surface commit,
indicates that the surface is ready to be transitioned into the configured state
This code is similar to code in weston, but doesn't really work properly
for us in E, since this can blow up buffers behind the async renderer's
back.
The rest of the reference code has been pushed into e_pixmap, so we can
kill this all now.
We need to keep wayland buffers around even if they'll never be written
to again. This is part of Buffer_Reference's task in weston, but we
already have our pixmap abstraction which can serve mostly the same
purpose.
Remove the "buffer reference" stuff from e_pixmap and replace it with a
kept buffer for the last commit.
Add shared memory pool references to keep pools from going away on us.
a cursor client should be shown/hidden as needed despite its lack of a
shell interface, and having a special flag to identify these types of
surfaces makes it easier to do that
when attaching a buffer, it's necessary to have the state available
in order to pull the buffer data into the state for use during commit
fixes subsurface frame callbacks
(2) e.src(s): add keyboard.repeat_delay, keyboard.repeat_rate into e.src files
Summary:
As of now, the default values of repeat delay/rate are being set in e_comp_wl.c.
Those values need to be configurable and will be used in e_comp_wl_init().
The limit of each of the values is defined from -1 to 1000. (maximum 1s).
If one of the two is negative, it means default repeat delay/rate are going to be used.
(e.g. delay:400, rate:25)
Test Plan:
N/A
Signed-off-by: Sung-Jin Park <input.hacker@gmail.com>
Reviewers: raster, stefan_schmidt, gwanglim, devilhorns, zmike
Subscribers: Jeon, ohduna, cedric
Differential Revision: https://phab.enlightenment.org/D3364
Summary:
this patch allow to use virtual keyboard such as weston-keyboard.
it was tested in wayland verion 1.6.
Test Plan:
<prerequisite>
- Configure with --enable-wl-text-input
- edit configuration file, e.cfg to enable module wl_text_input.
1. run enlightenment as a wayland display server.
2. run weston-keyboard.
3. run weston-editor.
Reviewers: raster, Sergeant_Whitespace, devilhorns, zmike
Reviewed By: zmike
Subscribers: ManMower, Sergeant_Whitespace, cedric, jihoon
Differential Revision: https://phab.enlightenment.org/D2275
when not resizing, the sizes passed to configure should be based on the
window size and not the surface size. in order to calculate this, it's
necessary to keep track of the last-known window geometry for non-maximized
states and create offsets with which to calculate new sizes
this fixes directional maximizes as well as unmaximizing
this prevents keys from immediately being sent to newly-focused clients
and avoids the case of reverting focus from one app to another on keybind
close, only to have the second app also close immediately using the same keybind
it is now possible to create a xephyr window in a drm-enlightenment session,
launch wl-x11 enlightenment in xephyr, and then launch wl-wl enlightenment
inside that enlightenment
the primary limitation on this output module is that all internal windows will
appear in the outer compositor due to the current restriction of ecore-wayland
with regard to only having a single global display server connection
#Inception
in order to maximize the amount of reused code the following details the current
process for xwayland compositing:
* get map request from window
* force reparenting
* show window
* await WL_SURFACE_ID x11 message
* move x11 client data + pixmap onto corresponding wayland client
* business as usual with wayland compositing
this is pretty similar to the method of the reference code in weston,
except that there's no x11 compositor in weston