OpenEZX

After almost one year of fixes and new functionalities here is libam7xxx-0.1.3. libam7xxx is a library to communicate with USB pico-projectors like, for instance, the Philips/Sagemcom PicoPix devices; you can read more about it in the previous ... [More] stories: On USB projectors, linux and libam7xxx An Open Source driver for USB pico projectors The devices supported in this release are: Acer C110 Acer C112 Aiptek PocketCinema T25 Philips/SagemCom PicoPix 1020 Philips/SagemCom PicoPix 2055 With this release PicoPix 1020 and 2055 are finally fully working, thanks to the people who helped fixing and testing the code, here is the entry from the NEWS file: News for v0.1.3: ================ * Better documentation * Ported to Windows (compiles with MinGW) * Added a minimal replacement of usb-modeswitch to use on systems where the latter is not available * Added support for Acer C112 (Thanks to Richard Wisenoecker) * Added support for Aiptek PocketCinema T25 (Thanks to Matti Koskinen) * Added some contrib scripts * Added support for setting the projectors zoom mode * Added multi-device support, now more than one projector can be used at the same time on the same system (Tested by Konstantin Lohmann) * Added support for Philips/SagemCom PicoPix PPX 2055 * Fixed some problems with the supported Philips/SagemCom PicoPix devices, now these devices are fully working (Thanks to the Certik family) Debian packages for i386 and amd64 are available at ao2.it/debian. If anyone knows people at Sagemcom, would you put me in contact with them? They didn't reply to my previous messages to their support service address. I'd like to ask if they may be interested in providing some test units or to sponsor some development-time to make the pico-projectors work on Android. Here is the shortlog between v0.1.2 and v0.1.3 for those interested in the development details: Antonio Ospite (60): picoproj: add a note about image dimensions and native resolution Merge remote-tracking branch 'origin/rettichschnidi' into mingw-port HACKING.asciidoc: fix cmake invocation examples picoproj: use MAP_PRIVATE in the mmap call am7xxx: use hex notation for USB endpoints am7xxx: fix setting the USB configuration am7xxx: MinGW does not have endian.h, provide fallbacks am7xxx: don't look for the math library when compiling for Windows picoproj: issue a warning when passing "-f" more than once picoproj: fix a typo picoproj: replace mmap() with more portable file stream operations Don't set -pedantic-errors in CMAKE_C_FLAGS, it breaks check_symbol_exists() Add a CMAKE_TOOLCHAIN_FILE to compile with MinGW HACKING.asciidoc: add a section to explain Windows cross compilation Merge branch 'mingw-port' TODO: mention the plan about GStreamer Add a simple usb_mode_switch clone for am7xxx devices README.asciidoc document how to get libam7xx running on MS Windows README.asciidoc: add Royaltek PJU-2100 to the AM7XXX based devices list HACKING.asciidoc: add info about getting and building libam7xxx mingw_cross_toolchain.cmake: set the MINGW variable to True am7xxx-play: get the framerate from the video stream am7xxx-play: add a fallback definition for ENOTSUP am7xxx-play: check if sigaction is available am7xxx-play: check if strtok_r is available HACKING.asciidoc: add info about compiling am7xxx-play for Windows README.asciidoc: add info about running am7xxx-play.exe on Windows README.asciidoc: add Aiptek PocketCinema T25 to the AM7XXX devices list am7xxx: rename am7xxx_header.unknown0 to am7xxx_header.direction doc: update the list of supported devices contrib: add other supported devices to 55-am7xxx.rules contrib: add an example of how to start displaying images automatically Merge remote-tracking branch 'origin/rettichschnidi' am7xxx: implement support for the AM7XXX_PACKET_TYPE_ZOOM picoproj: support setting the zoom mode am7xxx-play: support setting the zoom mode am7xxx: update signature and documentation of am7xxx_set_power_mode() picoproj: make the help about power mode more consistent am7xxx-play: make the help about power mode more consistent contrib: add a test image to show how zoom modes work Merge branch 'am7xxx_set_zoom_mode' doc: update Doxygen configuration examples: support multiple devices am7xxx: add support for Philips/SagemCom PicoPix PPX 2055 picoproj: clarify that when AM7XXX_ZOOM_TEST is set no image gets sent am7xxx: print text description of the 'direction' field am7xxx: assign device_list next to its first use am7xxx: add a note on the symmetry of read_header() and send_header() am7xxx: don't mention AM7XXX_DIRECTION_OUT in read_header() Fix an error when compiling with both -O0 and -Wp,-D_FORTIFY_SOURCE=2 am7xxx: detect unexpected responses to AM7XXX_PACKET_TYPE_DEVINFO requests am7xxx: cache device info in am7xxx_get_device_info() am7xxx: make libam7xxx work with Philips/Sagemcom PPX projectors Merge branch 'fix-devinfo-for-PicoPix' contrib: add the am7xxx-play-window.sh script am7xxx: fix coding style am7xxx-play: rename 'packet' to 'in_packet' am7xxx-play: remove an unreachable break am7xxx-play: switch to avcodec_encode_video2() Release version 0.1.3 Matti Koskinen (1): am7xxx: add support for Aiptek PocketCinema T25 Reto Schneider (5): Make example programs optional. Stop CMake if function avformat_open_input not available, print an error message. Prevents compile errors later on. Fix usage of FIND_PATH, allow $FFMPEG_DIR to be used. Fix typo. Add missing break. Richard Wisenoecker (1): am7xxx: add support for Acer C112 [Less]

