Hey Christopher, some comments were answered by k-s. I will add some thoughts.
On Tue, Sep 13, 2016 at 8:15 PM, Christopher Michael <cp.mich...@samsung.com > wrote: > Hi Gustavo, > > Quite a few inlined comments below, so please read whole email :) > > On 09/13/2016 06:00 PM, Bruno Dilly wrote: > > Hi folks, > > > > We’re working on improve EFL to support multi-seat in the same > application > > window. > > > > For make it doable, we’re considering the following approaches: > > > > - > > > > When using Wayland (Weston compositor) just get seat information from > it > > - > > > > What about the Enlightenment wayland compositor ?? > > > When using X11 or FB, use VNC server to gather multiple seats mapped > to > > remote clients > > > > > > To make it possible, the following changes on Evas, Ecore_Evas, Ecore and > > Ecore_Wl2 APIs are proposed. Please let us read your comments about it > =) > > > > After this work is done we’ll support it on Edje, but it’s not covered by > > this discussion (we’ll send another RFC if it seems required at the > time). > > > > Some tests and PoC were written on this repository: > > > > https://github.com/profusion/multi-seat-tests/ > > > > Also could somebody please help us creating dev accounts for Iscaro and > me? > > Uhhh, you should already have a dev account... > > > So we could create dev branches and avoid keeping our work on external > > repositories and making our workflow a bit more straightforward? > > > > Thanks in advance > > > > > > = Changes on Evas = > > > > - > > > > _Evas_Public_Data should contain a hash indexed by seat of focused > > Evas_Objects. From “pd->focused” to “pd->focused[seat]”. > > - > > > > A function similar to evas_object_top_at_pointer_get(const Evas *e) > > should be added. This new function will receive the Efl_Input_Device > (the > > seat) as argument. The old function should return the top Evas_Object > > according to the default seat > > - > > I don't think using Efl_Input_Device as "the seat" is a good idea here. > A single seat can have multiple input devices (pointer, keyboard, etc). > Efl_Input_Device (to me) implies a single input device (ie: a single > pointer, single keyboard, etc). Whereas a "seat" can have multiple > devices attached... > Well, we decided to use an Efl_Input_Device because it already exists a class that refers to a seat. In our idea every input (mouse, and keyboard) would have as parent the seat that it belongs to. > > > > > evas_canvas_focus_get() should return the object focused by the > default > > seat. > > IMO, this is not going to entirely work. In Wayland, you can have > "pointer focus", "keyboard focus", "touch focus", etc, etc ... a single > object focused by the "default" seat is not likely to cover everything. > > Pointer One on Seat One could be focused Object One, while Pointer Two > on Seat One could be focusing a different object but on the same canvas. > The function evas_canvas_focus_get should likely take some parameters > here...perhaps the seat ? Perhaps the pointer ? Not 100% sure, just > tossing out thoughts... > In this case where someone has two mices (for example) in the same seat, why not consider that the user just changed the focus from object one to object two ? > > > - > > > > 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() - Will set/unset the focus only for the > default > > seat. > > - > > > > evas_object_focus_by_seat_set() should be added > > - > > > > evas_event_feed_hold - Will act in the default seat > > - > > > > Likely all these above functions should take a "seat" as a parameter ... > Everything above is "coded" using the default seat ... What happens with > other seats ??? > > > Add evas_event_feed_hold_by_seat() - Should we support this ? > > Probably, yes... > > > - > > > > Add evas_device_seat_get(Evas_Device *dev); > > - > > > > We may create a helper function in Efl_Input_Device::seat_get > > - > > > > All evas_event_* functions will work on the top most seat. > > I think you may run into a problem in the future with this ... Have not > thought it out entirely, but (imo) limiting functions to a single "top > most" seat is likely to lead to problems in the future where there are > multiple seats... ie: What about events coming from other seats ?? > > So in order > > to add an event for ‘seat 1’ one should do: evas_device_push(evas, > > seatOne); evas_event_*(); evas_device_pop(evas); > > - > > > > Evas will automatically create Evas_Devices > > > > > > > > = Changes on Ecore_Evas = > > > > - > > > > ecore_evas_x11_vnc_server_enabled(Ecore_Evas *ee, bool enable); -> > This > > will enable vnc server for the ecore_evas x11 module. > > - > > > > 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_addr_set(Ecore_Evas *ee, const char *addr); > > - > > > > ecore_evas_x11_vnc_server_accept_cb_set(Ecore_Evas *ee, Cb > accept_cb); > > - > > > > 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 = > > > > - > > > > In _Ecore_Wl2_Input - a Eina_Stringshare * will be added to the wl > > substruct. This Eina_Stringshare * will represent the seat name. > > - > > Why ??? Ecore_Wl2_Input structure already has input->wl.seat pointer ... > Ecore_Wl2_Display already has an Eina_List of Ecore_Wl2_Seats wherein > Ecore_Wl2_Seat already contains a stringshare 'name'.... > My bad, sorry. > > > > > Implement the _seat_cb_name() function in order to collect the seat > name. > > - > > The skeleton for this is already in ecore_wl2_input.c.... > I meant to implement this skeleton :] > > > > > 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. > > > > Please see above comment about "I don't think using Efl_Input_Device as > "the seat" is a good idea here." ... It seems like above > Efl_Input_Device is a "seat", where here it is an actual Input Device.... > > > > > > > = Ecore = > > > > - > > > > Ecore_Events structs should contain the Efl_Input_Device that > originated > > the event. > > > > > > - > > > > These functions may be useful: > > - > > > > Eina_List *ecore_input_get_seats() - Return all the available seats > > Would prefer verbs last (as is EFL style) .. ecore_input_seats_get... > Oops > > > - > > > > Ecore_Seat * ecore_input_seat_find(const char *name) > > > > > > > > Cheers, > dh > > > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > Thanks ! ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
