Okay, I just put out v25 of my "hijack" patch (VolAdj, BreakOut, ScreenBlanker, Vitals, MaxTempWarning, RotaryKnob fixes, etc..).

This is the first version to also include the long-awaited ioctl()'s for interfacing with userland applications. So.. if you own/support an Empeg application that currently requires the menuhack patches or whatever, please have a look at possibly integrating it into the menu system instead.

http://rtr.ca/empeg/

The programming interface is currently quite simple, and looks something like this:

/* Basic sequence for userland app to bind into the menu, display, and IR buttons */

/* Not shown: all "rc" return codes have to be checked for success/failure */



#include 

int fd;

unsigned long data, buttons[5] = {5, IR_KW_PREVTRACK_PRESSED, IR_KW_PREVTRACK_RELEASED, IR_KW_NEXTTRACK_PRESSED, IR_KW_NEXTTRACK_RELEASED};

unsigned char screenbuf[EMPEG_SCREEN_BYTES] = {0,};



fd = open("/dev/empeg_display"); /* substitute the actual devicename -- I don't know it */

top: while (1) {

       rc = ioctl(fd, EMPEG_HIJACK_WAITMENU, "MyStuff");

       rc = ioctl(fd,EMPEG_HIJACK_BINDBUTTONS, buttons);

       while (looping) {

          rc = ioctl(fd,EMPEG_HIJACK_DISPWRITE, screenbuf);

            /* or ioctl(fd,EMPEG_HIJACK_DISPTEXT, "Some\nText"); */

          rc = ioctl(fd,EMPEG_HIJACK_WAITBUTTONS, &data);

       }

       rc = ioctl(fd,EMPEG_HIJACK_UNBINDBUTTONS, NULL); /* VERY important! */

   }

Downloading it now!

Ooh! I like the temp warning!
just one thing, you'll need to be able to set the alarm temp in C & F.

FITNR?

top work again!

>you'll need to be able to set the alarm temp in C & F.

Silly me, forgot about the Yank's again (despite the baseball playoffs).

I'll drop degreesF into v26 (no release date planned yet).

Update: Okay, v26 is out with the C/F conversions shown for all temperatures.

Also, I fixed some bugs in the text output, and simplified the MaxTemp logic.

I'll check v26 (jebus! now v27!!) in a moment. Could you have the screen go into blank or something when paused for some time, like say, 5 minutes. A bold paused box floating around the screen would be too much to ask I guess? ;)

>Could you have the screen go into blank or something when paused

I think my existing Screen Blanker function will do this already, so long as the screen contents are not changing/scrolling while paused.

Heh, here we go again. It's like rubbing a lamp! New genie, this time.

Mark, you have our admiration and respect. Nice work!

Now, today on the way home, I had a thought... (he says as he rubs the lamp)

What if the voladj selector had four presets instead of three. It could have the three existing ones (low medium high), and also a new one called CUSTOM. The custom settings could be derived from a special [voladj] section of config.ini.

I'm aware that the config.ini isn't available when the kernel first fires up (the disks are not yet spun up), but I'm pretty sure it's readable at some point, right? And the kernel somehow knows (or can know) when it is able to read the config.ini?

The reason is that I've been very keen on the idea of playing with the parameters for Richard's code to make it behave a little differently, there just hasn't been an easy way for me to throw a whole bunch of different parameters at it in short order.

Hmm. Now that I think about it... if there were a custom setting, is there enough free bytes of flash to store the four-or-so parameters for the custom voladj settings? Then we wouldn't even need config.ini and it'd be even easier to play with them...

I'm just thinking out loud here, of course. I wouldn't want to squander my three wishes on silly stuff...

Cool stuff, like it so far. Two comments:

1) Since you're in Canada, why do you only have a MAX temp warning, why not a minimum one as well?

2) Probably nothing you can do about this one, but....

Mike's timing fixes were intended to help debounce the switches on the volume control knob. His method for doing so was to check the timing of the messages and ignore them if the user changes volume direction too suddenly (as tends to happen with dirty switches).

The first problem I see is that it makes the breakout game harder to play because it won't change direction suddenly as easily as it used to.

I know, I know, I'm the one who suggested that the timing fixes should be in your kernel. I'm not saying to remove them. They are correct in the case of a flickery volume knob. I just wanted to say that this is one side-effect you might want to know about.

I'm wondering, though, just how the knob's switches are interpreted in the first place. Are they interpreted at the kernel level, or are they just getting Up and Down messages from a PIC somewhere? My point is that the current fix seems like a bit of a kludge (no offense, Mike), almost as if the REAL debouncing needed to be done in a PIC somewhere that the software doesn't have access to, and so the only solution was to put a band aid on the symptom of the problem rather than its source. If true, then Mike's current implementation seems like the only proper way to deal with it at this time.

Since your player has brand-new switches, you don't have a glitching knob to test against, so playing with the timings yourself (for instance, making them tighter for the game only) probably would be counterproductive...

Has anyone told you recently that "You Da Man!". Can't wait to try it out.

-Mike

Great news...
I was thinking of rewriting init, as this seems to be the ideal application for starting up external apps.
The idea is that init does the usual stuff ( mount disks, start player ) and then reads a file which contains menu items and commands to execute.
This will keep memory usage low and shouldn't affect the player app.
Is the source for the original init available? If it's not, would it suffice to mount disks and start the player app?

re: custom voladj settings

I don't think it would be too wise to chew up any more flash memory for custom VolAdj parameters. As much as I'd like it, we really do have to exercise restraint on this incredibly precious/limited resource. Currently I use just four bits (total) to keep track of separate car/home settings; to do fully custom would require perhaps 32 bits or more. Uh Uh.

