I was try made Godot Engine compatible with harbour store, but now i have one last error:
Libraries
=========
ERROR [/usr/bin/harbour-gdmaterials] Cannot link to shared library: libudev.so.1
INFO [/usr/bin/harbour-gdmaterials] Please see our FAQ here: https://harbour.jolla.com/faq#Shared_Libraries
FAILED
udev need for Controller Support in godot engine ( but it possible to rewrite this part to SDL2 only, but dont really want to do this )
You can ask for harbour inclusion of libudev. Maybe it can enter. Ask it at a community meeting for instance.
In the meantime, you can bundle it in your RPM (useless disk space usage but well) for instance (example given for libjpeg and libcairo) by adding:
install -d %{buildroot}/usr/share/%{name}/lib
install -m 644 -p %{_libdir}/libjpeg.so.62 %{buildroot}/usr/share/%{name}/lib/
install -m 644 -p %{_libdir}/libcairo.so.2 %{buildroot}/usr/share/%{name}/lib/
and defining an RPATH for your executable looking into /usr/share/%{name}/lib/.
You need also to add to your spec %define __requires_exclude ^libjpeg.*|libcairo.*$ somewhere to avoid your RPM to require the libraries that have been bundled. And also something like %define __provides_exclude_from ^/usr/share/.*$ to avoid your RPM to provide the bundled libraries.
i know about providing lib in package. But in my case, i has only binary file (godot export template for sailfish os), without any rpath (but it can be modified with patchelf tool). When i export my project in godot, it just pack prebuild binary and resources to RPM, i cant change rpath of binary at this moment ( without some special tool, like patchelf )
so, i have few ways:
/usr/share/<application_name>/lib, then export rpoject ( no one will do this ), and pack project with libudevpatchelf util for every arch for sailfish os, and add step for patching binary in every build, pack project with libudev ( not so long way, but not easy too )I’ll pitch for it at the next community meeting, if I can make it.
Just to clarify on one point, is the key aim here to use the Godot Engine in general (in which case it can be built without the need for libudev), or to explicitly build it with peripheral support (in which case the need for libudev is clear)?
Removing udev support would limit the development of cross-platform games. It’s easier to ‘supplement’ event handlers than rip them out. For instance, to add or simulate InputEventScreenTouch.
Presumably udev opens up a can of ‘sailjail worms’?
udev used in godot to support Controllers. And it would be great, if linking to libudev will be allowed in jolla harbour
P.S. its possible to wrtite controllers support with SDL2 API only, but its long way.
There was some good discussion today. @Thaodan mentioned some discussion from flatpak with a similar issue. In short, we probably need a permission. Though I don’t see what that has to do with linking to udev, per se? Here the relevant links.
@pvuorela had summarized:
yea, so on permission side there seem to be multiple problematic details. a) would need to get access to libudev, b) would also need access to the joypad devices but only them, c) the access to the /dev node could be problematic, there’s resource policy handling, eg two apps wanting to use the same device.
compare to e.g. bluetooth keyboard which doesn’t need any permissions and goes over wayland. might be nice if there was some similar wayland protocol for this. did find some preliminary work but that was getting old.
A slightly off-topic comment about external controllers, when using SDL input code in app at least usb and bluetooth controllers have been successfully tested with my work-in-progress OpenLara SailfishOS port.
And those are covered by --private-dev where sailjail is concerned?
I haven’t investigated which device nodes it uses for input but at least I have only enabled audio from sailjail so permissions should be quite strict. I will have to ask for strace output from the testers to check the device nodes.
i was add controller support to Quake 2 port ) based on SDL2, and work well too ) (published on openrepos)
One more aspect, the /dev/event/input* interfaces are usually used for read only. Perhaps pernissions could be granted for read?
there is also some write funtionalities for ganepads (force feedback etc), but maybe other files could be used for ir (/sys /proc & write - only)
I’m not sure it worth the hassle, but since sending the controls data over network is possible, maybe someone could build a Godot app that communicates with LÖVE framework over UDP and then I can retrieve that data and pass it to LÖVE so that the gamepad support it is extended to it…
In case anyone is interested on the workaround I’ve just explained above, I want to say that it works and you can use it from a löve to another löve instance. All you need is to connect the gamepad to a löve instance that supports gamepad (android,desktop pc) and then the controls are transmitted through UDP protocol.
If it can be done in löve framework it can also be done in godot.
Bt keyboard is a special case if its handled by lipstick/ compositor?
It would be “fairly” simple to symlink in defaultuser:defaultuser for the jail instead of root:root (/dev/input is but a symlink to sysfs after all).
also concurrent “use” of the device is a non-problem; only one user uses a gamepad; and evdev is conceived to support multiple reads in a coherent way already.
on top of this; why not forward via wayland the input events(as done for the keyboard)?
I guess the reason could be the lack of wayland interfaces?
Hm this could also be a use case for the XDG Portals project.
It has an interface specified for Input Capture:
Of course it’s not implemented yet, and engines would need to use Portals to request devices.
But it could become a nice standardized way of getting input.
Edit: meh, it depends on something called EIS to do the actual transport. Not sure it would be suitable…