Announcing the Latest, the Greatest, the Best Hijack kernel yet! Hijack v79 is now available from http://rtr.ca/empeg/. Get it while it lasts (hopefully a long time..).

Changes since v78:

-- independent "Knob Press Redefinition" actions saved for car / home
-- new options for "Knob Press Redefinition": [default], PopUp, VolAdj+, Details, Hush, Info, Mark, Shuffle
-- minor bugfix in read of config.ini (used to fail on "empty" players; may still!)
-- temperature now displays correctly on Vitals screen
-- the High Temperature Warning range is reduced to 35C - 65C (saves one bit in flash)

The "PopUp" knob setting causes each subsequent quick-knob-press to pop-up a small window from which a desired action can be chosen. Options on the pop-up menu include: [default], Details, Hush, Info, Mark, Repeat, Shuffle, Visual

In both menus, "[default]" means "factory default", without any "VolAdj" pop-ups, so selecting this will launch the Volume, Loudness, Balance, .. cycle of sound settings.

Together with separate knob settings for car/home, that oughta keep most of us happy.

Enjoy,

-ml

The "popup" option is awesome. Great stuff.

Given any thought to any of the startup behavior from config.ini stuff? Maybe a nice project to start off the new year?

excellent most excellent.

I've got a comment I meant to make earlier about the font used for the menus that your kernel shows.

I notice that you make the menu font dim for the prompts and the current option bold [normal brightness in the day].
This makes it hard to read these options when in the car in daytime.

