On 09/19/2016 05:27 PM, Guilherme Íscaro wrote: > On Fri, Sep 16, 2016 at 6:17 PM, Christopher Michael <cp.mich...@samsung.com >> wrote: > >> On 09/16/2016 05:11 PM, Guilherme Íscaro 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. >>> - >>> >> >> I still maintain that any functions dealing with a single specific seat >> are going to come back and bite you when true multi-seat is >> implemented... perhaps (for those type of functions) they should have a >> parameter "seat" or something ??? If no seat is passed in, then assume >> "default" seat... >> >> dh >> > > Hey Christopher, > > In teori we plan to refactor evas_canvas_pointer_canvas_xy_get() and make > it use evas_canvas_seat_pointer_canvas_xy_get() internally. Do you think > this might be a problem as well ? > >
I think that, eventually, when True multi-seat is supported (systemd/logind multiseat), Any API functions which assume "default" seat are going to end up (likely) having to be changed in order to support devices which are Not on the default seat. If we would like to be proactive and look to the future (without causing us major headaches at that time), then (IMO) these API functions should also take a "seat" parameter. When dealing with the "default" seat, that parameter can just be passed a NULL. dh >>> 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 >>> - >>> >>> 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). >>> - >>> >>> 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….); >>> - >>> >>> 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. >>> - >>> >>> 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_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. >>> >>> >>> >>> = 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 >>> the event. >>> >>> >>> - >>> >>> 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 ;-) >>>> >>>> >>>> -- >>>> Gustavo Sverzut Barbieri >>>> -------------------------------------- >>>> Mobile: +55 (16) 99354-9890 >>>> ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