But just as I have enabled easy menu extensions from within the kernel, with SOME space for certain persistent settings, I really believe the next step to be a userland application. Frank has suggested enhancing/replacing "init" as a starting point for userland extensions (good place to do it, too). As that line of development continues, I believe we may commandeer a couple of disk sectors for userland persistent settings -- like custom voladj. The existing VolAdj ioctl()s are still there, so a userland menu extension can easily be coded to allow full tweaking TODAY, and with some hope of persistence later on.

Anyone wanna volunteer to do that? (I'm almost strictly a kernel guy)

One definite possibility for grabbing a couple of disk sectors would be to simply resize the swap partition to be a block smaller. We could then do direct I/O to /dev/hda to read/write the freed sectors; they don't need to be in the partition table (but they could be..).

> Since you're in Canada, why do you only have a MAX temp warning, why not a minimum one as well?

Coming as soon as it cools down here some.. Not really a warning, though, but a complete "STALL BOOTING NOW UNTIL HELL THAWS AGAIN"!

I need to play with the thermal sensor some more, as it is definitely NOT working as intended (as an Empeg/Rio insider has already mentioned). With v25 of my patches, the thermometer on my Mk2. only changed reading after power cycles(!), which is why I added the superfluous call to empeg_inittherm() prior to each reading in subsequent patches.

>Mike's timing fixes ... makes the breakout game harder to play

Stop whining! The game was far too easy before, and I still win first try every time (almost).

>wondering just how the knob's switches are interpreted(?)

I haven't looked too closely, but the knob generates IR codes (all of the front panel stuff just pretends to be an IR remote) which are handled (repeat rate, debouncing, ..) in the kernel in empeg_input.c Take a look there if you need to figure it out more (I have not bothered.. my stuff just piggybacks on the output from that stage).

Cheers!

>Has anyone told you recently that "You Da Man!".

Yeah, just a few folks.
Thanks! Like most OSS developers, I thrive on feedback!

One definite possibility for grabbing a couple of disk sectors would be to simply resize the swap partition to be a block smaller. We could then do direct I/O to /dev/hda to read/write the freed sectors; they don't need to be in the partition table (but they could be..).

I think I mentioned this in another thread, /dev/hda3 (32MB) is an unused partition by default. Some people create a /usr filesystem as I did, but I would be willing to give that up if it could be used for user settings. Instead of resizing the swap partition (which will get erased by an upgrade because the partition table gets rewritten) shouldn't it just write to that unused partition? Just a thought. I'm not well versed enough in low-level disk IO to figure out this stuff but I do know that partition was basically meant for user apps.

>I was thinking of rewriting init, as this seems to be the ideal application for starting up external apps.

How about just renaming init to something like "real_init", and then substituting a separate program
which forks off a few threads to bind menu entries (the BIND is 100% blocking, at present), and which
then runs the "real_init" as normal afterwards?

>This will keep memory usage low and shouldn't affect the player app.

Ahh.. possibly. combining them into a single executable might save us some memory; or maybe not much, since libraries are the only really common part, and those ought to get shared in memory anyway.. but a combined init might be a better (simpler) way to do it anyway.

>Is the source for the original init available?

I should hope so (it had better be available!) .. Rob?

>I think I mentioned this in another thread, /dev/hda3 (32MB) is an unused partition by default
> Instead of resizing the swap partition (which will get erased by an upgrade because the partition table gets rewritten)

Another possibility might be the boot sectors. I haven't looked at the empeg partition table yet, but most Linux configurations blow a whole (virtual) track (63 sectors) for the "boot sector", leaving 62 unused unallocated sectors at the beginning of the drive, just after the partition table. We could grab one or more of those without much fuss, I suspect (various MS-DOS drive-extenders like DiskManager and EZDrive do something like this).

I agree with those who have sent some praises in your direction lately. You're really kicking some serious butt on the Empeg hacks & addenums -side.

I've actually been a bit bummed about the fact that we haven't had enough really deep-to-the-core guys working on the extras for Empeg. It seems that now we have a couple. I appreciate your work.

Sort of really buffs up my intentions on starting to work on a project myself, I've been really looking for something as the Hijack, because my resources aren't that great of creating one on my own.

It brings great value to be able (at least in the near future, if the issues where to store data gets cleared) to get code some little app on top of the actual player software. This was the thing hindering some little projects I've had in mind. So you're sort of adding others' interest to coding by coding yourself.

Ty.

I really believe the next step to be a userland application.

I guess. But I really like how the voladj settings are implemented in your kernel because I can do this stuff without needing to play at the shell prompt or even install the developer build of the software. There's something to be said for a kernel-only mod that can be loaded in one simple step (with my logo editor).

What about the one Custom setting controlled by some config.ini parameters?

What would be nice would be a method of calling a userspace program from the menus...

ie specify a command line in config.ini... read it in from the kernel and create a menu item for it... then call the program when the menu item is selected...

This would give us an installation method as well as a hook for running user space programs...

It would save having to modify init which gets rewritten after every update...

Is this feasible...? In fact the other though that just sprung into my head is that the kernel calls init itself... so wouldn't it be possible to change the path it calls...? maybe force a mount of /drive0 and then call our own init that could live in the music partition...?

The idea being to try and get away from putting anything in the partition that gets rewritten by a player upgrade...

Cheers

Kim

>This would give us an installation method as well as a hook for running user space programs

Err.. we'd still need a method for getting the actual executable program down to the empeg.

And having the kernel initiate exec'ing userspace stuff is .. well, quirky!
I'd kinda like to see a userspace application that initializes the menu items and handles the dispatching. Mmm.. gotta think more about it, though.

Not too big a deal, I suppose, to have the kernel initiate something.
But the config.ini data is not available to the kernel, unless we wanna add code to open it up and parse it. Could be done, but this is really much better left to userspace IMHO.

Mmmm..

Hijack v30 is now available. Get it! Try it!

Mark, What you've done is simply amazing! What a sweet package of utils for our favorite player. With the ever-present help of Tony (courtesy of his LogoEditor, thanks Tony!) the install was so simple--any user able to install the beta releases of the player software can easily apply this kernal patch. It was just a drag-n-drop of the .ZIMAGE file into the logo editor and away it went...60 seconds later--POW new kernal and new toys. Too sweet.

Folks, if you have not tried this yet--DO IT.

There is no longer a need to fear the kernal!

> > Is the source for the original init available?
>
> I should hope so (it had better be available!) .. Rob?

We've asked before but it hasn't appeared, so I guess not. It shouldn't be too hard to reverse engineer, though. I just haven't been able to find any round tuits...

Borislav

I've been thinking a little further...

how about we put our own root on /dev/hda2 with our own init that calls our userland programs mounts the empeg root (/dev/hda5) somewhere and chroot and execs the distributed init...

We still need a way to upload to /dev/hda2 but the contents of /dev/hda2 remain over an upgrade... and which partition to mount as root is managable from the kernel...

so user binaries would get installed in /dev/hda2 with our own init and the empeg distributed stuff remains untouched...

we could go further and have our init look for packages to install that have been uploaded to /dev/hda2 (or install scripts if the packages are too big for /dev/hda2)

Our init could see config.ini and initialise all the menus before calling the real init...

Would this work...? or would there be some additional problems with chrooting for the real init...? My understanding is that it should work as it is the equivalent of what happens with an initrd... and an initrd allows programs to continue running that were spawned from the initrd even after you remount the real root...

Cheers

Kim

OK in trying to play with this idea I seem to be having problems overriding the root to mount via the command line in the .config of the kernel... Am I wrong in assuming I should be able to change it here...? I have mine as "mem=12M,root=/dev/hda2" but it seems to ignore that and just continues mounting /dev/hda5 as it was before...

I am just building a kernel with no root in the CONFIG_CMDLINE at all just to see if it makes any difference... and then I will try hacking the source itself to force it to mount the partition I want it to...

Cheers

Kim

OK found where /dev/hda5 was hardwired in... have now got it booting to my own init... will go ahead and try and write an init that will spawn the original init after running it's own stuff...

I'll let you all know how it goes when I get it going...

Cheers

Kim

OK here it is... really small patch to use /dev/hda2 as root instead of /dev/hda5

I first booted using a normal kernel and dropped to the shell and copied everything off the existing root partition to a new partition on /dev/hda2...

mke2fs /dev/hda2
mount /dev/hda2 /mnt
tar -cplf - . | (cd /mnt && tar xpf -)

Next I removed the existing /sbin/init on my new partition and replaced it with a new script (nothing special... just mounts /dev/hda5 on /realroot before asking whether to drop to a shell or run the original init)

I have tested playing with blitecho etc in the replacement init before it calls the real init and that sort of thing works fine... next is to write a program that will use Mark's menu system and see how that goes...

Eventually we can cut the stuff that isn't needed out of /dev/hda2 and write some software to upload install scripts there and custom programs...

If we can settle on a standard layout for /dev/hda2 we might even be able to produce an image of the partition that could be written to partition in a similar way to how player upgrades are done...

Cheers

Kim

Umm... cosmetic update to really small patch so the comment matches the code... *grin*

Cheers

Kim

You shouldn't need to do inittherm repeatedly - just once. It starts the chip doing continuous conversions - or should do, if the config byte is set up for this (which it should be). Writing the config byte is dangerous, as I said before.

It takes between 0.5s-1s to do a conversion. Read temperature reads the result of the last conversion.

If you're trying to prevent HDD damage at low temperatures, use GPIO16; you can use this to hold the HDDs in reset, which puts them into deep sleep mode. The initial boot code has stuff in there to do this, which is currently disabled; the delay on reading the thermometer would add ~1s to boot time as you wouldn't be able to let the drives out of reset until you'd read the temperature.

Hugo

I should hope so (it had better be available!) .. Rob?

Why had it better be? It isn't based on any GPL code whatsoever - it's proprietry.

In practice it isn't rocket science (the whole point is that it's minimal) so I'll look into a source release.

