On 14/09/16 10: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 <[email protected] >> 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 ?
Before taking me too seriously, please understand that I know more about wayland than EFL, and don't really follow X details and what-not... Sorry if I'm repeating things people already know. Under wayland each seat can only have one "pointer", one "keyboard" and one "touch" object. The pointer for seat "One" will be moved by all the mice in seat "One" as if they were a single device. So the problem we're discussing here simply can't happen. The seat can have 1000 mice but it can only ever have one pointer (and thus one pointer focus) Seat "Two"'s pointer can, of course, focus something else entirely, or the same thing seat "One"'s pointer is focusing. Similarly, two keyboards in the same seat act as a single keyboard (the important bit here is that all their modifiers are combined, as is their map of down keys - banging on the "a" key on keyboard two while it's held down on keyboard one will do nothing at all). Wayland does have separate focus for pointer, keyboard, and touch within a seat - and there's no "seat focus" at all. Thanks for listening to my rambling, really nice to see this progressing! Derek > >> >>> - >>> >>> 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > Thanks ! > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
