Okay, are there any custom kernel patches floating around that are (1) of general interest, and (2) not already swallowed by Hijack ?

-ml

The only one I can think of is the one that was needed for DisplayServer remote control of the player, and that has been superceded by your own functions now and isn't needed any more.

I am still working on a couple... but have had to take a break from them until my empeg is fixed...

you are welcome to the last versions I had to see if you can get them working properly...

They are the tuner detection patch and the exec patch... and should be available from http://www.ned.dem.csiro.au/CovilKim/empeg/

note they both are work in progress and so may or may not work... Up to you as to whether you bother looking at them... Hopefully once my empeg is fixed I can get back to working on them though that isn't likely to be for 2+ weeks...

Cheers

Kim

Hi.

I just noticed that you have the chunk type 4 patch for my upgrade splitter/builder tool up on your page (nice work, and now integrated in my (still internal only) new build of the tool). I also noticed a patch to boot from /dev/hda2 instead of dev/hda5.

Regarding the latter, I have made a patch (and submitted it to Mark Lord) that allows make menuconfig/xconfig/config to see that setting and to allow switching between the two possible root partitions.

To Mark: I checked wether that patch is really needed by now, as you suggested that changing the default kernel command line might achieve the same. However, changing the default command line does not work the same as that patch, because the default command line never gets activated on the empeg (it is always overridden by a "mem={8|12|16}M" line, depending on the actual hardware).
So there is a double wish, one easier to achieve, the other more useful to me:

1. I really would like to see a setting within hijack that allows to change the next root device from hijack menus. Like a "mount alternative root device on next boot" vs. "mount default root device on next boot" setting, either as a one time setting (only active for the next boot) or as a "from now on" kind of setting. The latter is probably easier to create.
2. Alternatively (as a short term fix) I would appreciate prebuilt kernel binaries that boot from hda2 instead of hda5 (in addition to the existing MkI/MkII builts, of course).
   

Oh well. Any volunteers for the first alternative?

cu,
sven

Hijack already has some code that supposedly was needed for Displayserver input.. anyone every try it?

Cheers

The alternative root device, selected via menu, is the one I dislike least from that list.

So if you want to patch it in and get it working, I'll likely integrate it afterwards. But I'm leaving it to you until then, since it is probably of general interest to nobody else.

Cheers

>the tuner detection patch and the exec patch..

I'll wait until they're ready, thanks.

Just saving some wear and tear on my flash.

-ml

No worries... I won't get a chance to work on them for a couple of weeks as my empeg is out of action at the moment and I am away on the other side of the country for Easter... but I will pick them back up again after that... in the mean time if anyone else feels like having a hack at them feel free...

Cheers

Kim

Okay, are there any custom kernel patches floating around that are (1) of general interest, and (2) not already swallowed by Hijack

Well, I would really like to see Kim Salo's kernel changes that are part of his GPS project added into hijack so I can stop switching kernels when I am testing his stuff. But, I doubt that qualifies as general interest. How about the audio overlay portion of it mentioned in this thread? That might be handy for other apps as well and would decrease the amount of stuff I have to try to hack into the kernel if I want both GPS and hijack at the same time.

-Mike

I've been away for the last week, or I would have replied sooner. I second the audio overlay patch. This is the main reason I'm not always running the latest HiJack kernel, as I need the audio overlay stuff for a couple of projects I'm working on.

Again not general interest yet, but will become more so as userland audio apps are written.

Cheers
PeterK

Well, a couple of folks have asked that the audio-overlay patch be included into Hijack.

I don't know what this is used for, but the code seems nice enough. Except for one thing: since 99.9% of us will never use this feature, I'd prefer very much that the buffers it uses not be allocated until first use. No need to dealloc them again, just don't chew up the memory until somebody actually activates the feature.

If that were included, I'd happily tuck it in into the add-on patches for pre-built hijack kernels.

Cheers

Except for one thing: since 99.9% of us will never use this feature

The one interesting use I would have for this is to have my trivia game read the questions to the user via text-to-speech. Combined with a steering wheel remote, a driver could theoretically be playing the game without too much distraction from his driving duties (no more distraction than talking to a passenger, anyway.) But that would entail me getting past a few roadblocks I hit in getting the TTS to work in real-time. It seems efficient enough, but the sound output isn't Empeg-friendly without some hacking. Once I'm moved into my new home next week and situated, I think I'll have some more time to devote to these things.

While not exactly a patch, I'd like to request module support. But I haven't seen anyone else talk about it. I want to do IR programming for my pager (which I'm guessing about zero other people care about). I figure, I can compile the standard IrDA and IrCOMM modules (and anything else they may need), but nobody else will want them... maybe someone else would like module support for loading other modules?

I've had Hijack on my player since the day I got it so I haven't played around with the standard kernel. If it has module support compiled in, then I could just use that and switch between it and Hijack.

In reply to:

---

Well, I would really like to see Kim Salo's kernel changes that are part of his GPS project added into hijack so I can stop switching kernels when I am testing his stuff. But, I doubt that qualifies as general interest.

---

Only because the rest of us can't use them yet.

Though, to be honest, maybe we can, depending on what they do. One of these days I'll fix the bad cable in my Earthmate, make sure gpsd is all integer and build it for the empeg. (The Earthmate speaks only Rockwell binary, not NMEA, but you can get more out of if that way if you want to. gpsd doesn't, yet, it just emulates NMEA)

Only because the rest of us can't use them yet.

Yeah, yeah, yeah ;-)

Actually, there are only three things that Kim's patch does that I know of at least. It does video overlays, passes button presses through to his software, and does the audio overlay. I would like to see Kim update his software to use hijack for the video overlay and button presses since that functionality is already in hijack and almost everyone seems to be using hijack these days. The audio overlay is, I think, unique to Kim's patch which is why I suggested that it might be a useful addition to hijack. But, Mark never responded so I don't know if he is too busy or not interested at this point.

-Mike