Hijack Menus v82 released

Okay, v82 of the popular "Hijack" Empeg enhancements is out.

Hijack is an easy to install kernel replacement for Empeg/RioCar players running the v200beta (any beta version) release software from Rio, featuring a separate menu system with a number of user-designed user-implemented enhancements gleaned from this BBS. If you have not installed it yet, you are really missing out!

Features include: selectable "automatic volume adjustment", "countdown timer" (for sleep or wakeup), high temperature alarm, IR-Translations for third-party remotes (or even for redefining the "stock" remote), ..., and of course, the "Break-Out" video game. All in a single download, installable by even the most phobic of users.

The latest version v82 has two new features over v81:

-- a new "Restore DC/Car Visuals" menu entry allows the player to power up with visuals re-enabled when in "car mode", the same as normally happens when in AC/Home mode.

-- a new option in config.ini can be used to revert the menu displays to the original "classic" style used prior to v79 (?). Some folks wanted this, but most of us will probably just stick with the new default style. To get the original behaviour, stick this into config.ini (using Emplode):
[hijack]
old_style=1

Get your copy now from http://rtr.ca/empeg/

Cheers

-ml

Ok, since you like prompt replies, here is my test:

Set Restore DC/Car Visual to ENABLED
Forced the AC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Set the info mode to Transient
Forced the AC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Back to Track info mode, rather than Transient.

Either I'm doing something wrong, or v.82 does not work properly. Tomorrow I'll try in my car and let you know.

Thank you, Mark, as usual! Now, knowing you, I am tempted to stay awake and wait for v.83, but since it's 3.20 in the morning here, I'd rarther go and rest. So, take your time!

Is it me or does this version cause the "Favorite Visuals" button combination (holding down the Visual buton on Rio Remote) to not work anymore? It worked for me before upgrading. Any chance this would cause a problem with that feature?

Favorite visuals works for me, running v82.

In reply to:

---

Set Restore DC/Car Visual to ENABLED
Forced the DC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Set the info mode to Transient
Forced the DC/Car mode with HiJack 82
Rebooted. Empeg in Car Mode, as expected
Back to Track info mode, rather than Transient.

---

I assume you meant "Force DC/Car mode" (no such thing as "AC/Car").

Ahh.. but I have an idea. My changes & testing were against beta3 and beta6(internal), not beta7.

beta7 has that nifty new info mode for dialing a position within a track (forgot the name of it), which probably mucked everything up for this.

Too bad. Maybe I can detect which beta is running and do the appropriate thing for beta7 versus earlier ones.

Okay, so it's broken on beta7. Wait for v83 to fix it, or run beta3 instead.

I don't run beta7 here anymore.. just too buggy compared with earlier betas.

-ml

Okay, if you're running beta7, then the new feature of v82 won't work yet.. I'll fix it for v83, I hope.

Meanwhile, I need beta testers for another new feature: init sequences.