A blood pressure meter with a USB port happened to land into my hands, only Windows was supported for downloading data to a PC, and I wanted to see how the device interacted with the software and try to “free” it so that it could be used elsewhere. ... [More] The device is a Visomat Double Comfort, IMHO it is overpriced already (note, with no backup battery to keep the clock when you change the main batteries), and the limitation on what software you could use to access your data was upsetting. The result of my efforts to make it more accessible can be found in the visomat-utils repository, in the README there are some details about the communication protocol and the data format used by the device. The user manual of the device says that when connected to the PC the unit cannot perform pressure measurements, well this is not completely true, there is a command to start a new measurement via USB, however I didn't find how to restore USB communication after the measurement. BTW, if anyone find a creative use of a USB triggered air pump, let me know :). I didn't feel like tearing the device apart and dump the firmware, as I am not the owner of the device, but maybe some more commands can be found by looking there. Design decisions The original developers decided to expose the device as a USB CDC (in the ACM variant) and then use a custom protocol over USB bulk messages, that makes it necessary to install some CDC drivers on Windows even if the serial interface is not actually used. IIRC an alternative way to use custom USB protocols on Windows is to use fake HID devices, which do not require the user to install any drivers, anyone more into Windows can confirm that? Final words I've seen that there are more open and cheap blood pressure meters, like the ewh-bp-project. Does anyone know if device like that are already in production or if there are similar alternatives to recommend? [Less]

I've uploaded a simple wrapper around sudo, for executing commands as another user with full access to the X display (GLX works too); I call it xudo. The script basically does two things: Authorize the user: xauth extract - $DISPLAY | sudo -u ... [More] SOMEUSER xauth merge - Run the command preserving the DISPLAY environment variable: sudo DISPLAY="$DISPLAY" -u SOMEUSER SUDO_OPTIONS And you can of course use the -i or -s sudo options to get a shell as the other user, from where you can launch graphical applications. All the other bits in the script are really just boilerplate. Keep in mind that security-wise this is indeed a little stricter than the xhost +local: and xauth generate combination, as it authorizes only the user you want, but the command you execute still gets access to the whole X server, so you still don't want to run programs you don't trust using this method. [Less]

Hi folks! Obviously I don’t manage to update this blog more than a few times a year. I must confess that – for smaller status messages – I find Facebook and Twitter working quite well. So if you want to stay in touch a bit more, hop over to my page ... [More] @ Michael Lauer or follow my Tweets @ DrMickeyLauer. The biggest tasks this year was getting Lara Marie to sleep well and buying a house, both which we finished successfully. Right now we have a hole in the ground, but it’s supposed to be finished by October 2013. I’m going to report about the progress now and then. FOSS-wise I didn’t manage to do anything meaningful more than visiting FOSDEM and the OHSW this year. I tried to catch up with what’s happening in FSO, Vala, and OpenEmbedded though. Since I do no longer use OE on a frequent basis, I decided to not run for re-election as OE board member, thus also resigning from being OE e.V. president. I’m quite happy to hand the paperwork over to someone else With Lara Marie growing older (she’s now 18 months), I enjoy being a father more and more. While mommy was #1 in the first year, it becomes apparent that I’m #1 in the 2nd year, helping the little one to form her individuality and her will. Company-wise 2012 was a bit of a ride as due to the economy some of our biggest clients postponed their app updates and we struggled a bit getting enough contracts to keep the four of us busy. Then again, we worked on our own apps in the free time and I’m happy to announce the next major version of Volksradio / Just Radio, which is going to ship soon. I wish all of you a merry 2013! Yours, Mickey! [Less]

