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..

Ummm, WinVNC is what the AT&T guys distribute. Specifically, I'm using v3.3.3r2.

And, to be clear, you're saying that the scaling doesn't work, not the whole connection, right? If it's just the scaling, then there's nothing I can really do about it at this point. There's no function on the server side to enable that sort of scaling of which I'm aware. The client should just display it differently. Does your client successfully scale another server? Doing server-side scaling is going to require some serious overhauling of the server (at least to do it without generating insane amounts of network traffic -- and it uses too much as is).

Well, unless this client takes configuration differently from other programs. I enabled scaling, and put in 2 by 2. I then connect to the empeg and it's the normal size.

I tried TightVNC 1.2.2 and WinVNC 3.3.3r3..

Yeah, the AT&T client says scaling is experimental, and I believe it doesn't keep the scaling settings...

Oh, I see what you're doing. I grabbed a copy of TightVNC. Seems that its UI is nearly identical to WinVNC, which I assumed when I saw your numbers there. The two numbers in the UI are not the x and y scaling, they are intended as a ratio of display size to original size. When you enter 2 and 2, that's the ratio of 2:2, which is the same as 1:1. Try entering 2:1. It'll work. (Make sure you enable the scaling checkbox.)

I'll look at the mmap() stuff -- somebody else has been nagging me for it anyway, and it should be the fastest operational method for this. But in the meanwhile, have a go at using /proc/empeg_screen.raw instead, which has lower system loading (but it may "sleep" your read() process briefly while it does a screen grab). Let me know how it works (or not) -- Hijack v145, in about 20 minutes or so.

As for feeding button codes, do it this way (shell script example):

#!/bin/sh

if [ -e /proc/empeg_notify ]; then

	echo "BUTTON xxxxxxx" >/proc/empeg_notify

else

	## use ioctls() as at present for the hijack-deprived

fi

But that limits things a little, n'est-ce pas? Well, not really, cuz you can also do LONG presses with:

	echo "BUTTON xxxxxxx.L" >/proc/empeg_notify

But that also limits things, so here is how EmpegVNC ought to do it:

	echo "BUTTONRAW 0xxxxxxx" >/proc/empeg_notify

	## wait until user lets go of the button/icon, then do:

	echo "BUTTONRAW 8xxxxxxx" >/proc/empeg_notify

The last method above allows/requires separate press/release codes for each button (except for knob rotations, which don't have release codes). A list of most/all button codes is in hijack.h in the patchfile.

Cheers

Doh... no wonder, I never did good in those achievement tests... 1/1 is of corse the same thing as 2/2... I guess I was thinking of the way that scaling is done in graphics programs.. Works like a charm..

Haha who's been nagging you for the mmap buffer?

I did the same thing. You put it to 2/2, which is 1. Put it to 2/1 and see what happens.

Memo to myself: DO read the whole thread before responding!

Okay, in hijack.h, the RELEASED codes are different than the PRESSED codes. Even so, when I send the code to empeg_notify, I have to OR the RELEASED codes with 0x80000000? That's odd. Why?

Edit: It actually looks like that's wrong. I just tried it with the 8xxxxxxx and weird things happen. I think that it's not seeing the RELEASED code, but it's hard to see.

I'll have a look at it, and make sure it works in v161.

I'm assuming you are using RAWBUTTON for this.

Cheers

Nope.. seems to work fine.

But I did find/fix one bug, that was preventing multiple button codes per line.. it was only taking the first one.

So, with v160, you can do:

  echo "BUTTONRAW 0020df12" >/proc/empeg_notify

  echo "BUTTONRAW 8020df12" >/proc/empeg_notify

and with v161 (not out yet) you can instead do:

  echo "BUTTONRAW 0020df12;BUTTONRAW 8020df12" >/proc/empeg_notify

I will also add a config.ini flag in v161 to turn on ir_debug:

[hijack]

ir_debug=1

This will spew raw IR codes to the serial port, along with some internal state flags and such. You can ignore most everything except the first 8-digit value on each line (the raw press/release codes). This debug data comes straight from the Hijack IR handler.

-ml

Oh. I see. I was just using the codes for the front panel button codes, which are not in the same ``| 0x80000000'' style as the remote codes -- I didn't even scroll down far enough to notice that, not that the remote codes even occurred to me. Sorry. Brain not working too well tonight.