[9fans] X device

[9fans] X device

[rob]

I did this for Inferno, which has a different graphics protocol but
the same overall architecture, so it can be done.  I don't wish the
job on anyone; it's a nasty mess to get two unrelated graphics models
to function together.

I did it by modifying the underlying library, not the driver, although
I probably had to tweak the driver a bit; it was a while ago and my
memory has faded.  The basic notion was to allocate a bitmap on the
server for each image and then, for each operation, try to use remote
operations to do the work.  If they couldn't be done there, the
operation was done locally and sent over as an array of pixels.
Things like ldepth conversion were the hardest to handle.  In the end,
I lazily allocated a different ldepth pixmap (?)  on the server for
each image in Inferno, which I could at least use as a valid source.
But X doesn't mix ldepths much, other than having special pattern
operators defined with ldepth 0, so any of the myriad things we do
with mixing ldepths had to be done cleverly or go slow.

I did not use X fonts, but translated all character drawing into
already-implemented operations, to keep things simple and portable.

Getting all this to go fast involved much trickery and analysis of X
internals.  The result is barely satisfactory.  Plus, a huge piece of
the code deals with the psychotic pas de deux of allocating a screen
and color map in X. When it came to 16-bit X screens, we cut bait; it
wasn't worth any more time.

Similar games can be done on Windows, but it's much easier there, at
least conceptually, because you can write code that runs on (in X
terminology) the server and also just paint data on the screen, in
other words, decode the Plan 9 protocol on the machine with the frame
buffer.

-rob

[9fans] X device

[miller]

"Russ Cox" <rsc@plan9.bell-labs.com> wrote:

> I think that writing a VNC server for Plan 9 could be done
> quite easily, actually: write something to translate /dev/bitblt
> commands into a VNC transcript of sorts, and then send whatever
> part of the transcript the client hasn't seen yet. 

Yes, this could be done.  Most of the work would be in compressing
the data to compensate for the key difference between the VNC and
Plan 9 protocols: VNC doesn't maintain any bitmaps on the viewer
machine other than the frame buffer itself (not even font images),
so there can be a lot of redundant transmissions.  But you could
borrow compression code from existing VNC servers.

> It seems like a Plan 9 VNC client would be even simpler: I'm
> guessing five to ten pages of code at most.

Mine is 685 lines of C.

> The real question is whether VNC actually feels decent enough
> to use. 

It is for my purposes: occasionally I need to access an X-based
program on a remote machine (e.g. the graphical debugging system
on a Cray T3E).  VNC lets me do this without having to leave
Plan 9.  If I had to look at it all day, though, I would want
to make it a bit quicker and smoother.

-- Richard Miller

[9fans] X device

[Russ]

> The other possibility that came to mind was implementing a
> VNC server for Plan9. That would allow users of Unix/Doze/NT/Mac
> to pull up a Plan9 system on their screens without having to
> have a copy of the OS to run..

Even though
> VNC goes to show that what the world really desires are Yet More
> Stupid Protocols.

it is a neat hack, in that it would be a pain to rewrite
most of the window systems (X, MS-Win) to generate any other
protocol, be it /dev/bitblt or something else.  Instead, what
they've done is very inelegant but appears to work decently.

I think that writing a VNC server for Plan 9 could be done
quite easily, actually: write something to translate /dev/bitblt
commands into a VNC transcript of sorts, and then send whatever
part of the transcript the client hasn't seen yet.  You could
run a different 8.5 for each VNC session.  The method I have
in mind would maintain the screen bitmap in memory (so that, say,
if the VNC client asked for the whole screen you could give it)
but also kept the VNC transcript.  Very little overhead...
Mouse cursor changes seem to be a problem, but overall it might
be an easier than trying to make 9x work (only because someone
already has a VNC X client).

It seems like a Plan 9 VNC client would be even simpler: I'm
guessing five to ten pages of code at most.

The real question is whether VNC actually feels decent enough
to use.  Is it a good enough hack?
I don't know the answer to that since I haven't tried it.

Russ