Have you ever typed suod instead of sudo? I do that quite often; maybe I am becoming typing dixleysc, who knows. Context: Debian Gnu/Linux using the bash command line shell and bash-completion. The problem is: execute sudo when suod is typed. A ... [More] trivial solution would be to put in place a shell alias: alias suod='sudo' it makes sense, but command line completion will not be available. This can be worked around by setting up the same completion function of the aliased command for the aliasing one: source /usr/share/bash-completion/completions/sudo complete -F _sudo suod this is nice, but not enough for me, it is still lacking “cross-alias” history completion in case the wrong version is typed only sometime; and history completion is the greatest thing since... you know. Or, readline key bindings can be abused to implement an auto-correction functionality at the shell level. The problem is about a typo, after all. For that purpose this variant of key bindings will be used: KEYSEQ: STRING_MACRO Either the following can be put in ~/.inputrc: "suod": "\C-vsudo" or the bash builtin command bind can be invoked from ~/.bashrc: bind '"suod": "\C-vsudo"' Now every time the suod key sequence is typed in, it will be replaced automatically with sudo on the command line. The \C-v sequence calls the quoted-insert function which tells readline that the following character —namely s— has to be taken verbatim, this is needed to avoid that the s key is considered as the start of a macro expansion itself messing up the end result. This solution is good enough for me, as I get history completion. Maybe there could be downsides too: the expansion happens at any point in the line; there could be conflicts if many of these typo-fixing-hacks share letters one another; the possible issues could be alleviated by prefixing each character in the macro string with the sequence for quoted-insert. SIDE NOTE Unrelated, but while googling around I've found out how to have aliases executed in a sudo context by using this alias: alias sudo='sudo ' Check out the Aliases section of the bash manual for the complete explanation. [Less]

Support for the Digicom Digitune-S DVB-T USB stick will land in linux 3.9, the patch I sent was accepted along with other small refactorings. The adapter can also be found under these names: Twinhan/Azurewave DTV-DVB UDTT7049 Think Xtra ... [More] Hollywood DVB-T USB2.0 A dump of the USB communication of the Windows driver is attached, it was captured using SniffUSB 2.0 and it can be made more readable using the parse-sniffusb2.pl tool from v4l-utils. I used the dump also to figure out some details about the hardware: before writing any code I had to know what hardware components the adapter was using; the USB bridge (ULi M9206) and the frontend (MT352CG) could be seen clearly when opening the plastic case, but the tuner was protected by a metal shield and I couldn't easily find out what it was by reading the labels printed on the chip, so I tried to look at the USB communication to see if there were any clues, in particular these bits were useful: 40 23 c0 00 80 00 00 00 >>> 40 23 00 00 00 00 00 00 >>> 40 23 c1 00 80 00 00 00 >>> c0 23 00 00 60 00 01 00 <<< 63 I thought they had something to do with some chip identification, and in fact by following the m920x driver code you can derive that this communication means more or less: “read the register at address 0x00 of the I2C device at address 0x60”; the returned value was 0x63 and by grepping through the kernel code for that value this turned out to be the same value used in the mt2060 driver for the PART_REV constant, that was enough to understand what tuner the device was using and make the jigsaw complete. At that point adding support for the adapter was easy as all the drivers of the single components were already in the kernel, even the remote control mapping was there: separation of responsibility and modularity are good; what a surprise, eh? The firmware was extracted from the USB dumps too, by first using parse-sniffusb2.pl: $ v4l-utils/contrib/parse-sniffusb2.pl usbsnoop-digicom-digitune-s-dump.log_ > parsed-Digitune-S-dump.log and then by runing m920x_parse.pl on the pre-processed log with this command line: $ perl v4l-utils/contrib/m920x/m920x_parse.pl -i us2 -m fw < parsed-Digitune-S-dump.log $ mv fw dvb-usb-vp7049-0.95.fw While testing the adapter I've found out that signal reception improves when the little antenna with the magnetic base is on top of some metal object, I put mine on top of a candy tin box and I can get a few more channels, from what I read the physical principle that makes this work is the one of the ground plane of a monopole antenna. Note to world: if you want any hardware of yours to be working under linux, just find a way to have some kernel hackers put their hands on it; the rest will come by itself. Attached files:  Firmware for the vp7049 DVB-T USB stick Digicom Digitune-S UsbSnoop dump [Less]