Rob

OK further thoughts... (someone tell me to shut up if I think aloud too much... *smile*)

/dev/hda2 as a new root partition... /etc/rchome.d containing a list of programs to start if we are at home... /etc/rccar.d containing a list of programs to run if we are in the car... an installer program that runs something like ftp and allow for programs to be uploaded to the empeg (and maybe downloaded too...? empeg-taxi?) A more complete and up to date /usr with things like vi ssh etc...

rc*.d should be symlinks to somewhere on the music parition so that we can create a partition image of /dev/hda2 with the installer, init, and updated distribution...

maybe the rather than rc*.d directories we go for entries in config.ini ...? Actually this might be better as then we could add the installer program to the list of things to run only when we need to install something and remove it afterwards...

anyway the idea being to customise your empeg the first step is upload this new partiton image and a new kernel that boots off that partition using a program something like the upgrade tool... and then we have our complete installation system and plugin system running... AND it doesn't matter if we update to a new release of the player software... to call the player software from our new init we chroot to /dev/hda5 and call that init... (or maybe just player ?)

What do you think...?

Cheers

Kim

Thanks Hugo(!) for the Excellent information on the thermometer.

I'll change my kernel stuff to only do a single inittherm(),
and I'll keep in mind the disk stuff for when I get to that later
this winter.

Cheers

Kim, I think your line of research has great potential here.

As I said earlier, "I don't do userland", so keep running with it, Dude.

But I am still thinking through the hijack interface to userland,
based on your earlier comments. It would be really nice I suppose to
have a way for a single thread to wait on multiple menu items.

I suppose this could be done in a way similar to the BIND/WAIT BUTTONS stuff.

