Maybe you're trying to press'n'hold those buttons?

Just a short press/release of cancel (or *) works for me.

Anyone else got trouble?

Hmm. Works for me. I'm using 42, though.

Exactly what I was hoping for. Thanks Tony.

No, no luck, and the player buttons don't do anything either (the knob does though). Actually the buttons "seem" to control the player. Yep, they do! I can watch what they are doing in DisplayServer. The top button doesn't do anything though.

Weird. I thought I had selected "Email all responses, blah blah blah" but never got any. (I get the digest emailed, but don't always read it ;)

I've posted the files at http://www.brianosaurus.org/empeg/

This built against gd 1.8.1. I don't know what the current version is, but unless it changed dramatically, I would expect it works.

gd_empeg.c is the empeg output target. empegtest.c is a test program (go figure) that draws rectangles, circles and text on a gdImage and sends it to the screen. I put the Makefile up for the empegtest and libgd.a targets, where I added gd_empeg.o.

The gdImageEmpegXY() call will update only a portion of the screen. I used that to display output from 2 apps (a CPU meter and an xaudio-based mp3 player) on the screen at the same time, with each updating their portion of the screen. My goal was to make some sort of window manager daemon to update the screen and apps would send their images to it, but never found the time.

I threw in the code for the cpumeter and player, too. Enjoy.

OK, went out to the car and eveything worked fine - windows solution works again (i.e. reboot). First I thought "how embarassing" and then I thought I'd try playing with all the things I'd played with while I had it sitting on my desk. I managed to get it to not recognise "Cancel" again, but am not sure yet what is going it. I am guessing at Brickout or the calculator, but will have to have a bit more of a play to see. First comes some tea though ... Catch you later.

You are THE MAN. I'll check this stuff out when I get home.

Thought we might never see you around here again. :)

Okay, v43 is out, and fixes a guaranteed kernel "Ooops" from the INJECTBUTTONS ioctl().

And just for kicks, press-and-hold-for-2-seconds on the knob now cycles to the next input source, using this sequence: player -> tuner -> aux -> player -> ...

The tuner is skipped over if not present.

I'm grabbing it now. In the meantime, is there a possibility that something might have been messed up in 42?

I've had the player lock up on me (pause that can't be unpaused) twice now.

The issue here is having to have the space to write the image to and having the disk mount rw to do it... (though neither of those is a major problem)

I also think I would prefer a backup and restore program to be separate from Frank's display server...

My current thoughts are an ftp server which can serve the images of /dev/hda2, /dev/hda3, /dev/hda5, /dev/hda6 and serve the files that live in /drive0 and /drive1