On my server (http://rtr.ca/empeg/testing/) is a v82.5 ("restore visuals" still broken for beta7), which includes a first cut at "initial button press sequences" for car/home.

Syntax is the same as for regular IR translations, except that the "old" button is given as "initial" instead of an actual button code, as in:

[ir_translate]
initial=xxxxxxxx,xxxxxxx

Also new in v82.5 are the ".C" (Car) and ".H" (Home) qualifiers for translations, valid only on the left of the equal sign. These can be used with regular translations, as well as with the "initial", as in:

[ir_translate]
initial.C=xxxxxx,xxxxxxx
initial.H=xxxxxxx,xxxxxxx

Or even more complex:

[ir_translate]
initial.CR=xxxxxx,xxxxxxx ; only if in-car with radio active
initial=xxxxxxx,xxxxx ; all other times

One restriction: only a single "car" and a single "home" initial string can be specified.. if more than one is found, only the last one is used.

Somebody please try this out and get back to me (email) at [email protected]
I have not even tried it myself yet.. no time.

Cheers

-ml

I f***k**g dislike the way this BBS interacts with my browsers!!!

Anyway, after several "stale" edits, the previous posting with this subject line is now "correct".

Please reload/reread it if interested.

-ml

Sorry Mark, Yes, I meant DC/Car obviously. It was 3.20 am, as I said
However, Yes, I am using b7, that's why it was not working. I forgot to mention that.

It seems that there is a bug in the actual v82 hijack kernel implementation:

On all the menu entries generated from userland applications (EMPEG_HIJACK_WAITMENU ioctl), the last character of each entry isn't displayed.
In my case "RDS TMC Receive" instead of "RDS TMC Receiver" is displayed.

I'm running 2.00b7.

Can anyone else confirm this?

I can confirm it.
I've now fixed it in my internal sources, look for it in v83 later today.

-ml

Favorite visuals works for me, running v82.

Doh... Could it be that you're on 2.0b3 and I'm on 2.0b7? When I hold down the visuals button, instead of getting the "favorites visual mode on" message or whatever, it flashes up with the current info mode (it doesn't actually change the info mode, it just beeps and shows "Info: Transient" or whatever.)

I'm stumped on this one.. sigh.

doh.. no, I tryed et un bata sephen ass well.

Works fine on hijack v82 and v83 on beta6 and beta7.

-ml

Okay, Hijack v83 is now available from http://rtr.ca/empeg/

This version has several features of interest:

-- "restore visuals" now works with beta7, so the player can now power-up in-car with the visuals/info mode that was active at last power-down (car or home).

-- a new menu item allows disabling the "casual" filesystem checks that happen by default every 10th (?) sync or so.. these are pretty much unnecessary, since the filesystem checks will still be done anyway whenever there's really any trouble (like a failed sync), and they just add an unnecessary delay of 5-25 minutes at sync time.. so I like to turn them off ("disabled") on my player.

-- IR translations can now be different for "Car" and "Home" operation, using .C or .H "modifiers left of the equal sign in config.ini, as in:

xxxxxxx.H=yyyyyyyy
xxxxxxx.C=zzzzzzzz

(not 100% tested yet, but I think it works now.. let me know).

-- support for "initial=" IR sequences for startup. Not tested, but I think it should work: please test and let me know A.S.A.P., as in:

initial.C=xxxxx,xxxxxxx,xxxxxxx ;; car mode initial button press sequence
initial.H=yyyyyy,yyyyyyy,yyyyyy ;; home mode initial button press sequence

or

initial=xxxxxxx,xxxxxx,xxxxxx ;; initial button press sequence for both car/home


-- the Radio Data Service (RDS) patch is now integrated into Hijack, courtesy of René Vogt .

-- the beginnings of "notify=1" FID interception are in place, but not functional yet.. Soon.

Cheers

-ml

"restore visuals" now works with beta7, so the player can now power-up in-car with the visuals/info mode that was active at last power-down (car or home).

Yep, working for me with 2.0b7. Thank you!!!

Tom

Note that the spelling of several "Favorite Visuals" has changed in beta7, and the player software seems to ignore the old spellings.. if none of your spellings match the new spellings, then the feature may just get disabled.

??

-ml

-- a new menu item allows disabling the "casual" filesystem checks that happen by default every 10th (?) sync or so.. these are pretty much unnecessary, since the filesystem checks will still be done anyway whenever there's really any trouble (like a failed sync), and they just add an unnecessary delay of 5-25 minutes at sync time.. so I like to turn them off ("disabled") on my player.

And the crowd goes wild! Huzzah!

Testing now..

No, I don't think that's it.. I went to sync tonight and noticed all of my settings had been screwed (IP address, name of player, owner info, etc.) This morning I noticed that the Visual Names were showing on visual change, when I had disabled that on my player. Upon further inspection, my entire config.ini was a blob of binary data. I don't know if this was due to a bad sync, or me powering down without unmounting /drive0 (I don't remember this happening) or what... But anyway I thankfully had a backup of config.ini lying around. Once I replaced it, things worked fine.

Then I tried to re-enable the "show visuals on change" to see if that was the culprit, and it isn't. So I guess the mangled config.ini caused some kind of problem.

I just hope nothing else on my drives was lost. I'd love to know what happened to my data, I'm hoping this isn't the start of (gasp) hard drive troubles. /dev/hda is about 15 months old.

Another symptom of the messed-up config.ini was that my IR translations weren't working... Is it possible that Hijack chokes on a really mangled config.ini and stops working? I was still getting the hijack menu, but no IR translations.

Welp, no joy here on the restore visuals thing. Observations:

1. When the player boots into tuner mode, nothing happens at all. I switched to "transient" mode in tuner and when I restarted, it came up in the "Radio" info mode (no visuals.)

2. When booting into player, I wa in transient mode and when restarting, it sent two quick "Info change" commands but unfortunately that put it into "Info: Off" instead of Info: Transient. Maybe this has to do with the fact that 2.0b3 doesn't have the "Seek" info mode?

I was in a hurry since it was freezing outside when I tested this, so I might have been a little hasty in my testing. But I'm pretty sure these two things aren't working exactly right.

In reply to:

---

1. When the player boots into tuner mode, nothing happens at all. I switched to "transient" mode in tuner and when I restarted, it came up in the "Radio" info mode (no visuals.)

2. When booting into player, I wa in transient mode and when restarting, it sent two quick "Info change" commands but unfortunately that put it into "Info: Off" instead of Info: Transient. Maybe this has to do with the fact that 2.0b3 doesn't have the "Seek" info mode?

---

Well, I suppose #1 above is expected -- I haven't tested in Tuner mode, cuz my tuner is at home and I won't be back there for a few days yet.

As for #2.. not sure. I have tested with beta6 (internal) and beta7. Beta6 also does not have the "Seek" info mode, but perhaps there's some other difference. I'll retest perhaps when I get a chance, but it should work with beta7 as-is.

Thanks for the quick testing!

-ml

PS: and standby for v84, with /proc/empeg_notify for FIDs and other stuff.

>Is it possible that Hijack chokes on a really mangled config.ini and stops >working? I was still getting the hijack menu, but no IR translations.

Yes. Hijack STOPS reading from [ir_translate] at the first sign of a syntax error. You can tell what it likes by looking at the serial output.. only the accepted translations are echoed back.

Cheers

-ml

Okay, v84 is out.

Two changes:

(1) the countdown timer has been revamped; setting it is now easier.

(2) Hijack now creates and maintains /proc/empeg_notify on the player. To use this, you must first add this to config.ini:

   [output]

   notify=1

The data shown in /proc includes track name/fid/position/artist/album/etc.. the same as dumped to the serial port by notify=1.

Now the 115200bps question.. should I hack it some more such that the data is generated regardless, but only gets released to the serial port if notify=1 is in config.ini?? Doing it that way would be nicer (no load on the serial port), but it has potential to confuse other apps using the serial port with similar strings..

-ml

I am getting an entry "empeg_no" instead of "empeg_notify" and it doesn't contain anything. I'm getting the serial output, though... Maybe the serial output is different?

here's a sample of the serial output..

  serial_notify_thread.cpp: 116:@@ N0

  serial_notify_thread.cpp: 117:@@ F0xef10

  serial_notify_thread.cpp: 118:@@ TThose Damned Blue Collar Tweekers

  serial_notify_thread.cpp: 119:@@ APrimus

  serial_notify_thread.cpp: 120:@@ GModern Rock

  serial_notify_thread.cpp: 180:@@ #ef10  0:00:00

  serial_notify_thread.cpp: 170:@@ S0

And my /proc directory with v84 installed..

1   48       cpuinfo       empeg_power  ide         meminfo     slabinfo

16  49       devices       empeg_rds    interrupts  misc        stat

19  5        dma           empeg_state  ioports     mounts      swaps

2   7        empeg_cs4231  empeg_therm  kcore       net         sys

21  audio    empeg_id      empeg_usb    kmsg        partitions  tty

3   bus      empeg_ir      filesystems  loadavg     scsi        uptime

4   cmdline  empeg_no     fs           locks       self        version

I agree with your idea, only output stuff if notify=1 in the config.ini for hijack.
[this lets us end-users configure our config.ini ourselves and set either notify=1 in the normal player section of config.ini and have the player S/W output the notify info as it does now, or notify=0 in the normal place and notify=1 in your section to have the modified version output which includes the fid].

You of course always build the /proc entry for current fid, playlist etc etc -regardless of players notify= entry - that way software using your kernel will always be able to rely on the information there.

For apps that use the serial port themselves, they simply ensure/check that notify=0 in both places in the config.ini where it could appear.
[and presumably fail softly/warn the user if they are not both 0 as it would be fighting with another data stream on the serial port if it ignored these settings when either or both was 1]

My 2 cents.

The only apps that could be looking at the serial interface for this data ("serial_notify_thread.cpp: ") realistically would be external apps (ie, outside the empeg) like the video display generator from a while back. They'd have to set notify=1 anyway and live with the consequences.

Anybody else that needed this information inside the empeg (userland apps) I suspect would much rather grab it from /proc than parsing the serial line themselves. I'd say turn it on internally and always strip from the serial unless notify=1 is explicitly in config.ini.

If it truly is a problem, couldn't you add more indirection? Have the player dump to ttyS0 (and internally duplicate to ttyS1) and whatever software that wants to have complete control over the serial output from the player could watch that, while your massaged output could go over ttyS1 & /proc. Or does the serial hack apply to all serial ports? Maybe I'm making this more complicated than it should be. That's what I get for armchair kernel-hacking

I think it would be best if there was an option to choose whether Hijack should output or not regardles of notify=1.

TommyE

Yup. It's broken alright.

I just shoved it out late last night, hoping you'd test it for me.

But now I'm working on it again.. could be a while -- don't have all my fancy tools/hardware here that I'm used to using back at the office.

-ml

>I think it would be best if there was an option to choose
>whether Hijack should output or not regardles of notify=1.

Well, it turns out to be a moot point.

The player seems to use syslog() for its "notify" output, which is a separate kernel path from regular serial port output from an application. This means I can safely ALWAYS have hijack scanning for notifications and updating /proc with them.

But I don't really have an easy way to force the player to "turn them on".

So, to use this feature in the upcoming (fixed) v85 release (in a few hours), one will need to turn on notify in the config.ini file, using the normal [output] notify=1 stuff. But I will add an option to have Hijack supress the serial output of the notify stuff for those who don't want it actually spewing out.

Either way, no interference with "normal" serial port usage from other applications.

Cheers

-ml

I just shoved it out late last night, hoping you'd test it for me.

No prob, brings me back to my days in the ol' test lab here at work. I am really interested in this for my lyrics scroller, though I'm afraid the SLOW graphics libraries I have will prohibit it from being usable just yet.

We have a kernel/IDE expert "on staff" here, now we just need to send a free Empeg to someone who has the expertise to write assembly graphics routines. :)

