Hi,

Whenever I send "SERIAL=+" to proc/empeg_notify, only a space is copied to the serial port (as seen in Hyperterminal in Windows XP). Most other serial commands work, such as sending "SERIAL=-", which copies a minus sign to the serial port and lowers the volume. "SERIAL=x" does get copied to the serial port, but the volume is not changed.

Is this a bug, or is the "+" sign something special in Linux?

I am doing this by calling DoSerialCmd("+");

int DoSerialCmd(const char* szCmd)
{ FILE *fs_EmpegNotify=NULL;
fs_EmpegNotify = fopen("/proc/empeg_notify", "a");

if(NULL==fs_EmpegNotify)
{ DEBUGF("could not open empeg_notify to receive serial commands");
return 0;
}

fprintf(fs_EmpegNotify,"SERIAL=%s\n",szCmd);
fclose(fs_EmpegNotify);

return 1;

}

If I type "+" directly in the terminal the volume does get raised.

Any clues as to what is happening?

I think this is the last thing I need to get working before this stuff I'm working on is releseable for other Empegers to use..

Thanks.

EDIT: I subsequently tried copying "button=VolUp" to /proc/empeg_notify, and the result is a restart of the current tune.

Welcome to the URL construct, where a "+" sign represents a space..

Thanks for the reply Mark.

Is there any way to get around this? Or is there another way to raise the volume (I tried sending "x" which does nothing, and "button=VolUp" which is equivalent to pressing the left button in the empeg. --Neither work.

Haven't tried this, but give SERIAL=%2B a shot. That's a urlencoded '+' sign.

http://my.empeg?button=volup

Works for me.

Thanks you Tony!

That works great!

Mark,

http://my.emgeg?buton=volup works from a browser, but when I send it to proc/empeg_notify the effect is that of pressing the left button in the empeg.

That's probably because button is spelled with two t's, not one.

Works for me.

-ml

One "t" was a typo in the message. The behavior when using two t's is as explained. Perhaps there's something peculiar about my Empeg...

It works fine on my three empegs.

Maybe the method you are using to issue the command is (again) flawed.. ?

Here is (again) the function I wrote to execute serial commands:

int DoSerialCmd(const char* szCmd)
{ FILE *fs_EmpegNotify=NULL;
fs_EmpegNotify = fopen("/proc/empeg_notify", "a");

if(NULL==fs_EmpegNotify)
{ DEBUGF("could not open empeg_notify to receive serial commands");
return 0;
}

fprintf(fs_EmpegNotify,"SERIAL=%s\n",szCmd);
fclose(fs_EmpegNotify);

return 1;
}

When I call DoSerialCmd("-");, the volume goes down
When I call DoSerialCmd("F");, fast forward begins,

So calling DoSerialCmd works for most things, including replacing, enqueuing, Fids, etc.

However DoSerialCmd("button=volup"); does not raise the volume, instead it returns to the start of the currently playing tune. Sometimes it switches visuals. Does weird things, but never raise the volume.

DoSerialCmd("%2B"); does raise the volume, so my particular problem is solved. At this point, the issue as to why this doesn't work is more of a curiosity for me. Do you see the flaw in the function above?

I doubt that Hijack really understands the intent when that program sends this to /proc/empeg_notify: SERIAL=button=volup

Why not send this instead: BUTTON=volup

Cheers

Thanks!

I can see how two equal signs can confuse things. Perhaps you can help with two issues that are currently making my app delicate:

1) Is there any way to make the process running my app equal priority with the player? It only runs very short instructions (sends 16 bytes using sockets), and then only once every second. However, it must be able to do so. Sometimes it is CPU starved, typically when a tune has just started playing, and it doesn't get any processing cycles for up 7 seconds.

2) Can I programmatically take over all input to the player (but turn this off programatically as well). While I am controlling the Empeg, I want to prevent user interaction with the player app. Ignoring everything is OK. However I need to be able to restore interaction when the remote user is no longer controlling the Empeg. I run this with ;@exec_once.

Thanks again.

The Hijack ioctl() interface (see the hijack.h file in the kernel sources) has a means of intercepting nearly all button presses.

