Notices


Reply
Thread Tools
Posts: 136 | Thanked: 285 times | Joined on Nov 2014
#51
Originally Posted by rinigus View Post
Failed
  • Jolla 1, SFOS 2.1.0.11, n=2
    • Crashed during interaction
    • comment: noticed a black square (a few pixels wide) on the top left of the screen
I can verify also similar/same results with Jolla 1 running SFOS 2.1.1.26.
 

The Following 3 Users Say Thank You to tmi For This Useful Post:
Posts: 1,671 | Thanked: 1,640 times | Joined on Dec 2010
#52
Originally Posted by rinigus View Post
I will be updating test results in this post as they come along. Only SFOS with Qt 5.6 is supported (2.1.x.y and higher), hence I am not reporting issues with the earlier SFOS versions.

All works:
  • Oneplus X, SFOS 2.1.0.11
  • Oneplus One, SFOS 2.1.1.24
  • Jolla C, SFOS 2.1.1.26
  • Sony X, unknown version
  • Jolla Tablet, SFOS 2.1.1.26

Failed
It was very 2.1.1.26 on the Sony X
 

The Following 2 Users Say Thank You to m4r0v3r For This Useful Post:
Posts: 80 | Thanked: 285 times | Joined on Dec 2014 @ Poland
#53
When I open your app on Jolla 1 without access to internet everything is ok but after enabling internet connection, map loading and output of journalctl starts to look like this:
wrz 20 00:30:29 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 0 pid = 1442
wrz 20 00:30:30 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 40 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 80 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = C0 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 100 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 140 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 180 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 1C0 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 200 pid = 1442
wrz 20 00:30:31 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
 

The Following 4 Users Say Thank You to atlochowski For This Useful Post:
Posts: 227 | Thanked: 942 times | Joined on Oct 2013 @ France
#54
Originally Posted by atlochowski View Post
When I open your app on Jolla 1 without access to internet everything is ok but after enabling internet connection, map loading and output of journalctl starts to look like this:
well spotted !
note : when launch as nemo journalctl gives the misleading message that no jiurnal is found, not that it has no rights to open it. it have to be opened as devel-su.
options -f allows to keep it displaying only new messages (like tail) , and -l allows to output full line otherwise it cuts them when too long.


