Hey guys, Here's a version 2.
= Changes on Evas =
_Evas_Public_Data should contain a hash indexed by seat of focused
Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
evas_canvas_focus_get() should return the object focused by the default
evas_canvas_pointer_canvas_xy_get() Should return the XY from the
evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
evas_canvas_pointer_canvas_xy_get(), however it returns the XY based on the
evas_object_focus_set() - his function will be refactored to use
evas_canvas_object_focus_by_seat_set() should be added
Evas will automatically create Evas_Devices
All functions that handle multi-seat should be implement as non-legacy,
this is using EO.
For every new Evas_Device creation an event
(EFL_CANVAS_EVENT_DEVICE_ADD) should be generated containing the new
When a device is removed another event will be generated
Every time an object/canvas receives focus a new event will be
generated. The event
will contain the device itself that generated the focus event and the
Add new EO event functions: evas_canvas_event_*(EO *evas, Evas_Device
*device_that_originated_the_event, ...Event Args….);
All the existing evas_events_*() functions will be refactored to use
the new event functions passing NULL as device, this will flag
belongs to the default seat.
Internally EFL will be refactored to replace the old evas_event_*
functions and use the new ones.
= Changes on Ecore_Evas =
Eina_Bool ecore_evas_x11_vnc_server_start(Ecore_Evas *ee, const char
*addr, int port, Accept_Client_Cb cb, void *cb_data); -> This will enable
vnc server for the ecore_evas x11 module.
The Accept_Client_Cb will have the following signature: typedef
Eina_Bool (Accept_Client_Cb)(void *data, Ecore_Evas *ee, const char
*client_addr). This callback should return EINA_TRUE to accept the VNC
client or EINA_FALSE otherwise.
The struct _Ecore_Evas_Interface_X11 should contain a new function with
the following signature Eina_Bool _setup_vnc_server() that will create the
vnc server and start listening for clients.
Ecore_Evas_x11 will create Efl_Input_Devices for every new user and set
the emulated seat.
In case of x11 - For every new vnc client an Efl_Input_Device will be
created and added to the Evas canvas.
= Changes on Evas x11 engine =
A callback will be created in order to notify the ecore_evas_x11 backend
with the modified pixels. This will be used to properly draw the VNC remote
= Changes on Ecore_Wl2 =
Implement the _seat_cb_name() function in order to collect the seat name.
For every wl_pointer/wl_keyboard/wl_seat it will be create an
Efl_Input_Device. The wl_pointer and wl_keyboard will have the wl_seat as
parent. After creation of these Efl_Input_Devices an ecore_event will be
generated, so ecore_evas_input can grab it and properly add the devices
into the canvas.
= Ecore =
Ecore_Events structs should contain the Efl_Input_Device that originated
These functions may be useful:
Eina_List *ecore_input_seats_get() - Return all the available seats
- Ecore_Seat * ecore_input_seat_find(const char *name)
On Fri, Sep 16, 2016 at 12:51 PM, Gustavo Sverzut Barbieri <
> On Thu, Sep 15, 2016 at 10:47 PM, Derek Foreman <der...@osg.samsung.com>
> > On 15/09/16 10:51 AM, Gustavo Sverzut Barbieri wrote:
> >> On Wed, Sep 14, 2016 at 3:42 PM, Derek Foreman <der...@osg.samsung.com>
> >>> Wayland does have separate focus for pointer, keyboard, and touch
> >>> a seat - and there's no "seat focus" at all.
> >> Ok, that helps so we'll basically add focus per device, since your
> >> previous explanation that there is a single pointer/keyboard/touch per
> >> seat, it should work nice. For us it avoids one "parent lookup" to
> >> figure out the seat of a given device :-)
> >> BUT one thing that we need to understand is the relation between
> >> pointer/touch and keyboard focus, this is particularly important so we
> >> plan a solution that works for legacy EFL (or any toolkit that has a
> >> single focused object).
> >> Usually we have one focused object (ie: text entry). Clicking or
> >> taping (touch) it, will focus. Then typing at the keyboard will send
> >> keys there. If you use the keyboard to cycle focus (ie: Tab), then
> >> that object previously focused by pointer/touch is unfocused and a new
> >> one is focused.
> >> If pointer and touch are not changing that focus where keyboard send
> >> key presses... what are they use? This is why we're planning per-seat
> >> focus: be click, tap or "Tab", change the focused object where the
> >> next key press will be delivered.
> > Well, in wayland "activation" (window is "focused" and decorates itself
> > as such) is sent separately from input events. Pointer focus generally
> > means the pointer is inside a window - whether that activates the window
> > or not is up to the compositor (focus follows mouse vs click to focus,
> > On weston, when you mouse into a window it will receive a pointer enter
> > event (and have pointer focus) before it receives any pointer motion
> > events - but it won't be activated unless you click. Weston also sets
> > the keyboard focus when you click.
> > But I'm talking about how the compositor delivers events, not how
> > applications use them (pointer, touch, keyboard may focus on difference
> > surfaces in wayland... but how an application focuses widgets on its
> > canvas is entirely up to the application?)
> > Wayland doesn't know anything about "widget focus". That's up to the
> > application to define.
> >> The idea of multi-seat here is to allow 2 users to simultaneously use
> >> the same application window, like 2 text entries, each user would be
> >> sending text to his own entry (we're not attempting to do multi-user
> >> edit of the same text-entry, as that will be much more complex given
> >> Evas textblock).
> > I think it's probably completely reasonable to think of a seat as having
> > a focus at this level.
> nice, it was more like a terminology and scope thing then :-)
> >> Another use is to allow 2 users to interact with different edje drag
> >> parts, or in a game you can control 2 players at once.
> > A shame libinput doesn't do anything for gamepads. I'll assume that's
> > outside of the scope of this work. :)
> maybe another day ;-)
> Gustavo Sverzut Barbieri
> Mobile: +55 (16) 99354-9890
> enlightenment-devel mailing list
enlightenment-devel mailing list