On 09/14/2016 11:59 AM, Guilherme Íscaro wrote: > 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 ? >
You can ignore my comments wrt this. I was thinking of multiseat along the lines of the systemd/logind type of multiseat. > >> >>> - >>> >>> 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. > That's ok .. was probably just overlooked :) > >> >>> >>> 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 :] > Yea, would make sense to do that for multi-seat :) > >> >>> >>> 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 > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
