nanogui: Thread: X11 driver palette bug

: > I am updating my VNC port to use GrSetSystemPalette() and have run
: > into an inconsistency in the palette setting code in the screen
: > drivers, specifically the index used to access the palette array.
: > As far as I can tell, the frame buffer driver uses the correct index
: > while the X11 driver uses an incorrect index. The change needed to
: > the X11 driver is only three lines as follows:

George,
    You are correct.  I have changed the X11 driver.  However,
I don't notice any changes!  There is still a nasty bug in the X11
screen driver, as evidenced by the ./t1demo.sh that displays
fonts in a different color continuously.  After about 10 seconds,
the X11 screen driver starts displaying black...

WRT to VNC, I have placed your vnc port into microwin/src/demos/vnc
as part of the standard distribution.  There are a number of items
that aren't yet working.  These include the set system palette that you're
working on for the 8bpp mode, and then support for all the other
bpp modes that Microwindows may be running in.  I plan on helping
to get VNC running well.

Regards,

Greg

On 10-Jun-00, Greg Haerr wrote:
>: > I am updating my VNC port to use GrSetSystemPalette() and have run
>: > into an inconsistency in the palette setting code in the screen
>: > drivers, specifically the index used to access the palette array.
>: > As far as I can tell, the frame buffer driver uses the correct index
>: > while the X11 driver uses an incorrect index. The change needed to
>: > the X11 driver is only three lines as follows:

>George,
>    You are correct.  I have changed the X11 driver.  However,
>I don't notice any changes!  There is still a nasty bug in the X11
>screen driver, as evidenced by the ./t1demo.sh that displays
>fonts in a different color continuously.  After about 10 seconds,
>the X11 screen driver starts displaying black...

Thanks for checking that out. Without the patch, I got an all
black screen right away and with the patch I get a normal VNC
screen but I haven't done any stress testing to check longer
term stability.

>WRT to VNC, I have placed your vnc port into microwin/src/demos/vnc
>as part of the standard distribution.  There are a number of items
>that aren't yet working.  These include the set system palette that you're
>working on for the 8bpp mode, and then support for all the other
>bpp modes that Microwindows may be running in.  I plan on helping
>to get VNC running well.

Yep, I saw that. Now that you have confirmed the X11 fix, I am
fairly happy that I have 8-bit palette mode working. From what I
know of the source, I don't see any good reason that the
truecolour modes shouldn't work as-is but I haven't got suitable
systems for testing them. I will try and make my updated version
available this week and would appreciate your help in making
sure it works for all colour modes.

Regarding future developments, my port is based on VNC
3.3.2 but the current version is 3.3.3. I have had a look
at this and the viewer has been heavily updated to use Xt
instead of Xlib. With a port of fltk for nano-X on the
way, I was wondering if it would be easier to add things
like scroll bars and dialog boxes by converting the Xt
version to work with fltk or whether it would be better
to stay with a simpler viewer just using nano-X on its
own. My target platform is pretty slow so I am a bit
wary of adding extra layers of toolkit that might slow
it down even more.

(I have never programmed with Xt or fltk so I have
got no idea of how easy it would be to try and convert
a program from one to the other)

Any thoughts?


George

On 12-Jun-00, Greg Haerr wrote:
>: Yep, I saw that. Now that you have confirmed the X11 fix, I am
>: fairly happy that I have 8-bit palette mode working. From what I
>: know of the source, I don't see any good reason that the
>: truecolour modes shouldn't work as-is but I haven't got suitable
>: systems for testing them. I will try and make my updated version
>: available this week and would appreciate your help in making
>: sure it works for all colour modes.

>I'm pretty sure that the VNC client doesn't work for 
>other than 8bpp.  I mean VNC 8bpp, not Nano-X.  So
>you can still get the VNC 24bpp working on your palettized
>device, Microwindows will convert the colors for you.  However,
>there's still some work to be done in the VNC client.

OK, I'd be interested in knowing what combinations do or
don't work. It may be something simple like I am not picking
up the right nano-X parameter to set the VNC screen mode. 

>I suggest getting 3.3.2 to work first, then considering 3.3.3.  Are
>3.3.2 clients completely compatible with 3.3.3 servers?  If so,
>then I suggest sticking with the Nano-X 3.3.2 client.  Later,
>we can make an FLTK VNC widget and we'll get scrollbars
>from that.

