Okay, v39 is out there.

http://rtr.ca/empeg

This version has a different implementation of the WAITMENU ioctl(), so if you've written code that uses it, you'lll need to change your code. The new implementation allows a single process to create multiple menu items and wait on all of them at once with a single ioctl(). This is much closer to how it is most likely to be used with a userland "dispatcher" that fires up the actual applications.

User-visible changes include some small bug fixes (menu used to disappear too quickly sometimes), and the [Exit] item is no more. The TOP button on the panel and the * (or Cancel) button on the remote are used to exit from the menu (or just wait 5 seconds and it disappears anyway).

The menu also now wraps around back/forth, and remembers the last selection for the next time it is reentered. I think this makes it more convenient to use (?).

Have Fun!

Hey is there a way to "unbind" from the menu so the user app can exit? When mine does this, the player gets into an odd state where the buttons remain bound and the display stays on the user app's display even though it's exited. Is there a graceful way to tell the kernel that the app is done and control can return to the player or the hijack menu?

Damn...

You really live that "release early, release often", don't you?

Wonderful work man... Truely great stuff.

>Hey is there a way to "unbind" from the menu so the user app can exit?

No, once on the menu, the app is supposed to be there "for life".
Users don't like menus where options disappear over time.

But.. in v39 there appears to be a bug in that userland can never return control to the menu (oops).

I'll fix THAT for v40.

Users don't like menus where options disappear over time.

True enough. The bug you mentioned is more what I was concerned about. I couldn't find a way to get back into the player.

Just code your app to do another WAITMENU when it's done.

v40 will be another half hour or so (working on the blanker fuzz factor thingie)..

A half hour between releases? Slacker!

>A half hour between releases? Slacker!



Actually, I've never had so much trouble in recent memory with signed/unsigned problems..

Okay v40 is going up in a second or two.

It has a screen blanker sensitivity setting to supplement the timeout.

The WAITMENU ioctl should now allow apps to return to the menu.

Screen blanker timeouts are in 15sec multiples instead of 30sec now.
(max = about 15 minutes).

And the keypress detection in the blanker should now actually work.

Enjoy.

Ah. Fantastic.

The percentage-of-screen thing is a great compromise. Works perfectly. I'm happy!

>Damn...
>
>You really live that "release early, release often", don't you?

Not meaning to sound a lot like ESR, but early/often is by far the best way to harness the power of the internet for rapid development, especially early on when the design is in flux.

With almost instantaneous feedback and scrutiny from various clever folks on this BBS, the design has gone from clumsy double-button on/off with no feedback, to fancy, extensible menus with a ton of stock features, all in a rather condensed period of time (four weeks, one week of which I was completely offline rock-climbing in J-Tree).

I'm giving a small talk on these principles, and how to get involved with OSS, at Comdex next week. If any of you are around and can make it to the session, feel free to grab me and chat Empegs (or whatever).

Cheers

Mark Lord

v41 is up, on the heels of v40.

NO USER VISIBLE CHANGES!! So if you already have v40, don't bother with v41 unless you are programming with the ioctl's.

New in v41:

-- faster screen compares for the blanker function (frees up a tiny amount of CPU)
-- MENUWAIT now does an UNBINDBUTTONS first, in case userland forgot to
-- the comments on "how to use" MENUWAIT have been updated to match the altered interface

That's basically "it".

I'm going to disappear for a month or so, 10 days from now. Here is what I think I have left to do on the userland interface:

-- provide a way to mmap() the hijack_displaybuf[] for better efficiency from userland
-- provide a "REFRESH" ioctl for use with the mmap()
-- stop changing things so quickly

Speak now, or generate your own kernel patches until Christmas..

Cheers

-ml

Ok, I think this is maybe too much to ask but what about starting to work on a backup application? I mean, a complete one? All these hacks are absolutely great. I am installing one version after the other. But what I am still very concerned with is to have some sort of application that copies everything on my pc hdd and copies it back to the empeg any time I want. Dbase, playlists, fids, everything. I know you're developing stuff which is pretty different, but I was just hoping you could use your skills and expertise to do something about this.

Thank you for your great hacks, really.

Reading what Mark has said so far this isn't something we are going to get out of him... he works on the kernel and likes to stay there...

a back up application will most definitely be a userspace thing... hopefully it will be something we might be able to include in an hda2 image... maybe just having an ftpd easily installed and running will be enough for us to then be able to write a sensible backup and restore program from the desktop side (ie backup is just a get of everything... and a restore is a put of everything...)

backing up the settings would just be a get and put of the contents of /dev/hda3... this might be a bit harder through ftp (would a get on /dev/hda3 be enough to be able to add it to an upgrade file for reapplication...?)

Cheers

Kim

With userland menu, we could set parameters for F V Gestel Displayserver as already posted on the board.


With this menu we could launch the server to start and to stop.

;-)

>I'm going to disappear for a month or so, 10 days from now.

so you could squeeze out at least another 10 revisions?

This is really fantastic. Again, Great work!

I suppose a "SET_OVERLAY_GEOM ioctl would also be useful to more than a few apps, right?

In reply to:

---

This version has a different implementation of the WAITMENU ioctl() , so if you've written code that uses it, you'lll need to change your code. The new implementation allows a single process to create multiple menu items and wait on all of them at once with a single ioctl(). This is much closer to how it is most likely to be used with a userland "dispatcher" that fires up the actual applications.

---

Speaking of which, if somebody out there is writing a userland "dispatcher", which binds a bunch of menu items and then launches apps as the buttons are pressed: Just bind/wait everything all at once with the new WAITMENU ioctl.

