Warren Falk

And so it goes, one of the first problems I am running into while using linux is that there is no 64 bit flash player for linux. In fact, there might not be a 64 bit flash player at all. This surprises me. I hear people argue that there just isn’t that much demand for it, but part of the benefit of flash was supposedly its wide adoption and cross-platform availability, giving a developer a way to code without worrying about browser incompatibilities. If nobody on a 64 bit system is going to be able to use it, then that seems like a rather big deal. As far as I can tell, there are no official plans to create a 64 bit version.

What does this mean? No google video in linux, was the first thing I noticed.

[UPDATE] You can actually download the video as an AVI reportedly by pasting the following address in the address bar in mozilla (or by making it a bookmark):

javascript:if(document.getElementById('macdownloadlink')!=null){window.location.href=document.getElementById('macdownloadlink')}else{alert('Go to Google Video to download videos as AVI.')};

[UPDATE2] Also, if you can figure out how to download the FLV file, you can install ffmpeg which comes with ffplay, that can play flv files. It should be possible to write a quick plugin or something to do this easily. Of course, I don’t have time to be bothered with that.

Well after a lot of pain, I finally got a good linux system up and running on my AMD64 with ATI x850. It seems to work alright for the most part, though there are a couple glitches. Currently my entire system locks up if I try to quit X. I have not been able to determine if this is a problem with ATI’s drivers or the kernel, or some combination of both. It only seemed to have happened when I got dual monitors working (finally).

The dual monitors works much like Windows once it works. The basic dual monitor or multi-monitor technology in linux is usually referred to as Xinerama, though it isn’t always the exact same technology. What I found out was that KDE had to be recompiled to become “xinerama aware” before it would work correctly in the dual monitor system. Before being recompiled, the system behaved exactly like I had one double wide monitor. That means things maximized across both screens, and dialog boxes popped up centered between the screens. I don’t know, yet, if other applications have to be xinerama aware or not, or if it was enough that KDE and its window manager are now. I will find out soon enough. If it isn’t, I’ll be sure to post a complaint about that here.

Note that recompiling KDE to be xinerama aware is a gentoo thing. Most common (binary) distributions will probably have this already built-in.

3D accelleration does not seem to be working either. DRI is apparently enabled, but when I run the glxgears test, I get 450fps or so. I see other people reporting 8000fps or higher, so I know that mine is not working correctly. I may, therefore, move to the open source radeon driver since it is rumored to be more stable. If 3d accelleration is all I have to sacrifice, then I haven’t lost anything.

So yet another thing I have to deal with when trying to make a switch from Windows to Linux. In Windows, we simply right click the desktop, go to properties, settings, where I see my second monitor, which I can move to where I want it to be, relative to my primary monitor, and it even prompts me to extend the desktop onto it. How nice.

My single monitor “mirror” or “clone” works fine, but if I want to try to do dual monitors, the secondary goes into power save mode and the primary just stays blank (and, of course in true X fashion freezes and takes no more input).

I followed ATI’s instructions, but it seems to be that the second monitor has a different BusID which has a different chip id and that it isn’t in the list of supported chip ids in ATI’s driver. I’d heard of this happening before for primary monitors where companies like Asus where “branding” their chips and changing the chip ids. ATI fixed that, as I understood it, yet my primary is in the list and my secondary is not. The thing is that I don’t really see any secondaries in there and I don’t know if I should. But I do know that it doesn’t recognize mine.

Here is the list, from my log file:

RADEON 9000/9000 PRO (RV250 4966), RADEON 9000 LE (RV250 4967),
MOBILITY FireGL 9000 (M9 4C64), MOBILITY RADEON 9000 (M9 4C66),
RADEON 9000 PRO (D9 4C67), RADEON 9250 (RV280 5960),
RADEON 9200 (RV280 5961), RADEON 9200 SE (RV280 5964),
MOBILITY RADEON 9200 (M9+ 5C61), MOBILITY RADEON 9200 (M9+ 5C63),
FireGL 8800 (R200 5148), RADEON 8500 (R200 514C),
RADEON 9100 (R200 514D), RADEON 8500 AIW (R200 4242),
RADEON 9600 (RV350 4150), RADEON 9600 SE (RV350 4151),
RADEON 9600 PRO (RV360 4152), RADEON 9600 (RV350 4E51),
MOBILITY RADEON 9600/9700 (M10/M11 4E50),
MOBILITY RADEON 9550 (M12 4E56), RADEON 9500 (R300 4144),
RADEON 9600 TX (R300 4146), FireGL Z1 (R300 4147),
RADEON 9700 PRO (R300 4E44), RADEON 9500 PRO/9700 (R300 4E45),
RADEON 9600 TX (R300 4E46), FireGL X1 (R300 4E47),
RADEON 9800 SE (R350 4148), RADEON 9550 (RV350 4153),
FireGL T2 (RV350 4154), RADEON 9800 PRO (R350 4E48),
RADEON 9800 (R350 4E49), RADEON 9800 XT (R360 4E4A),
FireGL X2-256/X2-256t (R350 4E4B),
MOBILITY FireGL T2/T2e (M10/M11 4E54), RADEON X300 (RV370 5B60),
RADEON X600 (RV380 5B62), RADEON X550 (RV370 5B63),
FireGL V3100 (RV370 5B64), MOBILITY RADEON X300 (M22 5460),
MOBILITY RADEON X600 (M24 5462), MOBILITY FireGL V3100 (M22 5464),
RADEON X600 (RV380 3E50), FireGL V3200 (RV380 3E54),
MOBILITY RADEON X600 (M24 3150), MOBILITY RADEON X300 (M22 3152),
MOBILITY FireGL V3200 (M24 3154), RADEON X800 (R420 4A48),
RADEON X800 PRO (R420 4A49), RADEON X800 SE (R420 4A4A),
RADEON X800 XT (R420 4A4B), RADEON X800 (R420 4A4C),
FireGL X3-256 (R420 4A4D), MOBILITY RADEON 9800 (M18 4A4E),
RADEON X800 XT Platinum Edition (R420 4A50), RADEON X800 (R423 5548),
RADEON X800 PRO (R423 5549),
RADEON X800 XT Platinum Edition (R423 554A),
RADEON X800 SE (R423 554B), RADEON X800 XT (R423 5D57),
FireGL V7100 (R423 5550), FireGL V5100 (R423 5551),
MOBILITY RADEON X800 XT (M28 5D48), MOBILITY FireGL V5100 (M28 5D49),
RADEON X800 XL (R430 554D), RADEON X800 (R430 554F),
RADEON X850 XT Platinum Edition (R480 5D4D),
RADEON X850 PRO (R480 5D4F), RADEON X850 XT (R480 5D52),
MOBILITY FireGL V5000 (M26 564A), MOBILITY FireGL V5000 (M26 564B),
FireGL V5000 (RV410 5E48), FireGL V3300 (RV410 5E49),
RADEON X700 XT (RV410 5E4A), RADEON X700 PRO (RV410 5E4B),
RADEON X700 SE (RV410 5E4C), RADEON X700 (RV410 5E4D),
RADEON X700 (RV410 5E4F), MOBILITY RADEON X700 (M26 5652),
MOBILITY RADEON X700 (M26 5653), MOBILITY RADEON X700 XL,
RADEON 9100 IGP (RS300 5834),
RADEON 9000 PRO/9100 PRO IGP (RS350 7834),
MOBILITY RADEON 9000/9100 IGP (RS300M 5835),
RADEON XPRESS 200 (RS400 5A41), RADEON XPRESS 200M (RS400 5A42),
RADEON XPRESS 200 (RS480 5954), RADEON XPRESS 200M (RS480 5955),
RADEON XPRESS 200 (RS482 5974), RADEON XPRESS 200M (RS482 5975),
RADEON XPRESS 200 (RC410 5A61), RADEON XPRESS 200M (RC410 5A62),
RADEON 9000 (RV280 5962), MOBILITY RADEON 9500 (M11 4E52),
RADEON 9500 (R350 4149), RADEON 9600 (RV351 4155),
MOBILITY RADEON X300 (M22 5461), RADEON X800 SE (R420 4A4F),
RADEON X800 VE (R420 4A54), RADEON X800 GT (R423 554B),
MOBILITY RADEON X800 (M28 5D4A), RADEON X800 GT (R430 554E),
RADEON X800 GTO (R430 554F), RADEON X800 GTO (R480 5D4F),
RADEON X850 (R481 4B48), RADEON X850 XT (R481 4B49),
RADEON X850 SE (R481 4B4A), RADEON X850 PRO (R481 4B4B),
RADEON X850 XT Platinum Edition (R481 4B4C)


