I'm working on a userland application with the famous hijack kernel.
Everything is working by now. I can add my own menu entries and start my application.
Now my question: Is it possible to remove or replace some or all (own) userland menu entries? I don't see this functionality at the moment. Shouldn't the EMPEG_HIJACK_WAITMENU ioctl call replace the menuentries? (instead of just add the new ones)?
My application should dynamically change/add/remove menu entries.
Is this possible with the current hijack kernel or do I have to wait for one of the next releases?

Thanks

I'm not sure what you're looking for here... You're correct in that you cannot change any menu entries but I'm not sure why you would want to do this. Right now it's designed to allow you to bind your application to the menu so you can call your app from that menu. If you want your own menus within your app, you have to do those yourself (as I have in my trivia game.)

What is it you want to do with your app? Mlord is flexible, if you give him a good reason you want to change menu entries, I think he might be receptive to it when he goes to work on it again.

BTW glad to hear someone besides me is working on a hijack user app!

My plan is to implement a RDS TMC solution. This mean my application is collecting traffic messages in background and display it later. (Sorry but working in Switzerland only at the moment! Location code is country depended.)

So I think I need the following menu structure:
TMC: Turn service on (means start collecting messages)
TMC: Turn service off (replace the menu above)
TMC: Show messages (visible only if service is turned on)

Maybe I implement some kind of submenu like you did in your trivia game. Think this shouldn't be a big problem.

I htought sampling from the tuner is only possible if the empeg is in tuner mode ?
so it will only work if we listen to the radio, right ?

bobo

No, it should be possible to read the rds data even if the player is in mp3 mode. If not, I have to search for a workaround. :-)
It might be necesarry to tune in a station first.

RDS is still running when in other modes. Note though that we read all the data from the rds pipe (/dev/rds I think). If you want to read it too, you'll need to sit between the player and the rds device - much like people used to do with IR.

Hugo

I'm not a kernel developer, at least until now.
But, is there an easy way to add a second rds device (for example called /dev/rds2) from which I can read all the rds data, even if the player is running and consuming all the data from the main rds device? The data on this second device should be a raw copy of the main rds device. Don't know if this is possible?

ah, that's cool :-)

bobo

Take a look here. This example is intercepting the IR data, but I think it will be similar for the RDS data.

>Now my question: Is it possible to remove or replace some or all (own) userland menu entries?

Each call to EMPEG_HIJACK_WAITMENU "replaces" the previous definition with the newest one, but the menu labels remain the same..

So, in a word, no.

I am still not 100% happy with the interface, and may completely flip it around someday, such that it triggers an external program and WAITS for it to exit.

..someday..

I though I found a solution, but it seems it's not that easy.

What I have done:
- Renamed original /dev/rds0 to /dev/rds_org
- Created a new FIFO Device mkfifo /dev/rds0

The source looks like this:
{
ssize_t rts;
char rdscode[8];

fakeRDSfd = open(FAKE_RDS, O_WRONLY);
if(fakeRDSfd==-1) {
return -1;
}

realRDSfd = open(REAL_RDS, O_RDONLY&O_NDELAY&O_NONBLOCK);
if (realRDSfd==-1) {
close(fakeRDSfd);
return -1;
}

while(1) {
rts=read(realRDSfd, rdscode, 8);
if (rts>0) {
rts=write(fakeRDSfd, rdscode, rts);
}
}
}

If my userland application is running the player stops loading and displays "Starting RDS failed".
If my userland application is not running the player stops loading and displays "Starting RDS ..."

What does the message "Starting RDS failed" means? What is the player software expecting at startup? In which case does the player throws that message?

Thanks

One issue with your code is the open options for REAL_RDS; you should OR together flags ("|") not and them.

Actually, in this case you don't want to have O_NDELAY/O_NONBLOCK - this will just munch CPU. Data only ever turns up in 8-byte blocks, so your 8 byte read/write should be ok. Note also that errors return <0, not necessarily -1 in linux.

