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