My card is in bold. Here is what I get from lspci -v and lspci -n (relevant sections in bold):

02:00.0 VGA compatible controller: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc Unknown device 0112
Flags: bus master, fast devsel, latency 0, IRQ 50
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at e3000000 (64-bit, non-prefetchable) [size=64K]
I/O ports at a000 [size=256]
[virtual] Expansion ROM at e2000000 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Capabilities: [100] Advanced Error Reporting
02:00.1 Display controller: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (Secondary)
Subsystem: ATI Technologies Inc Unknown device 0113
Flags: bus master, fast devsel, latency 0
Memory at e3010000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint IRQ 0

02:00.0 0300: 1002:5d4f
02:00.1 0380: 1002:5d6f

Notice that 5D4F is the primary display, and it is in the list (I bolded it). Notice that 5D6F is not. And this is the message I get in the log:

(WW) fglrx: No matching Device section for instance (BusID PCI:2:0:1) found

Well, I went back through /var/log/emerge.log to find all the stuff that was merged to setup Modular X and I unmerged it all. I should have binaries of them to make remerging them easier if I change my mind again later. I emerged Xorg 6.8.2 again and got the card working. I’m using version 8.23.7 of the proprietary ATI driver (x11-drivers/ati-driver in portage).

It wasn’t perfect from the start, though. I ran X -configure and it exited on signal 11. I moved all the modules out of /usr/lib64/modules/drivers into a temporary directory except fglrx and vesa, but still, signal 11. However, the xorg.conf.new file was written, so I ran aticonfig on that one and then tried X -config xorg.conf.new and, to my surprise, it started up. I copied that config file to /etc/X11/xorg.conf and started everything up with /etc/init.d/xdm start

I’ll probably look into seeing if it is possible to get it running with X11R7 later on, but in the mean time, I’m going to poke around in KDE 3.5.2 and see how things work.

In an effort to save myself some time, I’m looking into setting up a share on my network dedicated to hosting precompiled gentoo packages (that I’ve compiled myself). This way when I unmerge a package and want to remerge it later, or I want to merge the same package on identically configured (same architecture and optimizations), I don’t have to go through all the trouble of recompiling everything.

I’m using a samba share because I already have one. If you want to use NFS or something else, then that is fine, but you’ll have to transpose this list as necessary. Also note that to use a samba share, you’ll want to have the smbfs module compiled and inserted, or compiled into the kernel. The basic process works as follows:

UPDATED: I’ve updated this now due to a problem with newer versions of portage getting ACCESS DENIED errors when creating the binaries. Because of the way the sandbox works, you can’t have symlinks inside the package directory (PKGDIR) that point outside the sandbox’s directory write list.