[9fans] X device

[forsyth]

> It would be nice if the Plan 9 and Inferno protocols could converge,
> and perhaps gain a wider acceptance as an alternate protocol
> for networking graphics.

it's just `graphics' not `networking graphics'.
the `networking' comes by composition with another
general facility of the system.

[9fans] X device

[Elliott.Hughes]

> Would it be more practical to play with the X server extensions
> mechanism, to decode the Plan 9 protocol, the same way postscript
> etc is added to some X servers?

this is bound to be more painful than what rob did.

> It would be nice if the Plan 9 and Inferno protocols could converge,
> and perhaps gain a wider acceptance as an alternate protocol
> for networking graphics.

but VNC goes to show that what the world really desires are Yet More
Stupid Protocols. people want IMAP and POP and CIFS (SMB) and
the like. it's a common belief in bioinformatics (i don't know if that's
the right English word, but i mean "computing focused on biological
questions") that their problems are special. that off-the-shelf solutions
from the general computer world aren't suitable. so their first instinct
isn't to stick their data in Oracle, it's to design and implement their
own DBMS. i'd laugh at this if it weren't so prevalent in computer
science in general. a variation on "not invented here", i suppose. so
rather than have a decent distributed filesystem, we bungle on with
NFS, admit it isn't really suitable for accessing our mail, and invent
an otherwise unnecessary new protocol. (and hey, let's base it on
LISP s-expressions: that'll convince everyone that we're real computer
scientists who know what they're doing!)

i think i saw an x-files episode where they explained that it's actually
a government conspiracy to keep programmers in full-employment
ready to be enlisted at the turn of the century when they'll be needed
to fix all the vital computer-based infrastructure that doesn't make
it past 1999-12-31...

-- 
http://users.ch.genedata.com/~enh/

[9fans] X device

[Scott]

Digby Tarvin <digbyt@acm.org> writes:
| The other possibility that came to mind was implementing a
| VNC server for Plan9. That would allow users of Unix/Doze/NT/Mac
| to pull up a Plan9 system on their screens without having to
| have a copy of the OS to run..

At Usenix, Richard Miller (I think) said he had VNC working 
in some capacity. Maybe it was in the other direction, though.

[9fans] X device

[Digby]

>
>Yes, the X work is part of the standard Inferno distribution.
>It supports the Linux, Solaris, and other Unix ports.
>The Inferno graphics model is now, with minor modifications,
>the core graphics system in Brazil, our in-house follow-on to
>Plan 9, but we haven't put the X support in Brazil.  It doesn't
>make too much sense anyway, because Brazil isn't hosted by
>another system.  Instead, we have a Windows-based simulation
>of a Brazil terminal, using completely different technology than
>was used to get Inferno running under X.  It is essentially the
>same, though, as what was used to get Inferno running under
>Windows.  Again, the difference is whether you get to run your
>own code on the machine with the frame buffer.

I assume the Windoze base is just so you can use the vendor
supplied drivers for the graphics cards. Otherwise I would think it better
to run a real operating system on the PC.

Is there discussion of a 'Brazil' upgrade available to Plan 9
licencees (or better still, commercial release) one day?
I guess you are asked that all the time, but so much of
the industry seems to have stagnated in the
Microsoft mire, reinventing the same old stuff,
where requiring more memory and processing power seems to be taken
as advancement..  oops, sorry - don't get me started on that. But
it would be nice to think that there was some hope for the industry
on the horizon..

>
>I cannot comment on whether you can adapt X to do anything.
>I learned what I had to do get my stuff working, and then went
>to a corner and licked my wounds.  I'm not going back in there.

If you can program under Windows then you have thicker skin
than I have :-)

Regards,
DigbyT

P.S. The naming of Brazil wouldn't have followed the Plan 9
"what was the last movie we watched" strategy would it :-)

-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

[9fans] X device

[rob]