Do you see any message on the serial port when the player starts? The player just does an open("/dev/rds0",O_RDONLY) and prints that message if the open fails. This is no different to what it does when opening /dev/ir.

Hugo

>One issue with your code is the open options for REAL_RDS; you should OR
>together flags ("|") not and them.
Ok, changed

>Actually, in this case you don't want to have O_NDELAY/O_NONBLOCK - this
>will just munch CPU. Data only ever turns up in 8-byte blocks, so your 8 byte
>read/write should be ok. Note also that errors return <0, not necessarily -1 in
>linux.
Fixed

>Do you see any message on the serial port when the player starts? The player
>just does an open("/dev/rds0",O_RDONLY) and prints that message if the open
>fails. This is no different to what it does when opening /dev/ir.

As I can see there is no special console output:
empeg:/drive0/rene# player
empeg-car 2.00-beta3 2001/10/17.
3c1f5763 DHCP name = lo
3c1f5763 DHCP index = 1
3c1f5763 DHCP flags = 0x8
3c1f5763 DHCP addr = 0.0.0.0
3c1f5763 DHCP bcast = 0.0.0.0
3c1f5763 DHCP mask = 0.0.0.0
3c1f5763 DHCP name = eth0
3c1f5763 DHCP index = 2
3c1f5763 DHCP flags = 0x1043
3c1f5763 DHCP addr = 169.254.53.54
3c1f5763 DHCP bcast = 169.254.255.255
3c1f5763 DHCP mask = 255.255.0.0
3c1f5763 DHCP Our mac is 00:02:d7:22:06:dd
3c1f5763 DHCP Current IP address is 169.254.53.54
3c1f5763 DHCP Broadcast address is 169.254.255.255
3c1f5763 DHCP Adding interface eth0
3c1f5763 DHCP Sending DHCP discover (eth0)
3c1f5763 DHCP Extensions present: 61 53 55 57
RDS TMC initialised << userland application message
3c1f5768 DHCP Sending DHCP discover (eth0)
3c1f5768 DHCP Extensions present: 61 53 55 57
3c1f5772 DHCP Sending DHCP discover (eth0)
3c1f5772 DHCP Extensions present: 61 53 55 57

Searching for a way to solve this at the moment. I'll post if I find a solution.

Additional help welcome

What does the message "Starting RDS failed" means? What is the player software expecting at startup?

The player calls an ioctl on the RDS fd and fails if the ioctl fails (which, of course, it will if the fd is a fifo as opposed to a real RDS device). This means that RDS (currently) can't be replaced in userland in the way that IR can.

Peter

Is it possible to create an own device (/dev/rds0 [RDS-FAKE], Major number 249 for example) with mknod and route all the requests from the player software to the original device? Sould be possible without kernel modification, shouldn't it?
What do I need to implement such a device? I think a good start point is the file empeg_rds.c from the kernel source, isn't it?
I hope we don't get a new beta of the player software with different implementation in the next few days. :-)

What chance then Peter of getting the player to 'echo'/broadcast the RDS packets it reads to a well-known UDP port (for example) so that Alex [or anyone elses] apps can also get their hands on the RDS packets being delivered to the player from the DSP?

It seems a real waste to have that valuable RDS data stream available in the empeg and yet have it locked away from the userland apps that really could make the best use of the data.

While its been a while since I did some unix socket programming I seem to recall a few mechanisms within Unix [and I suppose Linux too] whereby user level apps can 'share' in a fairly low-level resource wise way data via sockets such as Unix sockets or UDP broadcast sockets or similar.

In the best of all worlds, the player software would read [from config.ini?] a list of UDP ports to echo each RDS packet read from /dev/rds to and then each userland app [if more than one] could bind to a free UDP socket being sent the UPD packets.

In the worst case multiple userland apps could co-operate and rebroadcast amoungst themselves the RDs packets one of the them gets from the main UDP socket.

