r3dux.org

My Linux-running laptop seemed to be a little bit sluggish, so I had a look at the amount of free RAM available – and did a double take:

A few apps eating an entire 4GB? Say it ain't so!

This is on a 4GB machine with a web browser (6 tabs) open, email client, code::blocks IDE and totem to play some music. How can that devour my entire 4GB?

Answer: It can’t. Or at least it’s not! The Linux kernel is in fact using free RAM as a disk cache to keep your most often used data in memory and thus speed up the system. As soon as that RAM is actually needed for applications, then it’s instantly made available. This is in theory like the Windows Superfetch service (which is the first thing I disable on any Windows machine I’m forced to co-exist with), only the Linux version actually works well without perpetually thrashing the pants off the hard drive.

What’s really happening is this:

It ain't so =D

For the exact workings, please see the excellent (and indeed excellently named) site “Help! Linux ate my RAM!” – http://www.linuxatemyram.com/.

Bit of a PEBKAC moment, there

I’m working on using OpenCV to get Kinect sensor data via OpenNI, and needed a way to get a matrix (cv::Mat) into an OpenGL texture – so I wrote a function to do just that – woo! Apologies in advance for the terrible juggling

The function used to perform the sensor data to texture conversion is:

// Function turn a cv::Mat into a texture, and return the texture ID as a GLuint for use
GLuint matToTexture(cv::Mat &mat, GLenum minFilter, GLenum magFilter, GLenum wrapFilter)
{
	// Generate a number for our textureID's unique handle
	GLuint textureID;
	glGenTextures(1, &textureID);
 
	// Bind to our texture handle
	glBindTexture(GL_TEXTURE_2D, textureID);
 
	// Catch silly-mistake texture interpolation method for magnification
	if (magFilter == GL_LINEAR_MIPMAP_LINEAR  ||
	    magFilter == GL_LINEAR_MIPMAP_NEAREST ||
	    magFilter == GL_NEAREST_MIPMAP_LINEAR ||
	    magFilter == GL_NEAREST_MIPMAP_NEAREST)
	{
		cout < < "You can't use MIPMAPs for magnification - setting filter to GL_LINEAR" << endl;
		magFilter = GL_LINEAR;
	}
 
	// Set texture interpolation methods for minification and magnification
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, minFilter);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, magFilter);
 
	// Set texture clamping method
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, wrapFilter);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, wrapFilter);
 
	// Set incoming texture format to:
	// GL_BGR       for CV_CAP_OPENNI_BGR_IMAGE,
	// GL_LUMINANCE for CV_CAP_OPENNI_DISPARITY_MAP,
	// Work out other mappings as required ( there's a list in comments in main() )
	GLenum inputColourFormat = GL_BGR;
	if (mat.channels() == 1)
	{
		inputColourFormat = GL_LUMINANCE;
	}
 
	// Create the texture
	glTexImage2D(GL_TEXTURE_2D,     // Type of texture
	             0,                 // Pyramid level (for mip-mapping) - 0 is the top level
	             GL_RGB,            // Internal colour format to convert to
	             mat.cols,          // Image width  i.e. 640 for Kinect in standard mode
	             mat.rows,          // Image height i.e. 480 for Kinect in standard mode
	             0,                 // Border width in pixels (can either be 1 or 0)
	             inputColourFormat, // Input image format (i.e. GL_RGB, GL_RGBA, GL_BGR etc.)
	             GL_UNSIGNED_BYTE,  // Image data type
	             mat.ptr());        // The actual image data itself
 
	// If we're using mipmaps then generate them. Note: This requires OpenGL 3.0 or higher
	if (minFilter == GL_LINEAR_MIPMAP_LINEAR  ||
	    minFilter == GL_LINEAR_MIPMAP_NEAREST ||
	    minFilter == GL_NEAREST_MIPMAP_LINEAR ||
	    minFilter == GL_NEAREST_MIPMAP_NEAREST)
	{
		glGenerateMipmap(GL_TEXTURE_2D);
	}
 
	return textureID;
}

You can then use the above function like this:

// Create our capture object
cv::VideoCapture capture( CV_CAP_OPENNI );
 
// Check that we have actually opened a connection to the sensor
if( !capture.isOpened() )
{
	cout < < "Cannot open capture object." << endl;
	exit(-1);
}
 
// Create our cv::Mat object
cv::Mat camFrame;
 
	// *** loop ***
 
	// Grab the device
	capture.grab();
 
	// Retrieve desired sensor data (in this case the standard camera image)
	capture.retrieve(camFrame, CV_CAP_OPENNI_BGR_IMAGE);
 
	// Convert to texture
	GLuint tex = matToTexture(camFrame, GL_NEAREST, GL_NEAREST, GL_CLAMP);
 
	// Bind texture
	glBindTexture(GL_TEXTURE_2D, tex);
 
	// Do whatever you want with the texture here...
 
	// Free the texture memory
	glDeleteTextures(1, &tex);
 
	// *** End of loop ***
 
// Release the device
capture.release();

There's one very important issue to watch out for when using OpenCV and OpenNI together which I've commented in the code, but I'll place here as well as it can be a real deal breaker:

There appears to be a threading issue with the OpenCV grab() function where if you try to grab the device before it's ready to provide the next frame it takes up to 2 seconds to provide the frame, which it might do for a little while before crashing the XnSensorServer process & then you can't get any more frames without restarting the application. This results in horrible, stuttery framerates and garbled sensor data.

