[libcamera-devel] [PATCH] android: Split HAL to it's own shared library
Kieran Bingham
kieran.bingham at ideasonboard.com
Thu May 6 14:25:23 CEST 2021
Hi Jacopo,
On 03/05/2021 09:29, Jacopo Mondi wrote:
> Hello,
>
> On Mon, May 03, 2021 at 09:13:31AM +0100, Kieran Bingham wrote:
>> Hi Laurent,
>>
>> On 03/05/2021 08:58, Laurent Pinchart wrote:
>>> Hi Kieran,
>>>
>>> On Sun, May 02, 2021 at 09:02:45PM +0100, Kieran Bingham wrote:
>>>> On 01/05/2021 21:54, Laurent Pinchart wrote:
>>>>> On Fri, Apr 30, 2021 at 04:02:19PM +0100, Kieran Bingham wrote:
>>>>>> The libcamera Android HAL implementation should not be an integral part
>>>>>> of libcamera, but a support library that utilises the libcamera public
>>>>>> API.
>>>>>>
>>>>>> Move the implementation to it's own distinct library.
>>>>>>
>>>>>> Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
>>>>>> ---
>>>>>>
>>>>>> Please note that this no longer requires ChromeOS to manually symlink
>>>>>> into the camera_hal directory.
>>>>>>
>>>>>> A modification similar to the following should be applied to the Chrome
>>>>>> ebuilds if this is applied:
>>>>>>
>>>>>> diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild
>>>>>> index 433357f1ef74..cf90e438cfb3 100644
>>>>>> --- a/media-libs/libcamera/libcamera-9999.ebuild
>>>>>> +++ b/media-libs/libcamera/libcamera-9999.ebuild
>>>>>> @@ -57,6 +57,4 @@ src_compile() {
>>>>>>
>>>>>> src_install() {
>>>>>> meson_src_install
>>>>>> -
>>>>>> - dosym ../libcamera.so "/usr/$(get_libdir)/camera_hal/libcamera.so"
>>>>>> }
>>>>>
>>>>> Could you submit a patch to CrOS ?
>>>>>
>>>>>> src/android/meson.build | 10 ++++++++++
>>>>>> src/libcamera/meson.build | 11 -----------
>>>>>> src/meson.build | 7 +++----
>>>>>> 3 files changed, 13 insertions(+), 15 deletions(-)
>>>>>>
>>>>>> diff --git a/src/android/meson.build b/src/android/meson.build
>>>>>> index 2be20c97e118..6170448a73ce 100644
>>>>>> --- a/src/android/meson.build
>>>>>> +++ b/src/android/meson.build
>>>>>> @@ -3,6 +3,7 @@
>>>>>> android_deps = [
>>>>>> dependency('libexif', required : get_option('android')),
>>>>>> dependency('libjpeg', required : get_option('android')),
>>>>>> + libcamera_dep,
>>>>>> ]
>>>>>>
>>>>>> android_enabled = true
>>>>>> @@ -66,3 +67,12 @@ android_camera_metadata = static_library('camera_metadata',
>>>>>> android_camera_metadata_sources,
>>>>>> c_args : '-Wno-shadow',
>>>>>> include_directories : android_includes)
>>>>>> +
>>>>>> +android_hal = shared_library('android-hal',
>>>>>
>>>>> android-hal.so won't be a very descriptive name. Maybe libcamera-hal.so
>>>>
>>>> I started out with libcamera-hal, but then I decided I didn't like it so
>>>> I updated to android-hal ...
>>>>
>>>> Given that this is an android-hal implementation I thought that was
>>>> /more/ descriptive ...
>>>>
>>>> otherwise libcamera-hal sounds like it's an abstraction layer of libcamera.
>>>>
>>>> If you prefer libcamera-hal I'll change it back.
>>>
>>> Following that logic, every shared object on a Linux system should be
>>> called linux-* :-) Given that we may have different HAL implementations> in the same directory (both multiple camera HAL implementations in
>>> Chrome OS, and multiple HALs for unrelated devices in Android), it's
>>> important for the file name to specify the project and possibly the fact
>>> that it's related to cameras. With 'libcamera' as the project name, both
>>> goals are reached :-)
>>
>> Well ... maybe the Linux Abstraction Layer for Android could be called
>> linux-hal (ok, too meta, because Android is on top of Linux) ... but the
>> difference is the perspective. If this was installed on android then
>> yes, I see your point - but we don't (currently) install on android,
>> only chrome ;-) - where it is the 'android-hal' much like the 'libc' is
>> the c library...
>
> FWIW I second naming the newly introduced .so as libcamera-hal.so.
>
> As an example Cros currently ships two HALs on Soraka, intel and usb.
> Both implement the Android Camera3 API, why aren't they both called
> android-hal.so ?
Interestingly, On CrOS for IPU3 the intel hal builds a libcamera_hal.so
which is renamed to intel-ipu3.so by the installation:
chipset-kbl/media-libs/cros-camera-hal-intel-ipu3/cros-camera-hal-intel-ipu3-0.0.1-r617.ebuild
cros-camera_dohal "${OUT}/lib/libcamera_hal.so" intel-ipu3.so
and the chipset-rk3399 variant does the same thing:
cros-camera_dohal "${OUT}/lib/libcamera_hal.so" rockchip-isp1.so
Of course the catch is here, that our .so supports both, or all
platforms ;-)
> The HAL naming scheme usually reports the platform/camera manufacturer
> (unless you know there will always be a single HAL on your systems, so
> you can call it camera.so and that's it). Having 'libcamera' in the
> name is important to make sure we won't conflict with other components
> at install time, as they can claim to be the 'android-hal' of the
> system as well.
>
> Not to mention Android has several HAL, one for each subsystem, so
> this should at least be 'camera-hal.so' if we want to stay generic.
>
> Furthermore HAL is a pretty Android-specific thing, I don't think it
No - I believe HAL means "Hardware Abstraction Library" It's a very
common terminology, and I've encountered in in many places.
> needs to have 'android' in the name to make clear what API we
> implement.
As it stands here, this library is a libcamera based implementation of
the Android Camera HAL.
If we had to implement other Camera API's on top of libcamera, perhaps
imagine if we implemented a GenICam API ... - That is a Hardware
Abstraction Layer too ...
What would that be called?
libcamera-genicam.so?
Or would that also be handled in this same .so object?
And (ok, pushing the boat out) but what if we ended up supporting
windows, mac, or freebsd, fuchsia?
Would the support for those be
libcamera-hal.so
or
libcamera-mac-hal.so
libcamera-windows-hal.so
libcamera-freebsd-hal.so
libcamera-fuchsia-hal.so
(Wow, are OS's supposed to have 7 letters or something)
>> I guess it could be the libcamera-android-hal.so too
>
> Repeating 'android' in the 'hal' name is of no use imho.
>
> libcamera-hal.so is a perfectly fine name for the libcamera-based camera
> HAL. What are you afraid this can be confused with ?
My concern is that 'HAL' does not say much. It means 'android' to you -
but that's not a given.
And maybe that's the point we're arguing. Perhaps
libcamera-android.so
would be acceptable?
(If you're suggesting that it's the '-hal' suffix you don't think is needed)
>> Perhaps if Chrome decided not to use the Android HAL but to use a
>> wrapper on top of libcamera directly, I could imagine that could be
>> called the libcamera-hal for instance.
>
> They would call into libcamera.so in that case, don't they ?
I guess it depends on how they construct it. They might want a
centralised wrapper component to call into to handle all the things like
what chrome-specific hardware acceleration to apply on top...
And perhaps that would be the libcamera-hal from their perspective.
> What's
> the purpose of an HAL if not to behave like an HAL? HAL is not just a
> naming suffix, but a combination of the right exported symbols and the
> right C-API that makes it possible for the library to be loaded at
> run-time by the Android framework, and all of this is -very- Android
> specific.
I think we're talking across terms here. Yes, a HAL is an implementation
of a set of exported symbols to provide an interface to talk to hardware.
An *android camera HAL* is indeed that. But it's to implement the
android camera hal specifically.
A 'HAL' is ... just a generic term though, and it doesn't say "Which"
API it is implementing.
> Thanks
> j
>
>>
>> --
>> Kieran
>>
>>
>>>>> ?
>>>>>
>>>>>> + android_hal_sources,
>>>>>> + name_prefix : '',
>>>>>> + link_with : android_camera_metadata,
>>>>>> + install : true,
>>>>>> + cpp_args : libcamera_cpp_args,
>>>>>> + include_directories : android_includes,
>>>>>> + dependencies : android_deps)
>>>>>
>>>>> Without install_dir, this will get installed in /usr/lib/, which isn't
>>>>> where the CrOS camera service will look for it. We probably need a
>>>>> configuration option to set the path, as it will differ between CrOS and
>>>>> Android.
>>>>
>>>> But I have install_dir ... uhm ... Ok so I forgot to save out the
>>>> updated patch before sending ...
>>>>
>>>> It's there in the next version already ;-) ...
>>>>
>>>>> +android_installdir = get_option('libdir')
>>>>> +
>>>>> if get_option('android_platform') == 'cros'
>>>>> libcamera_cpp_args += [ '-DOS_CHROMEOS']
>>>
>>> Extra space.
>>>
>>>>> + android_installdir = get_option('libdir') / 'camera_hal'
>>>>> endif
>>>>
>>>> Will install it to camera_hal directly when the platform is set.
>>>
>>> Should install be set to true on CrOS only ? On Android meson isn't used
>>> anyway, and on other systems, the Android HAL isn't needed.
>>
>> If it isn't needed, then don't build it (i.e. don't enable android)?
>>
>> And if it doesn't need to be installed (i.e. just compile testing) well
>> then there's no need to call the install ...
>>
>>
>>
>>>>>> diff --git a/src/libcamera/meson.build b/src/libcamera/meson.build
>>>>>> index e0a48aa23ea5..f77b80b878d8 100644
>>>>>> --- a/src/libcamera/meson.build
>>>>>> +++ b/src/libcamera/meson.build
>>>>>> @@ -129,16 +129,6 @@ libcamera_deps = [
>>>>>> dependency('threads'),
>>>>>> ]
>>>>>>
>>>>>> -libcamera_link_with = []
>>>>>> -
>>>>>> -if android_enabled
>>>>>> - libcamera_sources += android_hal_sources
>>>>>> - includes += android_includes
>>>>>> - libcamera_link_with += android_camera_metadata
>>>>>> -
>>>>>> - libcamera_deps += android_deps
>>>>>> -endif
>>>>>> -
>>>>>> # We add '/' to the build_rpath as a 'safe' path to act as a boolean flag.
>>>>>> # The build_rpath is stripped at install time by meson, so we determine at
>>>>>> # runtime if the library is running from an installed location by checking
>>>>>> @@ -147,7 +137,6 @@ endif
>>>>>> libcamera = shared_library('camera',
>>>>>> libcamera_sources,
>>>>>> install : true,
>>>>>> - link_with : libcamera_link_with,
>>>>>> cpp_args : libcamera_cpp_args,
>>>>>> include_directories : includes,
>>>>>> objects : libcamera_objects,
>>>>>> diff --git a/src/meson.build b/src/meson.build
>>>>>> index 64d22b9ce5b6..9dc32751bbb1 100644
>>>>>> --- a/src/meson.build
>>>>>> +++ b/src/meson.build
>>>>>> @@ -31,11 +31,10 @@ endif
>>>>>> libcamera_cpp_args = []
>>>>>> libcamera_objects = []
>>>>>>
>>>>>> -# The 'android' subdir must be processed first, and the build targets
>>>>>> -# are included directly into the libcamera library when this is enabled.
>>>>>> -subdir('android')
>>>>>> -
>>>>>> +# libcamera must be built first as a dependency to the other components.
>>>>>> subdir('libcamera')
>>>>>
>>>>> This is really nice, having android first has been bugging me for a
>>>>> while.
>>>>
>>>> Me to, I somehow assumed last time I looked at this that there were
>>>> deeper reasons for integrating into the libcamera.so - but there wasn't
>>>> anything preventing the split really.
>>>>
>>>> Anyway, v2 to come anyway with the correct install paths, and if desired
>>>> - a rename.
>>>>
>>>>>> +
>>>>>> +subdir('android')
>>>>>> subdir('ipa')
>>>>>>
>>>>>> subdir('lc-compliance')
>>>
>>
>> --
>> Regards
>> --
>> Kieran
>> _______________________________________________
>> libcamera-devel mailing list
>> libcamera-devel at lists.libcamera.org
>> https://lists.libcamera.org/listinfo/libcamera-devel
--
Regards
--
Kieran
More information about the libcamera-devel
mailing list