Okay, I've got an initial proof-of-concept implementation of a VNC server for the empeg. It's written totally in user-space, uses totally the wrong VNC encoding method, wastes a load of CPU time and network bandwidth, probably makes the player run abnormally, etc. It also makes the Track Info position indicator go nuts. However, it does display the current screen on a VNC client.

I'll put up a web page in the next few minutes to let you download it if anyone wants to see. I'm not going to post the source code for it because I'm embarrased of it, but the next version will likely be totally rewritten and function better and I'll post the source code to that one.

awesome!! i might even put my VNC client back on my Palm!! :-D

Calvin "a vnc fan"

Very cool - Great job!

I made a change so that you can specify a delay time for updating the client. This is now the first argument, and the VNC display number is the second argument. You can leave both off. The delay time defaults to 0, which means to update as often as possible, like before. If you specify a number less than 10, it's in seconds; more than 10 is microseconds (millionths of a second). The VNC display defaults to 0, and, again, you can leave it off.

This update should reduce the bandwidth hogged by the server, but it doesn't seem to lessen the load. Can anyone give me numbers as to average loads when just the player is running? Mine seem to go a little over 1.

By the way, I'm still planning to rewrite the whole thing. Maybe tomorrow.

Before I commit to putting this admitedly uhh ... questionable software on my empeg, can you show me a screenshot of what the vnc client shows?

Greg

Well, right now, it's pretty much just the 128x32 screen in four colors (the middle two as close to grey as I could get). It's not magnified at all, currently, so it's pretty small, and there's no surrounding picture or anything to display the buttons. And it shows exactly what's on the screen (usually -- there seems to be an odd issue right now with the Info status and scrolling song names, but it's minor). There's currently no way to control the empeg from the VNC client, but this will come. But not until after I rewrite the thing. I'll post some screenshots when I can get back in front of the empeg to do it. Probably in a few hours.

Ah okay, now I'm getting it. So it will end up being a more accurate and actual display/controller compared to the display server.

If i remember right the display server only shows track information and not the visuals themselves. Your vnc server will show the visuals and eventually allow you to control it as if you were there?

I'm assuming this is all over the ethernet port?

Sounds interesting!

Greg

DS does show visuals as well.

That's correct. It shows exactly what's on the empeg's screen. More or less, as there are some bugs. I've put up some screenshots.

Honestly, I've never even looked at DisplayServer. I don't have any need for any of this at all, really. It's just an interesting project to bide my time while I look for a job (dammit!).

Not too shabby. I've always thought VNC was the holy grail of software, that and SSH.

As for joblessness ... Man I tell you what, after three layoffs in two years, and repeated abuse and unpleasant work environments for programmers, I got a little fed up with the high-tech industry.

I'm through with it. I don't think I'll ever be going back. I'm currently back in school to finish up a degree, then off to law school.

At least if I have to take abuse in a crappy environment, they can pay me a crap-load of money more than I was getting before. Money isn't everything, sure, but it helps.

Greg

I can give you some leads on jobs if you want 'em. The last one I was at was actually fairly decent (no lay-off for me there) and the pay was pretty good. I ain't there no more 'cause we had to move for my wifes work.

It's in Austin doing linux admin and system building ... if you're interested. Not sure if the job is still available, but it don't hurt to ask.

Greg

I don't think I want to move halfway across the country (and certainly not to TX, no offense). But I really appreciate the offer -- a lot. Thanks.

If you want to change your line of work, I've got family members in the Winston Salem/Raleigh Duram SWAT teams, they could probably get you into some form of law enforcement ;-)

Greg

I imagine that if they're on the street, I've probably already pissed them off in some way. I'm not a big fan of cops, and I go out of my way to annoy them as much as possible. Got myself landed in jail once already. I should probably stop.

Sounds interesting!

Doesn't it? Either this or built-in method (used by JEmplode) of displaying the screen, together with a way of routing serial commands through Mark's translator (and, if possible, having kernel listen for commands on a UDP port) give us a nice foundation for complete empeg remote control (for those who cannot/won't mount thir empegs within easy reach and/or sight).

empegVNC will eventually accept input. That is my final goal.

I'm also going to add "http POST" capability for remote button presses, as part of the Hijack khttpd server, probably next week sometime. Still working on the screen dump stuff -- currently placing screen captures under /proc/empeg_screen.tiff -- but gotta convert that to .png format instead of .tiff.

-ml

anyone else experience this...
if I launch my VNC Viewer and connect,
the empeg visuals speed up considerably both on the players screen and in the VNC window. Including the scrolling track info.

I thought I noticed that, but I don't use the visuals that much [gasp!], so I wasn't sure. I find it very odd, but it should be fixed before I get this finalized.

I haven't tried out empegVNC yet, but a question.. where are you grabbing the screen from? Do the Hijack menus show up on it?

If this is completely in userland, then Hijack probably does not appear. In that case, I can give you a /proc/empeg_screen raw image access to the display with Hijack menus/overlays in place, and your application could try that source first, and then default back to whereever it currently goes second..

Just a thought.

I was doing it first by mmapping /dev/display (and I'm doing it horribly right now). I wouldn't be surprised if the Hijack menus didn't show up. I would like to move it to the kernel, as you suggested earlier, so I don't know if it's worth your while to set that up.

By the way, it looks like the empegVNC code will be easily less than your kftp/khttp code. It's really a very simple protocol, once you get how it's supposed to work. Looking at your kftpd/kttpd code, I'm not quite sure how to get data from display_blat() to my VNC server code, but I'll figure it out.

You know what? This whole putting-it-in-the-kernel thing is stupid. You know why? Because I can't get it to work! Makes more sense as a userland app anyway (<-- sour grapes).

So, if it's not too much trouble, a device to read from that would include the Hijack visuals would be super. Right now, I'm mmap()ing /dev/display, so a device that functions identically would be super, but whatever you can do whenever you have the time.

Now if I can just figure out how to inject buttons so that Hijack will see them, too....

Now if I can just figure out how to inject buttons so that Hijack will see them, too....

#include <asm/arch/hijack.h>



unsigned long data=0, buttons[4] = {4,

   IR_KNOB_PRESSED,

   IR_KNOB_LEFT,

   IR_KNOB_RIGHT

};



rc = ioctl(fd, EMPEG_HIJACK_INJECTBUTTONS, (unsigned long *)data[]);

Any chance of allowing a multiplier to zoom the display? 128x32 isn't very large on my display..

Nope. That bypasses Hijack, unless it's changed in the last few releases. That is, I want to be able to send a long knob press to get the Hijack menu up. Using that ioctl() doesn't allow me to do it.

Oh yeah.

/me shuts his mouth for a change.

Yeah. I should put up a TODO list.

Edit: Done (the TODO list, that is). By the way, your client might support client-side scaling. Look around in the options. The Java client I hacked up doesn't, though.

Cool.. I tried using the Scale By feature of the TightVNC client, but it either needs to be supported by the server, or that "experimental" is annother way of saying "doesn't work".. Of corse, it's been tagged experimental for the past 6 months..

I know that the scaling on the Windows client I'm using (the one from the fine folks at AT&T) works fine.

are you using winvnc by chance? Neither the one from att or tightvnc (also based on the same code) work..