scratch x windows

[timl]

Hi, I have a pi running raspbian headlessly. I would like to run scratch via ssh and x windows. From my Fedora box I try:

ssh -X tim@10.1.1.91 /usr/bin/scratch

I get

Executing: /usr/lib/squeak/4.4.7-2357/squeakvm -encoding UTF-8 -vm-display-x11 -xshm -plugins /usr/lib/scratch/plugins/:/usr/lib/squeak/4.4.7-2357/ -vm-sound-alsa /usr/share/scratch/Scratch.image
XShmAttach: BadAccess (attempt to access private resource denied)
X Error: BadShmSeg (invalid shared segment parameter)
Major opcode of failed request: 130
Minor opcode of failed request: 3
Serial number of failed request: 87

I get a window which I guess is the scratch editor but it is blank.

Are there any specific switches I can add to the ssh statement to get scratch up and running?

Thanks

[DeeJay]

Short answer to your question: I don't know.

But to provide a comparison which might be helpful by eliminating something -

I run also run my RPi, running Raspbian, headless.

From my WindowsXP desktop, running the XMing xserver package, I used PuTTY to make an ssh connection to my RPi with X-forwarding enabled, and with the Remote Command option set to scratch. The result was a fully functioning version of Scratch presented on the screen of my desktop.

So in principle there's no reason why it should not work.

What's different for you? I notice you are not using the default pi user. If you ssh into the RPi interactively (to a shell prompt) as the same user tim, what happens if you try to run scratch & at the command line? (In other words, does your username tim have the privileges required to execute scratch?)

[croston]

From memory, I don't think Scratch works on a remote X server. You have to use VNC. I can't remember the reason why im afraid - hopefully, someone else will enlighten us.

[smithg400]

I also found that it works under XMing on Windows 7 but fails if try from an Ubuntu machine.

However I found this article http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692587 which should help.

Briefly /usr/bin/scratch is a short script that actually invokes the real program and it forces the -xshm option as part of the script (which produces the XShmAttach error). Simply edit /usr/bin/scratch and change the line that reads

Code: Select all

VMOPTIONS="-encoding UTF-8 -vm-display-x11 -xshm -plugins /usr/lib/scratch/plugins/:$SQ_DIR/"

to read

Code: Select all

VMOPTIONS="-encoding UTF-8 -vm-display-x11 -plugins /usr/lib/scratch/plugins/:$SQ_DIR/"

i.e. remove the -xshm option and it should be OK (works for me!)

[DeeJay]

I don't think Scratch works on a remote X server.

As stated in my response, this is not the case.

[timl]

Hi smithg. I tried your suggestion and it works

I only had time to run up the initial scratch window but it all looks good. Many thanks for the simple solution

[smithg400]

No problem timl, it was really someone else's solution anyway!

The -xshm tells scratch to used shared memory between the scratch process and the x server process to transfer images as this is quicker than sending them over the TCP/IP connection - this is fine if they are both on the same machine but not when on different machines. Removing the option allows it to work but will make the transfer slower (which means that screen updates will be slower).

I'm not sure how it is that it works when the X server is XMing on windows but I wonder if it may be that XMing doesn't support using shared memory and so it isn't used - whereas the X server on Fedora / Ubuntu does support it and scratch tries to use it without checking if the two processes are on the same machine.