on the desktop side we put the partition images downloaded from the ftp server into an upgrade file (using Smu's UpgradeBuilder) and we save the files from /drive0 and /drive1 to whereever the user wants to put them...

To restore it is a matter of applying the upgrade file using emplode (or building upgclient into the restore program) and doing a put to /drive0 and /drive1 of the contents of the local directories...

It would be nice to be able to read the kernel image off the empeg too... as this would then give us a COMPLETE backup... (is there anything else?)

Extra features would be to be able to flag whether you care about backing up /dev/hda2, /dev/hda5, or /dev/hda6 (or the kernel image if we work out how to read it) as you may not have modified them... which would change what is included in the upgrade file that gets built...

What this requires is a reasonably feature rich ftpd on the empeg (I am thinking of wu-ftpd at the moment as it has SITE EXEC which might be useful and security isn't a major issue and it can gzip etc on the fly) and the ability to serve drive images as files (which I have some ideas about)...

I'll see how I go... but I would love input...

Cheers

Kim

Hey, that makes me think of a great feature you could add to the hijack kernel. A player-reboot menu option. There are some situations where I have to yank the power to make the unit fully reboot because of whatever reason. If the kernel is still alive and I can get to the hijack menu, it would be cool to see a reboot option there to save wear and tear on the sled/power-plug.

>Is there a possibility that something might have been messed up in 42?
>I've had the player lock up on me (pause that can't be unpaused) twice now.

Yes, there is.
With v42, I can do this:

Start a tune playing.
Hit pause on the RIO remote.
Hold knob to enter my menus.
Hit Cancel to exit the menus: doesn't work.

Ugh. I really have to rewrite the keypress state machine in my stuff,
it has grown horribly since day 1.

Meanwhile, I'll try a quick rev to fix this but with v44 shortly, and perhaps a rewrite later.

And just for kicks, press-and-hold-for-2-seconds on the knob now cycles to the next input source...

Ummm... Correct me if I'm wrong here, but isn't that how we access your hijack menu...?

OK, so there must be another way...

Something on the remote then?

>isn't that how we access your hijack menu...?

Very close; the hijack menu requires a 1 second hold time.
The extra second (2 seconds total) gets the new (third level) functionality,
just ignore my menu when it pops up and keep holding for the extra second.

-ml

Maybe. Did you want a "player app" restart, or an empeg unit reboot ?

Maybe. Did you want a "player app" restart, or an empeg unit reboot ?

Full empeg unit reboot. If that's possible.

I know that it can be done by sending a command to the player on the serial port (my logo editor does it), so in theory the kernel could do it, too.

Hmm. I got the empegtest to build (I think) but when I run it, it draws a few boxes on the display and then I get this:

empegtest(47): memory violation at pc=0x02001d3c, lr=0x02001824 (bad address=0xbf7ffff8, code 0)
pc : [<02001d3c>] lr : [<02001824>]
sp : bf800008 ip : bf800008 fp : bf800020
r10: 00000000 r9 : 00000000 r8 : 0000000c
r7 : 0000000c r6 : 0000000c r5 : 02015230 r4 : 00000000
r3 : 00000001 r2 : 00000000 r1 : 0000000c r0 : 02015230
Flags: nZCv IRQs on FIQs on Mode USER_32 Segment user
Control: D020D17D Table: D020D17D DAC: 00000015
Function entered at [<02001808>] from [<020024a0>]
r6 = 02015230 r5 = 00000001 r4 = 0000000C


I couldn't build the player because a player.h file was missing. I'm a little confused why the empegtest works for a few seconds and then bombs out. I have to reboot the Empeg to get it to stop dumping those memory violation errors...

Here's what I did. I grabbed the gd library 1.8.1 as you used. I had to make some modifications to the Makefile since I'm cross-compiling (I'm assuming you compiled yours right on your Empeg? The Makefile you provided looks like a straight-up compile rather than a cross-compile.) Anyway, once I build libgd.a for the Empeg, I did a make empegtest and after some futzing with it, got it to build. However I'm getting the above error... Any ideas?

Thanks for stopping by again!

Nevermind I figured it out.. empegtest takes a text argument to display a string and I wasn't giving it a command-line argument. Coolness. I'm in business!

Nevermind my last post about v44 (deleted) I got it right. I wasn't using the rotary wear&tear patch before and because of that it couldn't find where to put the declaration for

static struct input_dev input_devices[1]

All is well now. Back to hacking...

Going for "most frequent poster" honors tonight..

I think I did find a real bug in v44 though. Using the knob-press for "details" causes funky things in v44. I get track details but it looks like it locks up thereafter. The workaround seems to be change to "default" behavior (voladj)

Anyone else see this problem?

>Anyone else see this problem?

I've been seeing lots of strange little things like that tonight.

Basically, my button press state machine broke at the seams with all of the weirdness recently added for triplexing the knob etc.. So I'm rewriting it right now. Looks cleaner, might even work. We'll see.

Very close; the hijack menu requires a 1 second hold time.
The extra second (2 seconds total) gets the new (third level) functionality,
just ignore my menu when it pops up and keep holding for the extra second.

Ahhhhh yes. "Third Level" functionality. Of course. What was I thinking?!?

Mark, you're a mad man! And we love you for it!

Keep up the good work!