From http://lxr.linux.no/#linux+v3.1.6/include/net/bluetooth/hci.h#L254 :
/* Link Key types */
#define HCI_LK_COMBINATION 0x00
#define HCI_LK_LOCAL_UNIT 0x01
#define HCI_LK_REMOTE_UNIT 0x02
#define HCI_LK_DEBUG_COMBINATION 0x03
#define HCI_LK_UNAUTH_COMBINATION 0x04
#define HCI_LK_AUTH_COMBINATION 0x05
#define HCI_LK_CHANGED_COMBINATION 0x06
Friday, December 30, 2011
Pairing Bluetooth devices from command line
Following appear to be commands required to trigger pairing process from the command line:
Commands must be on the same line, separated by the semicolon, as described in previous post.
At this point, Bluez auth agent should kick in, asking for a code, if you have GUI one.
I found a page which suggests that only "hcitool cc" was enough for the author to trigger pairing, this could be explained by the fact that prior to 2.1, Bluetooth supported security modes which could protect either entire device access or just some of its profiles.
hcitool cc <bdaddr>; hcitool auth <bdaddr> Commands must be on the same line, separated by the semicolon, as described in previous post.
At this point, Bluez auth agent should kick in, asking for a code, if you have GUI one.
I found a page which suggests that only "hcitool cc" was enough for the author to trigger pairing, this could be explained by the fact that prior to 2.1, Bluetooth supported security modes which could protect either entire device access or just some of its profiles.
Saturday, November 12, 2011
Shopping for 3D TV...
Shopping for 3D TV (again), few findings:
- There are no non-LED 3D TVs for sale in this part of world anymore (in particular, my older favorite, LE40C750 is no longer available)
- Samsung D6xxx series (the cheapest) were caught red-handed not providing FullHD resolution in 3D: via Samygo. (Note from myself: Samsung was caught because lots of people actually buy their stuff, what one can think about other vendors?)
- LG goes out of line of vendors with 3D shutter glasses technology with their FPR ("Cinema 3D" in marketing speak) technology. It uses passive (no power needed) polarized glasses, like RealD cimenas. Announced April (on these longitudes), already in local shops at not-so-indecent prices. FPR is Film Patterned Retarder, and I hope the last word is spelled right, because I have high hopes for this tech. It shares the same issue as Samsung D6xxx: there won't FullHD here for sure, but at least it's official and there're other benefits.
Wednesday, November 9, 2011
Tuesday, November 8, 2011
Links for November 2011
Kindle:
Linux kernel module tricks:
- Amazon Kindle official GPL source code
- Kindle keyboard shortcuts and other reference
- Latest jailbreak appears to be one from NiLuJe (forum). It's known to work with firmware 3.3. Hacks/updates should be copied to Kindle USB drive root.
- SirAlex's page
- Intro for writing kindlets
Linux kernel module tricks:
- How to bind Linux driver to device whose IDs it doesn't know (yet), without recompiling
- Building a kernel module separately (build module from a kernel source tarball using currently installed kernel config)
Sunday, October 23, 2011
Fixing fan cooler in Asus X34F notebook
I spent good deal of day today fixing howling, growling, roaring and making other unpleasant noises fan in my Asus X34F notebook. X34F appears to be region-specific version of U35F, and motherboard bears labels of UL30A, so I guess this may be pertinent to them either.
I wasn't able to find a service manual, so I proceeded with disassembly by experience and intuition. It turns out that to detach cooler one needs to unscrew one motherboard plate completely (there're two, bound with a connector). The cooler part number turned out to be KDB04505HA by Delta Electronics. Vendor site showed no trace of this part no. But quick googling showed that it's the same part no used in Macbook Pro with similar performance stories. One another reason you don't need to pay a lot to get the same c.r.a.p.
Once I completely detached it, I figured how it could make those noises - impeller could dance on its axis, and while doing so could touch plastic casing. So, my idea was to either cut the corresponding side of impeller, or increase vertical space in which it "dances". I went for the latter, adding two washers between metal and plastic casing parts and gluing another washer on third point to get more support.
I decided also to oil fan, and considering oiling with machine oil could lead to just more dust accumulation, figure I take a pencil and oil it with graphite. Big mistake - either that pencil didn't really have pure graphite, or I put it there too much, but after re-assembling and powering all stuff, I saw that the cooler stopped working at all.
I almost gave up and started to look for closest repair shop, then figured I already have thing half-disassembled, and they would need to extract the fan anyway, so guessed I do it myself and deliver it to repairman in pieces. But before then, heck, I'll make another pass it it - first of all, try to power it on despite its rather home-use unfriendly connector.
Couldn't reliably figure the connector pinout (found pinout only for 12V desktop fans, who knows if laptop one would be proprietary), so tried googling for wire color codes instead. This page gave me good hints (black - GND, red - VCC, blue - PWM for speed control, yellow or another - speed sensor) which I decided to try with power supply at last. Unfriendly connector? Was able to stick into it breadboard wires, then breadboard, then breadboard power adapter. Saw the motor nudge, as struggling with friction. Took off the impeller, wiped its axis, and cleaned other part as best as I could. Put it back and powered, and so it moving - but, with whistling and vibration, even though suspected plastic part was off. Well, decided there's little to lose and oiled it with smallish drop of machine oil.
That was it! The thing stopped its hellish screams and just monotonically buzzed if move ear close to it. Reassembled all the stuff - the noise level is close to that which was when I bought it, as far as I can tell. acpitz sensor temperature is down to 55dC from 95dC I saw before. Finger crossed that oiling will help for decent time.
Conclusion and note to myself: It's indeed nice idea to be in power of your hardware, no doubts, and fears off. And its better to invest into tools than to pay for services of unknown quality (could easily imagine the same oiling to be done, but charged as replacement).
UPDATE: No, it didn't last even a day :-(
I wasn't able to find a service manual, so I proceeded with disassembly by experience and intuition. It turns out that to detach cooler one needs to unscrew one motherboard plate completely (there're two, bound with a connector). The cooler part number turned out to be KDB04505HA by Delta Electronics. Vendor site showed no trace of this part no. But quick googling showed that it's the same part no used in Macbook Pro with similar performance stories. One another reason you don't need to pay a lot to get the same c.r.a.p.
Once I completely detached it, I figured how it could make those noises - impeller could dance on its axis, and while doing so could touch plastic casing. So, my idea was to either cut the corresponding side of impeller, or increase vertical space in which it "dances". I went for the latter, adding two washers between metal and plastic casing parts and gluing another washer on third point to get more support.
I decided also to oil fan, and considering oiling with machine oil could lead to just more dust accumulation, figure I take a pencil and oil it with graphite. Big mistake - either that pencil didn't really have pure graphite, or I put it there too much, but after re-assembling and powering all stuff, I saw that the cooler stopped working at all.
I almost gave up and started to look for closest repair shop, then figured I already have thing half-disassembled, and they would need to extract the fan anyway, so guessed I do it myself and deliver it to repairman in pieces. But before then, heck, I'll make another pass it it - first of all, try to power it on despite its rather home-use unfriendly connector.
Couldn't reliably figure the connector pinout (found pinout only for 12V desktop fans, who knows if laptop one would be proprietary), so tried googling for wire color codes instead. This page gave me good hints (black - GND, red - VCC, blue - PWM for speed control, yellow or another - speed sensor) which I decided to try with power supply at last. Unfriendly connector? Was able to stick into it breadboard wires, then breadboard, then breadboard power adapter. Saw the motor nudge, as struggling with friction. Took off the impeller, wiped its axis, and cleaned other part as best as I could. Put it back and powered, and so it moving - but, with whistling and vibration, even though suspected plastic part was off. Well, decided there's little to lose and oiled it with smallish drop of machine oil.
That was it! The thing stopped its hellish screams and just monotonically buzzed if move ear close to it. Reassembled all the stuff - the noise level is close to that which was when I bought it, as far as I can tell. acpitz sensor temperature is down to 55dC from 95dC I saw before. Finger crossed that oiling will help for decent time.
Conclusion and note to myself: It's indeed nice idea to be in power of your hardware, no doubts, and fears off. And its better to invest into tools than to pay for services of unknown quality (could easily imagine the same oiling to be done, but charged as replacement).
UPDATE: No, it didn't last even a day :-(
Wednesday, October 19, 2011
Making hcitool commands work
It's a shame how some now-ubiquitous technologies, like Bluetooth, are under-used and under-understood. And by usage I don't mean here occasional business card exchange, net access, being bluesnarfed and other boring consumer-level activity, but page scans, inquiries and having secure wireless communication you can trust (or not).
Anyway, if you ever tried using hcitool you may think it barely works. For example:
Ok, so here's the matter. First of all, hcitool accesses hci device directly, and that requires root access. Secondly, it works on low protocol level (ACL), so connection established by "cc" is of course not pairing or service-level connection. It's low level connection, which persist only while data is transferred and shutdown quickly to preserve the power. Yep, it shuts down while you type or even re-run next command. That's how it should be done:
More fun:
Anyway, if you ever tried using hcitool you may think it barely works. For example:
# hcitool cc <bdaddr>
# hcitool lq <bdaddr>
Not connected.
Ok, so here's the matter. First of all, hcitool accesses hci device directly, and that requires root access. Secondly, it works on low protocol level (ACL), so connection established by "cc" is of course not pairing or service-level connection. It's low level connection, which persist only while data is transferred and shutdown quickly to preserve the power. Yep, it shuts down while you type or even re-run next command. That's how it should be done:
# hcitool cc <bdaddr>; hcitool lq <bdaddr>
Link quality: 255
More fun:
# hcitool cc $BDADDR; hcitool auth $BDADDR; hcitool enc $BDADDR; hcitool key $BDADDR; hcitool con
Connections:
< ACL 7D:75:75:xx:xx:xx handle 12 state 1 lm MASTER AUTH ENCRYPT SECURE
Tuesday, September 13, 2011
Links for September 2011
Speech synthesis/TTS links, focusing on Russian:
OpenSource:
OpenSource:
- FestLang, Festival voices for different languages, in particular, Russian.
- VoxForge, speech corpus collection site
- AOT, automated text processing (Russian)
- RHVoice, mailing list archive (Russian)
Tuesday, June 28, 2011
Towards decent mouse wheel support in Android
One thing everyone would notice on attaching a USB mouse to an Android device is that mouse wheel is not supported, which makes interaction very tedious. I take a quick look at the state of its support.
Android-x86 project advertises mouse wheel support, but looking at their patch, they translate mouse wheel clicks into up/down buttons. That's better than not supporting wheel at all of course, but still not intuitive usage. What I'd like to have is not analog of up/down key press, but actual scroll, i.e. analog of drag.
But probably, such behavior couldn't be reliably emulated on the lower level of input processing, (or this might lead to adverse effects, like mouse wheel movement interpreted as click). Instead, higher-level controls should have explicit support for discrete scroll events. For example this event handler block should be factored out to be callable for such event and be passed just deltaY.
Of course, that would be more or less big refactor, so another approach would be just waiting until Google thinks it gave enough competitive advantage to big vendors over small and finally releases 3.0+ source code, which supposedly implements wheel support.
Android-x86 project advertises mouse wheel support, but looking at their patch, they translate mouse wheel clicks into up/down buttons. That's better than not supporting wheel at all of course, but still not intuitive usage. What I'd like to have is not analog of up/down key press, but actual scroll, i.e. analog of drag.
But probably, such behavior couldn't be reliably emulated on the lower level of input processing, (or this might lead to adverse effects, like mouse wheel movement interpreted as click). Instead, higher-level controls should have explicit support for discrete scroll events. For example this event handler block should be factored out to be callable for such event and be passed just deltaY.
Of course, that would be more or less big refactor, so another approach would be just waiting until Google thinks it gave enough competitive advantage to big vendors over small and finally releases 3.0+ source code, which supposedly implements wheel support.
Monday, June 27, 2011
Links for June 2011
- http://sigrok.org/ - OpenSource logic analyzer software supporting lot of hardware analyzers (C++/Qt, protocol plugins in Python)
- http://dangerousprototypes.com/2010/07/23/logic-analyzer-client-roundup/ - Logic analyzer client roundup
- http://blog.visucore.com/categories/embedded - Blog posts about using and hacking USBee SX. In particular, how to find UART pins on a device using it; how to replace firmware with self-compiled using SDCC, etc.
- http://openenergymonitor.org/ - Open Energy Monito
- On accuracy of (commercially available) power meters:
- Lies, Damn Lies and Cheap Power Meters
- That one lying disassembled with blob chip, but with potentiometers to calibrate
- Comparing KaW and a clone with industrial piece
- http://www.pupman.com/listarchives/2005/Aug/msg00936.html
Sunday, June 26, 2011
Hacking Luxeon SP-1
I finally going to get Arduino, and while I'm choosing flavor and waiting for it, I can't help but disassembling all devices I have at home, each time speaking: "This must have Arduino inside!" (meaning of course that I expect it to be based on general-purpose MCU). Gosh, I usually get "blob chip" (uncased chip with blob of epoxy on top).
Well, I finally had my expectations fulfilled - Luxeon SP-1 voltage stabilizer/cutter features ATMEGA48V-10PU (Flash: 4k, EEPROM: 256, RAM:512). Not only that, it is installed in DIP socket! Buy from Luxeon, they're hacker-friendly ;-).
I bought the device actually for a wattmeter it features (which fact is hard to figure out from common specs found in the shops, I accidentally read somebody mentioning it on a forum). The wattmeter is of course not bright - for a lamp rated 100W it shows 88W, and for more powerful equipment (like perforator) understates wattage even more (maybe it's difference between real and apparent power factor).
Still, for $17 you get Arudino-alike with voltage/current sensor and hacking possibility. Woot!
BOM:
High-power board:
Well, I finally had my expectations fulfilled - Luxeon SP-1 voltage stabilizer/cutter features ATMEGA48V-10PU (Flash: 4k, EEPROM: 256, RAM:512). Not only that, it is installed in DIP socket! Buy from Luxeon, they're hacker-friendly ;-).
I bought the device actually for a wattmeter it features (which fact is hard to figure out from common specs found in the shops, I accidentally read somebody mentioning it on a forum). The wattmeter is of course not bright - for a lamp rated 100W it shows 88W, and for more powerful equipment (like perforator) understates wattage even more (maybe it's difference between real and apparent power factor).
Still, for $17 you get Arudino-alike with voltage/current sensor and hacking possibility. Woot!
BOM:
High-power board:
- Relay: Coil: 24VDC, 5A/240VAC
- 7805
- Coil transformer LR-019B
- ATMEGA48V-10PU
- 2 buttons
- 2 LEDs (red & green)
- 3-digit 7-segment LED indicator
Hacking Technoline WS 585 weatherstation
Technoline WS 585 is a simple consumer weatherstation offering builtin indoor temperature sensor and outdoor wireless (433MHz) temperature sensor. But as funny extra, it comes with wireless USB dongle which, being attached to computer running special (Windows) software, transmits to the base station weather forecast for next few days as well as extra weather data for today.
There're two problems with that: I prefer my weather forecast site, not one hardcoded by the vendor, and, I don't have constantly running Windows box. Besides, this device is essentially low-resolution wireless LCD (albeit with funny pixel shape), so one may want to show build status or loadavg on it.
So, I wanted to hack a Linux driver for it for a long time. Wider-scope, I wanted to grok USB and hack driver for it for longer time. Few times before I had a look at usbsnoop log of something, It seemed for overwhelming and I didn't really put much effort into it.
So well, I read up USB docs (Usb in a NutShell is a good summarization of the spec), and started to look at USB descriptors and logs with understanding eye.
Here are info and descriptors for WS585 dongle btw:
dmesg:
[1118327.253222] usb 2-1.3: new low speed USB device using ehci_hcd and address 3 [1118327.524340] usbcore: registered new interface driver hiddev [1118327.527975] input: Tenx Non standard Device as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/input/input51 [1118327.528162] generic-usb 0003:1130:0202.0001: input,hidraw0: USB HID v1.10 Device [Tenx Non standard Device] on usb-0000:00:1d.0-1.3/input0 [1118327.530011] input: Tenx Non standard Device as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.1/input/input52 [1118327.530182] generic-usb 0003:1130:0202.0002: input,hidraw1: USB HID v1.10 Device [Tenx Non standard Device] on usb-0000:00:1d.0-1.3/input1 [1118327.530554] usbcore: registered new interface driver usbhid [1118327.530557] usbhid: USB HID core driver
lsusb:
Bus 002 Device 003: ID 1130:0202 Tenx Technology, Inc.
lsusb -v:
Device: ID 1130:0202 Tenx Technology, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1130 Tenx Technology, Inc.
idProduct 0x0202
bcdDevice 1.00
iManufacturer 0
iProduct 2 Tenx Non standard Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 41
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 23
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)So, it uses well-known programmable microcontroller chip from Tenx Technology, found in bunch of other devices like USB missile launchers, etc.
By the end of day I had a PyUSB app which implemented the protocol seen in usbsnoop log. It received all the same (way, similar) responses from the chip. But it didn't exhibit external behavior. Specifically, under Windows, LED on the dongle blinks about every 55s (sic, less than whole minute), and right at the same time weather station updates its display. Under Linux with my app, LED never blinks, and no updates are shown on the display. I tried to to adjust my app to use the same delays between requests as seen in the original log, but no avail.
So, I have 2 ideas here: I made some mistake transcribing log into PyUSB calls, or, it's all timing related, and I didn't get the timing right. I tried to capture USB log around the blink, and don't see any request which could make explicit "transmit" request. I have following hypothesis: base station doesn't listen air all the time, it turns on it radio only ~ once a minute. So, dongle at first synchronizes to the base station. Then, it just transmits data at predefined intervals. And control requests from host don't transmit stuff immediately, but put it into buffer for the next transmission.
Is that true or not, hard to tell. But this device is for sure more complicated than other Tenx-based ones due to its wireless and trickle-transmit features.
I've put my current code together with USB logs to git at https://gitorious.org/homeauto/homeauto-devices
Sunday, June 12, 2011
Comparison of OpenSource PDF readers for Android
Today we're going to review few open-source PDF readers for Android platform. The table below provides links and feature-by-feature comparison, with more detailed discussion of features below the table. It should be noted that all these readers are based on the same PDF rendering library - MuPDF, so offer roughly the same rendering quality, the differences may be only due different version of the library used, or different configuration options (for example, some readers compile MuPDF without JPEG2000/JBIG support, or without standard PDF fonts).
The review summarizes with expectable conclusion - there's no perfect reader so far, but selects clear winner, which is worth to be hacked on.
| Feature | DroidReader 0.5 | APV aka PDFViewer 0.2.9 | VuDroid 1.4 | MuPDF Android Client 0.8.165 |
|---|---|---|---|---|
| Builtin open file | - | + | + | - |
| On-screen zoom | - | + | + | + |
| Continuous pages | - | + | + | - |
| Page smaller than screen | - (force close on attempt) | + | - | - |
| In-app rotate | + | + | - | - |
| Go to page | + | + | + | - |
| Table of contents | - | - | - | - |
| Find text | - | + | - | - |
| JPEG2000/JBIG | - (doesn't recognize pdf) | + | - | + |
| Other formats | - | - | DJVU | - |
- Builtin open file - whether you can start application and select file to view, or must have a compatible file manager and open PDF in it using "open with".
- On-screen zoom - whether you can zoom by direct manipulation on screen (like, pinch zoom, zoom in/out widgets) or need to go to menu. Needless to say, without on-screen zoom a reader is hard to use for real reading.
- Continuous pages - whether you see single page at time and need to use explicit next/prev page actions, or can just scroll a page away and see next/previous page. (Arguably, continuous page reading is easier and more productive.)
- Page smaller than screen - whether you can zoom out page so it is smaller than screen. For continuous pages reader, that would mean showing more than 2 pages at the same time on the screen. While this seems like neat feature, it actually just complicates real reading, when you need to take extra care to zoom back carefully after occasional zoom-in. (That's of course why most apps don't bother to implement it.)
- In-app rotate - whether app has own support for rotating pages, or relies on OS to support rotation. Got a vendor-crippled device without OS support for rotation? You're lost without in-app rotate, so that's boon.
- Go to page - basic navigation feature. That's not much convenient for real reading, but without this, you can't do any real reading at all.
- Table of contents - real navigation. For an app to be really usable, it must support this. Nope of apps in review does though.
- Find text - other very useful navigational feature. You hardly can read technical/reference docs without this.
- JPEG2000/JBIG images support - Apps which doesn't support these images format don't really support PDF, just some crippled subset of it.
- Other formats support: You found your perfect PDF reader? Congrats, now repeat that for all other ebook formats you use. Don't wanna waste time like that? Choose readers which support all reasonably similar formats. For already typeset ebook, there're actually two formats: PDF & DJVU, so good reader should support both. For TXT, HTML, CHM you indeed would rather look for different reader with different featureset.
And the winner is...
Based on the table above, the clear winner is VuDroid: it supports both typeset-ebook formats, PDF & DJVU, and has reasonable usability features (like has limit for page zoom out, as well as adjusts zoom on rotation). One serious, but easy to fix thing lack of JPEG2000/JBIG support (fixable by extending MuPDF config). Other thing it lacks comparing to APV is text find. Well, all readers in review lack ToC support, which a perfect reader must have. Back to VuDroid, it's UI is rather bare - there's no even About dialog, so you can't know that you're running VuDroid at all, or its version!Sunday, March 20, 2011
Breaking out of Android sandbox
The aim: run real native applications side-by-side with Android Dalvik applications.
Reason: Android imposes drastic lifecycle scheme on any application started under its Dalvik VM. That lifecycle is not how real software is written (be be written, should be written).
So, the idea is to run Linux-native application which will create a window/surface/display compatible with ones managed by Android's "Window Manager". It seems that level on which such app should operate is "SurfaceFlinger" Android service which is essentially a compositing display server. So, the app will create a new surface (possibly, still showing standard Android toolbar), and essentially will have exclusive control over the hardware during its runtime (for example, it apparently would read input events directly from Linux devices), but of course it should be able to "minimize" itself to let Android window manager to control its windows, and be able to "maximize" (by receiving some IPC event).
The problem: how to deal with OOB Android window interaction (for example, alarm window pops up)? Apparently, that should lead to another surface to be created on top of our app's, so new one should be just visible to user, and our one should just go offscreen. But what about input events? Does SurfaceFlinger notifies clients of their surface state changes?
http://www.mail-archive.com/android-porting@googlegroups.com/msg01680.html
Reason: Android imposes drastic lifecycle scheme on any application started under its Dalvik VM. That lifecycle is not how real software is written (be be written, should be written).
So, the idea is to run Linux-native application which will create a window/surface/display compatible with ones managed by Android's "Window Manager". It seems that level on which such app should operate is "SurfaceFlinger" Android service which is essentially a compositing display server. So, the app will create a new surface (possibly, still showing standard Android toolbar), and essentially will have exclusive control over the hardware during its runtime (for example, it apparently would read input events directly from Linux devices), but of course it should be able to "minimize" itself to let Android window manager to control its windows, and be able to "maximize" (by receiving some IPC event).
The problem: how to deal with OOB Android window interaction (for example, alarm window pops up)? Apparently, that should lead to another surface to be created on top of our app's, so new one should be just visible to user, and our one should just go offscreen. But what about input events? Does SurfaceFlinger notifies clients of their surface state changes?
- Mobile Multitasking (iPhone vs. Android)
- Why the iPad and iPhone don’t Support Multitasking
- Anatomy & Physiology of an Android
- Using SKIA in Android native code
- Necessitas blits to surface from native code, AndroidBitmap_* functions (libjnigraphcs.so) are used, and it pulls its implementation from AOSP source, so it works for any Android version (libjnigraphcs.so is just a thin wrapper of Skia functions). A Necessitas commit where they switch from using internal surfaces to AndroidBitmap_*: http://qt.gitorious.org/~taipan/qt/android-lighthouse/commit/37f298c40ca19570f2c2302f227323711c8478e9 (Some info at Issue 4)
- Notes and native Linux programming under Android (static and dynamic linking examples using CodeSourcery toolchain)
- Hello World C program using Android Toolchain
- http://blog.sina.com.cn/s/blog_6074fcd20100g648.html - Some class diagrams
- http://kcchao.wikidot.com/surfaceflinger - Some class diagrams
- surface flinger framework and issues
- frame buffer
http://www.mail-archive.com/android-porting@googlegroups.com/msg01680.html
Sunday, March 13, 2011
OpenSource Package Manager for Android
So, next move of thought is towards open-source package manager. But only to find out that:
- Trackdroid is fool's gold, with source never released (or taken down after release)
- Undroid is stopped because "ultimately it was made irrelevant by Google market place."
- apkget was started just this year, but already undergone repo created - something committed - repo removed cycle.
They offer maintained client, they offer repository of packages. Hurrah!
UPDATE: F-Droid is a fork of Aptoide, which also specialized in Android repository provision, but not specializes in FOSS. Consequently, Aptoide client lacks detailed information about licencing, etc. and the repository provided by Aptoide project contains more than just FOSS project. At the same time, Aptoide seems to be leaning towards meta-level (i.e. provide package provision solution for others to reuse), and thus has more documentation and momentum.
F-Droid on the other hand also includes build system for its packages, albeit simple/limited one (e.g., entire recipe is written in one line).
All in all, it's great that there're such solutions for Android, and pity that that they are relatively hard to find, they should be published more, that will contribute to overall software quality on Android platform.
How it all started: F-Droid Repository Vapourware
Critical review of build systems
Last time I looked at possible alternatives to OpenEmbedded, I mostly looked at how many packages they support, how many architectures/OSes, and how easy is to add overrides. Of course, OpenEmbedded outperforms any other generally available build system in these respects.
But still, while the idea of grand unified build system is very cool, maybe it would be easier to add/extend support for some non-Linux OS to some other build system? (As OE is targetted at Linux.) Let's see.
GUB
This software tries to steal "grand unified" motto, though so far it has 200+ packages, but supports Windows. Recipes are structured as Python classes, overrides are handled like:
One thing which immediately catches eye is "def patch (self)". Yeah, Python doesn't let people play with curlies, but they'll go out fo their ways with braces. Recipes-classes do allow deal of declarativeness, for example, in specifying patches, and yet there're stuff like:
def patch (self):
self.system ('''
cd %(srcdir)s && patch -p1 < %(patchdir)s/busybox-mkconfigs.patch
''')
Summary: Violates standard codestyle for target language (PEP8), breaks declarative vs imperative metadata separation.
mingw-cross-env
Targets mingw32 (only). Doesn't support DLLs. Uses .mk for recipes. Both recipes and other files (patches, etc.) lie in one flat directory. Recipes look clean, but one target and no sharedlibs is trivial case on its own.
But still, while the idea of grand unified build system is very cool, maybe it would be easier to add/extend support for some non-Linux OS to some other build system? (As OE is targetted at Linux.) Let's see.
GUB
This software tries to steal "grand unified" motto, though so far it has 200+ packages, but supports Windows. Recipes are structured as Python classes, overrides are handled like:
class Ctypes__mingw (Ctypes):
One thing which immediately catches eye is "def patch (self)". Yeah, Python doesn't let people play with curlies, but they'll go out fo their ways with braces. Recipes-classes do allow deal of declarativeness, for example, in specifying patches, and yet there're stuff like:
def patch (self):
self.system ('''
cd %(srcdir)s && patch -p1 < %(patchdir)s/busybox-mkconfigs.patch
''')
Summary: Violates standard codestyle for target language (PEP8), breaks declarative vs imperative metadata separation.
mingw-cross-env
Targets mingw32 (only). Doesn't support DLLs. Uses .mk for recipes. Both recipes and other files (patches, etc.) lie in one flat directory. Recipes look clean, but one target and no sharedlibs is trivial case on its own.
Sunday, February 27, 2011
WM8505 (VT8500, WM85xx) hacking timeline
I've got my hands on cheap WM8505-based Android tablet, figuring out how open to hacking it is, as usual, the information is fragmented and outdated, so I'm going to try and compile timeline:
- 2010-05-28 Alexey Charkov makes first commit to the tree hosted at http://gitorious.org/linux-on-via-vt8500
- 2010-06-03 Alexey Charkov registers http://gitorious.org/linux-on-via-vt8500
- 2010-06-03 Angus Gratton's first blog post on Eken M001, Eken M001 Android tablet review (Pt 1)
- 2010-06-10 Angus Gratton Notes on porting Android 2.x to Eken M001 Discusses the fact the Android userspace was patched to use libwmtapi.so
- 2010-06-22 Angus Gratton Eken M001 teardown & serial console Show good internal pictures (in particular, "WM8505" lebel on CPU).
- 2010-06-13 created topic Kernel source almost available
- 2010-07-27 Harald Welte released initial packages from VIA, with binary objects for video and SD/MMC drivers
- 2010-07-28 Angus Gratton's follow-up on inial VIA release
- 2010-08-01 Angus Gratton created topic WM8505 linux kernel development (for Eken M001 & others).
- 2010-08-01 https://github.com/projectgus/kernel_wm8505 created
- 2010-08-06 Alexey Charkov invites Angus Gratton to join forces on clean implementation of wm850x support at http://gitorious.org/linux-on-via-vt8500/vt8500-kernel
- 2010-08-13 Harald Welte posts about making Android 2.6.29 kernel source available. That tarball actually has C source in drivers/video/wmt .
- 2010-08-18 Angus Gratton announces (blog) creation of VT8500/WM8505 Linux Kernel Google Group. "Kernel discussion seems to have running in a few different places concurrently, especially between netbook & tablet people."
- 2010-09-16 Angus Gratton created topic Testing: Custom kernel with cpu frequency scaling/overclock enabled.
- 2010-11-24 Angus Gratton: Froyo (Android 2.2) alpha for Eken M001 & M003
- https://github.com/projectgus/kernel_wm8505 - import and cleanup of original VIA sources, maintained by Angus Gratton
- http://gitorious.org/linux-on-via-vt8500 - from-scratch and cleaned up implementation maintained by Alexey Charkov
- https://github.com/bushing/android_wm8505 - just a few commits, last 2010-06-03, apparently superseded by other repos
Thursday, February 17, 2011
Ubuntu, somebody's favorite Linux-based distribution
Well, to get into the hype, I've installed Ubuntu 10.10 on new Asus X34F. Here's floating post what tweaks I did to get it into shape.
First note about all those "Herons" and "Lucids". Who said word-based versions are better than number-based? Words are better than numbers when they have meaning, and that's not the case with version numbers. So, as my mind is not going to waste its cycle on remember that stuff for some more time yet, note to myself: 10.10 == Maverick.
First note about all those "Herons" and "Lucids". Who said word-based versions are better than number-based? Words are better than numbers when they have meaning, and that's not the case with version numbers. So, as my mind is not going to waste its cycle on remember that stuff for some more time yet, note to myself: 10.10 == Maverick.
- -Replace dark-strange-buttons-god-knows-where default theme with Clearlooks. And don't even let me start about wallpaper...
- Fix suspend issue due to usb host module (give link to forum)
- Make mc stop pretending it's running on 50-years old tty and do Esc key well.
- Get bitmap fonts to be available for selection: remove /etc/fonts/conf.d/70-no-bitmaps.conf symlink which rules them out, and instead link 70-force-bitmaps.conf (yes, there's 70-yes-bitmaps.conf, but who wants to check if they'll listen if asked politely, granted that they managed to disable classy fonts at all).
- Set nice bitmap font for Gnome Terminal, because you don't want to file your eyes with anti-aliased vector novelties on a color background. We need classical "Fixed" font from X11's package fonts-misc-misc. For reference, one of font files is /usr/share/fonts/X11/misc/10x20.pcf.gz . When selecting this font for console, make sure to try different sizes: there's some weird substitution for some of them - instead of nice-looking sans-serif there's serif popping up. "Fixed 16" what worked here on X34F (same real size is "Fixed 20" on nx9420/Gentoo, probably because of different dpi or something).
- Uncommented net/ipv4/ip_forward=1 in /etc/ufw/sysctl.conf
- NO FIREWALL AFTER DEFAULT INSTALL?! https://help.ubuntu.com/community/UFW : "By default UFW is enabled but all ports are left open (otherwise there would be no Internet access following installation)." It's only on Ubuntu "not all ports open" means "no Internet access". They've got to learn that ports may be incoming and outgoing. Set incoming to Denied.
- Anyway, figured out masquerading. It's a shame it cannot be configured by simple rule and in GUI. It's outdated to think masquerading is only needed for router box, nowadays it's needed to give net access for sart devices, virtual machines, etc. The problem I had was that even after setting up masquerading per Ubuntu guide, I couldn't ping google. Well, the VM used physical Ubuntu box as DNS, so I had to add rule to enable incoming port 53.
- Where's my hibernate?
Tuesday, February 15, 2011
Xara Open Source - Sleeping Beauty
So, Xara showed that you can do great software if you like, to stand out of the crowd and make a difference. I remember it since then. And today I found out that Xara was open-sourced! "They must be crazy to have done that" - was first thought which occured to me when I saw the site. But this is fairytale, remember, and evil sourcerers must have kept me in parallel world - it turned that happened long ago, the first wave of commercial companies opening up their projects, and it had been dead few years by now, and epithaph written. So, they weren't mad after all, they didn't open up their low-level graphics lib which on 100MHz behaved better than Adobe Flash does now on 4-core 2GHz CPU. And community guys were too lazy to port it to multitude of other graphics engines, so project's dead.
But what amazes me is that open-source site is up and nicely running, docs are there, etc. just timestamps are old. And mailing lists are quiet. And the temple is full of ancient scrolls suggesting checking if SVN works by telneting to a port. Hush, this is fairytale. It's all working, it's not dead, it's sleeping. Sleeping Beauty.
So, apparently, as the site is running smooth, the company apparently does well. I checked Wikipedia - they do, and keep amaze their users (content-based bitmap resizing is what I saw with a corner of my eye). I don't know how to treat this case. I can't say "better they wouldn't have opened it up". I can't say "they must have opened up their gfx lib". It's not the case that everything should be open, and such applied software as Xara clearly should bring its owners a direct value. So, I better be amazed by Xara and its creators for the second time, it's nice to know they have tried. Not only they tried - they did it. I installed it on Ubuntu and it looks and works great, even though it's not maintained much any longer (well, there's Ununtu developers' merit to that too).
What amazed me is that, even though I tried, I found no attempts to resurrect it. Well, I found this, but it didn't get much beyond changing a preference dir name. It also used some ancient systems like SVN and imported some history-less archives. Well-well. I'm finishing git svn clone now, to push to gitorious, for git be more comfortable bed for the sleep...
https://gitorious.org/xaralx
UPDATE 2012-10: There's revived project to port Xara to Cairo: https://github.com/eradman/xara-cairo
Sunday, February 6, 2011
Hacking Osram NightLux
Ok, this blog had "DIY" included on reload, so here's a bit of it. (By "DIY" I mean hardwarish hacking, real-world directed mostly.)
For smarthoming purposes, I wanted to stick around my apartment LED motion-activated lights. Because it sucks to push the buttons of course. My requirements were: 1) LED; 2) motion-activated; 3) light-activated (works only at night); 4) thresholds adjustable; 5) battery-powered, so worked on power outages; 6) actually, accumulator-powered with builtin charger for technology to serve me, not me serving technology. Alas, as usual, it's "choose 2 of 3" thing. The best I could find were Osram's NightLux and SpyLux. The first one is floodlight-like, the second is flashlight-like. Well, they don't have builtin charger and - worst - don't have adjust knobs! The only control they have is off-10s delay-60s delay-always on.
And the light sensor threshold is actually pretty high - not facing a window, it starts to light just on cloudy weather. So, I went inside to see if knobs are there - no. What a shame for otherwise great product! But I found that light sensor actually looks into plastic covers, only slightly lighted by nearby PIR window. So, the hack for 1st NightLux was purely mechanical - I cut with my Dremel-like plastic inside which shadowed sensor. It helped. But I had to put it near the ceiling directly facing the bulb, because when it hanged on a fridge it still turned on couple of times until eco-bulb warmed up.
Well, I want to put the 2nd one in the hallway, where there's no direct window light at all. I could try drilling cover and exposing sensor, but have doubts such bad aesthetics would still help. So, I've set for real hardware hack this time, even if risking to brick it. The idea is to identify type of light sensor (photo-diod, photo-transistor, etc.) and resistor which passes current from it, then use old trick to either gently file it to increase resistance, or short-circuit with something to decrease.
I looked at the board more closely - it has small chip, marked M7616. Well, I am lucky, it's not custom one, datasheets are available.
(to be continued)
Wednesday, February 2, 2011
Monday, January 31, 2011
Links for January 2011
- mbed.org - Kind of Arduino for NXP microcontrollers. There are interesting algos, like JTAG Search.
- nookdevs.com - Hacking B&N Nook eReaders. For example, NookColor Hardware specs.
- novaports.org - Another embedded/Android/Nook hacking portal, features destructive teardown.
- http://wiki.osdev.org/ - OS Development Encyc
- Open Source J2ME software
Friday, January 21, 2011
And the winner is...
After problem with MSI X430 described in earlier post, I kept shopping. There were few interesting contenders. By chance I saw in the shop a ViewSonic ViewBook Pro VNB131. I didn't even consider a ViewSonic to be a company to consider notebooks from, but they keep providing surprises. The screen immediately catches attention - it's truly bright and vivid, unlikely washed-out generation of current inexpensive notebook screens. And in around 1.6kg they managed to cramp even easily-replaceable DVD. Which is a brilliant ... drawback, in the same way as big battery in notebook is ;-). DVD in my nx9420 is amost dead now, hardly reading every 5th disk I put into it (which is rare nowadays).
Well, anyway, VNB131 is outstanding device (they even promise all-aluminum frame), exactly of that type that you notice, keep in mind, and when finally you want to get one few months later - oops, it's no longer around. The reason I skipped it was that I got idea of L335 performance, and looked up Core2 ULV (used in VNB131) performance - it turned out it's not much better than 5-year old Toshiba M200 which I have. As I got idea taht i won't get anything decent for $500, I decided to shell out more, but get something noticeably powerful than even nx9420.
And the winnder was Asus X34F, which just recently got into stock around. X34F is a strange device, there was no info about it on Asus site. No reviews on the net. Googling just gave lot of pricelist hits clustered for some locality, giving good, though sometimes controversial specs. After extensive research, it turned out it's a U35F spinoff for these localities. Afre finally spotting an instance in a physical shop, I've ordered it and it seems everything is right with it. Funny thing, scrolling with touchpad again doesn't work with Ubuntu 10.10 (device otherwise sells with just FreeDOS). But I have high hopes and trust Asus not to stick films advertising 2-finger scroll on an unsupporting touchpad. Just Linux driver needs upgrade or maybe hacking. After all, I already fixed (thanks to forums) hang-on-suspend issue which at first occured.
Well, anyway, VNB131 is outstanding device (they even promise all-aluminum frame), exactly of that type that you notice, keep in mind, and when finally you want to get one few months later - oops, it's no longer around. The reason I skipped it was that I got idea of L335 performance, and looked up Core2 ULV (used in VNB131) performance - it turned out it's not much better than 5-year old Toshiba M200 which I have. As I got idea taht i won't get anything decent for $500, I decided to shell out more, but get something noticeably powerful than even nx9420.
And the winnder was Asus X34F, which just recently got into stock around. X34F is a strange device, there was no info about it on Asus site. No reviews on the net. Googling just gave lot of pricelist hits clustered for some locality, giving good, though sometimes controversial specs. After extensive research, it turned out it's a U35F spinoff for these localities. Afre finally spotting an instance in a physical shop, I've ordered it and it seems everything is right with it. Funny thing, scrolling with touchpad again doesn't work with Ubuntu 10.10 (device otherwise sells with just FreeDOS). But I have high hopes and trust Asus not to stick films advertising 2-finger scroll on an unsupporting touchpad. Just Linux driver needs upgrade or maybe hacking. After all, I already fixed (thanks to forums) hang-on-suspend issue which at first occured.
Friday, January 14, 2011
Samba and iptables UDP broadcast issues
Have been having issues with browsing Samba from Windows boxes or vice-versa for years, like me? No wonder - just google for "ip_conntrack_netbios_ns site:samba.org". See? It's not documented or even mentioned that that kernel module must be loaded for NetBIOS broadcasts to get thru firewall, except for one recent post, even though the issue was raised and solved 5 years ago: https://bugzilla.redhat.com/show_bug.cgi?id=113918 .
Wednesday, January 5, 2011
Notebook MSI X430 (aka X420 aka X410) - Big Disappointment
So, I've been shopping for notebook for some time - my current work model, HP Compaq nx9420, has been failing me for like 1.5yrs now, with its lid hanging on just one corner (the steel support plate in there broke, nice job, HP!). I also grew pretty tired to carry it's 3.3kg around, so was shopping for subnotebook. So, criteria was: minimal weight, workable screen size (12" is kinda small, 14" is kinda heavy, those are extreme bounds), budget price (also tired to shell out a grand+, especially that nx9420 shows that no matter how much you pay, you have strong chance to get budget quality nowadays).
I had Acer Timeline t3810 (or something close) in my shopping list, but was swamped by real world, so when I came closer to actual shopping - oops, that model is no longer available. That's another trait of modern hardware market - it's not like good stuff gradually becomes cheaper and better stuff comes in, it's like good stuff being replaced by more expensive and mediocre one.
So, I started looking for another replacement, and I found MSI X430. Gosh, it was brilliant. They cramped 14" in 1.5kg - there was/is no competitor in that regard. Battery life was crap (~2hrs), but that's actually brilliant engineering thought. Because laptop battery doesn't last "X or Y hours", it lasts untill next hot summer - when it completely dies. So, it makes little sense to pay lot for large battery which will anyway die soon. So, thanks to that nice crappy battery, X430 costed just $500 (my ideal upper bound for a contemporary piece of technical stuff), it made decent weight to of course. The performance wasn't great, but at least it had latest AMD X2 which has come to these vicinities, L335.
Guess what - when I started to actually call shops, it turned out the model went out of stock like a week ago. Yes, it was on hot sale the whole summer, and boom, suddenly there's only X410 & X420 which are less performance and/or much more pricey. Well, I waited a bit, and oh, miracle - one shop got it back.
Got it in a day, just to find out that:
No, I will not. I'm not keen on returning stuff, but that box went back to the shop. And I even wrote this blog post ;^).
I had Acer Timeline t3810 (or something close) in my shopping list, but was swamped by real world, so when I came closer to actual shopping - oops, that model is no longer available. That's another trait of modern hardware market - it's not like good stuff gradually becomes cheaper and better stuff comes in, it's like good stuff being replaced by more expensive and mediocre one.
So, I started looking for another replacement, and I found MSI X430. Gosh, it was brilliant. They cramped 14" in 1.5kg - there was/is no competitor in that regard. Battery life was crap (~2hrs), but that's actually brilliant engineering thought. Because laptop battery doesn't last "X or Y hours", it lasts untill next hot summer - when it completely dies. So, it makes little sense to pay lot for large battery which will anyway die soon. So, thanks to that nice crappy battery, X430 costed just $500 (my ideal upper bound for a contemporary piece of technical stuff), it made decent weight to of course. The performance wasn't great, but at least it had latest AMD X2 which has come to these vicinities, L335.
Guess what - when I started to actually call shops, it turned out the model went out of stock like a week ago. Yes, it was on hot sale the whole summer, and boom, suddenly there's only X410 & X420 which are less performance and/or much more pricey. Well, I waited a bit, and oh, miracle - one shop got it back.
Got it in a day, just to find out that:
- Max amount of memory ambgiously (not explicitly) mentioned in the docs is 2Gb. Come on, this is not netbook, which 2Gb?? And it doesn't have dedicated RAM cover to easily try 4Gb module - would need to disassemble it completely (either void warranty or go to service center - with what - 4Gb SODIMM I purchased not knowing if it works or not?)
- Booted Ubuntu 10.10. Got complete mess on the screen, more specifically torn off signal sync. Remember how old CRT TVs looked with broken row sync heterodyne? I couldn't even imagine that effect can be so faithfully reproduced on LCD panel! I was able to found just single report of someone else facing that, did some hacking, found a workaround, and then thanks to DRM driver people found easy solution. So, well, that DRM/Ubuntu issue, though, taking into account all points above and below, MSI engineers outwitted themselves too. (Support for such funky videoadapeters, as in X430, will be (was) fixed in next kernel version).
- One final point which really put me over the edge and made me return the thing. Its touchpad doesn't support scrolling. Well, to be exact, it does, in a following manner: you have to tap at top right corner to scroll up, somewhere near bottom right corner to scroll down. So yes, you had to target the tap, and target pretty carefully, requiring an eye-look. How that compares with familiar blind swipe near the right side? If that sounds like a petty complaint, you've got to use that yourself! Remember, I started all ecstatic about the box, and that dissatisfaction grew subconscious ways. It's like making you walk on the knees. Many people would say "So what? Connect any mouse you like, voila!" Well, but I'm buying a subnote to be light and lean and not carry extra stuff, and still being able to use it comfortably. If to start bringing around crutches everywhere, why bother with lack of selection, higher price, lower performance of subnote? Well, I started to drop into any notebook shop I saw in city motion and know what - all notebooks out there have sane touchpad scrolling, newer ones brag about multi-touch (2-finger) scrolling with stickers, couple of MSI models were the only ones with such brain-dead scrolling. I finally made a search over the Internet. And found dozen-of-pages hate-topics regarding MSI's touchpads. People go by any length to do something with them, like soldering out that thing and solder in normal touchpad.
No, I will not. I'm not keen on returning stuff, but that box went back to the shop. And I even wrote this blog post ;^).