My suggestion was to invert the font used for the current option selected and leave the prompt text not inverted but normal brightness [i.e. don't use dim/bold use normal/reverse text].

I'm not sure how easy it is to do this -if you do the bit map rendering onto the display yourself then presumably all you do is invert the meaning of the fonts bits for the current setting to make it reverse video text.

Thats my suggestion - it may look terrible I don't really know.

Then again it may look great.

any comments?

>Given any thought to any of the startup behavior from config.ini stuff?

Yes, and it's a BIG job, especially to keep a SMALL kernel afterwards.
But it will get done.

Over the next week or so I'm going to look more at incorporating a khttpd (or kftpd) into Hijack, with upload/download/dirlist capability.

Once that is working (if ever), I'll also add a mechanism for remote command execution (easy with khttpd, not so simple for kftpd..), which when implemented could also allow commands from config.ini and from the menu itself..

Cheers

>I notice that you make the menu font dim for the prompts
>and the current option bold [normal brightness in the day.
>This makes it hard to read these options when in the car in daytime.

Yes, in bright daylight the non-bold text is harder to see.

But I just don't like inverse video so much.. for it to look nice, the corners need to be rounded (ala Empeg menus).

But it's simple enough to try.. perhaps I'll make a config.ini option for it.

Cheers

Okay, I've just posted Hijack v80, which has a revamped look'n'feel, to hopefully make the menus & settings easier to see in bright daylight.

I would like to hear feedback on the new look (v80) versus the old (v79), before things change so much that it cannot be easily reverted.

Cheers

In reply to:

---

-- temperature now displays correctly on Vitals screen

---

Mark, can you clarify what you've done in this respect as mine displays correctly to within 1 deg C or so. This is the temp of the Hard Drive Cradle which is the most temperature sensitive part of the player I believe.

>temperature now displays correctly on Vitals screen

On v78 (at least), the temperature display on Vitals was toggling back and forth between "corrected" and "uncorrected" values (4C difference). It no longer does this, but rather just displays the corrected value as intended.

-ml

Oh, ok, thanks. I'm running v66. Haven't noticed any oddities in the temp display on this version. I know it's a bit late but, welcome back after your holiday.

>welcome back after your holiday.

Thanks! And to everyone else also!

-ml

Hmm,
Not quite what I had in mind - what I sort of envisaged was to have the current setting highlighted with normal brightness reverse video [with rounded corners to look nice] rather than the not so bright cross-hatched reverse video look you have now.
My idea was to make the current setting and the prompt for the setting the same brightness but to seperate 1 from the other using reverse video so you could tell the prompt from the setting.
I do like the rounded corners - it makes it look empeg like as thats how they do their menus I guess [which suffer the same problem in daylight in the car too I might add].

BTW: The reason the current setting rather than the prompt is reversed is thats normally the shorter of the two things, I assumed the shorter text in reverse video would look better.

Thanks for the follow-up!

Yeah, what's there now is definitely not as bright as plain reverse video would be (which is how I did it originally). But plain bright reverse video turns out to be VERY DIFFICULT to read, or at least I thought so when I tried it.

Bummer..

I'll live with v80 for my road trip this week, and see if it works or not for me.

Anybody else got opinions?

I don't think the v80 setup (bright foreground on dim background) is bad at all, but I think the background should extend all the way across instead of cutting off at the end of the text. Or in other words the "highlight" shouldn't change width. Also, the non-selected text should be bright foreground on black background, if you ask me.

The bright on dim combo is also what the player uses for the selected item in its horizontal menu, and nobody has seemed to have a problem with that. I agree that true inverse text (black foreground on bright background) looks crappy.

The other combo that might work would be black foreground on dim background, or black foreground on medium background. Then it's still "inverse" sorta, but maybe not as ugly. Try those maybe?

>the background should extend all the way across

I'm still thinking about that one (above).


>non-selected text should be bright foreground on black

It used to be dim foreground on black originally, and nobody complained .

I find that if I use bright, then the currently selected menu item is difficult to distinguish at arms length when driving.

What do you think?

-ml

I find that if I use bright, then the currently selected menu item is difficult to distinguish at arms length when driving.

Not if the selected item was black foreground on medium background... The dark text in the highlighted item should show up strongly.

>Over the next week or so I'm going to look more at incorporating a khttpd (or kftpd) into Hijack,

Okay, looks like it will be an ftpd that gets incorporated -- I want to be able to use "mirrordir" (awesome!) under Linux as my empeg filesystem backup manager, and mirrordir supports ftp but not http. That was an easy decision.

At present, I've got a basic custom-written ftpd skeleton working as a standalone usermode program. One connection at a time, no passive mode, but it is tiny in size and mostly works. After adding some more functionality to it, I'll try moving it to kernelspace and retest on my laptop. If that all goes well, then I'll move it to the Empeg "hijack" kernel, and see what breaks.

It'll likely be a couple of weeks, but we should soon have ftpd built-in to the kernel.

So what's the fuss, you ask?

With an FTP server (ftpd) built-in to hijack, easily installable by anyone who can point and click in Tony's Logo Editor, we can suddenly get FULL access for remote browsing / backup / restore / customization / whatever, usable by anyone.

As mentioned, us Linux users already have "mirrordir" for awesome automatic backup / restore of the player. Windows folks will need (or need to find) a similar program. I am giving this heads up so that y'all have time to look for or write something suitable.

The protocol will be this ftp subset: PORT, LIST, RETR, STOR, DELE, RMD, MKD, CWD
The USER and PASS commands are accepted but ignored.

See RFC 959 for more info.

-ml

So what's the fuss, you ask?

You're kidding, right? I think everyone can understand how terribly cool it would be to have an FTP server on the player that doesn't require any mucking about at the shell prompt (or even any Linux knowledge) to install.

What blows me away is that you can get it shoehorned into the kernel and keep it small enough to fit in the flash. That's just mind-boggling. Can't wait to see it.

There's something I really like about your approach to hacking the kernel. There are certain things you're doing which, in the past, have been dismissed by others on this BBS as being "inappropriate for inclusion into the kernel". In other words, things that should more logically be included in user-mode applications. For example, I always thought that the selections for the Voladj should have been in the kernel all along, but arguments were made against it.

But I say, hey, we've got this fully open source kernel that terribly easy to install. Why NOT throw the kitchen sink in there?

Yeah, fwiw, I like the original menu style. Guess I'll be using that config.ini option..

FTP is really easy...especially if you can assume you only have one user at a time, and only implement a small subset. I really would have liked to use rsync, but at present it takes up way too much core.

In reply to:

---

I would like to hear feedback on the new look (v80) versus the old (v79),

---

Dude, it's great. I really like it. Thanks for the hard work and continuous improvements.

rjf&

Hi.

At present, I've got a basic custom-written ftpd skeleton working as a standalone usermode program.

Would you mind sharing that program? I have some spare time tomorrow and would like to build an upgrade image that contains a kernel to boot from the spare partition and that includes some basic services (displayserver, ftp, probably rsync, possibility to start custom additions). And as some people reported stupidFtpD to be unstable, I am looking for a replacement.

cu,
sven

>would you like to share [kftpd]

I could send you the basic skeleton, but it is missing the code to actually generate directory listings (just echos back the dirname for now) and the code to read/return real file data (just echos back the dirname now). Those are "easy" to add, but I've left them out since they'll be completely different when done in kernel space, and I wasn't that interested in user space.

Cheers

Hi Mark.

Would still be nice (as it would save me from getting into the protocol stuff too deeply). Could you mail it to [email protected]?

cu,
sven

For the "original menu style", use this in config.ini:

[hijack]
old_style=1

Mark, could you maybe extend the "highlight" in the "new style" menus to the entire width of the display, regardless of the width of the menu text? That is more like other menu systems where the highlight bar is a fixed width.. It's picky, I know, but it looks more professional. Or maybe make it an option or something... I took a two minute look at the code and saw a bunch of places where colors are set, but couldn't find the right spot to make this change... Maybe I'm the only one who thinks that it's better that way, if so, forget I asked...

>maybe extend the "highlight" in the "new style" menus
>to the entire width of the display,

Not at all easy to accomplish -- it would require a fair bit of extra code, for no increase in functionality.

??

-ml

it would require a fair bit of extra code, for no increase in functionality.

Okay, wasn't aware it was that big of a deal. I agree, bigger fish to fry.

I have yet to install Hijack, but I'm determined to get another 4 posts in tonight, so I thought I'd stick my nose in. :)

Did I read that your menu system was vertical? Do you ever have any text to the right of the text that makes up the menu titles?

You can always pad the menu entries with spaces if your highlighting is character-based.

Now that I'm in here, these threads seem to always go all over the place, so here goes.

Someone else was mentioning the fact that your menus might be getting a little unwieldly for someone who wasn't going to use most of the options. How about a config parameter to eliminate (display only) options from your menu?

I'd actually like that ability for the player itself, because there are a bunch of items I'll set once and never touch again (or rarely). I wish most of the settings could be set through emplode, locked and hidden from the player interface; it would sure streamline player usage.

BTW, I'll definitely be installing Hijack. I just thought I'd better get my system to a stable state before I start throwing additional variables into the mix. :)

