In reply to:


Once you're in 'empeg space', everything is WGS84.
Only the python script that massages the route does datum conversion.



You are only in WGS84 in the Empeg, if your routes are in WGS84 co-ordinates AND your GPS is outputting NMEA data to the WGS84 datum.

But I understand your point, and the conversion in the Python scripts was what I was asking about.

In reply to:


Yes, pressing the top button 'exits', however this isn't a real application exit, so all the state will still be there. i.e. we still has the same route loaded and preferences set and will immediately try to find our new location in the route when we 'start' the application again.



When you say this, do you mean that the App is still running [in memory], just not actively updating the display or doing anything in particular?

If so, then how much work to have it continue to "navigate" behind the scene, e.g. accepting NMEA sentences, parsing them and updating your co-ordinates - is that just replacing your "Wait buttons" call with a Poll keys? and then continue if none of the keys are actually pressed?

And as mentioned before, when a waypoint is reached possibly make a beep noise or some audible indicator to let you know that the waypoint has been passed?

But If the app exits, then how does it know which route was active when it restarts?
[save its info to disk - but then how does it store this saved route info by mounted the disk rw and then saving - I haven't dug into this code?].

In reply to:


I did figure out that setting an alarm provides a nice way to get unstuck from the WAITMENU ioctl, so I could have the app do something even when it isn't visibly running (popups/beeps/voiceprompts?). I can re-add that code in 5 seconds flat if you think it would be useful.



Yes, please put it back.



In reply to:


_yn0t's post:

In reply to:

(Original comment from jaharkes)
I don't think I can 'hijack' the display when I haven't officially returned from the WAITMENU ioctl


Correct, you can't. But what you *can* do is run in overlay mode using the setgeom ioctl and reserve a little window for any output you want to do.

Unfortunately this means you interfere with operation of the player depending on what buttons you're trapping, because apps that run in overlay mode still get input focus, there's no way to run multiple overlay apps.

I think once Mark's climbing season comes to an end, we'll have a very good chance of getting improvements made to the userland interface.



This all raises some interesting points/possibilities.

1. Can a Userland App have mutilple screen geometries active at once?
[if so, how does the kernel which geometry is to be used - by the file handle passed to the hijack routines by the app (the file handle returned from the open of /dev/display)]

and/or can a Userland app reliquish the current geometriy and request a new one?

[e.g. to switch from full sreen to windowed mode and v.v.].

2. Whats to stop a Userland app, requesting a tiny 1 pixel wide by high window and then using that as a way to "hook" the input focus?, this would result in net zero effect on the resulting display - while getting control of the input focus, then it can use either multiple open "geometries" to select how much of the screen it wants to write over.

3. For keys/buttons that are not hijacked, does the player app still receive them normally?
[this would make sense], or are they simply 'thrown away' by the kernel?

In the former case, what if we dedicated a particular key code sequence as a sort of "attention" button, so that when we press it, we reactivate the userland app [as it is waiting in background for this keycode to appear having done told the kernel it wants this keycode (and this one only)], while the others go to the player app in the meantime. Once this keycode appears, the pap now extends the list of hooked keys to include all those it wants when it has the focus [e.g. all the numeric keys etc, along with say arrows and menu/cancel etc buttons].
Pressing the hotkey again while the app is active, will tell the app to "hide" itself, i.e. unhook all those keys except for the hotkey and stop updating the real display, and carry on doing what you do.

Note: This same hot key, with a little assistance from the kernel in future, could be used to allow multiple background apps to sit there ready to hijack the display window [or their bit of it], and the user can activate them/give them input focus by pressing the hotkey sequence followed by say a numeric code e.g. 1-9, to select app 1, 2 , 3 etc up to 9.
[obviously if that userland app is not running, then it doesn't appear/cannot be "activated" this way, so Hijack simply eats that key sequence].

This selected App is then "given" input focus in Hijack [and possibly woken up somehow - e.g. the kernel sends it a special "wake up" response to the WAITMENU IOCTL].

What I'm thinking of here is a bit like Alt-Tab in Windows, whereby you can "select" a particular app [i.e. there could be more than one app in background], which becomes the "foreground" app [as regards to input focus], while the rest execute in background mode [e.g. they continue to monitor your progress along a route if its a GPS app etc].

And you could consider the Player app to be the "desktop" i.e. its what you see and interact with when no other apps are running/active.