Subject: FVWM: Console switch zaps Fvwm2 colors

From: "Louis LeBlanc" <[email-masked]>
Date: Wed, 7 Feb 2001 14:19:48 -0500 (EST)

Hey everyone.  I am having a problem with using various consoles on my
Mandrake 7.1 box.  As anyone who uses Linux may know, you can switch
consoles with ALT-(F1-F7), with console 7 being the Xserver console.

Anyway, I noticed that when I switch the console, then switch back, the
color scheme is gone.  All windows, menus and other backgrounds are black. 
Only some borders and shadings can be seen - none of them are the correct
color.  Can this be fixed with a config?  I seem to have to reset the
Xserver to get it working again.  This does not happen with KDE.  Is there
another way to fix it without logging out?

I usually have to use Ctrl-Alt-F* to get from F7 to another console, then
just Alt-F* to choose another.

Thanks in advance.

Lou

-- 
Louis LeBlanc
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
[email-masked]
http://acadia.ne.mediaone.net

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Perry Hutchison <[email-masked]>
Date: Wed, 7 Feb 2001 12:00:35 -0800 (PST)

> another way to fix it without logging out?

Sounds like some kind of colormap issue -- the "Device" section of your
/etc/X11/XF86Config might be relevant.

I do not see that problem on Red Hat 6.2 with "Fvwm Version 2.2.4
compiled on Feb  4 2000 at 03:41:44" and this /etc/X11/XF86Config entry

# Device configured by Xconfigurator:

Section "Device"
    Identifier  "Matrox|MGA G400 AGP"
    VendorName  "Unknown"
    BoardName   "Unknown"
    VideoRam    32768
    # Insert Clocks lines here if appropriate
EndSection
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 7 Feb 2001 19:11:48 -0600

> consoles with ALT-(F1-F7), with console 7 being the Xserver console.

Ctrl-Alt-F1 is processed by X Server (some on this list previously said
this is processed by the kernel without X Server even knowing, but I don't
think so). Anyway this has nothing to do with a window manager.

> just Alt-F* to choose another.

If you always use Ctrl-Alt-F*, you will be consistent.
Or search this list archives for other solutions on this topic.

Regards,
Mikhael.

---

From: Perry Hutchison <[email-masked]>
Date: Wed, 7 Feb 2001 17:59:26 -0800 (PST)

> think so). Anyway this has nothing to do with a window manager.

Ctrl-Alt-Fn has to be handled mostly by the kernel, because it works
on a machine where X is not even installed.  When switching to a
console on which X is running, the kernel has to (somehow) inform
the X server that it's being reactivated, so that the X server can
arrange to get the screen redrawn; and the X server presumably has
to involve the window manager to install the correct colormap.
(It _is_ the window manager that manages colormaps, isn't it?)

Based on the OP's description, I suspect something in that chain
is failing.  Since he said it worked OK with KDE, it seems that
this communication path works:

kernel --reactivate--> X server --restoreColormap--> KDE WM
    --installColormap--> X server --installColormap--> display driver

however it fails when KDE WM is replaced with FVWM.  It may not be
an FVWM bug, but FVWM is somehow a factor.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 7 Feb 2001 20:20:16 -0600

On 07 Feb 2001 17:59:26 -0800, Perry Hutchison wrote:
> on a machine where X is not even installed.

Sorry, this logic does not seem correct to me. Just because Ctrl-Alt-F1
works without X does not prove that X does not handle it too.

Try Shift-Ctrl-Alt-F* within X and outside X, notice a difference.

I remember reading that Ctrl-Alt-F* may be disabled in XFree86 for
security reasons. Was this a dream? :)