Dunno if I'll get to it anytime soon, though. Got some Real Work to do again.

-ml

Would the source to upgclient be available anywhere...? Or would it be possible to make it availale...? or maybe give us a version which can write an image to /dev/hda2 instead of the normal partitions...?

Cheers

Kim

Wish: emptris!

Oh yeah, three other (minor) things.
1] When empeg is put in standby (pulsating LED) I can still go into your menu by holding the rotary button! I think it should check the state before entering the menu.
2] When entering a value in temp. warning, it should actually have a minimum of the current value! Funny thing is when you select ie. 32 and the current value is 34, you have to turn the empeg off and let it cool.
3] My remote doesn't have the 'any' button

Oh well, just trying to help...

Emptris might not be possible just yet because AFAIK the only method for getting user input is currently a blocking call. (mlord, correct me if I'm wrong.) bmihulka's Emptris code requires non-blocking reads.

However I'm working on a project which should be a fun passenger-seat diversion and doesn't care if the reads block. A very initial test using the userland ioctl()'s looked promising last night. I don't have a timetable for it just yet but this hijack interface is making my job much easier.

Once polling input reads are available in the hijack patch, I suspect the amount of changes needed to get Emptris hooked into it are very small.

Hi.

I haven't tried that yet (but plan to do so on the next weekend), but if you take a look at my upgrade splitter/builder (check http://incase.de/framed/empeg, the files section), and split a normal upgrade, you should be able to take that as a template to build an upgrade package that installs to /dev/hda2 instead of the original /dev/hda3(?). The partition files the builder needs (and the splitter provides) are simply binary images of the original partitions or, equivalently, binary files of the size of the partitions that contain an ext2 filesystem (or swap respectively) and can be mounted using the loopback option in mount (-o loop).

cu,
sven

> This would give us an installation method as well
>as a hook for running user space programs

Err.. we'd still need a method for getting the actual executable program down to the empeg.

Well, RZ works nicely for that. But I had another crazy thought. What about Frank's method? Send your userland programs as songs in Emplode. Feed the FID to the kernel-menu via a config.ini edit like so:

[userland_programs]
1a7c=Emptris
a7f2=GPS Navigator
23f=Activate Oil Slick
4f32=Activate Smoke Screen
5c2b=Launch Missiles

The menuing system could then simply run them directly from the FIDS folder.

This would allow you to install simple userland apps without even needing the developer image of the software. Just emplode and the custom kernel. No tedious mucking about at the shell.

Of course, the userland apps would have to be self-contained in a single executable file. If you had a bunch of support files for the app, then you'd have to make the userland app a little self-extractor or something. That'd be cool, too.

Oh, but darn, this won't work! Because the 2.0 emplode won't let us send a file to the player unless it's a valid MP3. Too bad there's no option to override the MP3-checking in 2.0, like holding down the CTRL key as you import, or putting in a secret registry setting or something.HINT HINT empeg guys!

Wow, v31 just rocks. You keep adding cool stuff. You da man!

What about Frank's method?

Call me cranky, but I really did not care for that method. It made the process a PITA for those of us who don't use the windows specific tools developed for it (emplode and Frank's installer). Something based on Empeg's .upgrade system or plain old zmodem (which someone can write a pretty Window's tool for if they want) just seems so much simpler to me.

-Mike

> When empeg is put in standby (pulsating LED) I can still go into your menu

Yeah, I thought of that a while ago, but just forgot about it again. Fixed in v33

>When entering a value in temp. warning, it should actually have a minimum of the current value..

No, I like to test smaller values too. If it fires on you, you can always get back into the menu system to change the setting (try it!) -- the flashing warning NEVER happens inside the menu. And newer versions now disable the warning within 5 seconds of any button press, just to make it even friendlier.

>My remote doesn't have the 'any' button..

Duh..

Okay, V33.. no wait.. v34 ..is out.

For those who haven't noticed, the last few versions (today) have included a menu option for reprogramming the "quick knob press" functionality. Personally, I don't like the way it bops me into the Volume/Loudness/Balance/Beep/Fader stuff. The only one of those I need to change regularly is Volume, and I can get that by spinning the knob without any presses.

Much more useful to me, when driving I can now just tap the knob to enter/exit Shuffle mode (one of the new choices).

And, oh yeah, entering my menus is now done via a LONG press of the (Rio Remote) MENU button rather than SELECTMODE.

-ml

Now *that's* very cool...I like having the "info" knob press.

Keep up the great work.

This is really great stuff.

So what do you plan on doing when one of the new releases actually implements an Empeg-defined feature for the main knob hold-down? Any ideas?

>Emptris might not be possible just yet because AFAIK the only method
>for getting user input is currently a blocking call.

Yeah, but a userland app could fork() and have one thread continue while the other grabs input.
Sometimes that's even better designwise than a single thread doing everything.

But.. it's so simple to do in the driver that I added another ioctl() for it in v34.

NOTE: v34 is 100% identical to v33 except for this internal addtion.. don't bother downloading it unless you're programming for it or don't already have v33.

Cheers

>So what do you plan on doing when one of the new releases actually implements
>an Empeg-defined feature for the main knob hold-down?

