Last first, your fstab and your /boot/cmdline.txt have to be pointing
to the partition you want to boot.  Those were the only changes I had
to make when I picloned my sd to my hard drive.  By default they point
to /dev/mmcblk0, change them to something like /dev/sda.  The ones on
the hard drive.

I'm not sure why you have color depth issues, just about everything
I've seen can run 24 bit color just fine.  I edit photos on most of
mine.  X has some capability to mix color depths, so there could be a
16 bit window on a 24 bit screen.  Try xwininfo if you have it, it
will tell you stuff like this on whatever window you click on first:

xwininfo: Window id: 0x8000002 "rxvt"
  Absolute upper-left X:  135
  Absolute upper-left Y:  56
  Relative upper-left X:  1
  Relative upper-left Y:  30
  Width: 578
  Height: 340
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +135+56  -787+56  -787-404  +135-404
  -geometry 80x24+134+26
That was a window in a vnc session and I could copy and paste it into
Firefox in OpenBSD.  copy/paste to/from vnc works about 70% of the
time

VNC is also called remote framebuffer  A server makes a connection to
X then forwards it over a network connection to a client that displays
it.  There are clients for windows and mac, there's even a java applet
that's a client so you can have a gui desktop on one machine in a web
browser on another.  It's been around for years so it's pretty stable.
No security or encryption, it's not safe to use raw vnc over the
internet, but you can  tunnel it through ssh.  Different versions have
different compression schemes, that gets negotiated between server and
client.  Keyboard and mouse activity go through it, there's no sound.
Color depth is a little muddy because less colors mean more speed,
sometimes 256 are plenty, so it's 1 byte per pixel instead of 2 or 3.
You don't usually have a lot of control over it.

What I have on this pi is:
ii  libvncclient0:armhf                        0.9.9+dfsg2-6.1+deb8u2
                  armhf        API to write one's own vnc server -
client library
rc  libvncserver0:armhf                        0.9.9+dfsg2-6.1+deb8u2
                  armhf        API to write one's own vnc server
ii  tightvncserver                             1.3.9-6.5
                  armhf        virtual network computing server
software
ii  x11vnc-data                                0.9.13-1.2
                  all          data files for x11vnc
ii  xtightvncviewer                            1.3.9-6.5
                  armhf        virtual network computing client
software for X

You probably don't care about the API stuff, you just need a server
and a client.  Tightvnc was a big deal because it used compression,
now it's just one of a dozen or so protocols that the server and
client agree on.  There's an order to the desirability, the client and
server pick the highest one they can both use but they can fall back
to lower ones.  So essentially a vnc client is a vnc client, details
don't matter.  It's remote control yet not: vnc makes its own
connection to the X server so what's happening remotely isn't visible
or accesible on the local machine other than cpu load.  You can't open
a document locally then see it or edit it remotely, you'd need to open
it again.

Your cnc stuff must be taking up the first 9 X connections, that's why
it's so demanding of speed. Most people only have 1 or 2 displays.
Seems like you might be better off with a modern quad or octal core
i386/amd64 machine with a lot of resources.  A gaming machine
essentially with enough cpu (and gpu) to be doing things like 3d
graphics, lots of video ram.

Something's odd here, if I do echo $DISPLAY in an ssh window it's not
even defined yet you're using up yours.  In local rxvt/xterms they all
read the same thing of :0.  I'm not sure it matters.  In fvwm if you
right click on the root window it shows other applications you might
want to switch to.  I've got stuff in 6 of 9 panes of my pager,
connections to 3 other machines.  This is on an old Pentium 4 machine
circa 2002, a Dell gx270.

> restricted things like running synaptic-pkexec to a local keyboard and
Synaptic sounds like a laptop touchpad driver (or a debian application
manager).  I'm not sure that will work in a non-local situation.

> So, tell me more about vnc please.  If it can bypass this crap, and let
> me do gfx stuff as root using sudo, I'll see if I can make it work.

I don't use sudo much, I just log in as root.  I'm not saying everyone
should but I've been doing it for 20 years, old habits die hard.  I
haven't screwed up anything I haven't been able to fix, and I'm behind
a firewall.  Pretty good with regedit in windows too, used to get in
there and chop out the triggers that were making viruses start up on
every reboot.

> The puzzling part is that the limited colors but otherwise full power of
> the pi's gfx engine can run LinuxCNC over this X11 connection well
> except for video rendering speed, its slowed to around 3 or 4 fps over
> the network connection. I have lcnc configured such that I can power it
> up and run it from here, but if I see a potential crash about to occur
> in the backplot, its already happened at the machine. Thats hard on
> tooling as it usually will break the tool or its carbide insert, at
> several dollars a copy, so that isn't done.

Sounds like it's hard on computers too.  3-4 fps, over wifi or what?
Over wires that shouldn't be a big deal.  I can watch videos over vnc
and a wired connection, not that I do it often.  And never full
screen.  Are these big windows?  They need more cpu/bandwidth.

>> > find a target device.  The help there says "the card its booted
>> > from" as if it might be a fixed address to pull from, in which case
>> > why the ghosted out source selection buttons?

I see them ghosted out until it's scanned for devices and found them,
maybe that's a clue that it isn't finding them.  It doesn't seem to
look for them until I click the down arrow and sometimes it takes a
few seconds.  I forget what it's written in but it's not fast.
Doesn't need to be.

>> > And of course I cannot do anything from here as root via sudo
>> > because localhost:11 is not a valid x11 screen.

  Says what?  As I understand remote X you start an application in an
ssh or telnet window and tell it to display on the machine you're on.
Localhost is always where the program is, not where you are.  Well, it
means local, not networked.  Try the ip address of the machine you
want the display on and :11.  It especially wouldn't be valid when
one's up to 10 or 11 and the other's only at 1 or 2. Try echoing
$DISPLAY in a local rxvt, xterm, etc window, not over ssh to another
machine.  Feed your IP and that display number to the machine hosting
the application.

> dd  if=somefile bs=512 of=somedevice, and in the case of sd card copying,
> since no 2 are alike so I usually look at the src's declared size in
> dmesg and set count=that-5k so it doesn't error out copying a pny 32GB
>to a Sandisk 32GB.  Etcher, which is faster, has the same problem &
> pitches a fit when it can't find room to put the last 10 sectors.  I've

Blocksize on my 128s is 4096, I'm not sure how critical it is.  Or
where I read it, sfdisk, fsck, badblocks, one of those.

What I don't like about dd for this is that it copies sector for
sector, including empty ones.  Piclone essentially does an ls then cp
so it recreates the directory structure.  I used to copy a 128 to a 64
as long as less than 64 were used.  And it's faster because it isn't
copying empty sectors.  dd's good for forensics, like to make an exact
copy of questionable media before you start trying to fix it.

Reply via email to