Hmmm...little quicky problem I have in Info:Track mode.

The screen blanker wasn't doing anything at all, and I figured out that because of the CFB was blinking even as the playlist was finished and nothing else on the screen was moving, it was enough to keep the sensor thinking that there was activity.

So, I changed the sensitivity of the sensor to 95% instead of 100%, and voila..it worked. Only, now the screen will go blank in the middle of songs, where the elapsed time used to keep the "active" state, apparently with between the elapsed time and CFB less than 5% of the screen is active.

Does this make sense? Is there a way to not have it blank out on me when it's playing a song, and still blank out on me when there's nothing playing?

Hey Mark, it looks like the details option for knob press redefinition has vanished? Is there a reason for that and if not can we have it back? I really like being able to get the track details without the remote.

-Mike

"Details" is still available from the "PopUp" option.. good enuf?

-ml

Yeah, with "Track Info" on beta7, the screen is NEVER 100% idle, due to that blinking "track position" dot. I'll adjust things in Hijack v85 (uploading now) such that the 100% means "100% minus one pixel". That will fix it.

On a related note.. now that Hijack can read the "notify=1" information, it can be aware of "paused/playing" mode, the current FID, and lots of other neat information. Of all of this, the "paused/playing" data might be useful for some things like the screensaver.

But using this info REQUIRES EXTRA WORK: the user must enable "edit config.ini" in Emplode, and the use Emplode to set: [output] notify=1

So I'm not sure that we actually want to take advantage of this extra info anyplace. Discussion?

-ml

Graphics routines don't need to be in assembly (but nice if they are), they just have to be written to run fast rather than look "CS Class Pretty", or possibly both simultaneously.

Are you sure your slowdown is not due to the ioctl() interface for userland screen updates? To test the theory, use the regular empeg MMAP function from empeg_display() to run your app while the player is shut down.. see if it's any faster that way (direct memory access, almost..).

If faster, then we can add a second mmap() page for the hijack buffer.

Cheers

-ml

such that the 100% means "100% minus one pixel". That will fix it

Thanks..that's helpful.

So I'm not sure that we actually want to take advantage of this extra info anyplace. Discussion?

I think for the purposes of the screen saver, it would be grand if it could "know" if it's playing or not, and behave accordingly. Are you saying the extra work consists of adding one line to the config file? That's hardly a great deal of work.

Doing a great job here, by the way.

Okay, v85 is out at http://rtr.ca/empeg/

This version has:
-- working implementation of /proc/empeg_notify, with the small exception that I forgot to fix the name, so it still shows up as /proc/empeg_no instead. That will be fixed in v86 in an hour or two. To use this feature, you have to add the [output] notify=1 lines to config.ini

-- If you want to supress actual output of notify=1 to the serial port, then also specify [hijack] block_notify=1 in config.ini. Note that this will also block the silly "dhcp" messages that stream out when no ethernet is connected on ac/home mode, but should not block anything else (or anything at all from a userland app).

-- There are some new #ifdef'd (disabled) menu entries in the source code for poking around at /proc/empeg_notify from the front panel.

-- the screen blanker now treats "100% sensitivity" as "100% minus one pixel", so that it will work with the "Info: Track" screen in beta7 (with the blinking dot).

Enjoy, and let me know if anything is still broken.

-ml

In reply to:

---

the Radio Data Service (RDS) patch is now integrated into Hijack, courtesy of René Vogt

---

Mark,

What is this patch exactly doing? I did not found any information about that here....

Thanks for a quick update.
bye

The RDS hack just causes all of the RDS data that is normally scooped by player software from /dev/rds0 to be echoed to a fifo called "/dev/rds1", a cheap way of making it available to a second userland application.

-ml

"Details" is still available from the "PopUp" option.. good enuf?

Umm, well, ummm... no?

It is just that I got really used to having it available at the push of a button. If you don't want to make it available as a standard redefinition I can program one of my steering wheel remote buttons to do it, but I am kind of low on remote buttons. Whatever.

-Mike

Are you sure your slowdown is not due to the ioctl() interface for userland screen updates? To test the theory, use the regular empeg MMAP function from empeg_display() to run your app while the player is shut down.. see if it's any faster that way (direct memory access, almost..).

That's good thinking. I will give that a shot to see what's up. The thing is, then I can't test it while the player is running, which is when I see more slowdown. There's still some level of slowdown when I run "sans player" but it's not as noticable. I'll see if I can figure out who the culprit is. Thanks for the testing strategy.

I can program one of my steering wheel remote buttons to do it

Well do you have a steering wheel button assigned to "Info"? Hold it down... Or if that doesn't work add a "Long press" modifier so that holding it down gets you the details screen. I'm guessing the Details was removed to make room for another option? (I don't have my Empeg near me right now so I can't check.)

>>"Details" is still available from the "PopUp" option.. good enuf?
>Umm, well, ummm... no?

Okay, since I know you actually use this, and I don't know that anyone else uses any of the other choices, I'll nuke the "Hush" function and put back "Details" onto the Quick Knob Press.

I am also modifying the PopUp choices to allow short/long presses of the selected buttons based on how long the knob is held in when selecting the PopUp item.. this will allow things like "Info/Details" on a single selection, or "Visuals/Favorites" for example.

This will (hopefully) be in v87 tomorrow.

Cheers

Just remember. You're a canuck. Don't forget to make release 99 extra-special. I figure you'll be there soon and I just wanted to make sure to mention it before I go away for few days.

Bruno

Don't forget to make release 99 extra-special

Actually since #99 is retired throughout the league, I think he should skip from 98 directly to 100...

Hey Mark... In v87 I noticed details is now in the knob press menu but it's not in the "popup" knob press menu.. Any way it could be put there as well? I like the popup so I can get easy access to Visual+, Info+, etc. but having details available there would be nice as well.

This guy is amasing i just wondering if a serial port an wear out though

In reply to:

---

That's good thinking. I will give that a shot to see what's up. The thing is, then I can't test it while the player is running, which is when I see more slowdown. There's still some level of slowdown when I run "sans player" but it's not as noticable. I'll see if I can figure out who the culprit is. Thanks for the testing strategy.

---

If you run other applications same time with the player, be aware that the player uses real time scheduling and if you want your process to get time more equally with the player, you also must use real time scheduling. The normal background tasks gets very little time while the player is running.

This topic has been briefly discussed, here.

Kim

if you want your process to get time more equally with the player, you also must use real time scheduling.

Aaaah yes I do remember that thread now that you mention it. I will also give that a shot. Though I'm wondering what the implications might be in terms of stealing too much CPU away from the player. It looks like I might find some time to test this stuff out this weekend.

Thanks for the tip.

>In v87 I noticed details is now in the knob press menu
>but it's not in the "popup" knob press menu

It's not on my Rio remote either, but if I press and hold "INFO" for a second or so then I get "Details" with it. The PopUp knob presses now work the same way.

So.. press and hold "Info+" for "Details",
and press and hold "Visuals+" for "Favorites",
and press and hold "Tuner" for "Presets", etc..

That's what the "+" signs are there for, as reminders..
I seem to have forgotten to add a "+" on the end of "Tuner" -- next release.

Cheers

-ml

Ahhhhhhh... My bad for not reading the destruction manual before I tried it out.

"restore visuals" now works with beta7

I'm using 2.0b7 (Consumer), with hijack 87, and I can't seem to get this to work. Every time my player boots up in the car, it starts off in "Now & Next" mode.

I do have some other wierdness that might be related... "Volume ramps up gradually" only works on my player the first time after I physically pull it out of the sleeve, and then put it back in. In other words, when I start my car with the player already in there, it comes on with the volume wherever I left it at, with no ramp. But, if I've just put the player in the sleeve, then the ramp works fine.

As far as I can tell, the player does think it's in car mode, because the dimmer menu item is there, and it functions as expected when I turn on my headlights.

One other thing I noticed though, is that I always have an option to "Force DC/Car Mode". Shouldn't this change to "Force AC/Home Mode" if I'm in the car? It doesn't...

So, I'm guessing that somewhere the notion of "Car Mode" is being lost.

Any ideas?

Let me know if you need more info, or have any tests you want me to run.

>I'm using 2.0b7 (Consumer), with hijack 87, and I can't seem
>to get this to work. Every time my player boots up in the car,
>it starts off in "Now & Next" mode.

Mmm.. Okay, we should be able to fix that.

What Info mode is active when you power down?
And what info mode is active when it powers up again?
And just before powerdown, could you run the "Show flash savearea"
(or whatever I named it), and tell me what you see in byte 40,
and in bytes 4C and 4D.

Thanks

40, 4C, and 4D correlate to 40, 48, & 50, right? I hope so, 'cause 4C and 4D aren't in there...

Anyway, here's the info:

On bootup, it allways starts off in "Now & Next" info mode.
40 0202 0001 D014 0000
48 79F1 5009 1505 0001
50 0000 0000 0000 0000

If I change the info mode to "Transient" I get this set:
40 0202 0001 D014 0000
48 79F1 5009 1105 0001
50 0000 0000 0000 0000

Hope this helps!

>On bootup, it allways starts off in "Now & Next" info mode.

>    "Now & Next"

>    40 0202 0001 D014 0000 

>    48 79F1 5009 1505 0001 

>

>    "Transient" 

>    40 0202 0001 D014 0000 

>    48 79F1 5009 1105 0001 

Are you sure those were from a DC-Powered Empeg? Or at least from one that was using "Force DC/Car Mode" at the time?

Taking into account your numbers and mine, we thus far have (combining locations 40,4C,4D into a single 6-digit number:

Visuals visible:

0x000004: // off (beta3, beta6)

0x000005: // off (beta7)

0x010004: // line (beta3, beta6)

0x010005: // line (beta7)

0x020004: // transient (beta3, beta6)

0x020005: // transient (beta7)

0x021515: // transient (beta7)



Visuals NOT visible:

0x020403: // track (beta3, beta6, beta7)

0x020404: // now&next (beta3, beta6)

0x020405: // now&next (beta7)

0x021505: // now&next (beta7)

0x020404: // infoseek (beta7)

Would anyone else like to join the fray and help us sort this out?

We are trying to figure out which flash values indicate "Visuals visible" versus "Visuals NOT visible", so that the "DC/Car Restore Visuals" feature can be made to work in all cases. The flash data of interest appears to be locations 0x40, 0x4c, and 0x4d (viewable from the Hijack menus). Of course, we ONLY care about values from "Car mode", not "Home mode"!!

Thanks

-ml

Oops.. I got that wrong in the previous post.
Here are the corrected current observations:

   Visuals visible:

   0x000004: // off (beta3, beta6)

   0x000005: // off (beta7)

   0x010004: // line (beta3, beta6)

   0x010005: // line (beta7)

   0x020004: // transient (beta3, beta6)

   0x020005: // transient (beta7)

   0x021105: // transient (beta7)   <--- corrected value



   Visuals NOT visible:

   0x020403: // track (beta3, beta6, beta7)

   0x020404: // now&next (beta3, beta6)

   0x020405: // now&next (beta7)

   0x021505: // now&next (beta7)

   0x020404: // infoseek (beta7)

>One other thing I noticed though, is that
>I always have an option to "Force DC/Car Mode".
>Shouldn't this change to "Force AC/Home Mode"
>if I'm in the car?

No, it should not. The original impetus for this menu item was a chap who's Empeg often thought itself to be on AC power, even when in the Car, due to a flakey sensor on the AC power plug socket at the back of the unit.

This menu item allows him to force the unit to work correctly in the car, whether the flakey sensor was working or not on any particular day.

And as it turns out, I (and others) now use the menu item all the time for feature testing "in the lab" (at home).. gotta make sure the car settings still work (Hey! It's getting colder outside now -- in Canada).

Cheers

-ml

As noted in another subthread, could you try setting "Info-none", "Info-line", "Info-transient", "Info-Track", "Info-now+next", "Info-Seek", and (whew!) "Info-Details", while in DC/Car mode, and then use the "Show Flash Savearea" menu item to dump out locations 0x40, 0x4c, and 0x4d for each of those. Please report back with your observations.

Thanks

-ml

Are you sure those were from a DC-Powered Empeg? Or at least from one that was using "Force DC/Car Mode" at the time?

OK, so I just re-checked everything, in AC, DC, and AC with "Force DC/Car Mode", and the readings are the same every time. The only thing that changes is that "1505" is there in "Now & Next" mode, and it turns into a "1105" if I switch to "Transient".

So, I guess my player isn't really switching into Car mode...?

No, your player is very likely working correctly, and switching into DC/Car mode on command.. it's just that we have not yet fully figured out how all the bits in the flash savearea are used. Your data helps a lot, and hijack v88 will incorporate it in an improved "restore visuals" algorithm. Hopefully others will also contribute data to help us perfect the algorithm.

Cheers

-ml

Cool cool.

Let me know if you want me to test anything else.

Well, you could retest with Hijack v88 in 30min or so (still compiling right now..)

-ml

Mark, with great great pleasure, I am honored to help!
So, here's the data you're asking:

I am using 2.00b7 Developer

In DC/Car Mode I am in Info-Off. Enter Hijack v.87, select Show Flash Savearea and read the following:
40 0001 0101 6005 0000
48 0A3F 0000 0003 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Line. Enter Hijack v.87, select Show Flash Savearea and read the following:
40 0101 0101 0000 0000
48 0000 0000 0003 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Transient. Enter Hijack v.87, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0003 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Track. Enter Hijack v.87, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0403 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Seek Tool. Enter Hijack v.87, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0404 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Now & Next. Enter Hijack v.87, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0405 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Track Detail. Enter Hijack v.87, select Show Flash Savearea and read the following:
40 0001 0101 0000 0000
48 0000 0000 0403 0000
50 0000 0000 0000 0000

Awesome Mark, 88 works just fine!

Now if I could only get that "Volume Ramps Up" thing to work... Hmmm...

Version 88 Now.
I am using 2.00b7 Developer

In DC/Car Mode I am in Info-Off. Enter Hijack v.88, select Show Flash Savearea and read the following:
40 0001 0101 0000 0000
48 0000 0000 0003 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Line. Enter Hijack v.88, select Show Flash Savearea and read the following:
40 0101 0101 0000 0000
48 0000 0000 0003 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Transient. Enter Hijack v.88, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0003 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Track. Enter Hijack v.88, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0403 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Seek Tool. Enter Hijack v.88, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0404 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Now & Next. Enter Hijack v.88, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0405 0000
50 0000 0000 0000 0000

In DC/Car Mode I am in Info-Track Detail. Enter Hijack v.88, select Show Flash Savearea and read the following:
40 0201 0101 0000 0000
48 0000 0000 0403 0000
50 0000 0000 0000 0000

Thanks! Note that v88 is likely "broken" for you, but using your data I've fixed it for the next release (tomorrow sometime).

We need more contributions.. anyone else?

I confirm, It works! Bravo!

Broken? Meaning? I was in transient info mode, DC/Car mode forced. Unplugged, plugged, back in transient mode! Seems to be working! :)

Taym,

In your case, v88 is broken if you set Info==OFF and then reboot.

I'll fix it in v89 in 30-40minutes from now -- say 10:45EST (currenly 10:12EST).

-ml

Oh! Ok, I'll test all the modes and report as soon as I finish this upload session. Unfortunately I have to wait 15 minutes at least before I can test, it's a big upload. Sorry, I thought you would release 89 tomorrow, I hope my post will be early enough to be actually useful. Anyway... THANK YOU!

Okay Hijack v89 is out. The "Restore DC/Car Visuals" function is now working for everyone who has reported back on it. If it works (or not) for you, I'd like to hear from ya.

Thanks all!

-ml

Test HiJack v.89 on 2.00b7
DC/Car Mode Forced

Unplug/Plug Performed

Info-Off - OK
Info-Line - OK
INfo-Transient - OK
Info-Track - OK
Info-Seek - OK
Inf0-Now Next - OK

Great!

Just tried v89 in my car and it still isn't handling when the player boots into tuner mode. This is probably a feature and not a bug, as I'm guessing you haven't coded tuner info mode switching just yet.

Everything else checks out fine.

89 works fine for me.

One comment... When the player boots in AC mode, it goes instantly to the assigned visual, but in DC mode, it flashes through a few screens really quickly before switching to the visual. This is expected behavior, due to the nature of your fix, right?

One comment... When the player boots in AC mode, it goes instantly to the assigned visual, but in DC mode, it flashes through a few screens really quickly before switching to the visual. This is expected behavior, due to the nature of your fix, right?

Actually it's much simpler than that. In AC mode the player doesn't bother to switch to Track info mode because it's assuming you're not in your car while you're on AC power. The whole reason the player switches to Track info mode is to make the user explicitly turn on the "distracting" visuals, thereby absolving them of legal responsbility when someone runs their car off the road whilst engrossed in a Hula Hoops-induced trance.

So we are only concerned with switching info modes if we're in DC mode. In AC mode, the info mode will already come up correctly.

Sadly, there seems to be no easier way to switch to the correct info mode besides faking some IR presses. At least none that we've found yet... Someone who is handy with GDB and a hex editor might be able to locate (and possibly skip past) the code where the player does the info mode switch, but that would be a hefty assignment... Borislav, are you listening? I would think doing this would be similar to the unsorted menus hack... And it would provide a lot of benefit... The hijack solution is, in my opinion, less than ideal (though effective.)

Of course if you don't want to hack the software to force-restore a visual in-car, you can feel free to run your car off the road while trying to read the info track display.

I had to slam my brakes tonight (didn't lock up or kick on ABS) to slow down and avoid smashing a raccoon, but it didn't have much to do with the empeg. Though I did think about it when it happened. "Mmmm, good thing I wasn't checking out the display just then..." :)

Bruno

. "Mmmm, good thing I wasn't checking out the display just then..." :)

