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.