On Tue, Sep 13, 2016 at 8:17 PM, Cedric BAIL <cedric.b...@free.fr> 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). > > > 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). > About the events - In Ecore_Wl2 section we said that after a wl_keyboard/wl_seat is added we would generate an ecore_event for that notifying that a new device is available. This event_info will be the Efl_Input_Device itself. Is this ok? We can do the same thing for focus, inform the object + seat + device itself. > > - > > > > 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 ? > Just wanted to keep the API sane. Should we ignore this one? > > > - > > > > 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). > Indeed, our idea was to implement refactor the old functions to use new seat functions passing the default seat as argument. > > > - > > > > 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. > ok > > > - > > > > 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); > We did 3 separated functions to make it easir for an user to start using vnc with he default configuration, but I see no problem in your approuch. > > > - > > > > 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. > Awesome. I will take a look once it's ready. > > > = 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 > Thanks. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