At the current rate of development, that might be a very long while from now.
And even if they do use it it will likely be for something that is already on a menu somewhere (since Mk1 doesn't have a knob), so we could just supplant their normal (new) usage.

Or not bother, since the remote's can also be used to enter the menu system.

-ml

Suggestion for next version, if possible...

Do you have any way of knowing, in your kernel, if the player software is within its menu screen or not?

Reason I ask is that the new version prevents using the remote control for the functionality of the jump-to-sub-playlist and insert-playlist features on the Rio remote because those also do a menu-button-hold to implement.

Also, the quick-press of the knob used to be the same as "enter" from within the menu structure. Now, when you are in the menu, if you press the button to confirm something, it executes your function instead of the normal function of pressing the knob.

>any way of knowing ... if the player software is within its menu screen or not?

No, I don't think so.

>using the remote control for the functionality of the jump-to-sub-playlist and insert-playlist features
>on the Rio remote because those also do a menu-button-hold to implement.

Oh.. I didn't even know about those features! And they're not in Tony's ButtonFAQ applet, either.
Mmm... this one bugs me.. I may revert back, or .. something.. ..

>Also, the quick-press of the knob used to be the same as "enter" from within the menu structure.
>Now, when you are in the menu, if you press the button to confirm something, it executes your
>function instead of the normal function of pressing the knob.

Oh... yeah, that would happen (bug, or nice feature?).
One can always leave it on the [default] setting if it's a problem.

And they're not in Tony's ButtonFAQ applet, either.

Whoops. Working on it.

How is it that you are writing these faster than I can compile them? Time for a faster machine I guess. Anyway, there is a new "Kitchen Sink Kernel (tm)*" here if anybody wants it.

-Mike

* The KSK is an award winning mix of other peoples work including HijackV34, voladj, irtrans, rotaryFix, displayserver IR stuff, and no FM Bass boost. It is suitable for the discriminating empeger who wants everything but can't be bothered to do any of the actual work. Order in the next 15 minutes and get a free bottle of SnakeOil brand miracle tonic.

If it's really bothering you then maybe press-and-hold 4 is a better option? It's not exactly as intuitive as the Menu button but it seems to be currently unused...

>>any way of knowing ... if the player software is within its menu screen or not?

>No, I don't think so.

I take that back. I've now written code to figure it out, and modify the menu-button and knob behaviours accordingly.
It'll probably be in the next release (tomorrow sometime..).

UPDATE It's in, and it's out. v35.

>How is it that you are writing these faster than I can compile them?

I subscribe to the "Release Early, Release Often" school of OSS development.

COOOOOL...

Yup, like rubbing a lamp.

Do you do monetary wishes, too?

I take that back. I've now written code to figure it out

Let's try a little experiment here folks...

Is there any way that hijack can feed the starving, create world piece, or bring Voice Recognition to the empeg? I am expecting something by tomorrow afternoon ;-)

For those who haven't noticed, the last few versions (today) have included a menu option for reprogramming the "quick knob press"

Can we get one more option added to the list of alternate uses? The detailed info screen that shows up when you hold down the info button on the rio remote. My remote never seems to be handy when I want to know song details.

-Mike

I'm surprised nobody else comented on this...

23f=Activate Oil Slick
4f32=Activate Smoke Screen
5c2b=Launch Missiles

WTF has Tony done to his car!?!

Hmmm...

This must have been in repsonse to the warmongering hordes chasing him back in the pre-2.0b3 days...

I've now written code to figure it out, and modify the menu-button and knob behaviours accordingly.

Cool, so how did you do it?

I peeked at the kernel patch and it's a pretty slick solution... It's basically "screen scraping" the top 3 rows and looking for what the player menu looks like. I can't really follow what the actual code is doing beyond that (ie what pattern it's looking for) but who cares, it works!

Oh, that's nasty.

Great... :)

ok will take a look at it and see if I can build an upgrade image that leaves /dev/hda5 alone and just writes /dev/hda2 and a new kernel... :) Of course it will probably have to wait until this afternoon/evening... and will depend on me not having written myself off from Melbourne Cup day.... *smile*

Cheers

Kim

>It's basically "screen scraping" the top 3 rows and looking for what the player menu...

Slightly complicated by the fact that the player menu appears slightly buggy, in that if you go more than two levels deep, the entire display shifts down by two pixels. Ugh. But we handle it.

>Can we get one more option added to the list of alternate uses?
>The detailed info screen ...

Ahh. Thank-you. I really disliked the "Repeat" option that I placed on the menu as filler, since hitting PREV-TRACK will repeat it anyway.

But "Detail" is a difficult one, since it replaces a "short" press with a completely different "long" press. Especially since the player may go berserk if the "button release" gets lost due to subsequent activity. Very, very tricky. Some may fail to perservere. Some would despair at the though. Some might even say "impossible". Some could do Real Work instead. Some may have/get a life. Some may even (gasp!) ham it up a bit much. But.. v36 seems to handle it all nicely.

Okay, now that we've got the "knob-press" and "menu" buttons working well, how about some nominations for what to provide as "replacement" functions for "press-and-hold-DOWN-BUTTON" on the front panel? I seem to recall some discussion (elsewhere?) as to various dislikes of the current functionality of that button.

I seem to recall some discussion (elsewhere?) as to various dislikes of the current functionality of that button.

The only problem is that once you've used it to do the "user accepts responsibility" thing at the after-boot-full-screen-info-screen, it always toggles to "Off" after that.

For instance, Let's say I boot it in the car. It's fullscreen info:Track. I press and hold the bottom button and it goes to the screen it was on when I powered down last time, which was Transient. All well and good. But now that it's in Transient, it would be nice if it would toggle back to Track. But it doesn't, it toggles back to OFF.

Now, as much as I'd like to see you actually do something about this in your kernel hacks, I would like to warn you that I think the empeg guys might be working on changing this behavior and you might not want to mess around with that button's behavior until their work has settled down (after beta).

Wish list item: The ability to provide a text color for the EMPEG_HIJACK_DISPTEXT ioctl.

BTW signal handling is working great.

But.. v36 seems to handle it all nicely.

Heh, cool.

Hey, how is the inactivity blanker supposed to work? I set it to 30 seconds, and after 30 seconds the screen doesn't go blank.

Oh hey, and Mark...

I noticed at your web site that you have both a Rio remote and a Kenwood remote.

Did you buy a Kenwood remote just so you could play with kernel hacks that supported it? Or did you already have one lying around?

