Fatdog64 Update
I have been busy with FatdogArm in recent times but it doesn't mean that Fatdog64 is ignored. In fact, the development of the next version of Fatdog64 is currently in the works now.Fatdog64 development usually alternates between two phases - development phase and release phase.
During development phase, kirk and I get very active and do all the usual stuff you usually attribute to "development" - and in between we will release alpha or beta releases in quick succession for others to tests so that we can squash the bugs. When the quality is good enough, we will make a release - this marks the beginning of the release phase.
During this release phase, generally all development slows down except for immediate bug fixes and/or experimental ideas for the next release; it also helps to relieve us from burnouts and focus on other things in life. After a while (usually a period of between 3 to 6 months), the development phase will begin again.
Fatdog64 621 was last released on 8 May this year, so it is due for a refresh, which is in the works. One of the thing we waited before we update Fatdog64 was for kernel 3.11, which, among others, comes with improved power management for radeon cards.
The next release of Fatdog64 will still be based on the 600-series base; this (barring unforeseen circumstances) will be the final release of the series, and expected to last until early next year - thus making the entire series to last about two years from its initial release (which is another Fatdog tradition - Fatdog64 500 series also last for about two years from its initial release).
It is exciting times; we have Fatdog Next running in our system and while we still have to tweak it, things are looking good.
No comments - Edit - Delete
FatdogArm on Cubieboard2
I have received a Cubieboard2 from someone who shall remain anonymous (thank you!).The delivery took quite a while, but it finally arrived yesterday; and today I have FatdogArm running on it (screenshot here).
It is still in the early days and it will need tweaks, but in general it is running smooth and well. Cubieboard2 will be a supported platform in the next release.
---
I noticed something. I'm using linux-sunxi kernel, 3.4 branch, the latest, and using cubieboard2_defconfig (suitably modified) from cubieboard2/linux-sunxi fork. The difference between this and my previous ARM kernels is that this kernel enables a lot of modules. Which is ok, except for one thing: I noticed that the kernel modules are *huge*. For example, the entire collection of netfilter modules on my x86_64 is around 1.3MB. The same collection on the A20 kernel I just compiled is - guess what? It's *18MB* - more than 10 times! Initially I thought it is because of the compiler (I used gcc 4.6.2) so I used Linaro's gcc 4.7, and the result is almost identical. Hmmmm.
1 Comment - Edit - Delete
Turbovnc now plays well with xrdp
I've recently toyed with xrdp to see how far it has progressed. Quite to happy to see that it finally has x11rdp back on the table in the latest git-master (0.7.0). During my experiment, though, I noticed that I can't login to any of sesman-Xvnc session. There was no error message from xrdp-sesman or from Xvnc (which was launched by sesman) itself, and there was no message from the rdesktop screen either. Surprisingly, I can *connect* to the underlying Xvnc server, but xrdp can't seem to connect to it, no matter what I did. It just seemed to hang during early protocol negotiation phase. For the record, my Xvnc is actually turbovnc.Naturally, I did a google search and I only found one occurrence of someone complaining that turbovnc doesn't play well with xrdp, with no solution (the only solution was to use tightvnc instead); this was from 2011. Hmmm. There was another somewhat unrelated 2010 post that they managed to use turbovnc with xrdp, but were having problems with x11rdp. I wasn't using x11rdp, but the interesting part is that it seemed that they could get turbovnc play well with xrdp - but no clue on exactly how. Mmmm, okay. Time to roll-up the sleeves again.
Initially I thought the problem was with xrdp, so I spent some time debugging it. I came to the conclusion that the hanging situation happened because xrdp (or rather, its vnc plugin) was waiting for authentication acknowledgement from the Xvnc but never got it. Upon closer examination and comparison with RFB protocol specification, I was quite certain that xrdp implemented the protocol correctly. But why did it hang, while my regular vncviewer (which is tightvnc's, not turbovnc's), didn't?
As I went on for a little while, I noticed that (tight)vncviewer connected to the (turbovnc) Xvnc using RFB protocol version 3.8. This protocol is quite different from the one used by xrdp; it used an earlier version, version 3.3. So I got tightvnc source, and hacked it a little to force it to use RFB 3.3 instead of the latest supported (in this case 3.8). Look and behold - this time the vncviewer hung, too! There must be something weird in turbovnc's implementation of the version 3.3 of the RFB protocol.
A little more debugging later, I came to the conclusion that there was indeed a bug in turbovnc's implementation of RFB 3.3 and 3.7 protocol (basically anything other than 3.8). In addition it also has a bug that render "no authentication" (ie, password-less) connection useless. Once found, it was easy to fix both of them.
It is to be noted that most vncviewers these days implement RFB 3.8 protocol; and most people will run Xvnc with authentication, so it is unlikely that you will encounter either one of these bugs. But if you do, and you need a solution, hit into my patches page and get the patch from there. Oh and by the way my patch also changes the root of X11 to be in /usr instead of /usr/X11R6 (that was long ago), and the location of the font directory (FontDir), as well as disabling PAM by default (you can re-enable it by removing the patch that disable it - it should be obvious which one). The patch is meant for turbovnc 1.1 but it will also apply cleanly to turbovnc 1.2 (which still has the bug).
As a happy ending, with the patch xrdp now works beautifully with turbovnc.
No comments - Edit - Delete
FatdogArm for XO-4 is released
Based on alpha3, Mavrothal has kindly released FatdogArm for XO-4. I have updated the release notes to reflect this.Release announcement: http://distro.ibiblio.org/fatdog/web/arm-latest.html#xo4.
Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=728487#728487.
Images: http://distro.ibiblio.org/fatdog/arm/images/.
No comments - Edit - Delete
FatdogArm alpha3 is released
Make sure your read the release notes first: http://distro.ibiblio.org/fatdog/web/arm-alpha3.htmlGet it from ibiblio (or one of its mirrors):
http://distro.ibiblio.org/fatdog/arm/images/
Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=728353
Alpha3 supersedes the Alpha2 (which has been removed from the server).
Apart from a few fixes, the main feature of Alpha3 release is support for XO-4 (in a separate image) - and the release of FatdogArm as a "meta-distribution" allowing anyone to build a customised version of FatdogArm.
No comments - Edit - Delete
Patches page
I have a small collection of patches of various nature, so I thought I'd put them together in a page to make it easier for others (and myself) to find it when it is needed.The patches page is here.
One new patch in that page is a patch for guvcview, a webcam viewer and recorder. The latest version is GTK3 only, but I don't run GTK3, so I created a patch to compile and run guvcview in GTK2.
No comments - Edit - Delete
XO-4 native Xorg driver for FatdogArm
I finally managed to build dovefb Xorg driver for XO-4. That means XO-4 now has a native Xorg driver (using proprietary blobs from Marvell), and should provide equal features as Fedora XO.The difficulty with compiling the driver lies in finding the right version of the proprietary blobs to use. The one in the git repository turns out to be not the latest one, the one in OLPC RPM Dropbox is.
One thing that it immediately fixes is screen rotation (xrandr). 3D may work too, but I haven't tested that (no EGL / GLES test programs). There is no acceleration for hardware decoding though, as it is another subsystem of the SoC (VMeta) and requires complete different library ...
Anyway, with this, and the other hard work from Mavrothal, FatdogArm on XO-4 is looking very good.
No comments - Edit - Delete
BootMenu updated
The original post was here. I just updated the BootMenu to add a few scriptable functions (reboot, init, shell, poweroff), as well as replacing the deadlock-prone evtest-based input with pure shell based input (using "read").The updated article and script is here.
No comments - Edit - Delete
Linux 3.12 will support USER_NS with XFS
I was hoping this was fixed in 3.11, but it isn't (I think it simply missed the commit window for 3.11).That being said, the good news is that it has been fixed and Linux kernel 3.12 *will support* building XFS with user namespace enabled! This is the commit that enables that, and it already appears in 3.12-rc1.
Good stuff!
No comments - Edit - Delete
Fixing XO-4 touch input
I'm in a hurry, so here's a short summary.FatdogArm works well on XO-4, except that it's touchscreen isn't working (but it works under Fedora Arm).
I have two touchscreen-capable drivers in FatdogArm: evdev, and xf86-input-tslib. Both are the latest versions. And as it happens, both have bugs preventing them to work.
a) evdev 2.8.1 (latest as of time of writing) has bugs, calling mtdev for unnecessarily. This bug is fixed by this commit. Fedora Arm doesn't encounter this bug because it uses an ancient version of evdev, version 2.7.3. Upgrading to the latest git version (commit 0f16065b00436c5df48af6e1d6a18e2ed27a12fd) fixes it.
b) xf86-input-tslib has bugs and its underlying tslib library has problems:
b1) input-tslib will crash because of missing xf86InputSetScreen. This function was removed from Xorg in 2011, so all that is needed is to comment it out. But I've already used Debian Sid patches for this, I wonder why they haven't included this fix in their patchset? (perhaps because it is seldom used at all?)
b2) tslib doesn't suport multitouch, so XO-4 input confuses it. Furthermore, XO-4 touch reports that it has BTN_TOUCH support but never generates one. There are multitouch patches for tslib lying around but they don't work.
So I went inside tslib and patch it to work with XO-4 driver (adding the appropriate event recognition to tslib - ABS_MT_PRESSURE, ABS_MT_TRACKING_ID, etc). It *does not* make tslib multitouch-capable, it only makes tslib works with touchscreen that uses multitouch drivers / protocol.
The patch fixes issues with XO-4 touchscreen but I believe that it isn't XO-4 specific - anyone with multitouch driver will meet similar problem sooner or later. I have sent the patch to tslib maintainer (Chris Larson) but in case you need it sooner, you can find the patch here.
----
With those, now both drivers work with XO-4 (and hopefully with others too). Whichever you choose to use is up to you. For now, I'm putting evdev as the default driver and removing xf86-input-tslib and tslib from the basesfs; however they are available in the repository.
No comments - Edit - Delete