Bruno

> I have yet to install Hijack, but I'm determined to .. stick my nose in

I think maybe you should try it first, and make suggestions later.

At present, the menu is NOT unwieldly, especially when using the knob to access it. But it has potential to become more encumbered over time.

There are a couple of items that would be nice to merge into single entries (the two blanker settings and the two timer settings), but apart from that, just about everything is there for a good reason, rather than in config.ini

There are some Hijack settings in config.ini also, and one or two that may get moved to there (and off of the menu). But config.ini currently REQUIRES Emplode on MS-Windows for modifications, and us Linux folks think that's pretty software-racist. Jemplode isn't currently working on RedHat 7.2, and Emplode doesn't quite run under wine yet (could somebody please fix that!). Emptool doesn't have any obvious way to edit config.ini either.

So, I will not be putting too much into config.ini until I can easily edit it from Linux -- something I'm actually working on right now for Hijack.

Cheers

-ml

Oh, it's not that I wanted settings from Hijack moved to the config... It's that based on the other thread, instead of merging things and possibly sacrificing your design (something you shouldn't do, IMO), you might be able to offer people the ability to simply hide what they think they won't be using. Even if the interface to hide certain items is built into the interface of Hijack itself. :)

BTW, you can edit the config.ini remotely and upload it to the empeg, right?

Bruno

BTW, you can edit the config.ini remotely and upload it to the empeg, right?

Right. Or in situ, from the bash prompt, if you have installed an editor on the empeg.

/Michael

>BTW, you can edit the config.ini remotely and upload it to the empeg, right?

Not today, I can't. There is no way for the consumer image to do this.

And even the developer image requires a lot of work to set it up for this, other than mucking about with sz/rz every time.

A Huge part of the elegance and appeal of Hijack is that it does NOT require any Linux hacking of any kind to install and use. Just a simple kernel download, using simple tools available on both major platforms.

