On 09/13/2016 07:17 PM, Cedric BAIL wrote: > Hello, > > On Tue, Sep 13, 2016 at 3:00 PM, Bruno Dilly <bdi...@profusion.mobi> wrote: >> We’re working on improve EFL to support multi-seat in the same application >> window. > > For people who do not know what multi-seat means in this context, we > are talking about allowing multiple set of keyboard/mouse grouped into > seat behave independently in the same application. There is no toolkit > that support this at the moment, but Wayland/Weston does as you can > see in this video: https://www.youtube.com/watch?v=WO2L_ihO_rI . This > has nothing to do with systemd/logind multi seat, which actually > account to a group of screen/keyboard/mouse per user just sharing the > same CPU (like an hold X terminal on a mainframe). >
Ok, some of my previous comments may not entirely apply then. I was thinking in the systemd/logind context.... dh >> For make it doable, we’re considering the following approaches: >> >> - >> >> When using Wayland (Weston compositor) just get seat information from it >> - >> >> 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? >> So we could create dev branches and avoid keeping our work on external >> repositories and making our workflow a bit more straightforward? > > Sure, we have the probie status for that purpose. With the large work > to be done here, I don't think there is any problem to let you become > probies. Please send me your info.txt properly filled and a ssh public > keys. I will wait for a week before pushing it to let a chance to > everyone to complain here if they feel like it is not motivated. > >> 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]”. > > Wouldn't it make sense to actually just give internally a number to > each seat and use this as a mapping ? This way instead of a hash, you > would have an array, which is nicer for just holding a pointer I > think. Also I don't see anywhere in your proposal any event to notify > the registration/unregistration of a seat. This will be necessary in > the future for handling for example focus in elementary. There is an > EFL_CANVAS_EVENT_DEVICE_CHANGED, but I don't think it match the use > case. Would an EFL_CANVAS_EVENT_DEVICE_ADD and > EFL_CANVAS_EVENT_DEVICE_DEL make sense to everyone ? Speaking of event > you have also not talked about the focus event (object and canvas). > >> - >> >> 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 > > For what purpose ? > >> - >> >> 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. > > It will be nice in code to refactor evas_canvas_pointer_canvas_xy_get > to reuse evas_canvas_seat_pointer_canvas_xy_get. Also at this stage, I > think none of the multi seat function should be part of the legacy API > and the efl/eo interface should all be multi seat by default (If you > pass NULL as a device, I think it should target the default seat). > >> - >> >> evas_object_focus_set() - Will set/unset the focus only for the default >> seat. >> - >> >> evas_object_focus_by_seat_set() should be added > > Same as above. > >> - >> >> evas_event_feed_hold - Will act in the default seat >> - >> >> Add evas_event_feed_hold_by_seat() - Should we support this ? >> - >> >> Add evas_device_seat_get(Evas_Device *dev); > > What will be the purpose of this function ? > >> - >> >> We may create a helper function in Efl_Input_Device::seat_get >> - >> >> All evas_event_* functions will work on the top most seat. 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_event functions are legacy only and mostly used internaly. I > think we can just go with extending them and refactor the old version > to call the new version with a NULL for seat. > >> - >> >> 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. > > Hum, why not the following instead of 3 differents functions : > > Ecore_Evas_VNC_Handler *ecore_evas_vnc_server_add(Ecore_Evas *ee, > const char *addr, int port, Cb accept_cb); > void ecore_evas_vnc_server_del(Ecore_Evas_VNC_Handler *h); > >> - >> >> 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. > > I am working on Efl_Canvas_Output (in Evas). This enable the > possibility to define specific output from a canvas and you can have > multiple output at the same time. If no output is set, we have the > same behavior as today. If an output is set, it will only render the > part of the canvas covered by that output. Each output is backend > specific and can be extended by some custom engine info, but if no > engine information is provided, it will just create a buffer. An > output is also always also providing an Efl.Gfx.Buffer API and allow > to get pixels back (I only plan to implement it for software backend > at the moment, but it could be extended for OpenGL backend later). > > The use case for this feature are multi screen support in Wayland (and > maybe improving the X one by limiting the size of the output to each > screen instead of a max of both), screen casting, wireless display and > remote display. I should be done by end of next week if everything > goes as planned. > >> = 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. >> - >> >> 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. > > I am not versed enough in Wayland, so will let Chris and Derek comment here. > >> = 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 >> - >> >> Ecore_Seat * ecore_input_seat_find(const char *name) > > Thanks, > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