I was planning on “playing” with a certain device, so I wanted some adapter which allowed me to interface with the device at a low level to facilitate the information gathering phase in the hacking process. I wanted something to connect to UART ... [More] signals, and a JTAG port and maybe something able to program SPI flash chips too; Marek Vasut suggested I should pick up something based on the FT2232H IC, after a round of research I settled on a TUMPA; it arrived some days ago. Testing TUMPA under Linux The TUMPA manual is more than OK, but some more specific info about linux can still be useful. UART The FT2232H has two serial channels (A and B), on the TUMPA only channel B is dedicated to UART communication, either as TTL signals or as a full RS-232 interface. Using the TUMPA for a naked serial connection/console works fine, the linux ftdi_sio USB-serial driver can be used for that, the module can be loaded passing the vendor and product options to it: $ sudo modprobe ftdi_sio vendor=0x0403 product=0x8a98 In this case two new device nodes show up, in my case they are /dev/ttyUSB0 and /dev/ttyUSB1, the latter corresponds to channel B. Alternatively a patch to add direct support for TUMPA to ftdi_sio is available and will hopefully be added to linux-3.7, with this mechanism only one new device node shows up (/dev/ttyUSB0 here) which is mapped to channel B (channel A is reserved to JTAG/SPI1 on the TUMPA). [ 211.848085] usb 2-2: new high-speed USB device number 3 using ehci_hcd [ 211.996305] hub 2-0:1.0: unable to enumerate USB device on port 2 [ 212.452090] usb 4-2: new full-speed USB device number 3 using ohci_hcd [ 212.652083] usb 4-2: not running at top speed; connect to a high speed hub [ 212.672078] usb 4-2: New USB device found, idVendor=0403, idProduct=8a98 [ 212.672086] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 212.672092] usb 4-2: Product: TIAO USB Multi-Protocol Adapter [ 212.672098] usb 4-2: Manufacturer: TIAO [ 212.672103] usb 4-2: SerialNumber: XXXXXXXX [ 212.770697] usbcore: registered new interface driver usbserial [ 212.771255] usbcore: registered new interface driver usbserial_generic [ 212.771835] USB Serial support registered for generic [ 212.771850] usbserial: USB Serial Driver core [ 212.791528] usbcore: registered new interface driver ftdi_sio [ 212.792885] USB Serial support registered for FTDI USB Serial Device [ 212.794682] usb 4-2: Ignoring serial port reserved for JTAG [ 212.794755] ftdi_sio 4-2:1.1: FTDI USB Serial Device converter detected [ 212.797208] usb 4-2: Detected FT2232H [ 212.797217] usb 4-2: Number of endpoints 2 [ 212.797224] usb 4-2: Endpoint 1 MaxPacketSize 64 [ 212.797229] usb 4-2: Endpoint 2 MaxPacketSize 64 [ 212.797235] usb 4-2: Setting MaxPacketSize 64 [ 212.808428] usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 212.808477] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver After connecting the interface to the target device, the serial console on the device can be accessed using minicom: $ minicom -D /dev/ttyUSBX SPI I tested the SPI interface using a chip from an old motherboard I had lying around, it is a MX25L8005, I just needed to make the connections: and use flashrom which already has support for both the TUMPA and the MX25L8005: $ sudo flashrom -p ft2232_spi:type=tumpa,port=B -r flash.bin flashrom v0.9.6.1-r1563 on Linux 3.6.0-rc5-ao2 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found Macronix flash chip "MX25L8005" (1024 kB, SPI) on ft2232_spi. Reading flash... done. I2C, GPIO and bit-banging FTDI chips are quite flexible, they can operate in a mode called Multi-Protocol Synchronous Serial Engine (MPSSE) which can be used to talk to I2C devices, or to set up some chip lines as GPIO pins, or for bit banging. I used MPSSE via libmpsse to read data off a 24C16 EEPROM, the mapping can be derived by joining the different documents about MPSSE Basics, MPSSE Commands and TUMPA manual, a table is following for convenience: JTAGTUMPA-jtagFT2232HMPSSEI2C TCKpin9ADBUS0TCK/SKSCK TDIpin5ADBUS1TDI/DOSDA TDOpin13ADBUS2TDO/DISDA TMSpin7ADBUS3TMS/CS RSTpin15ADBUS4GPIOL0 nTRSTpin3ADBUS5GPIOL1WP DBGRQpin17ADBUS6GPIOL2 RTCKpin11ADBUS7GPIOL3 DBGACKpin19ACBUS0GPIOH0 ACBUS1GPIOH1 ACBUS2GPIOH2 ACBUS3GPIOH3 And here is the final wiring to read an EEPROM via I2C: With the GPIO mode I was also able to test a trivial circuit with a LED and a resistor and make the LED blink controlling the delay via software using libmpsse. I don't know if MPSSE mode can be used to flash programs to PIC microcontrollers too, the PICPgm mentions a USB interface based on an FTDI chip but I didn't go deeper into the matter. Reading the FTDI eeprom on TUMPA The FTDI chip stores some info into an internal EEPROM, this one can be read (and flashed) using ftdi_eeprom from libftdi (NOTE: bash command line): $ ftdi_eeprom --read-eeprom <(echo -e "vendor_id=0x0403\nproduct_id=0x8a98\nfilename=TUMPA-eeprom.bin") The official utility to deal with the FTDI eeprom is the closed source FT_PROG. Final words Now that I know something more about FT2232H I think I can compare the TUMPA to simpler solutions like the basic FT2232H Mini Module: On the plus side, having dedicated connectors for SPI, JTAG and TTL/RS232 on the TUMPA speeds up the connections as that avoids keeping track of the pin mapping each time. On the other hand I note that the TUMPA does not make it easy to access all the FT2232H lines, which is limiting especially in MPSSE GPIO mode. I will update the article when I get a chance to test the JTAG functionality. [Less]