> (It _is_ the window manager that manages colormaps, isn't it?)

I skipped the part about colormaps in my message, because I assumed you
answered this part. I only answered the question whether Alt-F* may be
used instead of Ctrl-Alt-F* (assuming there was such question).

Currently I am clueless about colormaps.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Wed, 07 Feb 2001 21:59:16 -0500

> on a machine where X is not even installed.

I believe thats correct, the VT switching stuff is in the kernel.
It works different when X starts on a VT because X changes the display
mode.

> > > Anyway, I noticed  that when I switch  the console, then switch  back,
> > > the color scheme is gone.   All  windows, menus and other  backgrounds
> > > are black.  Only some borders and shadings can be  seen - none of them

Is the entire screen's colormap bad, including the background?

> > > are the correct  color.  Can this  be fixed with  a config?  I seem to
> > > have to reset   the Xserver to get  it  working again.   This does not
> > > happen with KDE.  Is there another way to fix it without logging out?

> > > I usually have to use  Ctrl-Alt-F* to get from  F7 to another console,
> > > then just Alt-F* to choose another.

Are you saying that repeating the C-A-F* sequence fixes the problem?
Just above you say you have to log out.

> an FVWM bug, but FVWM is somehow a factor.

This reasoning seems sound.

Since fvwm works on lots of Mandrake 7.1 boxes something else
is involved too.

I believe that the VT switching logic is responsible for restoring the
screen image.  I don't think fvwm is notified.

Not that I have any idea what the problem is.

Maybe the visual fvwm is using?

Can we see the output from xdpyinfo?

Which fvwm release is this?

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Louis LeBlanc" <[email-masked]>
Date: Thu, 8 Feb 2001 11:34:45 -0500 (EST)

>> > > Hey everyone.  I am having a problem with using various consoles
>> > > on my Mandrake 7.1 box.  As anyone who uses Linux may know, you
>> > > can switch consoles with ALT-(F1-F7), with console 7 being the
>> > > Xserver console.
>> >
>> > Ctrl-Alt-F1 is processed by X Server (some on this list previously
>> > said this is processed by the kernel without X Server even knowing,
>> > but I don't think so). Anyway this has nothing to do with a window
>> > manager.
>> 
>> > > Anyway, I noticed  that when I switch  the console, then switch 
>> > > back, the color scheme is gone.   All  windows, menus and other 
>> > > backgrounds are black.  Only some borders and shadings can be 
>> > > seen - none of them
> 

The whole screens colormap goes south.  Kinda looks like the video card had
a brain hiccup.

> 
>> > > are the correct  color.  Can this  be fixed with  a config?  I
>> > > seem to have to reset   the Xserver to get  it  working again.  
>> > > This does not happen with KDE.  Is there another way to fix it
>> > > without logging out?
> 
>> > > I usually have to use  Ctrl-Alt-F* to get from  F7 to another
>> > > console, then just Alt-F* to choose another.
> 

No, not really.  Typically, using A-Fn will move you to another virtual
console, but from an Xsession, I have to use C-A-Fn.  From a regular
virtual console, A-Fn will change to any other console, including the
Xsession.  But when I get back to the Xsession, the colormap is blown
away.  I have to log out and restart the Xserver from the xdm screen to get
it back together.

> 
>> Based on the OP's description, I suspect something in that chain is
>> failing.  Since he said it worked OK with KDE, it seems that
>> however it fails when KDE WM is replaced with FVWM.  It may not be an
>> FVWM bug, but FVWM is somehow a factor.
> 

Not sure what you mean here.

> Can we see the output from xdpyinfo?

That is a whole lot of output, but here it is:
=======================================================================
$ xdpyinfo
name of display:    :0.0
version number:    11.0
vendor string:    Linux Mandrake (XFree86 4.0, patch level 6mdk)
vendor release number:    4000
maximum request size:  4194300 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    6
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 134
focus:  window 0x240000e, revert to Parent
number of extensions:    23
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    FontCache
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    XC-APPGROUP
    XC-MISC
    XFree86-Bigfont
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1024x768 pixels (347x260 millimeters)
  resolution:    75x75 dots per inch
  depths (1):    24
  root window id:    0x34
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x21
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    64x64
  current input event mask:    0x58203d
    KeyPressMask             ButtonPressMask         
ButtonReleaseMask        
    EnterWindowMask          LeaveWindowMask         
ButtonMotionMask         
    SubstructureNotifyMask   SubstructureRedirectMask
PropertyChangeMask       
  number of visuals:    14
  default visual id:  0x24
  visual:
    visual id:    0x24
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x25
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x26
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x27
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x28
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x29
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2a
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2b
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2c
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2d
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2e
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x2f
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x30
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x31
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

=======================================================================

> Which fvwm release is this?

$ fvwm2 -version
[FVWM][main]:  Fvwm Version 2.2.4 compiled on May  2 2000 at 14:38:39

Thank you all for helping with this.

Now, I have to say that I have used several window managers, from KDE, to
Gnome(enlightenment, Sawmill, etc) and the Sun WMs, and FVWM2 is by far my
favorite.  I find it more flexible and versatile than any of the others,
not to mention far easier to configure.  Never mind the absence of gui
config tools.  When those are available, I find them extremely limiting. 
When all the configuration info is handled in one place, it is easier to
configure it with any tool from vi to the fancy GUIs.

Well done.

L