I've found that this can be worked around by playing an mp3 in the background. No, really. I'm guessing the threading of the mp3 player introduces some kind of latency which prevents the grab() function being called too soon. Try it if you don't believe me!

So just be aware that if you're using a Kinect you have to be careful with the grab() function... The source code used to create the above video is provided in full after the jump, if you're interested.

Cheers!

Read the rest of this entry »

Linux.conf.au 2012 kicks off next week in Ballarat at the UB Mt. Helen campus (commuting win – 10 minute drive!) so I’ve just spent a few hours working out my conference schedule… You might think this is perhaps too long to be pondering over schedules, but as the conference runs for 5 days and is organised around multiple sessions in streams, you can pick and choose which sessions you attend each day. For example, options for Tuesday the 17th (with my planned sessional route in blue) look like this:

Even reading about each talk takes a while, nevermind deciding which ones to attend - but it's a nice problem to have

So, yeah, it’s taken a bit of reading and thinking to figure out which sessions I’d like to attend (of-interest or fun stuff), which sessions I should attend (useful learning opportunities but not necessarily fun) and which sessions I’m not particularly fussed about, of which I’m not finding many – quite the opposite in fact, I keep finding multiple sessions I’d like to attend which are on at the same time! Looking forward to a great week of Linuxy shenanigans and learning stuff. Should be fun =D

Update: Update/fix at bottom of post…

Flash on Linux has always been a mess, especially on 64-bit, so when I upgraded my flash plugin the other day to the latest 11.2 beta I wasn’t in the least bit surprised when it broke. This time, watching videos with people in them had the people looking like they were from Avatar – all the skin was blue, and in general the colours were well off. For example:

Flash being, well, Flash...

To fix this up, you need to twiddle with the flash settings at /etc/adobe/mms.cfg, or if you wanted to, do the twiddling through the Flash-Aid plugin like below (in my final working config I actually use the top option of GPU validation as enabled and disable VDPAU):

Flash Plugin Acceleration Options

Once that’s done, restart your browser and hey-presto – correct colours in Youtube:

Flash Colours Restored

You may have to turn on or off some combination for it to work with your particular machine in a trial & error style, because what might work in YouTube might crash when using other flash video sites (vimeo, gametrailers etc). After some playing around, I’ve decided to live with the bad youtube colours and use the following settings in the /etc/adobe/mms.cfg config file:

$ cat /etc/adobe/mms.cfg 
OverrideGPUValidation=1
EnableLinuxHWVideoDecode=0

And as I’m a curious lad, I thought I’d make a table of what works and what doesn’t (on my setup – LMDE w/ NVidia 290 drivers):

Looks like there’s no clear winner that works for everything… Oh wells, there’s a good write-up with alternate solutions and things over on WebUpd8 here – even though they talk about flash 10.2 on Ubuntu, this is the first time I’ve had this issue and it’s on LMDE (Debian based) with the flash 11.2 beta and the same fixes work here. I guess if you’re that bothered, you could always downgrade to some previous flashplugin (like something from the 10.x series) and see how that holds out.

But on the upside, it’s kinda funny watching things in Avatar mode =P

Update: You can fix the bad colours in Flash 11.2.202.221 by setting the following options in /etc/adobe/mms.cfg:

OverrideGPUValidation=0
EnableLinuxHWVideoDecode=1

With NVidia 295.20 drivers (although I’m not sure if that’s part of the problem) Flash video plays fine without any colour issues. Hurrah! =D

I recently changed my LMDE repos and did a full update/upgrade/dist-upgrade – which landed me with Gnome 3… only it didn’t work, and only fallback mode was available.

Unfortunately, fallback mode isn’t very good.

When attempting to start a Gnome 3 session proper, I was getting an error message like this:

Oh no! Something has gone wrong.
A problem has occurred and the system can’t recover.
Please log out and try again.
[Log out]

Then you had to click the [Log Out] button and start a fallback mode session if you wanted to actually be able to do anything with the machine.

So, I did a bit of googling and the easiest way to fix it that I’ve found is to go to the folder: ~/.config/autostart/, create file called Gnome-Shell.desktop (the name doesn’t really matter as long as it ends with .desktop) and the put the following contents in it:

[Desktop Entry]
Type=Application
Exec=gnome-shell --replace
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[en_US]=Gnome Shell
Name=Gnome Shell
Comment[en_US]=
Comment=

BUT – for all this to work properly I had to do a little house cleaning first as I already had a “Gnome-Session.desktop” autostart item which was trying to start Gnome 2 (which isn’t even on the system anymore) and was causing mischief with the Gnome 3 session, so the safest way to do this is probably to:

1. Create a copy of the entire ~/.config/autostart folder,
2. Now you’ve got a copy in case things go wrong, go into the autostart folder and strip out anything you think might interfere (such as any existing Gnome-Session stuff),
3. Add the new Gnome-Shell.desktop file with contents as above, and finally
4. Log out then back in to a proper Gnome 3 session and you should be good to go!

Gnome 3 window management is a bit different to the norm, but I'm finding it actually keeps things quite uncluttered...

I’ve got to say that apart from a few niggles (like the entire Ctrl+Delete to delete a file, Shift+Ctrl+Delete to permanently delete a file rubbish) I’m actually quite liking Gnome 3 so far – it’s a bit like Unity, but without crashing five times a day…

Not a bad start =D