Re: When to use libweston plugin registry
On Wed, 20 Jul 2016 13:49:05 +0200 Armin Krezović wrote: > On 20.07.2016 09:45, Pekka Paalanen wrote: > > Hi Armin, > > > > I didn't manage to catch you online, so here is re: > > https://paste.debian.net/hidden/ac601ed5/ > > > > Hi Pekka, > > Sorry for not being available in the past few days. I will be > once again available full time starting tomorrow afternoon. > > > Yes, that's the mechanics of using the plugin registry, but I > > didn't think of using it for those particular entries. > > > > For libweston-core <-> backend APIs using the plugin registry seems > > like an unnecessary detour. I don't see it benefiting anything. > > Libweston-core loads the backend directly and communicates with it > > directly. We also wouldn't want to expose interfaces meant only for > > the use of libweston-core. libweston-core is non-optional, so the > > flexibility is not useful. > > > > Originally plugin registry was written for plugins to interface > > with other plugins, so that we don't need to keep adding new > > plugin-specific APIs or relays to (lib)weston-core or the > > compositor. > > > > Another use case in my mind is offering optional interfaces from > > libweston and anything below it to the compositor. It might be seen > > as a layering violation since we skip over libweston-core rather > > than plumbing things through it, but in this case I think it's for > > the better. > > > > E.g. DRM-backend specific APIs might want to use libdrm, libudev or > > libinput types. If these were exposed from libweston proper, we > > would have libweston depend on all of them, regardless whether the > > compositor actually wanted the DRM-backend. It would be even more > > glaring if x11-backend had some API using XCB or X11 types, > > causing libweston to depend on libxcb. When we use the plugin > > registry for these, we don't need the extra dependencies on the > > libweston-core. The extra dependencies can be pulled in by the > > backends and the interface headers used with the plugin registry as > > needed instead of always. > > > > In summary, I'd like to see the plugin registry used for optional > > interfaces that might also come with a cost (e.g. extra > > dependencies) if offered straight from libweston proper. > > > > I still consider it optional even if it is mandatory for using a > > specific backend or feature, because compositors are free to choose > > the backend(s) and features they use. > > > > When we discussed API for configuring outputs, you mentioned that > I should consider using plugin-registry to call backend specific > functions to configure an output. > > We already have API's calling into backend specific code via > function pointers (mode switching comes to mind), so I think > it's safe to use same approach for output configuration (backend > specific parts only). > > So, to be sure, I don't need plugin-registry for such features? Hi Armin, there are two different kinds of things you should process differently. The same solution won't fit everything. The first category is functions like "destroy" and "restore" which are meant to be called by libweston (core) alone. These should not be exposed via plugin registry. Libweston loads the backend, so it can just call its functions "directly" anyway. There is nothing optional in that, whether libweston would like to use that API or not - it will always use it. Libweston is also the only user of these functions. The second category are functions offered by the backend, but meant to be called by the compositor (or plugins) and likely not by libweston. These should be exported via the plugin registry, because their availability and whatever requirements they bring e.g. dependency-wise depends on the compositor choosing to use the backend. The functions in the second category also cannot be called directly anyway, because libweston loads the backend but the caller is not libweston. Either libweston would have to wrap those functions and export them again, or we need to use the plugin registry to get to them. Output configuration functions would seem to fall into the second category, each backend offering its own, slightly different API, to be called not by libweston, but the compositor. IOW, both backend-specific, and called from outside of libweston. An example of such backend-specific configuration would be setting the video mode, resolution, or (for nested windows) size: - DRM has the whole modeline stuff you have to choose from - fbdev cannot change modes, but you might still be able to pick which /dev/fb* you want to light up - x11 can have an output of arbitrary size and create new outputs on demand - wayland backend would behave either like DRM or x11, depending on the shell interface offered by the host compositor - rdp I'm not even sure how it should behave - headless would be like x11 mostly OTOH, there could be some totally generic output configuration functions too, like setting the output position in the
Re: When to use libweston plugin registry
On 20.07.2016 09:45, Pekka Paalanen wrote: > Hi Armin, > > I didn't manage to catch you online, so here is re: > https://paste.debian.net/hidden/ac601ed5/ > Hi Pekka, Sorry for not being available in the past few days. I will be once again available full time starting tomorrow afternoon. > Yes, that's the mechanics of using the plugin registry, but I > didn't think of using it for those particular entries. > > For libweston-core <-> backend APIs using the plugin registry seems > like an unnecessary detour. I don't see it benefiting anything. > Libweston-core loads the backend directly and communicates with it > directly. We also wouldn't want to expose interfaces meant only for > the use of libweston-core. libweston-core is non-optional, so the > flexibility is not useful. > > Originally plugin registry was written for plugins to interface > with other plugins, so that we don't need to keep adding new > plugin-specific APIs or relays to (lib)weston-core or the > compositor. > > Another use case in my mind is offering optional interfaces from > libweston and anything below it to the compositor. It might be seen > as a layering violation since we skip over libweston-core rather > than plumbing things through it, but in this case I think it's for > the better. > > E.g. DRM-backend specific APIs might want to use libdrm, libudev or > libinput types. If these were exposed from libweston proper, we > would have libweston depend on all of them, regardless whether the > compositor actually wanted the DRM-backend. It would be even more > glaring if x11-backend had some API using XCB or X11 types, > causing libweston to depend on libxcb. When we use the plugin > registry for these, we don't need the extra dependencies on the > libweston-core. The extra dependencies can be pulled in by the > backends and the interface headers used with the plugin registry as > needed instead of always. > > In summary, I'd like to see the plugin registry used for optional > interfaces that might also come with a cost (e.g. extra > dependencies) if offered straight from libweston proper. > > I still consider it optional even if it is mandatory for using a > specific backend or feature, because compositors are free to choose > the backend(s) and features they use. > When we discussed API for configuring outputs, you mentioned that I should consider using plugin-registry to call backend specific functions to configure an output. We already have API's calling into backend specific code via function pointers (mode switching comes to mind), so I think it's safe to use same approach for output configuration (backend specific parts only). So, to be sure, I don't need plugin-registry for such features? > > Thanks, > pq > Cheers. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
When to use libweston plugin registry
Hi Armin, I didn't manage to catch you online, so here is re: https://paste.debian.net/hidden/ac601ed5/ Yes, that's the mechanics of using the plugin registry, but I didn't think of using it for those particular entries. For libweston-core <-> backend APIs using the plugin registry seems like an unnecessary detour. I don't see it benefiting anything. Libweston-core loads the backend directly and communicates with it directly. We also wouldn't want to expose interfaces meant only for the use of libweston-core. libweston-core is non-optional, so the flexibility is not useful. Originally plugin registry was written for plugins to interface with other plugins, so that we don't need to keep adding new plugin-specific APIs or relays to (lib)weston-core or the compositor. Another use case in my mind is offering optional interfaces from libweston and anything below it to the compositor. It might be seen as a layering violation since we skip over libweston-core rather than plumbing things through it, but in this case I think it's for the better. E.g. DRM-backend specific APIs might want to use libdrm, libudev or libinput types. If these were exposed from libweston proper, we would have libweston depend on all of them, regardless whether the compositor actually wanted the DRM-backend. It would be even more glaring if x11-backend had some API using XCB or X11 types, causing libweston to depend on libxcb. When we use the plugin registry for these, we don't need the extra dependencies on the libweston-core. The extra dependencies can be pulled in by the backends and the interface headers used with the plugin registry as needed instead of always. In summary, I'd like to see the plugin registry used for optional interfaces that might also come with a cost (e.g. extra dependencies) if offered straight from libweston proper. I still consider it optional even if it is mandatory for using a specific backend or feature, because compositors are free to choose the backend(s) and features they use. Thanks, pq pgpqxbSfVoWhS.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
