My Tech Notes

"Backing store" is an old, albeit not well-known, feature of X servers, going back to the 80's or may be even before that. More often when not, servers do not enable it by default, and then users are left to search through server customization option to discover appropriate magic to enable it.

This page, which, I believe, is devoted to some specific Java drawing problems, has some good and concise explanation of "backing store" mechanism (emphasis added):

Usage of backing store is another way of improving our painting procedure. Backing store is a feature of most of X servers: provided that a window has the backing store attribute set, such an X server automatically maintains the contents of the window while it is obscured. When (a part of) a window is exposed, its contents is automatically copied to the screen, and expose events are not generated as the contents is restored. Though the attribute is only a hint to an X server.

Backing store does conflict with DGA, so backing store attribute is not set for a window if Java2D uses DGA on at least one screen. (DGA is used only on some Solaris/SPARC machines.)

To allow setting of the backing store attribute for a window (if DGA is used), one may set the env var NO_J2D_DGA; refer to http://java.sun.com/j2se/1.5.0/docs/guide/2d/flags.html.

To leverage backing store feature, in addition to setting of the backing store attribute for a window, the X server must have backing store support enabled. One should consult his/her X server documentation in order to enable X server's support for backing store. Let's consider typical setting of 3 most popular X servers.

1. Xsun has backing store support enabled by default.
2. XFree86: put 
   Option "backingstore"
   in each Screen section of /etc/X11/XF86Config-4 or /etc/X11/XF86Config if the former isn't present. (See also http://www.xfree86.org/current/ati5.html)
3. Xorg: put    
   Option "backingstore"
   in each Screen section of /etc/X11/xorg.conf. (See also http://www.x.org/X11R6.8.2/doc/ati5.html)

It turns out that there is also option "SaveUnders" somehow related to this. In any case, this is an example of "Screen" section of /etc/X11/xorg.conf with backing store enabled:

Section "Screen"
   Identifier     "Screen0"
   Device         "Device0"
   Monitor        "Monitor0"
   DefaultDepth    24
   Option "BackingStore" "on"
   Option "SaveUnders" "on"
   SubSection     "Display"
       Depth       24
   EndSubSection
EndSection

Enjoy!

Labels: linux, solaris, xwindows

# posted by Kostya @ 4:39 PM 0 comments

Despite many Unix-type file system in existence, it is still problematic to have a single file system which is well compatible with both traditional BSD-based Unix systems, like OpenSolaris (which use older ufs or newer ZFS), and modern Linux distributions (using ext2 or ext3). Though it is technically possible to both mount ufs under Linux and ext3 under Solaris, in neither case support is enabled by default and it may not be very reliable.

That leaves the only file system type which is shared by all Unix/Linux computers without need of any hacking or kernel recompilation as FAT32 from Microsoft. All of its inherit limitations non-withstanding, FAT32-formatted USB flash cards are usually immediately understood and mounted with full read/write access by all modern Unix and Linux distributions.

The only things is, creating such file systems  is not exactly simple. For starters, since Windows 2000 operating system, Microsoft does not provide an option to (re-) format driver as FAT32 if its size exceeds 32 GB, despite the fact and the file system itself has no such limit, so, funny as it is, to create new FAT32 drives one needs either older Windows OS, like Windows 98, or, a Unix/Linux computer.

Debian (and I guess all other modern Linux systems) allows you to create FAT32 file system with one simple command like that (you need to have dosfstools installed first):

mkdosfs -F 32 /dev/sdb1

(you can also use 'fdisk' prior to that to create DOS partition table, but I am not sure it is necessary). Drives so formatted can be then accessed from Windows computer with not trouble as any other FAT32 drive.

With Solaris though, things aren't exactly that simple. I assume that it is being somewhat too picky about existence of "valid" DOS-style "primary" partition table (remember this old DOS logic of four "primary" partitions C,D,E,F and then the rest, if any, being "extended" partitions?). While I am sure it must be somehow possible to convince fdisk and mkdosfs under Linux to create something Solaris will understand, here I present an opposite approach of creating FAT32 system under Solaris.

All operations are executed under "root".

First off, Solaris has so-called "volume management" which (I guess) is charged with auto-mounting user disks. All instructions related to any manipulation with disk devices and mounts outside of services provided by "volume management" insist that you shut down volume management server upfront with this command:

/etc/init.d/volmgt stop

and then restart it with "/etc/init.d/volmgt start" when you're done.

Next, after you plugged it/installed your drive to be formatted, this command:

iostat -En

will help you to identify correct device name for your disk. My external USB hard drive "Free Agent" from Seagate, for example, is reported like that:

c2t0d0           Soft Errors: 86 Hard Errors: 0 Transport Errors: 0 
Vendor: Seagate  Product: FreeAgent Pro Revision: 400D Serial No:  Size: 750.16GB <750156374016 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 
Illegal Request: 86 Predictive Failure Analysis: 0 

Next, you run Sun's fdisk to (interactively) create DOS partition table, like that:

fdisk /dev/rdsk/c2t0d0p0

(note that this has to be "character special" file from /dev/rdsk, and p0 (meaning "first primary partition") appended to the name)

Finally, this command generates file system:

mkfs -F pcfs -o 'fat=32' /dev/rdsk/c2t0d0p0:c

(Note ":c" appended to the name, corresponding to the traditions DOS assignment of drive letter "C" to the 1-st partition)

You can now mount your system with this command:

mount -F pcfs /dev/dsk/c2t0d0p0:c /myusbdrive

(Note that this time we use "block special" file from /dev/dsk)

Labels: solaris

# posted by Kostya @ 12:23 PM 1 comments

OK, after having heard SUN now offers Sun Studio 11 on Linux, I tried to download it.

This is of course a pathetic excuse for a software. Simply NetBeans-based IDE which merely invokes GNU compilers. There is also Motif-based "X-designer" ... Br... And yes, there is "sample" C++ GUI "project". Nonsense.

The only remotely useful piece of whole crap could be dbx debugger, but of course it fails to start on my system asking for newer version of GNU libc :

dbx: /lib/i686/libc.so.6: version `GLIBC_2.3.4' not found (required by dbx)

I even risked downloading latest GNU libc (2.3.6 right now), hoping to install it into a separate directory (not really sure whether this is possible in the first place); this hope however died in vain after this error:

cannot set up thread-local storage: set_thread_area failed when setting up thread-local storage

It seems like something on my system is too old, either kernel (2.4.21), or compiler (3.3.1), or both.

Found one interesting page on the subject of upgrading libc.so which supposedly describes a (presumably) safe way to do so. It follows from it that I might have better luck trying 2.3.4, though I still don't understand whether I can simply install it in another directory to a avoid de-stabilizing the system or not.

May be I try it one day.

My SuSe 9.0 is rapidly becoming too old and outdated, so that few pre-compiled binaries can be installed. Unfortunately.

Labels: linux, solaris, suse

# posted by Kostya @ 10:49 PM 0 comments