> On Aug 2, 2017, at 3:33 AM, Lutz Vieweg <[email protected]> wrote: > > 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.
That makes sense. We don't have a daily/test build for Arch. And that shouldn't be all that hard to do, anyway. Given all the changes lately that might be a great idea. >> 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 unions-fuse. OK >> 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. :-) ) I have a Perdix and a Linux system that I could try it on. You seemed to say that BT wasn't supported at all, that's why I didn't even look, yet. >>> - 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. And Marble is going away, anyway. We still have panning and zooming in the QtLocation based maps, though. >>> 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). The AppImage needs more work for sure. The one I posted crashes :-( That's on my todo list, but I may run out of time before heading on non diving, non hacking family vacation. /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
