P3
As one of the glass platforms, Monocle has a number of underlying sub-platforms that share some implementation details.
Adding a new sub-platform requires a number of new Java classes (e.g. FooPlatformFactory, FooPlatform, FooScreen, FooAcceleratedScreen, FooCursor) to be added, which pollutes the repository.
Most of the code in this classes is similar to the code in parallel classes (e.g. FooPlatform and BarPlatform), and the main differences in the native implementations.
The native libraries can be separate libs per sub-platform, as is already the case with the EPD sub-platform.
This issue is not about refactoring the whole Monocle approach, but tackling the specific case where different implementations for talking to a framebuffer all require their own Java classes.
In particular, the Dispman sub-platform is being phased out in favor of a gbm-drm subsystem. Switching between Dispman and gbm-drm should be as simple as providing a system property (e.g. monocle.subplatform) but it should not require a new set of Java classes.
Adding a new sub-platform requires a number of new Java classes (e.g. FooPlatformFactory, FooPlatform, FooScreen, FooAcceleratedScreen, FooCursor) to be added, which pollutes the repository.
Most of the code in this classes is similar to the code in parallel classes (e.g. FooPlatform and BarPlatform), and the main differences in the native implementations.
The native libraries can be separate libs per sub-platform, as is already the case with the EPD sub-platform.
This issue is not about refactoring the whole Monocle approach, but tackling the specific case where different implementations for talking to a framebuffer all require their own Java classes.
In particular, the Dispman sub-platform is being phased out in favor of a gbm-drm subsystem. Switching between Dispman and gbm-drm should be as simple as providing a system property (e.g. monocle.subplatform) but it should not require a new set of Java classes.