Yes, the X work is part of the standard Inferno distribution.
It supports the Linux, Solaris, and other Unix ports.
The Inferno graphics model is now, with minor modifications,
the core graphics system in Brazil, our in-house follow-on to
Plan 9, but we haven't put the X support in Brazil.  It doesn't
make too much sense anyway, because Brazil isn't hosted by
another system.  Instead, we have a Windows-based simulation
of a Brazil terminal, using completely different technology than
was used to get Inferno running under X.  It is essentially the
same, though, as what was used to get Inferno running under
Windows.  Again, the difference is whether you get to run your
own code on the machine with the frame buffer.

I cannot comment on whether you can adapt X to do anything.
I learned what I had to do get my stuff working, and then went
to a corner and licked my wounds.  I'm not going back in there.

-rob

[9fans] X device

[Digby]

>
>I did this for Inferno, which has a different graphics protocol but
>the same overall architecture, so it can be done.  I don't wish the
>job on anyone; it's a nasty mess to get two unrelated graphics models
>to function together.
>
Hi Rob,

Thanks for the quick and detailed insights.

Did your work make it into the Inferno distribution?
Have you any idea if the VNC model (http://www.orl.co.uk/vnc/)
is any more compatible with Plan9? I have used it to get
a Windows machine console in a window on my X-Terminal
(and vice versa), although performance does suffer when
using the Internet to access a remote machine in Sydney
when using a display in London...

Is the Inferno implementation an improvement, as in a re-design
incorportating lessons learnt from Plan 9, or is there some
sort of trade off whereby both have merits?

>I did it by..
>
You have convinced me that it isn't a good learners project :-)

>Getting all this to go fast involved much trickery and analysis of X
>internals.  The result is barely satisfactory.  Plus, a huge piece of
>the code deals with the psychotic pas de deux of allocating a screen
>and color map in X. When it came to 16-bit X screens, we cut bait; it
>wasn't worth any more time.
>
Mine is a 24-bit 1600x1200 NCD - hence my preference for it over
the SPARCstation 2 screen. It seemed preferable to share
one good display amoungst all of my machines, rather than trying
to equip then all with usable displays. Even if I could afford
the latter, I would have nowhere to put them all. Of course that
relies on everything supporting the same network graphics protocol,
which fortunately most do, with the exception of Windows (and who cares!)
and Plan 9 :-(.

>Similar games can be done on Windows, but it's much easier there, at
>least conceptually, because you can write code that runs on (in X
>terminology) the server and also just paint data on the screen, in
>other words, decode the Plan 9 protocol on the machine with the frame
>buffer.
>
Would it be more practical to play with the X server extensions
mechanism, to decode the Plan 9 protocol, the same way postscript
etc is added to some X servers?

Is the reverse easier to achieve - translating X protocol
into Plan 9 or Inferno protocol?

It would be nice if the Plan 9 and Inferno protocols could converge,
and perhaps gain a wider acceptance as an alternate protocol
for networking graphics.

Regards,
DigbyT
-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

[9fans] X device

[Digby]

This is somthing I suggested in a private mail, which I thought
I would put to the list to see if any more experienced Plan9'ers
could see any problems with my proposal.

What I would like is a Plan9 display driver that, instead of
talking to a display adapter card on the bus, controls a remote
display using the network and the X protocol.

Effectively, I want to be able to use my X terminal as a Plan9
console. This would be different from implementing Xlib
on Plan9, because that would result in a situation where only
X aware applications could be used on X-terminals. 
If the X terminal looked like a Plan9 device, then all existing
applications should work unmodified, and a single Plan9 system
would become multi-user in (the Unix sense, rather than the
Windows NT sense of one screen per CPU).

Also, if the driver were to talk to a window on the X terminal
(which could be the root window), then it would be possible
to use the same X term to access other operating systems
at the same time.

Does anyone know if there is any fundamental conflict between the
types of access a Plan9 screen driver needs to make, and the
capabilities of the X protocol?

The other possibility that came to mind was implementing a
VNC server for Plan9. That would allow users of Unix/Doze/NT/Mac
to pull up a Plan9 system on their screens without having to
have a copy of the OS to run..

Regards,
DigbyT
-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk