#16 display-x fails on Solaris/sparc64
GGI's display-x works fine on Solaris on my SparcStation 5
(= Solaris/sparc32)
But on my Ultra 1 Creator (= Solaris/sparc64),
display-x fails:
XError of failed request: BadValue (integer parameter
out of range for operation)
Major opcode of failed request: 91 (X_QueryColors)
Value in failed request: 0xffffff
Serial number of failed request: 33
Current serial number in output stream: 33
The failure occures in libggi/display/X/color.c, function
_ggi_x_create_colormaps() within the call of
XQueryColors()
- note the plural, do not mix it up
with XQueryColor().
It uses the visual ID 0x2B, which is (output from
xdpyinfo):
visual:
visual id: 0x2b
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification:
8 bits
BTW: The visual ID 0x26 might be also interesting:
visual:
visual id: 0x26
class: DirectColor
depth: 8 planes
available colormap entries: 8 per subfield
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification:
8 bits
Logged In: YES
user_id=51548
It is interesting that the ggi applications work fine on the
0x26 X visual.
Just use GGI_DISPLAY="[C8]" and display-x uses this 8bit
directcolor X visual.
It looks to me, that there must be a field that contains the
available number
of gamma channels we just should use rather calculating it
based on the depth... Can anyone provide some information
on this, please?
Declare some variables as uint32_t instead of unsigned int (and shuffle).
Logged In: YES
user_id=972775
Can you try this (untested) patch?
Basically, the current code is assuming that variables
are 32 bit and wrap to zero, but on 64-bit they hit
0x100000000 instead (so the loop continue for far
too long).
Logged In: YES
user_id=51548
I tested it. And no, the patch does not fix this
particular problem.
I still see this error:
XError of failed request: BadValue (integer parameter
out of range for operation)
Major opcode of failed request: 91 (X_QueryColors)
Value in failed request: 0xffffff
Serial number of failed request: 33
Current serial number in output stream: 33
But tnx for your help.
Logged In: YES
user_id=972775
And here I was thinking I nailed it. I still think the
patch is worthwhile, but I don't use display-x much and
would like somebody to test it.
My suggestion is to dump the actual values passed to
XQueryColors to stdout, that should reveal the cause...
Logged In: YES
user_id=972775
What output do you get with colormaps-2.patch?
(Do not use in conjunction with the previous
colormaps.patch)
Dump some variables to log, to see if anything obvious turns up
Logged In: YES
user_id=972775
Oops, forgot the checkbox...
Logged In: YES
user_id=51548
Output with colormaps-2.patch:
red: count 256 (= 256?) mask 000000ff
green: count 256 (= 256?) mask 0000ff00
blue: count 256 (= 256?) mask 00ff0000
gamma: count 256 (= 256?)
Logged In: YES
user_id=972775
Ahhh, "unsigned int" is not 64 bits on sparc64, that's why
colormaps.patch didn't make a difference. The current code
will bomb out when "unsigned int" is not 32 bits though,
but that's an unrelated problem...