Some difficulty though when lyrics should be scrolled of 1 pixel in a shorter delay than 20 msec...

Well, you're using a pretty big font, if you use a smaller font (like the 5-pixel high font the player uses), you'll squeeze more letters onto the display, although obviously it will be smaller, and maybe harder to read. Then you *could* skip 2 or even 3 pixels per screen update, but I doubt it would look very pretty. 1 pixel every 20 ms means that a given word is going to only be on the screen for about 2.5 seconds... Might be kinda hard to read if things are flying by faster than that.

Also, are you switching the scheduling policy to SCHED_RR when you start the application? If you're not, this would make things run a little smoother.

One thing you might think about for future development is a full-screen mode which would scroll the lyrics vertically. That way you'd have the ability to have 4 or 5 lines on the screen at once, for songs with a lot of really fast lyrics.

The other thing is, pretty soon after I started my lyrics scroller, I realized that Hijack's menu binding system was getting in the way a little bit. The user app becomes the "foreground" application, and the player is kind of in the background. IR presses can go through to the player, but in order to return control to the player, you have to call the WAITMENU ioctl, which makes your program stop. To get the most out of a lyrics scroller, I think Hijack needs some mechanism for user apps to run in the background and update the screen after returning control to the player. Not sure if that's in the cards, though.

Great stuff -- can't wait to see it in action on my player.