Tracing the segmentation fault problem caused by glutBitmapCharacter or glutBitmapString

When porting an openGL+freeGLUT program to a laptop running with an integrated on-board graphics card ( actually, a part of the chipset, the model is Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller in HP Presario CQ60 standard configuration ), a call in the code to glutBitmapCharacter always leads the program to perish in the runtime.

Built it in debug mode first and then trace the program with the dumped memory core. It is found that the problem can be traced to glBitmap -> libGL.so.xx -> /usr/lib/dri/i965_dri.so. 

Tried dozens of "solutions" ranging from reinstalling many times of freeglut-2.6 to changing GLUT to the classic GLUT-3.7 following the instruction from http://original.jamesthornton.com/linux/HOWTO/Nvidia-OpenGL-Configuration/instglut.html, including debugging deeply in the code itself, trying different fonts and using glutBitmapString, for instance,  just all end up with failures.

Finally, the installation of GLUT-3.7 through an indirect approach - by installing MesaLib (the another ordeal has been put in http://surfingtroves.blogspot.com/2011/07/defeating-mesalib-installation-issues.html)
give the sense of graphics driver issues. It really is! 

Now, skipping the obscure discussions about the notorious graphics card driver problem in Linux ( this is true at least as far as I am concerned ), just show you the one of real "solutions":

go to /usr/lib/, mv i965_dri.so i965_dri.so.old.

get back the code, I am lucky to get the long gnawing problem solved. You should be as well if your case is similar to mine.

Defeating the MesaLib installation issues - not sufficiently high version of libdrm and then "915_EXEC_BLT" undeclared

While obstructed by the tricky installation of GLUT-3.7 in Linux (Fedora 13/14 in this post's case), an easy expedient is to indirectly install MesaLib since this package should have already included GLUT-3.7 and thus the desirable installation of GLUT-3.7 can be achieved tortuously by installing MesaLib through the source package building.

However, there might be still other problems with the building installation itself of MesaLib, here are several candidates:

1. before generating the makefile, "./configure"  can complains that the version of libdrm_intel is lower than 2.4.21 which is required to compile mesa.

---> download the package of libdrm from http://packages.pardus.org.tr/info/corporate2/devel/source/libdrm.html ,unpack it and go to "./configure", here you may get another obstacle, however, by failure in checking PCIACCESS. fix this easily by "yum -y install libpciaccess" and perhaps also "yum -y install libpciaccess-devel". Then "make" -> "make install". and get back to mesa

Unfortunately, the complaints did not disappear as most likely happens. This is a problem of package recognition previously encountered as the case of "http://surfingtroves.blogspot.com/2010/12/linux-fedora-upgraded-package-and.html" . For this instance, find libdrm_intel.pc ( should be found in /usr/local/lib/pkgconfig/ after installation, if not, copy from the source package of libdrm ( typically in intel/ ) and copy it to a directory like this), then add the containing path to the environment variable PKG_CONFIG_PATH. for example
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH.

Then "pkg-config --modversion libdrm_intel" should confirm that the version is updated to suffice the installation of mesaLib.

2. "./configure" continues to grouches, but with missing of TALLOC this time. Fix it by installing libtalloc and libtalloc-devel using yum like above. and you should be able to get through it.

3. now, do the sure thing "make" , you are probably expected to get stymied again by the complaint like:

"error:  I915_EXEC_BLT undeclared "

The is because the older version of the drm_intel library is still being used. Look at the compilation command line before this complaints, you can find "-I/usr/include/libdrm"  therein.  A simple fix is to copy the command line and manually compile again with "-I/usr/include/libdrm" changed to "-I/usr/local/include/libdrm"  since drm_intel is installed to /usr/local by default.

4. "make install".  And, done.

To check if GLUT-3.7 has been installed during the installation of mesaLib, look at /usr/local/lib/libglut* and /usr/local/include/GL/glut*.

Now you should be alreay there.

Can not hear from earphone on fedora linux ALSA Conexant

1. check if the file /etc/modprobe.d/alsa-base exists, touch an empty one of this if not.


2. add following line to it :
options snd-hda-intel model=olpc-xo-1_5


3.save and reboot.


Then the problem should have gone.


Note that this may only do the tricks for exact this sound device
"Codec: Conexant CX20583 (Pebble HSF)". If it is not working for you, please refer to the original post at http://linux.derkeiler.com/Mailing-Lists/Ubuntu/2010-05/msg00541.html.


 Many thanks to the original author.

Can not hear from earphone on fedora linux ALSA Conexant