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). > 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, -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