v36 seems to handle it all nicely

Cool! But, now I am two versions out of date again. The things that happen while I am driving home from work!

-Mike

I though it was only supposed to work on the end of playlist screen. If you have a visual or anything else on the screen it wouldnt work, right?

Smu,

Have you managed to split the 2.00beta3 upgrade...? I get an error:

upgraderversion=0x02
info=Upgrade file
what=empegcar developer image
2001/10/17 16:03
release=empegcar player software - developer release v2.00-beta3
version=empegcar player software - developer release v2.00-beta3
ERROR: Unknown chunk type 0x04 found

Same with the consumer image...

Cheers

Kim

I have had a bit of a play with your splitter and got it to compile under Linux and stopped it from just dying when it meets an Unknown chunk but rather it now assumes it is a string and prints it out before continuing...

the resulting unknown string seems to be:

7
9

but I managed to get the partition image out so will have a play and try and get your builder working and changed to upgrade to hda2

Cheers

Kim

(I'll clean up the fixes I have made and give you a patch when I get it working... )

Ahh... I see I should have unpacked the SplitterBuilder zip first... :)

that one compiles find under Linux... :)

Cheers

Kim

It is supposed to kick in (and it does, AFAI can see) when the screen does not change for selected period of time. So, it will work when the player is paused with info-only screen or, say, 'scope visual, but won't with, say, stardust.

It worked!!!

Well done Smu... I had to hack the code to allow for the unknown chunk I found which I duely copied to the new upgrade image I build (am slightly worried about not knowing what this is but it seemed to work just being copied)... but I managed to end up with an upgrade image that puts on a new kernel that looks for hda2 and pumps hda2 with a root image...

Takes far longer to upgrade as the partition is twice the size... Also for some reason my gzip of the 32Mb partition came out to be ~27Mb whereas empeg's gzip of a 16Mb partition came out to be 3Mb... Need to work out how to get that size down as my current upgrade file is over 28Mb compared to the usual ~3-4Mb... and I am not including the image of hda5...

I have put the image up off my personal page at work (too big for my home server/connection)... If anyone wants to try it... it is Mark Lord's v36 kernel with the hda2 patch and the hda2 partition is just a copy of hda5 with a new init that I have been toying with to test out the idea...

Now need to spend some time and build a more useful hda2 image and start work on an installer program... :)

My thoughts are that we should make it so that /dev/hda2 is wipeable with an image like this and that actual 3rd party software (rather than infrastructure stuff like this) is stored on the music partitions...

Cheers

Kim

PS no guarantees on the upgrade image and I would definitely like to know the meaning of the 0x04 chunk I copied over... but if anyone feels like giving it a test I would love to hear how it goes...

and Smu, I will try and get together a patch of the changes I had to make to your Splitter and Builder code to split the 2.00beta3 upgrade

That's not a bug, it's a feature :)

ISTR it's that previous menus "stack up" below the active (lowest one) with a fixed vertical offset between them. This may mean that the top row is not always the top of a menu.

Hugo

OK worked out how to cut the size of my partition image down... start with a zeroed out image... :)

now have a upgrade that just pumps hda2 at 3.8Mb and one that pumps both hda2 and hda5 at 6.6Mb... will test them both out and add them to the same page I put the first one...

Cheers

Kim

Hi,

It seems there is a spare partition which we could use.

This leaves the problem of mounting rw a partition and yanking the power.

Hasn't the new kernel support for a journaling file system? If we make a "settings" partition, this could be a journaling FS, and it doesn't matter if we yank the power.

The spinning up/down problem could probably be fixed in the kernel, as mlord knows both kernel and IDE pretty well.

Just a quick thought ....

>how is the inactivity blanker supposed to work?

When the screen is inactive (not changing at all) for the specified interval, it blanks (still "on", just cleared). If you have a clock or music timer incrementing, it will not blank. If a LONG title is scrolling back and forth sideways, it will not blank.

>Did you buy a Kenwood remote just so you could play with kernel hacks .. ?

Actually, I've had my unit (s/n080000316) for more than a year, and back then it came with a Kenwood remote and an amber screen. So, when I heard of all the nifty new v200b3 stuff that works only/better with a Rio remote, I plunked down the cash for a new one. Of course, the accountant / taxman believe that my company purchased it so we could write software for it as part of our global marketing plan, just like the original player purchase.

>If you have a visual or anything else on the screen it wouldnt work, right?

It's an "screen inactivity" blanker: it watches the screen for periods of 100% stagnancy, and then blanks the screen after the user-specified period of stagnancy. This means it WILL operate even when the player is running, but only if the screen never changes (no timers, counters, visuals, scrolling titles, etc..).

The easiest way to see a demo, is to start a tune playing, go into my menus, set the timeout to 30sec, and then select the Font Display item from the menu -- wait 30 seconds, and poof.. music still playing, but screen is blank.

Actually, forget the "font display part", just sit looking at the 30 second setting screen for 30 secs.

Any chance of adding a new option in the quick knob press list. I want to be able to toggle between the current voladj setting and "off" with a single press of the knob.

If it briefly displayed the voladj state (i.e. off/low/mid/high) at the same time then that would be even better...

As noted previously, you shouldn't be distributing the hda5 image; this is copyright, etc. You don't need to though, if you do clever stuff with the kernel and hda2...

Hugo

>I want to be able to toggle between the current voladj setting and "off" with a single press of the knob.

No, this won't happen. But in v37, I've "prefixed" the usual Volume / Loudness / Balance / Beep rotation with a VolAdj setting overlay. So, one press of the knob brings up VolAdj, and then a twist of the knob alters the settings. Another press of the knob cycles to the next adjustment (Volume / Loudness / .. ).

Close enough?

Hi,

AWE ..... some.