1. [Server A] Set up a centralized directory with read/write access for storing the binary packages. Share it with samba.
2. [Server B] Set up a centralized web server (apache in my case) that can point to the share. This could be the same box as “A”, but mine is not.
3. [Client] Mount the samba share somewhere. Mine is called “pub” because it was already created and I mount it in /mnt/pub, for instance.
4. [Client] cd into the share, and create a folder for your architecture. This should be something like i686-pc-linux-gnu-4.1.0/pentium4/O2. The first directory name (e.g. i686-pc-linux-gnu) is the compiler architecture (CHOST) being used (from `gcc-config -c`). The next directory name (e.g. pentium4) is the architecture. This comes from the -march in CFLAGS in /etc/make.conf. The next is the compiler optimization used (e.g. O2 for -O2) in the CFLAGS of /etc/make.conf.
5. [Client] Add PKGDIR variable to /etc/make.conf that points to the directory you created in the previous step
6. [Client] Add to /etc/make.conf: FEATURES=”buildpkg”
7. [Client] (optional, see caveat) Use quickpkg to create binary packages of everything you already have built. Caveat: if the package contains any files you’ve modified, these go into your binary package. So this isn’t really safe. The better thing to do is to re-emerge everything.
8. [Client] Add the following alias to your /etc/bash/bashrc aliases, alias emerge=”emerge –usepkg –getbinpkg”
9. [Client] Add to /etc/make.conf: PORTAGE_BINHOST=”http:///path/to/share/i686-pc-linux-gnu/pentium4/O2/” (Try not to miss the last slash as it results in a redirect from the server and an annoying message from emerge)

The basic idea, here, is that steps 1 and 2 create a central repository. Steps 3-8 ensure that binaries are cached for existing builds and new builds, and step 9 sets the system up to use the cached binaries if they are available.

Tips:

One thing I noticed is that I have some machines configured to use the -march k8 and some to use -march athlon64, but that these are aliases for the same thing and produce identical binaries. So, if you want to share binaries between these machines, you can symlink the k8 and athlon64 directories under the x86_64* dir.

Caveats:

1. I believe that different glibc versions might cause problems and this could potentially be remedied by adding a glibc version into the PKGDIR and PORTAGE_BINHOST paths.
2. If you upgrade gcc, gcc-config will not fix /etc/make for you to put the new binaries in a new folder, so you just have to remember to do that. I experimented with having make.conf detect the current version, but that caused problems with gcc-config.
3. If you share these among machines, it looks like the USE flags are compiled into the binaries so the two machines are forced to use the same USE flags or compile separately. Compiling separately might cause some confusing problems since the paths to the binary packages will be identical causing overwrites.

I’ve put the video card debacle on hold for now to compile KDE because it is convenient at this time to have my machine doing large compiles while I’m off doing other things. I have set up a script which runs the build, and then texts my cellphone when it is complete so that I don’t have to keep monitoring it. This is quite handy.

The first problem I run into is kde-base/superkaramba-3.5.2. I immediately tried 3.5.1 but it requires downgrading the kde-libs to 3.5.1 and I can’t do that because all the other packages depend on it. So I have to fix 3.5.2.

The failure message appeared to be that Python.h was missing in one of the compiles. However running make in the working directory didn’t reproduce that error. In fact, it succeeded fine. So I went and tried to run ebuild … install and there was the error, during the install phase, it is compiling. That led me down a wild goose chase. When I tried the whole thing over again step-by-step, I found that the compile appears to succeed, and portage things it succeeds, but it doesn’t. The configure script complains that it is missing Python.

Superkaramba can’t be compiled
because of missing Python libraries/headers.

Python is almost certainly installed, but let’s check:

# equery list python
[I--] [ ] dev-lang/python-2.4.2 (2.4)
[I--] [ ] dev-python/python-fchksum-1.7.1 (0)

Yep, it’s installed. So why does the configure script miss it? I’m looking at config.log and see that it finds Python 2.4 headers and libraries but apparently not the modules. I’m looking at this line:

configure:34568: result: header /usr/include/python2.4 library /usr/lib64 modules no

It is looking for the modules in the following locations:

configure: 34552: /usr/local/lib64/python2.4/copy.py
configure: 34552: /usr/lib64/python2.4/copy.py
configure: 34552: /usr/local/python2.4/copy.py
configure: 34552: /usr/lib64/python2.4/copy.py

Specifically it is looking for copy.py, and, of course, it isn’t in any of those locations, it is in /usr/lib/python2.4/copy.py. So I’m thinking that this has something to do with the fact that I’m on a 64bit system. Well, at least, that’s why it hasn’t been fixed yet.
It isn’t clear whether the configure script is looking in the wrong place, or the python installation isn’t quite right. My guess is to blame the configure script because it is searching the same location twice.

If I look at the configure script, I find that it in fact is hard coded to search the same location twice. Here’s the line:

python_libdirs=”$ac_python_dir/lib$kdelibsuff /usr/lib$kdelibsuff /usr/local /usr/lib$kdelibsuff $kde_extra_libs”

Notice that /usr/lib$kdelibsuff exists twice. Why would you want to search the same dir twice? I’m changed that to:

python_libdirs=”$ac_python_dir/lib$kdelibsuff /usr/lib$kdelibsuff /usr/local /usr/lib $kde_extra_libs”

…and reran configure. Look in config.log to find how portage is running configure. Mine was:

# ./configure –prefix=/usr \
–host=x86_64-pc-linux-gnu \
–mandir=/usr/share/man \
–infodir=/usr/share/info \
–datadir=/usr/share \
–sysconfdir=/etc \
–localstatedir=/var/lib \
–with-x \
–enable-mitshm \
–without-xinerama \
–with-qt-dir=/usr/qt/3 \
–enable-mt \
–with-qt-libraries=/usr/qt/3/lib64 \
–disable-dependency-tracking \
–disable-debug \
–without-debug \
–disable-final \
–without-arts \
–prefix=/usr/kde/3.5 \
–mandir=/usr/kde/3.5/share/man \
–infodir=/usr/kde/3.5/share/info \
–datadir=/usr/kde/3.5/share \
–sysconfdir=/usr/kde/3.5/etc \
–enable-libsuffix=64 \
–libdir=/usr/kde/3.5/lib64 \
–build=x86_64-pc-linux-gnu

This gives me:

Good - your configure finished. Start make now

And so I go back to portage to do run all the steps, but this time editing the file before compiling, and I find that the configure script is built from a file called acinclude.m4 where we want to make our change, and then I also see another file in the admin directory with the same line so I edit and change that one too just in case.

# cd /usr/portage/kde-base/superkaramba/
# ebuild superkaramba-3.5.2.ebuild clean
# ebuild superkaramba-3.5.2.ebuild unpack
# nano -w /var/tmp/portage/superkaramba-3.5.2/work/superkaramba-3.5.2/acinclude.m4
(made my change and saved)
# nano -w /var/tmp/portage/superkaramba-3.5.2/work/superkaramba-3.5.2/admin/acinclude.m4.in
(made my change and saved)
# ebuild superkaramba-3.5.2.ebuild compile

I remember, that the compile appeared to succeed, before, even though nothing was compiled, so this time, I am watching and I see the “Good - your configure finished…” message scroll by and it does, and portage is compiling stuff. I sigh with relief, cross my fingers and finish it off:

# ebuild superkaramba-3.5.2.ebuild install
# ebuild superkaramba-3.5.2.ebuild qmerge

All goes well.

[EDIT] … And I have no further problems compiling KDE 3.5.2

I got a great deal on the ATI card and I got it for gaming in Windows. Otherwise, I advise anyone interested in one day switching to linux to avoid ATI. Nvidia is so much nicer to the linux community.

Nevertheless, I’m going to try to get this working because ATI is what I have. The x850 is based on the radeon 300 chipset. The open-source drivers for linux just don’t work with it, from what I understand and so we need the proprietery (pronounced: “evil”) driver from ATI.

And I’m doing this all on an AMD64 machine with Gentoo, running X11 7.0 and gcc 4.1.0. Both of which, at this point, are not really stable.

I managed to get X11 compiled after fixing one of the ebuilds, but X doesn’t actually work. I first tried to install the stable version of the ATI drivers but the build failed.

Then I tried to install the testing (unstable) drivers. Those built, but didn’t work. I’m going to work on getting these to work rather than trying to get the stable version built. If I find myself in over my head, I’ll go back to the stable version and just try to get it built.

The error I’m getting with the development drivers is that when I run

X -configure

I get the following error:

