I previously announced that the version of David Young's popvision
library available at the free poplog site
http://www.cs.bham.ac.uk/research/poplog/popvision.tar.gz
worked with linux. I had tested it while remotely logged into a PC
running linux, sitting at a sun! Foolish me.
I have now tried to run it on a Del Latitude Cpt Laptop with
RedHat 6.1.
It still works fine when the laptop is on a network and I run
popvision remotely on the laptop while sitting at a sun.
However, rci_show and rc_array do not work when I use the laptop
screen locally, and I get the same error if I log through from the
Laptop running linux to the sun.
This example from TEACH VISION1 produces the error:
uses popvision
vars image; ;;; declare a permanent variable
arrayfile(popvision_data dir_>< 'stereo1.pic') -> image;
rci_show(image) -> ;
so does this example from TEACH RC_ARRAY
uses rc_array
vars image;
sunrasterfile(popvision_data dir_>< 'mtg_ho.ras') -> image;
rc_new_window(500, 500, 520, 300, true);
rc_win_coords();
rc_array(image, false, false, false, false);
In both cases the mishap is 'Unable to allocate colour map entries'
in the lconstant procedure getcrange.
Looking at the code suggests that XpwAllocColorRange is not working
(i.e. it always returns a false result), which I confirmed by
doing this:
rc_start();
XpwAllocColorRange(rc_window, 64, 0,0,0, 0,0,0)=>
** <false>
changing the numbers, e.g. using all 1s, or using 0,0,0, 1,1,1,
or combinations of 255, makes no difference as far as I can tell,
The same command in the context where everything works (i.e. using
the Sun screen) gives the result
** <external_ptr>
Can anyone provide tips as to how to fix this?
The Sun has an 8 bit colour display whereas the PC uses 24 bits (I
think). But I don't think that can be the cause of the problem.
(X uses only 8 bits anyway??)
The procedure XpwAllocColorRange is defined in
$usepop/pop/x/pop/lib/Xpw/XpwGraphic.p
It apparently uses the C procedure AllocColorRange defined in
$usepop/pop/x/Xpw/Graphics.c
Using my limited understanding of C, I infer that this call of the C
function
XAllocColorCells(dpy, cmap, TRUE, plane_masks, 0, pixels,num_cells)
is returning a false result. I have no idea why, or what needs
to be done to change this.
The other piece of information I have gleaned experimentally is that
on the laptop the colour bits are inverted relative to the sun. This
means that if you try using the GXxor line style for drawing easily
movable objects it doesn't work, as drawing onto a white background
produces the wrong colour. However using GXequiv works fine.
(Is there some piece of program which can test for that??)
I don't know if the difference in behaviour of xor is related to the
failure of XpwAllocColorRange.
Suggestions welcome.
Aaron
===
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (NB: Anti Spam address)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
|