On 08/01/2017 06:18 AM, Dirk Hohndel wrote:
https://transfer.sh/2tLny/subsurface-4.6.4-2-x86_64.AppImage
Really cool.
Is that a stock 4.6.4? What's the version number scheme you use?
I packaged just the Arch-Linux provided subsurface binaries, as in:
https://www.archlinux.org/packages/community/x86_64/subsurface/
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/subsurface
- that's also where the numbering "4.6.4-2" comes from.
Of course, the same could be done quickly for any other version,
provided it runs fine on some source system.
I wonder about USB devices like the Cobalt... will they need extra support
as well?
"makeaoi" reports if the "strace" it does while running
"makeaoi trace somedir subsurface" contains ioctl()s not
yet supported.
Looking at
https://github.com/libusb/libusb/blob/73d15d1f8eee372e0609d072f3df705f7de18214/libusb/os/linux_usbfs.h#L145
I would assume that usage of libusb does imply using additional
ioctl()s, but as long as it is documented what parameters/structures
they take, it is not difficult to add them to the range of ioctls()
supported by unionfs-fuse.
And then of course that whole BLE mess :-/
I may later be able to lend a BLE-talking "Perdix" for trying this.
(Of course we would know sooner if somebody owning such a device
would try. :-) )
- Qt5 seems to try using all kinds of modern X visuals and direct
rendering mechanisms, before it falls back to using plain old X11,
which is more than enough performance-wise for subsurface.
Thus I did exclude all the fancy GPU-dependent DRI modules from
the AppImage, they are not really needed and would probably bring
a lot of compatibility issues (some even use completely undocumented
ioctl).
Interesting. Does that have any impact on the visual experience of what
is actually rendered on screen?
I did not notice any visual difference. There might be "tearing" when
quickly moving the globe in a large-sized "marble" display, but that
seems of minor cosmetic relevance.
Of course, manually prepared AppImages, built on "older operating systems"
might still be the better / smaller / more compatible(?) solution, I just
thought that since it seems to be a tedious and problematic task at the
moment for the Subsurface maintainers to create more recent AppImages,
I should give the "AppImage with everything" idea a try, since it is really
not much work to create or update such images once a working executable
is available on one machine.
I have managed to fix a couple of the bugs with the current AppImage
creation and have a current 4.6.4.675 image up that I hope people will
test...
Ah, I see, in https://subsurface-divelog.org/downloads/test/
I will try to compare both AppImage versions (but can still only try the D9).
Regards,
Lutz Vieweg
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