dlopen: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: __glXActiveScreens
(EE) Failed to load /usr/lib64/xorg/modules/drivers/fglrx_drv.so
(EE) Failed to load module “fglrx” (loader failed, 7)

I’ll post my progress (if any) here as comments

This wasn’t as difficult as I thought it would be. The only problem I encountered buliding it successfully was in the previous post where mesa-progs failed to compile. I’m not even sure at this time why it is required, but I did get it working. Here’s what I did.

ebuild /usr/local/portage/x11-apps/mesa-progs/mesa-progs-6.4.2.ebuild unpack
cd /var/tmp/portage/mesa-progs-6.4.2/work/Mesa-6.4.2

Then I edit one of the Makefiles in there and add four lines.

nano -w progs/xdemos/Makefile

I add the following:

glxgears: glxgears.c
$(CC) $(CFLAGS) -I$(INCDIR) glxgears.c $(GLUT_LIB_DEPS) -o $@
glxinfo: glxinfo.c
$(CC) $(CFLAGS) -I$(INCDIR) glxinfo.c $(GLUT_LIB_DEPS) -o $@

Now I can compile, install and merge

ebuild /usr/local/portage/x11-apps/mesa-progs/mesa-progs-6.4.2.ebuild compile
ebuild /usr/local/portage/x11-apps/mesa-progs/mesa-progs-6.4.2.ebuild install
ebuild /usr/local/portage/x11-apps/mesa-progs/mesa-progs-6.4.2.ebuild qmerge

Done. This is roughly equivalent to running emerge mesa-progs except that it works.

…Well, it compiles. It doesn’t work. I can’t seem to get my ATI card to work. I am saving that for the next post, though.

GCC 4.1.0 is hard masked in Gentoo currently and as I understand it is unsupported. Modular X is not yet listed as stable but is in the testing phase. I can’t seem to get a cross compiling distcc setup without using GCC 4.1.0 because the crossdev package is unable to build the toolchain for 3.4.5 correctly (and selects 4.1.0 by default). So to make this work, I have to upgrade to GCC 4.1.0 on everything which up until modular X didn’t cause any problems, but within the last 4 packages of the 108 needed for modular X, mesa-progs failed.
The truth is that I don’t know if GCC 4.1.0 is to blame for the failure. I successfully emerged 98 of 102 packages, but failed on glxinfo in x11-apps/mesa-progs with the following:

x86_64-pc-linux-gnu-gcc -I../../include -Wall -march=athlon64 -O2 -pipe -m64 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DUSE_X86_64_ASM -std=c99 -ffast-math glxinfo.c -L../../lib64 -lglut -lGLU -lGL -lm -o glxinfo
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XGetExtensionVersion’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XFreeDeviceList’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XQueryDeviceState’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XListInputDevices’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XFreeDeviceState’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XOpenDevice’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XmuLookupStandardColormap’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../lib64/libglut.so: undefined reference to `XSelectExtensionEvent’
collect2: ld returned 1 exit status
distcc[10000] ERROR: compile glxinfo.c on localhost failed

I looked up those undefined references and found the last one in libXmu.so and the rest in libXi.so. I added -lXmu -lXi to the build command and glxinfo.o build correctly.I don’t know why GCC 4.1.0 might cause this problem. In fact, perhaps, it is an amd64 bug. Hopefully this helps someone. I will post something about how to fix it and build it with portage as soon as I read up on how to do that.

Since GCC 4.1.0 isn’t supported, it isn’t clear where I should post this bug since they might not yet consider it a bug. I imagine someone would like to know that the package is not yet forwards compatible, but don’t know who to tell or how to tell them.

Here’s a picture of me playing a really simple flash video game to entertain the boys. The game itself isn’t loads of fun, but Ethan and Isaac love to sit on my lap and watch me make the Fancy Pants Man jump over the angry penguin. Ethan gets really excited. He asks me to play the “Pantsy Fants” game, and Isaac asks me to jump over the “Anggy Penggin.”

[EDIT] The game can be found here for all that are interested.