#6645 NORM Never A: Read of PDF suspends while showing "Loading..." rather than a page
Zarro Boogs per Child
bugtracker at laptop.org
Fri Mar 7 14:54:45 EST 2008
#6645: Read of PDF suspends while showing "Loading..." rather than a page
----------------------------+-----------------------------------------------
Reporter: gnu | Owner: rwh
Type: defect | Status: new
Priority: normal | Milestone: Never Assigned
Component: read-activity | Version: Development build as of this date
Resolution: | Keywords: suspend
Verified: 0 | Blocking:
Blockedby: |
----------------------------+-----------------------------------------------
Comment(by gnu):
I'm having trouble confirming your statement that "Update.1 has suspending
disabled." I was running update.1 (build 691) at the time I reported this
bug. But update.1 apparently means many things to many people. Please
confirm:
Does the current version of Read entirely eliminate the forced suspend
kludge that was unique to Read? I see no Trac ticket for doing this, and
the source tree at http://dev.laptop.org/git?p=projects/read-
activity;a=blob;f=readactivity.py;h=3992290d0a9194742c82d9a924e0c15bd32bfea3;hb=master
still has plenty of suspend stuff in it. In particular, it calls
self._service.set_kernel_suspend (whose definition appears to be in
/usr/bin/olpc-hardware-manager!!! I can't figure out how that could be in
scope to be called by Read!) which does a direct write to the kernel,
rather than going through HAL or Ohm to decide any policy questions about
suspending). So if this code is what's running, in what sense does
"update.1 ha[ve] suspending disabled"?
Is that hypothetical Read change approved for inclusion in update.1?
Is it in the current release candidate? (What release candidate *is*
that, so I can test it?)
Thanks...
--
Ticket URL: <http://dev.laptop.org/ticket/6645#comment:4>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs
mailing list