If later you need to further extend the menu, just send a signal to your waiting thread (the one that did the WAITMENU) -- it will return from the ioctl with -EINTR as the result code. It can then add whatever to its menu label list and then reissue the WAITMENU. Not likely anyone needs to do this just yet, though.

A couple of more suggestions of things that would be useful in your short knob press remapping...

1. Mark a track
2. Set as bookmark 1 (or X would be nice... but picking 1 would be fine)

Cheers

Kim

Are you sure you really want the knob to act as a "Mark" button?

Or are you just looking for a menu selection to "(un)Mark current track" instead, just to have the capability when the remote is absent?

Yep... I suppose I am looking for an easy way to mark a track while driving... cos hunting for the remote, which I rarely use when in the car, is annoying and often means I don't bother to mark a track I would otherwise mark for attention...

What would be nice would be to have menu of configurable shortcuts... ie I could add Mark, Info, Set as Bookmark 1, Get Bookmark 1 to my shortcut menu... and others might add a different set of things they want to get quick access to... These are not quite things you can do with a userspace menu... unless we have some way of attaching these capabilities to menu items we add... call it being able to add a menu item that calls a builtin function rather than only being to add menu items for user defined functions...

Further along this line... having written a patch to allow overriding of the power connector detection (I'll hopefully have it tidied up and available tomorrow), it might be nice to be able to change from in-car mode to in-house mode on the fly... (not sure if the player would keep up with this mind you)

Did any of that make sense...?

Cheers

Kim

I'm giving a small talk on these principles, and how to get involved with OSS, at Comdex next week. If any of you are around and can make it to the session, feel free to grab me and chat Empegs (or whatever).



Re: release early,often... I was NOT complaining... That was most definitely a compliment. I wish more would do that.... (1.x - 2.x... hint hint hint )

RE: Comdex... Damn it. I canceled out of coming simply because it appeared to be more of the same... NOW you tell me.

this might be a bit harder through ftp (would a get on /dev/hda3 be enough to be able to add it to an upgrade file for reapplication...?)




dd if=/dev/hda3 | gzip -c -9 > /tmp/hda3.gz

Takes about 20 seconds to do, results in a 166k image.

zcat /tmp/hda3.gz | dd of=/dev/hda3

Does the restore.

Now we just need a small script launched by displayserver that runs this, transfers the file and then transfers the fids. It ain't perfect, but it would (and does) do the job.

Heck yeah, the overlay thing would be a beautiful Christmas gift. :)

In reply to:

---

What would be nice would be to have menu of configurable shortcuts... ie I could add Mark, Info, Set as Bookmark 1, Get Bookmark 1 to my shortcut menu... and others might add a different set of things they want to get quick access to... These are not quite things you can do with a userspace menu... unless we have some way of attaching these capabilities to menu items we add... call it being able to add a menu item that calls a builtin function rather than only being to add menu items for user defined functions...

---

Okay, I've just added a new ioctl() to allow userland to "inject" button presses into the player software (bypassing the hijack: ya can't inject buttons to yourself).

Now go and implement that nice userland shortcut menu for us!

>Heck yeah, the overlay thing would be a beautiful Christmas gift. :)

Done.

Okay, the HHGTTG release (v42) of "hijack" is out.

I rewrote the voladj overlay code to be more generic, and included a userland ioctl() to make use of it. So, to do an overlay from userland, fill in your 2048 byte copy of the display buffer as normal, and use SETGEOM to specify which rectangular portion actually gets displayed. Only one overlay at a time for now.

I also spent another flash bit to extend the choices for blanker sensitivity down to 65%. That should be more than enough for any realistic scenario.

There's also a new INJECTBUTTONS ioctl for userland apps to send button press / release codes to the player software, for shortcut menus or whatever.

That's all I plan on doing until Christmas, other than fixing the odd bug or two (the mmap() stuff can wait for now; it might not even be needed by anyone).

Now I want to see some code that uses this stuff !!

Speak now, or generate your own kernel patches until Christmas..

Okay this isn't directed at Mark, it's more directed at everyone who's doing userland development. This kernel patch is basically the Rosetta Stone for Empeg development. We now have the key to accessing the display, taking input, and selecting menu options, all while the player is running. I think we can now start to put together the rest of the puzzle and knock down some of the things that have impeded development so far.

With this in mind, I think the next step is a vector graphics library which writes to the soon-to-be-mmap'ed hijack display buffer. Awhile back in this post a guy named brianosaurus said he had successfully ported the GD library to the Empeg and had it working pretty well. Unfortunately this was his only post to the BBS this entire year, and he hasn't been back since. He also doesn't have his email visible in his profile... (Tony, any chance you can see it with your moderator powers?) This sounds like it might work... But if we can't get that, or it's not the right solution, there needs to be some consistent graphics API for user developers to use.. I'm just not smart enough to write my own vector graphics routines. Anyone have any ideas?

The custom init dispatcher is another big piece of the puzzle, but until that happens, there's nothing very much wrong with each app binding to the menu on its own. Besides I just ordered a MkIIa so I'll have an extra 4MB to play with. :)

Tony, any chance you can see it with your moderator powers?

Yes, but if someone chooses not to reveal their email address publicly, I have to respect their privacy and I don't think it would be right to give it out.

I'll send an e-mail to that address myself and give him yours in case he wants to get in touch with you. That should take care of it without compromising his privacy.

I have just loaded v41 onto my Mk2 empeg. Now if I understoodd your instructions correctly pushing "Cancel" on the Rio remote or "*" on the Kenwood remote should get me out of your menus. Well it doesn't Waiting 5 seconds does work though.

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!