[argyllcms] dispread issues, in an android tablet chroot
- From: Dan Wilcox <dmwilcox@xxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Tue, 28 Aug 2012 19:00:50 -0700
Hello! I'm fairly new to the list and the Argyll suite so please let me
know if there is anything I should be including but am not.
Background and Motivation:
I noticed in the mailing list archives some Android profiling has come up
before, my attempt is slightly different as I'm using the tablet to profile
itself by way of a Debian chroot. As a result of the limitation of not
having either VideoLUT access or a native windowing display system (I'm
using VNC to provide Debian with an X environment) the attempt is here to
profile the display only. As such I'll be doing other things to ensure
consistent display settings--using scripts to set brightness and profiling
at different known brightness levels. And I'm perfectly happy to only use
color aware applications in said VNC environment (for the time being) as
that is where I can run my photo processing applications (ufraw and gimp).
Environment:
Asus Transformer Prime with Android 4.0 and a Debian chroot (Wheezy) built
with multistrap.
$ uname -a
Linux localhost 2.6.39.4-00003-g2108187 #1 SMP PREEMPT Tue Feb 21 18:40:24
CST 2012 armv7l GNU/Linux
(funny enough, yes this is the version string from Android)
OK, now to sweat and tears, I have generated a target file with targen,
poured over documentation, tried a few different environments only to come
back to find that when dispread tries to load up the target patch file it
goes into an infinite loop, on the tablet--x86 laptop is fine of course.
I'm still tracing through some of the parsing state machine code but could
certainly use another pair of eyes to assist if anyone is willing. Let me
know if anyone has any ideas for tracking down this issue, or circumventing
it. This parse condition does not look like it should exist, but it
stubbornly appears to.
Thanks! I'm so glad to see such great open source tools and such a vibrant
community around this stuff.
Daniel
<written on an android, wew it'll work better someday> :)
off to look at p->fp->getch(p->fp)
Data:
Excuse annotation/verbosity, thought it might be handy.
<snip from an system call trace on dispread when it gets stuck in a read
loop>
open("target-chart.ti1", O_RDONLY) = 16
fstat64(16, {st_mode=S_IFREG|0666, st_size=11281, ...}) = 0
fstat64(16, {st_mode=S_IFREG|0666, st_size=11281, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40041000
read(16, "CTI1 \n\nDESCRIPTOR \"Argyll Cali"..., 4096) = 4096
read(16, "7.642 39.734 73.389 18.751 \n79 7"..., 4096) = 4096
read(16, "166 86.118 44.061 13.217 36.160 "..., 4096) = 3089
read(16, "", 4096) = 0
read(16, "", 4096) = 0
read(16, "", 4096) = 0
read(16, "", 4096) = 0
... stuck here in a loop reading...
spectro/dispread:~580
it starts here, goes through declaring a new_cgats which in turn calls some
allocator code in cgats/cgats.c and cgatsstd.c, but ultimately the parsing
is what is going to read the file.
cgats.c:370 -- should make the read calls stop
if ((rc = pp->read_line(pp)) == 0)
(file parsing exits if this condition is met)
pars.c: 345 -- likewise this looks good too
(in what pp->read_line calls)
if ((c = p->fp->getch(p->fp)) == EOF) {
if (p->bo == 0) { /* If there is nothing in
the buffer */
p->line = 0;
return 0;
}
c = 0; /* Finish the line */
}
Other related posts:
