I've been hacking Hijack today, trying to remember How Things Work.

In the course of doing so, the Calculator function has now been nixed, the Flash Savearea Display has been fixed (wasn't highlighting all changes before), and the display "jitter" sometimes seen on the Hijack menus has been removed completely.

Version v359 is the one I want everyone to try and use. It should work perfectly for all.

But I will shortly be following up with v360, which changes how the display is refreshed slightly. I would like to hear if anyone out there can tell the difference between v359 and v360, paying particular attention to Visuals syncing with whatever is playing.

You see, today I instrumented things, and discovered that the player software is issuing needless "refresh" requests to the display driver. Needless, in the sense that the audio driver is already driving the display updates in sync (mostly) with whatever audio is playing (or not). So this logic meant that the display was being refreshed twice as many times per second as necessary, mostly just a waste of processing power as near as I could tell.

This is all very important to me, because the entire Hijack UI is simply a hook into the display refresh logic. So cutting refreshes by half cuts Hijack overhead by half. And makes things much more predictable inside Hijack, as it should now be atomic. Before v359, it was not atomic, thus the weird display jitter on some menu displays!

As of v359, the display updates, and Hijack UI, are ALWAYS only ever invoked from tq_immediate, a kind of "soft IRQ" mechanism in tne 2.2 Linux kernel. Previously, this code was ALSO being invoked simultaneously from a userspace ioctl() call into the kernel. In v359, this second invocation now just acts as another trigger for the first method.

As of v360, the second invocation doesn't even bother with the trigger -- but I'm curious if anyone can note any change in Visuals timing as a result. I cannot -- with all recent Hijack's the visuals all look delayed by about 1/10 of a second or so.

Cheers

I'll try it out shortly (since I happen to have Waldorf handy at the moment..) But, is this HiJack good for 3.00v3 AND 3.00v5?

Thanks for the hard work! :>
Me.

Downloading now.

Mark is good about that stuff. You'll be fine w. the Alphas.

Okay, v360 is now available.

By default, it no longer bothers with the redundant display refreshes from the player app. Let me know if you can actually see any difference in the Visuals.

To make comparisms easier, there is also now a (temporary) new Hijack menu entry to toggle back to the old behaviour: "Reduce Display Overhead". If one sets this back to "disabled", then the redundant refreshes *immediately* begin again until you turn it off, or until the player is rebooted (this setting is NOT saved over reboots).

Another side effect of v359+ is that long animations at boot-up may now play more smoothly -- or not. I haven't checked.

Safe for all player software versions 2.x and 3.x-alpha.

Cheers

Well, silly me.. I went outdoors to play some ice-hockey for half an hour, just got back in from the cold now, and can no longer touch type -- one of my little (smallest) fingers appears to be disabled -- cannot control one of the joints!

Broken tendon, I suppose..

Cheers

Well, that sucks.

Mark, it's good to see that a guy of your tallent is also able to ruff it up on ice! I'm sorry to hear about your finger, but you're typing is suffering (too much);).

In regards to your latest HiJack, mine is syncing visuals with music very well.

EDIT !! lol, I meant to type "but your typging isn't suffering". Oops!

Mmmm.. yah.. It appears to be a case of "mallet finger", and may require a splint for 8+ weeks to heal.. Mmm..

Cheers

I've put v360 through its paces today and I can't say I see a difference. Any reduction in overhead is good, of course, but I'm not sure it's a visible difference.

Speaking of things related to the display, care to take a look at the attached patch (against v360) and see if it's worthy of inclusion in Hijack? I added two ioctl()'s, one gets the player UI flags out of the kernel, and the other gets the contents of the player's display buffer. Both of them seem to be working for what I'm doing, and in lieu of further upgrades to the userland API, I'd like to see these available.

And I suppose I should finish the crap to allow injecting messages to the tuner and send that patch soon. Sigh.

One minor nitpick. Could you fill in the comments bit?

 #define EMPEG_HIJACK_INJECTBUTTONS	_IO(EMPEG_DISPLAY_MAGIC, 90)	// Inject button codes into player's input queue

+#define EMPEG_HIJACK_GETPLAYERBUFFER	_IO(EMPEG_DISPLAY_MAGIC, 91)	// Inject button codes into player's input queue

+#define EMPEG_HIJACK_GETPLAYERUIFLAGS	_IO(EMPEG_DISPLAY_MAGIC, 92)	// Inject button codes into player's input queue

Guh. You've found my downfall as a programmer.

Revised patched attached.

Believe it or not but I actually used the calculator regularly.

Oh well.

Rene

Believe it or not but I actually used the calculator regularly.

I imagine that Mark's intent was to encourage someone to move the calculator functionality into a user-space program, rather than having it take up space in the kernel.

Whether anyone will actually get around to doing this is another thing, however.

RPN here we come! Does anybody else here actually use RPN?

Does anybody else here actually use RPN?

Yoda?

>Believe it or not but I actually used the calculator regularly.

I did too, until I got a cellphone that has a better calculator built-in.

I think that makes two of us, in total, as ex fans of the Hijack calculator!

Cheers

Hijack v356, v357, v358, v359, and soon.. v360

So, I'm thinking: Taking a break from the contract work at the moment, Mark?

Exclusively!

I've always thought that it was about 1000% faster and easier once you got used to it. I can't use a "normal" calculator now.

I've started going through Structure and Interpretation of Computer Programs (the famous "wizard book") and it is my first experience with Lisp (actually, the scheme variant of lisp).

As many of you probably know, scheme uses "prefix notation", so instead of RPN's "5 enter 5 +", you have (+ 5 5). It took some getting used to, but I like it a lot! it works with an indefinite number of arguments, which is very cool.

Jim

>So, I'm thinking: Taking a break from the contract work at the moment, Mark?

Only a small break. On my little finger!

And I suppose I should finish the crap to allow injecting messages to the tuner and send that patch soon. Sigh.

And after you finish that (or before, if you like) I could sure use a vfdlib_drawBitmapScaled() function that can display a vfdlib bitmap, scaling it to user-supplied dimensions. I've had no luck finding an appropriate image scaling algorithm, and my attempts to use the GD library to do it resulted in (as expected) very poor performance.

Mark, I was very sorry to hear about your injury. I hope that working on Hijack and answering posts on the BBS isn't hurting it.

If you're still able to type, I had an idea this morning that might be fun for Hijack, if it's even possible...

Does the player I/O report the line voltage back to the OS anywhere? I know that somewhere in the electronics, the player knows what the voltage is, so it can do the bit where it puts up the battery icon. But is that value reported anywhere that Hijack can get its mitts onto the number? If so, could that number make an appearance in the Vital Signs screen?

Dunno how you'd reformat that screen to make it fit, but I wouldn't care if it was just the number followed by "v" (i.e., no label) if that helped it fit.

The hardware appears to have the capability to generate a powerfail interrupt when the car power supply drops below about 10VDC. When this happens, the kernel does a number of things, including muting the audio, writing the 128byte flash savearea, and blanking the display.

Software also disables the powerfail detection, so that the interrupt doesn't just keep interrupting things -- polling is used to detect when the powerfail trigger goes away -- voltage above 10VDC again.

The player software "sees" this by looking at /proc/empeg_power, where there is a bit labelled "1 (Powerfail enabled)". When this shows up as "0", the player displays the battery icon. When it shows as "1", the player does not display the battery icon.

EDIT: there does not appear to be a way to read the actual voltage, but rather just the trigger for above/below 10VDC.

Cheers

Ah, that answers my question. Too bad. It would only have been useful if we could have seen the actual voltage itself.

Now that I think about it, I'm sure I've asked that question before and gotten the same answer. It's just been so long that I didn't remember.

what? you asked it before and it didn't make it into the FAQ? What's the world coming to...



--pj

There's a FAQ?

It's just a model.

And after you finish that (or before, if you like) I could sure use a vfdlib_drawBitmapScaled() function that can display a vfdlib bitmap, scaling it to user-supplied dimensions. I've had no luck finding an appropriate image scaling algorithm, and my attempts to use the GD library to do it resulted in (as expected) very poor performance.

Probably after. The code for the tuner injection stuff is mostly done but needs cleanup; The real thing holding up this project is that after the last car was totalled the new vehicle's empeg install resulted in no antenna being connected to the tuner, despite what was otherwise a much nicer install. So, I either have to take the minivan (the one I had in Ohio in 2002) out to test or open the dash in the Neon, and with the crappy weather neither has happened. It's a shame, because I think tunermon works otherwise already, it just can't change what channel is being monitored.

I don't use any of the fancy visuals, just track info, but I haven't noticed any difference between 352 and 360. Playing oggs the load avg via vital signs is about the same, 1.10 +/- 0.25

--Nathan