Xin He from Amlogic informed me that the linux kernel source code for their AML8726-MX SoC has been released: Hi Antonio, Amlogic just posted MX kernel source code (branch ics-mx-develop) on openlinux. Here is the ... [More] link:http://openlinux.amlogic.com/download/linux/GPL_code_release/2012-08-03/kernel-common-2012-08-03-git-a63244fb9c.tar.gz AML8726-MX (code named MESON6) is the base of a lot of Android tablets from Chinese system integrators/distributors, like the ones from Ainol for instance; I was even considering getting one of them myself and try to get Debian running on it, but I haven't made up my mind yet. A tarball is not the ideal medium to release kernel code, a public git repository would have been the best way to do it, but it is more than enough for Amlogic to comply to the GPL; the code seems to be based on the Android common kernel code in particular on the andoid-3.0 branch, with some other fixes from different linux-stable releases on top. The complete archive from Amlogic is about 107 MiB, I took some time to isolate the Amlogic changes and here is a compressed patch (4 MiB, about 40 MiB uncompressed) if you want to take a look. The patch contains also code from other Amlogic platforms, it applies cleanly on top of the android-3.0 branch of the Android common Kernel code, and “almost cleanly” on top of the v3.0.31 branch of the linux-stable tree. This story made me think about companies basing their code on top of android kernels instead of mainline linux, is this something that other companies are doing as well? [Less]