Either way Alexes problems would be solved as I don't think his application would mind a few milliseconds delay between the RDS packets arriving in the player and then being broadcast back out to his app.

Got it to work!

But I did it the other way round now. I changed and compiled a new kernel. Now all the RDS datas are streamed to two independent devices (/dev/rds0 and /dev/rds1)
First I hoped I can do it without to modify the kernel. But now I think it was the easiest solution.

Disadvantage: Everytime time Mark Lord is releasing a new kernel I have to rebuild my own kernel. :-)

RDS data is now flushing trough /dev/rds1 device while the player is running!
Hope to release a preview version of my TMC software soon!

alex why not forward your kernel changes to Mlord so he can include them with his latest kernels.
that way provided the user is running the mlord kernel your RDS app will work.

Don't know if Mark Lord is interested in including my changes.

There are a few restrictions at the moment:
- There are only data on /dev/rds1 if the player app is running. -> Should be no problem
- Don't know if I implemented it correct. However I had no crashes during my tests and the player still show the rds information.

Don't know if Mark Lord is interested in including my changes



He will be, trust me

Couldn't this same technique be used for getting FIDs from the serial port (/dev/ttyS0?) with the timecodes=1 option in config.ini?

I think _yn0t was trying to get that info for a lyrics scroller, and I'm sure other people would be interested for other uses.

Couldn't this same technique be used for getting FIDs from the serial port (/dev/ttyS0?) with the timecodes=1 option in config.ini?

I think it's notify=1 instead of timecodes=1. Yeah I'm very interested in any easy and non-invasive way of getting the FID of the current song. Timecode also, but I already have a method to get that. When I asked about it, Mike @ Empeg didn't seem enthused enough about the idea to provide a /proc entry or anything like that. He suggested the notify=1 idea.

So I guess what you're saying is we would create a fake serial device which the player would be able read and then pass on to the real serial device... Interesting...

>Couldn't this same technique be used for getting FIDs from the serial port (/dev/ttyS0?)
>with the timecodes=1 option in config.ini?

Now there's a clever idea! I could have hijack internally enable "notify=1", and just strip them off as they arrive at the ttyS0 driver -- only allowing them out the serial line if "notify=1" was actually specified in config.ini. Meanwhile, they could be placed under /proc, or made available by other means.

Mmm.. looks relatively simple to do, too..
Anyone want to send me a patch for it?

Otherwise it will wait until I get the ftp server working inside hijack.

-ml

Don't internally activate the timecodes=1 (or whatever the setting is really called). Only pull the stunt if it's really activated in config.ini. There is an associated slowdown with sending characters to the serial port that some people might not want. At least that's the way I remember it working.

Plus, every once in a while the empeg team introduces a bug into that feature that isn't necessarily noticed right away (happened once during 2.0 if I recall), so it's best to leave it alone unless someone really needs it.

>an associated slowdown with sending characters to the serial port

The slowdown ought to only happen if the chars are actually passed out the serial hardware.

I propose intercepting them before they get that far, allowing them to flow out only if "notify=1" is truly set. And having a feature that uses them like this is a good way to ensure that future bugs are noticed much earlier.

-ml

Your logic is compelling.

It's a great idea, but Tony's right about 2.0b3. The player app crashes if the machine boots into an empty playlist with timecodes active. My guess is it doesn't fault outputting to the port device, but rather generating the timecode.
Worth a try, either way.

Mark, if you got the notify=1 info onto the /proc filesystem you would officially be my hero.

I just toyed with the config.ini and it appears that (as promised) timecodes=1 has been removed and replaced by notify=1. For 2.0b3 that is.

I propose intercepting them before they get that far, allowing them to flow out only if "notify=1" is truly set. And having a feature that uses them like this is a good way to ensure that future bugs are noticed much earlier.

Wouldn't that interfere with other output the player might generate or with the output of kernel messages? Or even with the shell if the player executable is terminated?

cu,
sven