Quirky xterm behavior after suspend/resume (T420 Fedora 15)

I’ve been a happy fvwm user since around 1998, first under RedHat Linux 5.0, then under Fedora Core 1. :smiley:

My employer recently bestowed a 64-bit Lenovo ThinkPad T420 on me, necessitating a new version of
Linux and a new version of fvwm. I loaded up Fedora 15 x86_64 along with:

xorg-x11-server-Xorg.x86_64(1.10.1-14.fc15)
xorg-x11-drv-intel.x86_64(2.15.0-4.fc15)
pm-utils.x86_64(1.4.1-8.fc15)
fvwm.x86_64(2.5.30-4.fc15)
xterm.x86_64(268-1.fc15)

I have fvwm mostly configured and behaving just as it does on my old T40 under FC1. However,
I’m having a problem with xterms after suspend/resume: after resuming, the xterms still work, but
refresh during typing is intermittent. Sometimes I have to move the pointer off of the xterm in
order to get it to update and reflect what I have just typed.

Restarting fvwm does not cure the problem. Logout/login seems to cure the problem, but of course
I lose all window contents.

The reason I’m posting here is because these symptoms do not manifest under gnome or kde. Any
xterms I start under those window managers behave normally after suspend/resume. The problem
manifests only under fvwm. :frowning:

This may of course not be an fvwm problem at all, but some quirk of pm-suspend, or the X server,
or some other component.

Has anyone else seen this type of symptom? Any advice would be most welcome!

This is not an FVWM problem.

– Thomas Adam

Well, I’ll keep investigating and report back here if I can identify the root cause and find a remedy.
Perhaps it will help someone else in the future. In the mean time, any advice from other members
of the forum is most welcome. Thanks!

Try reseting xterm or try different terminal.

It has nothing to do with the terminal – I suspect it’s something else such as the PTYs not being picked up by the kernel correctly, or what have you.

– Thomas Adam

I’m experiencing the same problem (with xterm, emacs), but not with FVWM : I use awesome. Did you arrive to a solution kewampler?

I promised to post a follow-up with more information if I solved or worked around the problem I described with xterm refresh on the T420 under Fedora 15.

The problem is apparently related to the i915 driver which Fedora 15 configures as the driver for the integrated Intel graphics associated with the Sandybridge processor(s) in the T420. There have been several patches for the i915 driver that some have reported success with; I went as far as applying these various patches and building a new i915.ko kernel module, but this did not solve the problems for me, so I reverted those changes for now. The reports I found through much searching indicated that the problem manifests easily in xterms, and in some other terminal emulators, and under various window managers, so it is not unique to the xterm/fvwm combination.

I won’t bore the readers here with the full litany of everything else I tried – suffice to say I wasted many hours. :frowning:

I did, however, find a workaround that is satisfactory for my purposes. :smiley: I invoked Xorg itself to create a new /etc/X11/xorg.conf file (not present at all in the default Fedora 15 installation), then edited the xorg.conf file to change Driver “intel” to Driver “fbdev” in Section “Device”. This has completely cured the problems I was seeing with xterm refresh after coming out of suspend. I suppose the i915 driver will eventually be fixed and I can then re-adopt it.

As an aside, finding the necessary additional daemons to respond to the audio control buttons, the suspend (Fn-F4) sequence, the backlight controls, etc. was also a big time sink. On older hardware, these didn’t seem to require software support, but on the T420 they do. Right now, when I launch fvwm, I have it launch the following two daemons:

/usr/bin/kmix --keepvisibility
/usr/bin/gnome-power-manager

in order to get all of those special buttons to work.

Thanks kewampler! I can only imagine the time you spent on this issue, so this is a really sincere thanks :slight_smile:

(Edit) I just installed the latest i915 driver available on Arch Linux (2.15.901-2 a.k.a. 2.16-alpha1), and the problem is gone. Thanks a bunch!