08-17-2007, 07:16 PM | #1 |
Developer
Posts: 345
Karma: 3473
Join Date: Apr 2007
Location: Brooklyn, NY, USA
Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.
|
Understanding the ContentLister
Since the first step in changing (or replacing) something is understanding what it does, I thought I would start a thread about what the contentLister does.
I originally looked into this because I wanted to understand how button presses are handled by the iLiad's software. Now that I've learned a little bit, I've seen something surprising: It seems that the contentLister does a LOT more than just display directories. I wouldn't be surprised if the contentLister does a large part of the job of running the iLiad. I strongly suspect that the contentLister actually functions as a keyboard driver for the iLiad's buttons (including the power button!). But I might be wrong about all of this. Here's what I did: First, I made a slightly modified version of iPDF. In this version, every keypress seen by iPDF is written to a log file. Using this I've been able to determine the GTK+ keycodes for:
I wanted to learn what happens when those buttons are pressed, and where the signals go. My first guess was to that the contentLister was intercepting those keypresses from X... So, I wanted to learn what happens when we run the contentLister. I set up an ethernet connection to my iLiad and ran DropBear, then used ssh to log in as root. All of the following was done on the command line while logged in to the iLiad. It's possible that some error messages are a result of that. First, I killed the old contentLister. Then, I had to define DISPLAY so that the new contentLister would know where the display was, then I called the contentLister, just as it's called by start.sh during boot: Code:
# killall contentLister # export DISPLAY=:0 # /usr/bin/contentLister --sync & (CL_E)control.c:344,ctrl_read_configfile() cannot read [CONTENTLISTER] [doc_signing] - Key file does not have key 'doc_signing' [3] (CL_E)erConnect.c:68,erConnectInit() Lock the connect mutex (CL_E)metadataStoreManager.c:977,recreateArchives() Can not create directory /mnt/free/newspapers! (CL_E)metadataStoreManager.c:988,recreateArchives() Can not create directory /mnt/free/books! (CL_E)metadataStoreManager.c:999,recreateArchives() Can not create directory /mnt/free/documents! (CL_E)metadataStoreManager.c:1010,recreateArchives() Can not create directory /mnt/free/notes! (W)eripc.c:37,erIpcInitServer() Version: 256 (W)eripc.c:76,erIpcInitServer() Bound successfully to 127.0.0.1:50070. (E)erregcommon.c:138,erRegGetExtInfoFromMemory() theExtInfo->iconlocation - Key file does not have key 'ari' [3] (E)erregcommon.c:138,erRegGetExtInfoFromMemory() theExtInfo->iconlocation - Key file does not have key 'ARI' [3] (E)erregcommon.c:138,erRegGetExtInfoFromMemory() theExtInfo->iconlocation - Key file does not have key 'sh' [3] (E)erregcommon.c:138,erRegGetExtInfoFromMemory() theExtInfo->iconlocation - Key file does not have key 'SH' [3] (E)erregcommon.c:1112,erRegGetAutoconnectFromMemory() theAutoconnect->backgroundConnectTo - Key file does not have key 'background_connect_to' [3] (CL_W)control.c:432,ctrl_background_connect_timeout_start_withinterval() registry read: enable [0] interval [5] Opening /dev/otgdev0 Try 1...Success (CL_W)programManager.c:144,on_sigchld() entry: signo [17] pid [806] status [0x0000] (CL_W)programManager.c:207,on_sigchld() end Next, I moved to the "books" directory by pressing the "books" button, and navigated down a couple of subdirectories, all with button presses: Code:
... Code:
(CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 (CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 (W)eripc.c:37,erIpcInitServer() Version: 256 (W)eripc.c:76,erIpcInitServer() Bound successfully to 127.0.0.1:50067. (ERM_TRACE)ermanifest.c:95,LocateTo() LocateTo failed! no or empty xmlNodeSet (ERM_TRACE)ermanifest.c:95,LocateTo() LocateTo failed! no or empty xmlNodeSet (ERM_TRACE)ermanifest.c:95,LocateTo() LocateTo failed! no or empty xmlNodeSet CPDFApp::loadScribble uses 45247 PDFDoc::displayPage 127 uses 891228 drawImage and XSync time 36792 PDFDoc::displayPage 128 uses 1348748 PDFDoc::displayPage 129 uses 876218 PDFDoc::displayPage 130 uses 891040 PDFDoc::displayPage 131 uses 759569 PDFDoc::displayPage 132 uses 836193 The "PDFDoc::displayPage 131 uses 759569" messages are actually from iPDF, although they are obviously being passed along through the contentLister's output. Let's turn the page backward: Code:
(CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 PDFDoc::displayPage 126 uses 820161 drawImage and XSync time 34761 PDFDoc::displayPage 125 uses 955291 PDFDoc::displayPage 124 uses 612510 PDFDoc::displayPage 123 uses 425989 PDFDoc::displayPage 122 uses 793361 PDFDoc::displayPage 121 uses 885760 Code:
(CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 (CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 (CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 Code:
(CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 (CL_E)programManager.c:448,pm_SendKey() NOT Sending keyrelease for UP key.... (CL_W)programManager.c:144,on_sigchld() entry: signo [17] pid [808] status [0x0000] (CL_W)programManager.c:168,on_sigchld() last started [IPDF] pid [808] (CL_W)programManager.c:207,on_sigchld() end Code:
(CL_E)programManager.c:887,pm_UpdateState() Failed to fetch class hint for window 0x200004 (CL_W)programManager.c:521,pm_TerminateUserApp() Terminate process [ipdf] pid [811] On receive signal 15 pid 811 (CL_W)programManager.c:144,on_sigchld() entry: signo [17] pid [811] status [0x0000] (CL_W)programManager.c:168,on_sigchld() last started [IPDF] pid [811] (CL_W)programManager.c:207,on_sigchld() end Finally, here's a small experiment. I opened a pdf document using my modified iPDF which dumps keypresses to a log file. After testing it by turning pages (and reading the corresponding pagebar "keypresses" in the log), I killed the contentLister manually, then checked to be sure iPDF was still running: Code:
# killall contentLister # ps | grep ipdf 820 root 14656 S /usr/bin/ipdf /mnt/free/books/Doyle, Arthur Conan/Doyle - The Memoirs of Sherlock Holmes.pdf/Doyle - The Memoirs of Sherlock Holmes.pdf 821 root 14656 S /usr/bin/ipdf /mnt/free/books/Doyle, Arthur Conan/Doyle - The Memoirs of Sherlock Holmes.pdf/Doyle - The Memoirs of Sherlock Holmes.pdf 822 root 14656 S /usr/bin/ipdf /mnt/free/books/Doyle, Arthur Conan/Doyle - The Memoirs of Sherlock Holmes.pdf/Doyle - The Memoirs of Sherlock Holmes.pdf 833 root 448 S grep ipdf Finally, I killed iPDF and restarted the contentLister again. Keys worked as before, and on sliding the power switch, I got this: Code:
(CL_W)control.c:3293,ctrl_shutdown() entry ** (contentLister:850): CRITICAL **: ctrl_hide_pincode_screen: assertion `g_listerState == STATE_PINCODE' failed Broadcast message from root (pts/0) (Mon Apr 12 14:12:20 1954): The system is going down for system halt NOW! (CL_W)control.c:3317,ctrl_shutdown() end One interesting message from the contentLister's start sequence is "Opening /dev/otgdev0 Try 1...Success". My guess would be that one of iRex's binary kernel drivers translates button interrupts into keypress data and dumps it to /dev/otgdev0. Then the contentLister takes that data from /dev/otgdev0 and forwards button press codes to window applications as necessary. Bear in mind that this might be completely wrong. My interpretation and understanding of these experiments may be flawed. As I understand it, the conventional approach to X is that normally an X keyboard driver does the work of reading keyboard data and passing it along to the window manager. I have not yet read the iRex patches to the kernel and the xserver, and one of them may deal with button presses. Comments, questions, suggestions, corrections, etc....? |
08-18-2007, 03:09 AM | #2 |
reader
Posts: 6,975
Karma: 5183568
Join Date: Mar 2006
Location: Mississippi, USA
Device: Kindle 3, Kobo Glo HD
|
Have you seen the post Mobipocket Reader for GNU/Linux, Mac, all!? It is about running the iLiad (Java) MobiPocket Reader on other machines. The strange thing about the reader is that it is just the book display pane (no icons etcetera) and is controlled by "a UDP socket running on port 50079". I initially attributed the strangeness to MobiPocket, but perhaps this is another example of splitting window manager like actions into a separate program.
By the way, FBReader has a menu item to bind keys to actions (keys tab under the options icon) and it will tell you what key it detected for each keypress. So you can get some of this info from FBReader without recompiling. It may also be possible to bind two actions to some keys (standard and long keypresses), which isn't something I would have thought to try. |
Advert | |
|
08-18-2007, 03:57 AM | #3 |
Developer
Posts: 345
Karma: 3473
Join Date: Apr 2007
Location: Brooklyn, NY, USA
Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.
|
Interesting about the Mobipocket reader, I hadn't thought about that...
Well, the way things seem to work on the iLiad, button press interrupts are dealt with on a low level (kernel driver, probably) and converted to more conventional keypress signals, which are then picked up by another low-level program (I thought an X11 driver, but now I think the ContentLister) and passed to the window manager, which passes it to programs like iPDF and FBReader. Ultimately, many of the buttons are seen by applications as normal keyboard keys. For example, the "escape" button, to iPDF or FBReader, looks like F5. A forward pageflip looks like PgUp, back pageflip looks like PgDn, etc. Interestingly, a LONG forward pageflip isn't simply a long-held PgUp, but instead generates a F1. Similarly, the long backward pageflip generates an F2. Somewhere I have a list of the keyboard keys associated with each button action, and it's always a different key for short and long. This is how the buttons are seen at the GTK level within the window manager in X windows. The problem is, that the "books", "news", etc. buttons do NOT generate any keyboard key press visible to a regular application. So my question was, what DO they do, and where are those signals handled? The answer seems to be that the ContentLister takes care of interpreting button presses, but it only translates some into keyboard key press events for the Xserver / window manager. The "books" etc. buttons are intercepted and never get sent to the X server / window manager at all. At least, that's my theory at the moment... |
08-19-2007, 12:57 AM | #4 |
Developer
Posts: 345
Karma: 3473
Join Date: Apr 2007
Location: Brooklyn, NY, USA
Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.
|
Somewhat obviously, I realized that button signals are probably piped out through... surprise, surprise, /dev/buttons ! However, I can't seem to read any signals from it. cat /dev/buttons gives nothing, and I wrote a little program to read files character by character, which works fine in my computer for the mouse (/dev/psaux) but gives nothing from /dev/buttons when buttons are pressed.
Anyone have any ideas? |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
iLiad Better contentLister | rudysplif | iRex Developer's Corner | 5 | 11-26-2008 11:11 PM |
contentLister not starting :( | thetechnobear | iRex | 2 | 12-02-2007 12:59 PM |
fbshot via the contentlister | wallcraft | iRex | 2 | 10-26-2007 07:16 AM |
iLiad Replacing the contentlister | tribble | iRex Developer's Corner | 21 | 06-22-2007 03:58 PM |
iLiad Contentlister Enhancement | scotty1024 | iRex Developer's Corner | 22 | 12-15-2006 06:29 PM |