Could you give us more info about the software you created?

There's really almost nothing to it. I just open the serial port (you could borrow the serial code from gpsapp) and wait for data, then decide what to inject based on what letter I received. All the button code constants are defined in hijack.h. I wrote the basic stamp code to send capital letters for press and the same letter lowercase for release; If you don't handle presses and releases separately then you can't do long presses. U/D/L/R/K for the 5 fascia buttons, + - for knob rotation, and Z/X/C/V/B/N/M for the 7 (only ended up using 6) 'soft' buttons.

The only problem is that the app runs as just another application, so the Player can take all the CPU time and starve it whenever it wants. This usually happens when it spins up the disks, which is usually you're pushing buttons. Then keypresses get queued up in the serial buffer and when the app gets processor time again the actions all get blasted out. It should be possible to give it the same priority as the Player since the button listener app needs virtually no processor time to check for input every once in a long (to the CPU) while, but I don't know how to go about doing that in a way that doesn't stick it in the kernel.. anybody?

unsigned long buttons[2] = { 2, 0 };



serial_open();

displayFD = open("/dev/display",O_WRONLY);



while(1)

{

	got = serial_read(&buf,1);

	

	if ( got > 0 )

	{

		switch ( buf )

		{

		case 'U':	// Up

			buttons[1] = IR_TOP_BUTTON_PRESSED;

			break;

		case 'u':

			buttons[1] = IR_TOP_BUTTON_RELEASED;

			break;

		...

		}

			

		ioctl(displayFD, EMPEG_HIJACK_INJECTBUTTONS, &buttons);

	}



	usleep(10000);

}