so, with devel-su journalctl -fl, I get :
Code:
sept. 20 01:02:47 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
sept. 20 01:02:47 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| GPU PAGE FAULT: addr = 1C40 p
id = 17865
sept. 20 01:02:47 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A
sept. 20 01:02:47 Sailfish kernel: QSGRenderThread: unhandled page fault (11) at 0x0000004d, code 0x005
sept. 20 01:02:47 Sailfish kernel: pgd = c46c4000
sept. 20 01:02:47 Sailfish kernel: [0000004d] *pgd=00000000
sept. 20 01:02:47 Sailfish kernel: sept. 20 01:02:47 Sailfish kernel: Pid: 18028, comm:      QSGRenderThre
ad
sept. 20 01:02:47 Sailfish kernel: CPU: 1    Tainted: P        W  O  (3.4.108.20161101.1 #1)
sept. 20 01:02:47 Sailfish kernel: PC is at 0x40090ea8
sept. 20 01:02:47 Sailfish kernel: LR is at 0x40090eb1
sept. 20 01:02:47 Sailfish kernel: pc : [<40090ea8>]    lr : [<40090eb1>]    psr: 600d0030
sp : 4852f8b0  ip : 41b41510  fp : 49ce1544
sept. 20 01:02:47 Sailfish kernel: r10: 4a798d68  r9 : 4a7a9bd0  r8 : 4852f8f4
sept. 20 01:02:47 Sailfish kernel: r7 : 403357a8  r6 : 49c5b6e8  r5 : 4aaa8cf8  r4 : 00000041
sept. 20 01:02:47 Sailfish kernel: r3 : 00000000  r2 : 00000fec  r1 : 00000041  r0 : 49c5b6e8
sept. 20 01:02:47 Sailfish kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA Thumb  Segment user
sept. 20 01:02:47 Sailfish kernel: Control: 10c5787d  Table: 848c406a  DAC: 00000015
sept. 20 01:02:47 Sailfish kernel: [<c010b73c>] (unwind_backtrace+0x0/0x118) from [<c010f658>] (__do_user_
fault+0x6c/0xb4)
sept. 20 01:02:47 Sailfish kernel: [<c010f658>] (__do_user_fault+0x6c/0xb4) from [<c08a3364>] (do_page_fau
lt+0x358/0x3e8)
sept. 20 01:02:47 Sailfish kernel: [<c08a3364>] (do_page_fault+0x358/0x3e8) from [<c01002f8>] (do_DataAbor
t+0x134/0x1a8)
sept. 20 01:02:47 Sailfish kernel: [<c01002f8>] (do_DataAbort+0x134/0x1a8) from [<c08a1bd4>] (__dabt_usr+0
x34/0x40)
sept. 20 01:02:47 Sailfish kernel: Exception stack(0xdb1d1fb0 to 0xdb1d1ff8)
sept. 20 01:02:47 Sailfish kernel: 1fa0:                                     49c5b6e8 00000041 00000fec 00
000000
sept. 20 01:02:47 Sailfish kernel: 1fc0: 00000041 4aaa8cf8 49c5b6e8 403357a8 4852f8f4 4a7a9bd0 4a798d68 49
ce1544
sept. 20 01:02:47 Sailfish kernel: 1fe0: 41b41510 4852f8b0 40090eb1 40090ea8 600d0030 ffffffff
sept. 20 01:02:47 Sailfish kernel: QSGRenderThread(17865) send signal 11 to QSGRenderThread(17865)
sept. 20 01:02:47 Sailfish kernel: booster-generic(845) send signal 11 to invoker(18015)
sept. 20 01:02:47 Sailfish kernel: invoker(18015) send signal 11 to invoker(18015)
sept. 20 01:02:48 Sailfish invoker[1134]: WARNING: An inactive plugin is misbehaving - tried to show a win
dow!
sept. 20 01:02:48 Sailfish invoker[1134]: WARNING: requestActivate() called for  QQuickView(0x1f22c58)  wh
ich has Qt::WindowDoesNotAcceptFocus set.
sept. 20 01:02:49 Sailfish kernel: [TSL277X_P][Before] raw=115, status=0, far=390, near=677
sept. 20 01:02:49 Sailfish kernel: [TSL277X_P][After] far=365, near=677, from=114, to=677
sept. 20 01:02:52 Sailfish fingerterm[13901]: [D] unknown:0 - unknown special key:  67108864
I'm on the phone without computer at end, so can't search much right now, but hope it will help and complete the previous answer.
 

The Following 3 Users Say Thank You to Zeta For This Useful Post:
Posts: 304 | Thanked: 1,348 times | Joined on Aug 2016 @ Estonia
#55
I submitted the issue at mapbox-gl-native repository, let's see if they can guide us. Used the kernel messages in the description, hopefully they contain most of the info.
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Posts: 227 | Thanked: 942 times | Joined on Oct 2013 @ France
#56
Originally Posted by rinigus View Post
I submitted the issue at mapbox-gl-native repository, let's see if they can guide us. Used the kernel messages in the description, hopefully they contain most of the info.
Thanks!
I will follow it closely to see if they need some other tests/traces.

For references for other who would want to follow it too, here is the issue link: https://github.com/mapbox/mapbox-gl-native/issues/10029
 

The Following User Says Thank You to Zeta For This Useful Post:
Posts: 304 | Thanked: 1,348 times | Joined on Aug 2016 @ Estonia
#57
Originally Posted by Zeta View Post
Thanks!
I will follow it closely to see if they need some other tests/traces.

For references for other who would want to follow it too, here is the issue link: https://github.com/mapbox/mapbox-gl-native/issues/10029
I have not been successful with the filling issues so far at mapbox-gl-native. They all got lovely stickers (Qt) and stayed unanswered. Maybe Qt backend coder is on vacation, maybe he just doesn't have too much time. In short, let's not put too much hopes on getting it magically resolved.

I'll continue coding the widget and work on testing it. When we start getting map client(s) adopting it, the exposure to the problem will increase and maybe someone skilled in GL ES will look into it. J1 is rather old and non-support for J1-type hardware will disappear eventually
 

The Following 2 Users Say Thank You to rinigus For This Useful Post:
Posts: 227 | Thanked: 942 times | Joined on Oct 2013 @ France
#58
Originally Posted by rinigus View Post
I have not been successful with the filling issues so far at mapbox-gl-native. They all got lovely stickers (Qt) and stayed unanswered.
That's only one day. I didn't expect much in less than a week. We'll see.

Originally Posted by rinigus View Post
I'll continue coding the widget and work on testing it. When we start getting map client(s) adopting it, the exposure to the problem will increase and maybe someone skilled in GL ES will look into it. J1 is rather old and non-support for J1-type hardware will disappear eventually
Yes, you shouldn't lose too much time on that. If you can get it working on the other devices, that's good !
I can still help a bit with the desktop version then (and can still test with the J1, but I have no other Sailfish phone).

Do you have some kind of roadmap or task list, to see how we could "share" tasks (taking into account you work 100 times faster than me...) ?
 

The Following 2 Users Say Thank You to Zeta For This Useful Post:
Posts: 1,388 | Thanked: 6,348 times | Joined on Apr 2010 @ Czech Republic
#59
Originally Posted by rinigus View Post
Its possible to provide location for a click since we can calculate lat/lon for any pixel. However, due to the map object living in another thread, the communication would be via request and signal back:

onClickEvent: you ask for coordinate via async mechanism. Something like "map.getCoordinates(my_tag_as_string, qpoint)

you get reply via signal:

onCoordinatesRequest: point

Then you could implement adding of other widgets on the top which will allow you to interact. Tricky with panning/rotating/tilting though. Maybe the map programs would just remove widget on rotation,tilting and follow panning signals to move it around.
Yeah, that's what I've been thinking as well - hide all the elements you put on top when user starts interacting with the map itself (drag, pinch, rotation) or if the map widget animates (switching to a new center, induced zoom/rotation/pitch change).
Still might not be always doable, for example if centering is enabled & centering is animated. That way there would basically be no time as which to show the custom widgets as the Open GL widget would be animating & asynchronously changing to arbitrary coordinates all the time.

There could still be workaround but I'll likely just try to use the polyline/polygon/marker API where possible.


Originally Posted by rinigus View Post
I would prefer to keep out from GeoJSON parsing and figuring out what did you add there. Maybe widget-added POIs could get extra support, but let's see when we get there (later this week?).
That's a good point - it should be fine to just handle the GeoJSON internally as long as there is an API that can be used to add/remove objects from the map.

A rough outline what would enable modRana support it's current map overlay feature set:

* position indicator API
- show current position & the direction of travel
- turn position display on/off

This is how the modRana position indicator looks like:



* POI marker API
usecase: show POI on the map
- add/remove markers given as a lat/lon coordinate with a label
- each marker should likely have an unique id (app provided/returned by function call ?)
- would it be possible to make the marker label clickable ? (eq. a markerClicked signal returning the id of the marker if callback registration would be too complicated)
- in general the markers & labels should be drawn on top of any polylines or polygons if possible

BTW, this is how modRana created POI markers look at the moment:



* polyline API
usecases: show tracklogs, navigation routes, live logging trace
- add/remove polylines given as ordered lists of lat/lon coordinates
- again they should have unique IDs
- for drawing routes it would he handy to be able to supply also a second list of points that would be highlighted on top of the polyline (turn points)
- alternatively this could be emulated by drawing POIs without labels for the turn points, requiring a bit extra map object management code on the application side
- for the specific use case of drawing on map trace/live logging trace (eq. basically a live trail of last visited points) an appendable polyline would be nice, if possible, as removing/adding a new polyline every location update would likely not work very well
- or there could be a special built-in "trail" polyline that would automatically track current location and could be turned on/off - that way it should be possible to avoid the trail lagging behind the position indicator

ModRana currently draws routes like this:

The yellow points are turn points and the red/green circles are start/destination designators. Tracklogs & logging traces look similar, but don't have the turn points and start/destination designators.


* polygon API
use cases: show areas of interest, map area selection
- add/remove polygons given as ordered lists of lat/lon coordinates
- again they should have unique IDs
- color selection would likely by handy to tell polygons apart
- labels are likely not needed - one can just place a labeled marker inside the polygon

ModRana currently does not draw polygons on the map.

This is just a rough outline and feedback from other potential users of the widget is certainly welcome!


Originally Posted by rinigus View Post
I suspect that by the time we will get to adding tiles into the widget, noone will want to use them. Except checking traffic in google maps layer . Probably easier to keep the tiled versions around for old hardware (if we cannot make it work on J1 and similar) or other occasional use and focus on getting vector maps supported the best.
Definitely! I guess it would be different if there were some widely available aerial/satellite map layers as that's something one can't really render from map data. But that's unfortunately not the case (unless some of the emerging small-sat constellations help with that) and we should be basically able to draw anything else.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader

Thanks to everyone who voted for modRana & Mieru in the Maemo.org coding competition !
 

The Following 3 Users Say Thank You to MartinK For This Useful Post:
Posts: 304 | Thanked: 1,348 times | Joined on Aug 2016 @ Estonia
#60
Originally Posted by Zeta View Post
That's only one day. I didn't expect much in less than a week. We'll see.

Yes, you shouldn't lose too much time on that. If you can get it working on the other devices, that's good !
I can still help a bit with the desktop version then (and can still test with the J1, but I have no other Sailfish phone).

Do you have some kind of roadmap or task list, to see how we could "share" tasks (taking into account you work 100 times faster than me...) ?
I am working on getting GeoJSON (and probably any other supported type) support into the widget. As soon as I get some elementary example working, it would be great if we can start testing the code. I do expect bugs in handling adding/updating/removing items. That would be great if you could test on desktop and we can address issues one-by-one. But to get there, I need to finish the code that we can test and write documentation for each method that needs it.

Additional help would be reading what is actually possible. I am new to Mapbox GL and I am learning by doing this interface. I wouldn't be surprised if many of MartinK requests are already supported via Mapbox GL. Not that you have to rewrite the docs, but help when we get requests on whether one or another thing is possible and help to write simple-to-use wrappers that map applications can use (add route, position marker, pois, ...)
 

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 02:21.