I'm happy with that, I'll continue with 3.3.2 for now. The VNC
documentation says that any 3.3.x viewer should work with any
3.3.x server so compatibility is not a problem.

George

: >I'm pretty sure that the VNC client doesn't work for 
: >other than 8bpp.  I mean VNC 8bpp, not Nano-X.  So
: >you can still get the VNC 24bpp working on your palettized
: >device, Microwindows will convert the colors for you.  However,
: >there's still some work to be done in the VNC client.
: 
: OK, I'd be interested in knowing what combinations do or
: don't work. It may be something simple like I am not picking
: up the right nano-X parameter to set the VNC screen mode. 

The issue here is fundamentally simple, but could get
complex in testing:  the VNC client talks to the VNC server
using the RFB protocol, and part of the setup for that
involves telling the server what pixel depth it would
like to see the screen contents in.  The servers IIRC
must handle all bit depths.   After the VNC client
gets the screen contents, it then calls Nano-X functions
to display those colors.  These two pixel depths
are different, and don't need to be the same.  In other
words, Nano-X will possibly transform again a color
(since all colors are specified in RGB) to display
it on the actual display hardware.

Currently, the VNC client only requests pixels in 8bpp.
George, you need to try out having the VNC client tell the
VNC server to send pixels in 16, and 24bpp.  The problem is,
right now, that since VNC always gets pixels in 8bpp mode,
it passes them thru unmodified (this is equivalent to a trick)
to Nano-X, and makes Nano-X think that they are really
palette values, which they are.  But for systems with 
better than 8bpp hardware, the screen won't look exact,
so we need to also get pixels in 565 and 888 formats, and
then Microwindows will translate them (according to the
hardware it is actually running on) to the appropriate values.

There are some other minor enhancements, like adding
the client capability to scroll or offset to different server
screen regions, that I would also like to add.  I will
add some Nano-X viewport functions to help with this.


The VNC
: documentation says that any 3.3.x viewer should work with any
: 3.3.x server so compatibility is not a problem.

Then why were people saying that it didn't work with the latest
version of VNC??

Regards,

Greg

On 14-Jun-00, Greg Haerr wrote:

>: >I'm pretty sure that the VNC client doesn't work for 
>: >other than 8bpp.  I mean VNC 8bpp, not Nano-X.  So
>: >you can still get the VNC 24bpp working on your palettized
>: >device, Microwindows will convert the colors for you.  However,
>: >there's still some work to be done in the VNC client.
>: 
>: OK, I'd be interested in knowing what combinations do or
>: don't work. It may be something simple like I am not picking
>: up the right nano-X parameter to set the VNC screen mode. 

[ snip palette issues ]

I'll have to think about the colour handling some more, I'll
have another look at what VNC is trying to do and come back
with any questions.

>There are some other minor enhancements, like adding
>the client capability to scroll or offset to different server
>screen regions, that I would also like to add.  I will
>add some Nano-X viewport functions to help with this.

Scrolling is the next thing I was going to work on, I haven't
looked at it at all yet. Does your mention of viewports mean
that scrolling is not possible with the current nano-X ?

>The VNC
>: documentation says that any 3.3.x viewer should work with any
>: 3.3.x server so compatibility is not a problem.

>Then why were people saying that it didn't work with the latest
>version of VNC??

I just updated my servers to 3.3.3r1 and my 3.3.2 clients still
work fine. Which version/platform combinations don't work?

Regards,

George

: Scrolling is the next thing I was going to work on, I haven't
: looked at it at all yet. Does your mention of viewports mean
: that scrolling is not possible with the current nano-X ?

We have scrolling implemented as screen-to-screen blitting
now.  But you don't really need "scrolling".  What you want is
just to change the GrCopyArea's X or Y offset and copy
a different RFB area to the screen.  A scrollbar control
on the right side of the window will just specify this Y offset.

: 
: 
: I just updated my servers to 3.3.3r1 and my 3.3.2 clients still
: work fine. Which version/platform combinations don't work?

Well, someone said they didn't work, but it appears that they do.

Regards,

Greg