This is why I'd like to see voice synthesis (text to speech) on the Empeg. I haven't had ANY time to work on it since my earlier investigation, but I really do want it. Putting the right hooks into it and convincing Empeg to hook into it from the player app would be another story entirely.

Right. "restore visuals" is currently only working correctly for the mp3/wav player function, not for AUX or TUNER. I'll try to remember those two when I get back home next week, where my Tuner is hiding.

Cheers

-ml

>When the player boots in AC mode, it goes instantly
>to the assigned visual, but in DC mode, it flashes
>through a few screens really quickly before switching to the visual.

Correct. Basically, Hijack forces "Info-Track" mode, and then waits for the horiztonal line to appear from "Info-Track", which lets it know that the player is now up and running. Note that "Info-Track" is the ONLY Info mode that can be easily "recognized" in such fashion. Then, Hijack injects the required number of "INFO" button press/releases to restore the original mode.

Concept stolen from a much older patch, forwarded to me by somebody else in this group. Good idea, and simple to implement.

Cheers

-ml

Oh yeah, this "restore visuals" feature is ONLY invoked when in "DC/Car" mode, since the player software itself handles the "AC/Home" situation -- that's why there's no "flicker" in "AC/Home".

-ml

Hey Mark, I gave this a shot and it looks like the mmap is indeed faster. I can't tell how much faster, and I couldn't do my whole app because I don't have the display writes contained in one function just yet, but it definitely looks like the graphics library speeds up when not using the ioctl() interface. So chalk me up as a vote for a memory-mapped buffer for the display.