Wednesday, 13 June 2012, 00:13.37, the moon is shining white above the Super- Secret Second Googleplex in Amsterdam, California, United States. G-heads call the location AMplexUS, and unlike Google X Lab, it really exists. If you've never heard of ... [More] it it is because this is the place where the TOP SECRET G-ideas are conceived and get nourished (along with batches of new über-fancy frog breeds). This is where the predecessor of Android —code named OMEOSTATO— started, and where the 0th iteration of Project Glass took birth (although it was still called “Project Silica” at the time). After finding out about aosp.it, someone from Google, for some reason, decided to invite me to their facility to take a tour. You know how these things go: some weird kind of poisonous frogs escaped, the alarm sounded, and there was a mess all around. They let loose the leash on me and I was able to escape and prowl for the deepest secrets of the G-world. The usual stuff when mutant frogs are around, one would say. With the handheld scanner I always carry around with me I was able to capture some cool images before I had to go back on the “normal” tour. I am not at liberty to disclose everything I saw there, and as humans, most of it you wouldn't understand it anyway. Some of it I had trouble figuring out myself, but there's one thing I can reveal. The next version of Android (5.0) will be called —wait for it— “MINT TO BE”. The waving hand you see in the image above symbolizes a new technology called “Don't touch this”, where actual contact with the screen is not needed to perform gestures. It is enough for the fingers to simply be near the device, which is meant to avoid leaving skin-grease on the screen. It is not clear if this will be ready for 5.0. In addition, “Mint to be” will bring a breath of fresh air to the Linux embedded ecosystem, with a kernel interface compatible with the mainline Linux kernel (starting from linux-3.10). According to other documents I found, Big-G is also planning to make a deal with Callard & Bowser, the Altoids manufacturer, to make special tin boxes with a hacker-friendly, ultra-cheap ARM SoC inside. A system à-la Raspberry Pi but far more powerful and Android-ready. Ideal for every flavor of experimints, the device will initially be made entirely in USA, but I've seen notes about looking for a European manufacturer for the European market. The expected price should be around 50 bucks, but lower prices might be possible without the tin box once the project (its provisional name being Aldroino) takes off. Hard times for Arduino appear to be ahead. There was also a note about re-using the “mint” moniker on versions after 8.0... [Less]

Here are a few tricks about SSH tunnels I don't want to forget. Tunneling through a “jump host” It is possible to access a service behind a firewall or NAT by using a public SSH server as a “jump host”. A possible script to make connections to ... [More] port 1234 of the “jump host” to be forwarded to port 80 of the host not publicly accessible is the following: #!/bin/sh set -e LOCAL_USER=me LOCAL_SSH_PORT=22 LOCAL_SERVICE_PORT=80 REMOTE_USER=user REMOTE_HOST=example.com REMOTE_PUBLIC_PORT=1234 REMOTE_PRIVATE_PORT=1235 ssh -t -R ${REMOTE_PRIVATE_PORT}:localhost:${LOCAL_SSH_PORT} ${REMOTE_USER}@${REMOTE_HOST} \ "ssh -c none -g -L ${REMOTE_PUBLIC_PORT}:localhost:${LOCAL_SERVICE_PORT} ${LOCAL_USER}@localhost -p ${REMOTE_PRIVATE_PORT}" Someone calls this approach “double tunneling”, here is a graphical explanation to make it stick into my memory: Keep in mind that connections to port 1234 must be allowed by the firewall on the “jump host”, in my iptables setup (which uses a chain named in-new for new input connections), I'd do something like that: REMOTE_PUBLIC_PORT=1234 INPUT_CHAIN="in-new" sudo iptables -A $INPUT_CHAIN -p tcp -m tcp --dport $REMOTE_PUBLIC_PORT --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT In order to delete this single rule it is possible to list all the rules with this command: sudo iptables -v -n -L $INPUT_CHAIN --line-numbers take note of the rule number, and then call: sudo iptables -D $INPUT_CHAIN <rule number> Tunneling to your IM contacts SSH port forwarding can be combined with Telepathy and ssh-contact too. For instance the command below makes your SSH server accessible to the local port 2222 of the contact you choose: ssh-contact -- -l remote_ssh_user -R 2222:localhost:22 These kind of tricks can be useful if you want to do some file transfers via SCP/sftp, for example. Note It's been a while since I did some networking stuff, so my terminology may sound a little off: I could have used “Jump Node” or “Relay Node” instead of “Jump Host”, let me know if you think there is room for improvement in the article or in the drawing. Attached files:  SSH tunneling/port-forwarding through a “jump host” [Less]