Close, but I might look into installing a cross-compiler, as I guess it wouldn't now be hard for me to tweak your patch to do exactly what I want rather than very nearly what I want...

Now if only the player was open source !

(and yes I know why it is not open source and realise it will remain so)

Now I have actually downloaded and install v37 I realise that the latest changes do give me pretty much want I want, although I now don't have a single front panel button press to toggle shuffle...

This thing just doesn't have enough buttons !

> The thermometer is still flakey in my unit -- without the continuous inittherm() calls, it sometimes stops updating. Unplug / replug the power, and the temperature then "corrects" by 20C over 3 seconds.

I'm going to put the inittherm() calls back into the code, maybe once a minute or so.

-ml

It's an "screen inactivity" blanker: it watches the screen for periods of 100% stagnancy, and then blanks the screen after the user-specified period of stagnancy. This means it WILL operate even when the player is running, but only if the screen never changes (no timers, counters, visuals, scrolling titles, etc..).

May I suggest that the screen blanker be made into one which is based on the last keypress (from front panel or remote) instead of based on the screen-scrape?

I could go into a long discussion about why I think it's important, but I thought I'd just try rubbing the lamp first.

Also: The number of seconds of inactivity selector: Could it be in MM:SS format instead of SSSS format?

But in v37, I've "prefixed" the usual Volume / Loudness / Balance / Beep rotation with a VolAdj setting overlay.

This is amazing the way you've done this. Quite impressive.

>May I suggest that the screen blanker be made into one which is based on the last keypress
>(from front panel or remote) instead of based on the screen-scrape

Even better: I'll take both times (last keypress, last screenchange) into account in the next version.

>seconds of inactivity selector: Could it be in MM:SS format instead of SSSS format?

I'll pass; I like the seconds display, and doing mm:ss is unnecessary bloat.

Even better: I'll take both times (last keypress, last screenchange) into account in the next version.

I'm not sure you understood what I was saying (unless 39 doesn't yet implement it).

What I meant was:

- The screen-scrape method is useless to me as the unit will never ever blank. There is always something on the screen that moves. Even if I put up a plain INFO:TRACK screen, the track timer changes the screen.

- What would be more useful is if it ignored the screen changes and instead paid attention to key presses. That way I could leave it on Now and Next or Info:Track and it would blank after a certain time between input actions from me. If I wanted to look at the screen I could twist the knob or press a volume button on the remote.

The screen-scrape method is useless to me as the unit will never ever blank. There is always something on the screen that moves.

isn't that the point? to prevent burn in? If something's moving it should stay on....

What would be more useful is if it ignored the screen changes and instead paid attention to key presses. That way I could leave it on Now and Next or Info:Track and it would blank after a certain time between input actions from me. If I wanted to look at the screen I could twist the knob or press a volume button on the remote.

That would change the way it works completely. Here's how i see it, and everyone correct me if i'm wrong on this... But it's exactly like a screen saver on a PC, it only kicks in after a certain amount of time if there's no activity on the screen to prevent screen burn in. If you don't want anything on the screen just switch to the blank visual and hold down the visual toggle to see the info you want. I for one like it the way it is... it seems like you're asking for a seperate function all together... so it would have "screen saver" and "screen blanker", the former shutting off the screen after periods of inactivity on the screen, and the latter doing so after periods of inactiviy on the buttons.

Mmmm I dunno what screen saver you use, but mine react to periods of input inactivity, not display inactivity. If the latter were the case, a blinking cursor would be enough to keep the screen saver from kicking in...

I'm with tfabris on the no input = screen blank idea.

Doh, you're definitely correct on that one. I put that very poorly. Hrm... Okay... am i correct in that the blanking function is meant to be a screen saver in the truest sense? If so... then if there are visuals on the screen moving about, or something scrolling, then there is no reason to blank the screen to prevent burn in. If however there is a static image on screen, then there is a need to blank the screen.

I use the current blanking setup and would like it to stay the way it is...

If i put on a playlist and am sitting at my machine, then i want the screen on flashing and scrolling about. . . but if I jump up to go review an animation or something and leave my desk without turning the empeg off and the playlist ends and i don't return for another hour or so, i don't want it sitting there with a static screen. That just makes sense to me. I don't see what the point of the other way is... if you don't want the screen on then set the visual to off.

Am i alone in seeing it that way?

Am i alone in seeing it that way?

No, but you're missing my point...

INFO:TRACK and INFO:NOW AND NEXT are static displays that will burn the screen. But the screen blanker will never blank them becaue the clock timer portion of the screen changes every second.

>But the screen blanker will never blank them becaue the clock timer portion
>of the screen changes every second.

Funny thing is, I originally implemented it to handle such things, basing the blanking decision on a percentage of screen that remained static..

But I figured folks would complain about premature empblankulation if I left it that way, so I changed it. I suppose now I'll have to add an option to make it work either way..

>Funny thing is, I originally implemented it to handle such things, basing the blanking decision on a percentage of screen that
>remained static..

Could you please change the percentage to be less strict? When listening to radio, if the signal strength changes even for a moment it will unblank the screen. not great if you're driving around and the signal is prone to change.

very clever way of implementing it.

rub

>When listening to radio, if the signal strength changes even for a moment it will unblank the screen

Send me your radio module and I'll fix it.

Why not do something really wacky like only blanking parts of the screen that have been inactive for a certain amount of time. With 4096 pixels you can afford to do this down to the individual pixel.

You could even drop the brightness of a pixel based on how long it has remained the same until it just disappears.

Toby.

But couldn't that mean that parts of text/numbers will disappear or darken within the letter or number itself? For example, looking at the elapsed/remaining numbers, the top pixel, one-right from center, is lit for every number that is showed. Using your idea as I see it, that pixel would blank out before those around it.
I totally agree that this logic would be good for the line in info:track, and the various slashes and colons on the different displays, but it would just make the non-moving portions of the text look "wacky".

