Hi, On 17 September 2016 at 06:11, Guilherme Íscaro <isc...@profusion.mobi> wrote:
> 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 > seat. > - > > evas_canvas_pointer_canvas_xy_get() Should return the XY from the > default seat. > - > > evas_canvas_seat_pointer_canvas_xy_get() - Same thing as > evas_canvas_pointer_canvas_xy_get(), however it returns the XY based > on the > seat. > - > > evas_object_focus_set() - his function will be refactored to use > evas_canvas_object_focus_by_seat_set(). > - > > evas_canvas_object_focus_by_seat_set() should be added > - > I would rather not have any new legacy function. All new or existing EO functions should have an @optional seat object (where relevant). At the moment it seems Efl.Input.Device can represent a seat, and an input device should have a seat as a parent. If this design is OK, then let's keep it that way. Note that all I did when "creating" Efl.Input.Device was convert Evas_Device to EO and avoid merging a patch where we introduce a different struct for Ecore_Device. Now, if we have device info at ecore level, it will be forwarded to evas automatically. In theory. Nothing in upstream code actually does this yet :( > 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 > Evas_Device. > - > > When a device is removed another event will be generated > (EFL_CANVAS_EVENT_DEVICE_DEL). > I agree that those 2 extra events make sense. Currently CHANGED is triggered for ADD. A legacy wrapper needs to forward a change on both add and change. > - > > Every time an object/canvas receives focus a new event will be > generated. The event > (EFL_CANVAS_EVENT_DEVICE_FOCUS_IN/OUT)/(EFL_CANVAS_ > EVENT_OBJECT_DEVICE_FOCUS_IN/OUT) > will contain the device itself that generated the focus event and the > focused object/canvas. > - > > Add new EO event functions: evas_canvas_event_*(EO *evas, Evas_Device > *device_that_originated_the_event, ...Event Args….); > There shouldn't be any new (legacy or eo) function for that. Events are not "fed" anymore but simply forged and sent with efl_event_callback_call. ecore_evas or evas do that. Legacy C API will simply not support multi-seat (only default seat / NULL). > - > > All the existing evas_events_*() functions will be refactored to use > the new event functions passing NULL as device, this will flag > that device > belongs to the default seat. > Yes. > - > > Internally EFL will be refactored to replace the old evas_event_* > functions and use the new ones. > No. As above, we don't call a feed function to feed events to evas. Instead, we send an event to evas (yes, the Evas * eo object). > = 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_vnc_server_stop(Ecore_Evas *ee); > - > > 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 > screen. > So VNC would be used to allow a second client to remotely connect to a running app on X? Interesting... Though I believe proper Wayland support for multi-seat is more important right now :) > > > > = 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. > > yes > > > = Ecore = > > - > > Ecore_Events structs should contain the Efl_Input_Device that originated > the event. > yes > > > - > > 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 < > barbi...@gmail.com> wrote: > > > On Thu, Sep 15, 2016 at 10:47 PM, Derek Foreman <der...@osg.samsung.com> > > wrote: > > > 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> > > wrote: > > >>> Wayland does have separate focus for pointer, keyboard, and touch > > within > > >>> 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, > > etc) > > > > > > 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 ;-) > > > > Best regards, -- Jean-Philippe André ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