This limits what we can do (to maintain mass appeal), and forces a lot of stuff into the kernel that might otherwise be in userland.

Once I finish getting my kftpd incorporated into Hijack (next week?), this will all change.. anybody with an ftp/web browser can then hack any file on the player with relative ease. And it's really easy to whip up more restrictive front-ends for specific tasks like option-setting and backup/restore.

But it ain't there yet.

Cheers

-ml

>>BTW, you can edit the config.ini remotely and upload it to the empeg, right?
>Right. Or in situ, from the bash prompt,
>if you have installed an editor on the empeg

Both of those are impossible for 99% of empeg users, running the standard consumer images. There is no bash prompt. There is no (easy) editor, other than perhaps "cat" (which is what I personally use to write all my code)

Cheers

-ml

Are you saying that this doesn't work on the consumer image? If so, I need to update this FAQ entry.

What Mark originally said was:

But config.ini currently REQUIRES Emplode on MS-Windows for modifications, and us Linux folks think that's pretty software-racist. Jemplode isn't currently working on RedHat 7.2, and Emplode doesn't quite run under wine yet (could somebody please fix that!). Emptool doesn't have any obvious way to edit config.ini either.

Or of course the developer version for rz/sz'ing the file, ftp, scp etc or editing in situ.

To the best of my knowledge the edit config.ini via emplode works (I've only used the consumer version when it initially came preloaded on my MkIIa and briefly when trying to debug a snag in my disk shuffling exercise - 3 existing disks, 1 new; 1 MkI and one MkIIa...)

/Michael

i think mark meant that there's no way for a non-windows user, like himself, to edit config.ini with the standard consumer image install.

--dan.

I think the number of people running the developer image is greater than 1%, but I guess most would be running consumer. I've always run the developer version except when I very first tried 1.03 to make sure the new drive cable was working.

Now with all the drive space I'm thinking of installing a mail and nntp server.

Bruno

Yeah, just kidding about the mail and news. :)

Myself, I have never yet installed a Developer image..

I'm hoping to use one of my units as an auxiliary NFS server for my website when the latter starts running low on space.. would be better if I had a 60GB unit rather than the 30GB I have on order.. anyone wanna do a swap?

-ml

I think it does, but editing Win registry is not for the faint of heart, either (i.e. for your average Joe the Consumer). (Not that Joes the Consumers are very likely to buy empeg, though ).

Simple to double-click on a reg file to add in the needed keys. I've seen people mess up their systems in all sorts of ways. I wouldn't dream of ever telling these people that Windows even "had" a registry, let alone they could touch it.

I think I first opened regedit a few days after I installed my first Win95 system (that was my first PC :)

Bruno

Yeah, I forgot one does not have to actually edit the registry (and I am still extra carefull doing that, like checking working directory three times when typing 'rm -rf' while root on Unix ). Ah, I see now there is a link to .reg file. Tony thinks of everything!

I believe the issue with JEmplode on RH 7.2 (other than RH 7.2 being broken ), is that RH installs kaffe as the jvm, and personally, I haven't had much luck with it. Better off with the blackdown or the Sun versions of the jre.

I am currently working on a HiJack panel in the Configure Player dialog in JEmplode. I currently have it sync'ing "Use Old Style Menus", so the framework is there, and I will be adding the options for voladj, and other's.

Gimme a week. I also told mlord that I will try to find the issues with kaffe, but that is lower on my list, given that I really don't like kaffe :-)

rjf&

So, I did a little investigation into why Kaffe isn't able to run JEmplode.

The issue appears to be that it doesn't fully support the 1.2 jvm, and that would be a problem for sure.

If you guys really wanna try out JEmplode (and you should), grab the Sun JRE for Linux

Cheers,
rjf&

Is there any way you could include some redefinition for the buttons of the Sony Stalk remote? I'd like to see something like that very much.

Great work you're doing so far!!!!

Greg

Im working on it [or more like trying to get Mark Lord to put a mod into the Kernel so we can start looking into this].

There another thread with this in it.

If you can figure out where (if at all) the stalk data passes through the kernel, then I will add code to intercept it and allow IR translations on it.

Cheers