Yes, but the idea is to blank pixels which remain lit in order to prevent burn in.

The way around this would be to blank (or progressively fade) individual pixels which have remained unchanged for a certain amount of time, and reset their counters when a neighbouring pixel's colour changes.

This way static portions of the screen would be blanked, but pixels which wouldn't necessarily change state when they should would still get re-drawn when a neighbour changes state.

It's a pity the grey-scale isn't evenly spaced (and I do understand the reasons why). If it were, it would be easy to periodically invert the display (every 6 hours, or something). It might work anyway.

Do you actually want a tuner, if so I'm sure it could be arranged...

Yup. That would do it nicely.

Yes, but the idea is to blank pixels which remain lit in order to prevent burn in.

I see what you're saying, Toby, but this would result in worse burn-in in my case.

See, the problem I have isn't the main part of the display with the track names. That changes completely every five minutes and doesn't burn.

The problem is the time-counter section of the screen. This changes constantly, so it would never blank, but it keeps cycling through the same ten digits which stay in the same area of the screen constantly.

My Mark1 has a little (faintly) burned rectangle in that area of the screen from leaving Now and Next up on the screen for a few weeks. This is the very area of the screen that wouldn't blank under your proposed scheme.

I like what he's just done with it. Although I'd like to see available numbers lower than 85% because sometimes it un-blanks when the clock goes from 0:59 to 1:00 in Now and Next mode depending on the track length.

My Mark1 has a little (faintly) burned rectangle in that area of the screen from leaving Now and Next up on the screen for a few weeks. This is the very area of the screen that wouldn't blank under your proposed scheme.

I also have this problem, and I didn't leave now and next up for weeks...

>I'd like to see available numbers lower than 85%

Okay, I'll spend another bit on it, doubling the range available.

>Do you actually want a tuner, if so I'm sure it could be arranged...

If I had one here, I would undoubtedly incorporate some tuner-specifics into my enhancements package. So, yes! Whatcha got in mind?

I thought perhaps I might buy you one to thank you for all your hard work, just wondering what the easiest way to achieve it would be.

I would undoubtedly incorporate some tuner-specifics into my enhancements package.

The only thing I'd like to see is some sort of easier way to switch to the tuner without using the remote. As it stands right now you have to dig into the menu. Perhaps having that be one of the "press" options for the knob... Argh, but I don't want to give up the Info switch... Hmmm.... What to do...

I know, I know...

A new feature that lets you spell out in morse code the feature you want, by repeatedly pressing the knob.

Problem solved !

You think that's funny. But I've actually been thinking of ways to access more features from the front panel and I had a couple of ideas...

1) Double-clicks. Can this be detected from the kernel? Can anyone think of a way this could be implemented gracefully?

2) Chords. Can the front panel's button grid be read from the kernel in such a way that combinations of simultaneous presses can be detected?

Examples of chords:
Hold down knob while turning=jog/shuttle mode or rotary radio tuning.
Press bottom and top button at the same time: Switch source.
Hold bottom button then press FF/REW: next/previous playlist

That sort of thing...

Sounds good to me. I think at the very least "push and twist" on the knob should be used for something useful.

My original (v1) version of the voladj on/off used button chords, so, yes, they're possible.

Double-clicks have also been on my mind, but they don't work well on the knob (too easy to spin it while pressing, and things WILL get confused). But they work just fine on the other four buttons (and those are available on mk1 as well).

But maybe simplier would be to redefine the press'n'hold FF/REW functions (front panel), since they are rarely used in the car (and if needed, the menu is there to reenable them..).

>I'd like to see is some sort of easier way to switch to the tuner without using the remote

How about "press and hold knob" until it switches (beyond the menu..)?

I think I can add that, although it won't be able to "know" whether or not the tuner is active, so it may require a couple of such long presses to get the tuner (I'll have it toggle between tuner and player on alternate presses).

??

How about "press and hold knob" until it switches (beyond the menu..)?

I would like that very much.

It's possible that this might be what they decide to implement for the final 2.0 release anyway, so you could eventually just hijack the long press, then send a long press underneath your menu, and that would solve your mode-detection problem.

I wonder, though, if there isn't a way to detect whether tuner/aux is active from within the kernel. Perhaps by reading from the DSP?

>I wonder, though, if there isn't a way to detect whether tuner/aux is active .. ?

Probably from looking at the hardware regs.

But we don't need it after all here; I'll have have the extra long press emulate the "SOURCE" button from the Rio remote, which automatically cycles among input sources.

Ah, of course. Cool.

No, wait. That won't work. I think source is simply empeg/aux, doesn't go to tuner. You have to press tuner to go to tuner.

I think.

Not sure, I'm at my desk right now.

No, wait. That won't work. I think source is simply empeg/aux, doesn't go to tuner. You have to press tuner to go to tuner.

I think.


That's currently true.

However, there WAS (in 1.03) a SRC button for some of the kenwood remotes that just ran through the choices. It doesn't work in 2.03B, but it WAS there....

I'd contribute to buy a tuner for mlord.

My new Tuner+v2+hijack has given me a completely new toy
to play with, and worth a lot more than I've paid for it!

Marius (Escort Cab + MArk II)

Too late, I beat you to it. He ordered one last night...

>Too late, I beat you to it.

And I really appreciate it, too!

You guys are simply *outstanding* !

Don't worry, you had earned it

Frank, any progress on this new init which fits in with the hijack mods to allow configuration of user apps? Just wondering if this project is still on your radar these days.

Hi.

I just modified your patch a little so that it is now switchable from "make menuconfig". The patch was created against the beta7 kernel with hijack (umm, an outdated version by now, I guess) but should work against any empeg kernel.
Just look at the last setting in "General setup", right below the initial kernel command line.

cu,
sven