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.