As for the priority -- if you are willing to have the music playback "stutter", then you can have Linux move your process/thread into a real-time scheduling class, similar to the player software. I think this is done via "sched_setparam(2)" -- try "man sched_setparam" on a Linux box. The real-time classes are SCHED_FIFO and SCHED_RR (round-robin), with several priority levels to choose from (any will do here).

Cheers

emphatic does both of the things you're talking about. Go to my empeg page (in my .sig) and download the emphatic 1.10 source. The setschedparam stuff is towards the top of emphatic.c, and the means of optionally blocking/sending input events is sprinkled throughout.. Basically, you bind all the buttons you want to trap, and inject all the ones you want to send (or unbind from them, in the case you no longer need to receive them at all.)

Incidentally, I'm not sure setting your scheduler / priority is going to necessarily give you the results you want.. But it's worth a shot.

Mark, Tony, thank you both for the pointers to priority setting and intercepting buttons!! You guys are great help.

I Will try to implement. These kind of things are tough when you've been programming DOS/Windows all your life and the only experience outside of that is this little Empeg project. I can see effectiveness of how the Linux/Unix world operates, but it is a daunting thing for a Windows programmer. I'm learning quite a bit.

Please pardon my obtuseness, but how can I get my hands on Hijack.h? tars, bz2's, and patches are all completely new things to me, and I don't have tools to deal with them under Windows. Luckily, WinZip was able to handle the tar gzip format of the Emphatic source.

Thanks again guys!

You probably already have hijack.h, since you are already compiling code somehow for the the player.

But just in case you don't have the kernel sources, I've attached the current copy here.

Cheers

In reply to:

---

You probably already have hijack.h, since you are already compiling code somehow for the the player.

---

Not necessarily, as the program shown doesn't use any Hijack APIs - it just opens the control device using stdio.h calls. The few programs I've written for my player were compiled, installed and run before I first downloaded Hijack (oh, those dark, unenlightened days).

Thank you very much.

I currently compile remotely courtesy of Bitt Faulk (was never able to set up a toolchain in my machine), so I assume I should've been able to find Hijack.h somewhere in his machine. However my code does not have #include "hijack.h", so I can't be positive. Your courtesy in attaching it is greatly appreciated.

Setting the realtime priority worked great, and it did mostly solve the issues I was looking to solve. Thanks for the pointers, Mark and Tony.

The button hijacking thing is not doing a thing for me. When I start to block all button input to the player, the following code executes:

int rc,fd;

unsigned long data, buttons[13] = {13,
IR_TOP_BUTTON_PRESSED,
IR_TOP_BUTTON_RELEASED,
IR_RIGHT_BUTTON_PRESSED,
IR_RIGHT_BUTTON_RELEASED,
IR_LEFT_BUTTON_PRESSED,
IR_LEFT_BUTTON_RELEASED,
IR_BOTTOM_BUTTON_PRESSED,
IR_BOTTOM_BUTTON_RELEASED,
IR_KNOB_PRESSED,
IR_KNOB_RELEASED,
IR_KNOB_RIGHT,
IR_KNOB_LEFT};



fd = open("/dev/display",O_RDWR);
if(fd<0)
{ DEBUGF("/dev/display could not be opened!!:");
DEBUGF(sys_errlist[errno]);
}
else
{

rc = ioctl(fd,EMPEG_HIJACK_BINDBUTTONS, buttons);
if(rc<0)
{ DEBUGF("EMPEG_HIJACK_BINDBUTTONS failed!!:");
DEBUGF(sys_errlist[errno]);
}

rc = ioctl(fd,EMPEG_HIJACK_DISPTEXT, "Empeg under control\nof ES&P");
if(rc<0)
{ DEBUGF("EMPEG_HIJACK_DISPTEXT failed!!:");
DEBUGF(sys_errlist[errno]);
}

close(fd);
}

However, when the program is run, I get none of the DEBUGF indicators of failure, plus it is possible to interact with the player using its buttons. The text is not displayed in the screen either.

All I want to do is prevent direct user interaction with the player, by any means other than programatically. Should the procedure work, is it necessary to specify a humongous buttons array (and risk missing custom IR remotes), or can I somehow specify a range of button codes?

Is it necesary to call EMPEG_HIJACK_WAITBUTTONS ? Is it otherwise necessary to create a secondary thread that sits in loop executing EMPEG_HIJACK_WAITBUTTONS?

Again, thanks for all this free tutoring....