Quote:
demo of my seeburg wallbox interface.

Quote:
Absolutely fucking brilliant.

Awesome.

Quote:

1. I was planning to use the DTR output as the pullup resistor +5V source. But it looks like it's deasserted (-5V). Most rs-232 DTEs assert DTR. I can turn it on in my driver, but is it used for something else?

Quote:

2. I'm currenly using fprintf(empeg_notify_fp,"SERIAL=#fid\n") to queue the song. But I was thinking of using the "write" portion of my driver to "notify" the Hijack kernel directly. I've looked at notify.c, but I'm not sure which function to call.

Quote:

3. I'm using down(&sem) but I'd like to use down_interrruptable. When I do, I get an unresolved external. I #include <asm-arm/semaphore.h> but it doesn't help.

Quote:

4. What's the best licence to release under (e.g. BSD)?

Quote:

5. I'd like to release the code, but I probably need some sort of "code review" for my kernel / driver changes. Can anyone help out?

Quote:

6. How do I pick a "real" device MAJOR number?

Quote:

... DTR seems to have no non-standard (RS232) use.

Quote:

The implementation of "SERIAL=" itself calls hijack_serial_rx_insert(the_string, strlen(the_string, 1))

Quote:

That's weird. down_interruptible() is a kernel inline function, so it doesn't really exist at run/link time.

Quote:

Just release it, and anyone who cares will eventually have a peek at it.

Quote:

Quote:

6. How do I pick a "real" device MAJOR number?

For the empeg kernel, the simplest is to just re-use an existing one that never had meaning on an empeg. [See] Documentation/devices.txt file from the kernel source tree.

Quote:
I noticed that when I write to empeg_notify, I need to send "+" as "%2B". When I call rx_insert directly, Can I send "#FID+\n" or do I still need to send "#FID%2B\n"?

Quote:

How exactly do I release the kernel part?

Quote:
tfabris, you are fined one credit for a violation of the verbal morality statute.

Quote:

Quote:

How exactly do I release the kernel part?

You could start by posting it here as an attachment. Then I can have a look-see and decide how best to incorporate it into Hijack (based mostly on code size, compatbility, etc..).

file:drivers/char/serial_sa1100.c line 2342
.
#ifdef SERIAL_DEBUG_OPEN
        printk("rs_open %s%d, count = %d\n", tty->driver.name, info->line,
               info->state->count);
#endif
+        //hack -- force on DTR because driver doesn't
+        if(line==1)
+           GPDR &= ~EMPEG_SERIALDTR;
+        //hack-end
.
.
.
file /drivers/char/mem.c line 699
.
	extern void empeg_cs4231_init(void);
	extern int empeg_power_init(void);
+	extern int seeburg_init(void);
+	seeburg_init();
#ifdef CONFIG_EMPEG_RAMTEST
.
.
.
file: arch/arm/special/notify.c line 40
.
#define NOTIFY_FIDLINE           2               // index of 'F' in notify_chars[]
+#define NOTIFY_SOUNDLINE        6               // index of 'S' in notify_chars[]
#define NOTIFY_MAX_LENGTH       64
static char notify_data[NOTIFY_MAX_LINES][NOTIFY_MAX_LENGTH] = {{0,},};
.
+const char *notify_sound (void)
+{
+        return &notify_data[NOTIFY_SOUNDLINE][0];
+}

Quote:
Seeburg.c driver attached

Quote:

Could you perhaps just create a proper unified patch instead,
by running this command (below) to differentiate between an original
Hijack kernel tree and your modified kernel treee?

diff -u --recursive --new-file hijack-v477/ seeburg/

Quote:

Do I need to patch to the current v477 or can I do the diff -u on my unmodified v461 tree?

Quote:

A diff against v461 should be new enough for this purpose, so just diff what you've got.

Quote:

A diff against v461 should be new enough for this purpose, so just diff what you've got.

Quote:

As requested... Two of two attachments. This patch is for time.h only. It looks like I ran "indent" on the time.h file after I added my code.

Quote:

Could ya maybe do it again with the -b flag then ?

Quote:
Just re-read my post, I think what I am really asking is can you post a copy of the patched kernel and info on how the whole project can together.

I am sure there are few people here who would love to give something similar a try

Quote:
I'm on my way back from vacation, but I'll try to get something out late next week.

Brilliant!

There is no rush of course, my unit is in safe hands in the States until I can figure a cost effective way of shipping it across the pond

Again, cool project

Cheers

Cris.

Quote:
...why don't you try and use a microcontroller like a Picaxe to fit between your box and your empeg, I bet you'd find it much easier.

Quote:
Cris, seeing as hacking kernels isn't your thing, why don't you try and use a microcontroller like a Picaxe to fit between your box and your empeg, I bet you'd find it much easier. The Picaxe is a piece of piss to program.

I like the idea. And I think an ultimate goal may be this solution. I had been looking around at other solutions but hadn't seen this product before.

I'd like to develop something that would interface with my slimserver network in the house, say over WiFi. But for now using the empeg seems like a really good idea, it gets used once every 2 weeks or so at the moment and this will put it back into regular usage.

I guess I will have to wait for my unit to turn up and see if it works first

I am still unsure how you build the seeburg driver into Hijack, is it possible to post a patched version here that I could upload just like anyother hijack update?

Cheers

Cris.