multiple X sessions

multiple X sessions

[Karthik Vishwanath]

Hello,

Could someone point out how I could setup my machine so that a second user
may log in to the machine and run a 'startx' even though the first user is
logged in and has an active X session running, without killing the first
user's X session?


Thanks,

-K


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: multiple X sessions

[Peter Garrett]

One way is to type at the prompt:

startx -- :1

which will start x on tty8 if tty7 is the default.
Of course, you can also do

startx -- :2 and so on but -- :1 would be the usual second session.

Hope this helps.
 To switch between them you would type alt-F8 0r alt-F7 or perhaps
ctrl-alt-F7 or F8 if already in X. The numbers vary with distributions
but those are the usual ones AFAIK.

On Tue, 2003-12-09 at 12:46, Karthik Vishwanath wrote:
> Hello,
> 
> Could someone point out how I could setup my machine so that a second user
> may log in to the machine and run a 'startx' even though the first user is
> logged in and has an active X session running, without killing the first
> user's X session?
> 
> 
> Thanks,
> 
> -K
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: multiple X sessions

[Anupam]

> Hope this helps.
>  To switch between them you would type alt-F8 0r alt-F7 or perhaps
> ctrl-alt-F7 or F8 if already in X. The numbers vary with distributions
> but those are the usual ones AFAIK.


Is there any way to switch between the 2 sessions if the ``DontZap''
is set to ``yes'' in XF86Config?

Thanks.
-- 
Anupam [http://home.iitk.ac.in/student/anupamg/]
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Getting a valid display under Debian revisited

[jamtat]

Hello all.  I'm still experimenting with various ways of installing
Debian.  Since I seem to have hosed the gui on a system I've been using,
and since a "new" computer showed up in the dumpster over at the
department, my latest victim for cruel Debian install experiments is a
P166 with 32MB RAM, 2GB HD and S3Trio64v+ video card (among other things).
I chose the floppy install: six diskettes, then everything downloaded from
the 'net (the machine had an SMC NIC as well, and I have a fairly fast
connection here at the U).  So, the base system was installed as Woody
(2.2.20 kernel and all).  Side note: I really wanted to try out the new
installer beta, but I couldn't access any documentation on it (maybe
because of the Debian server compromises of late).

After installing the base system, I edited /etc/apt/sources.list and
switched over to unstable.  I then ran apt-get update, apt-get
dist-upgrade.  Then, I proceeded to install additional software - the X
window system being the central concern, installed using tasksel.  I also
installed (apt-got) fluxbox for a WM.  Entered settings for my monitor
and video card when asked.  On next boot, however, I got pretty much the
same black screen I wrote to the list about earlier - though that black
screen was with a different video card, monitor and computer: it's just
blank black, as though the monitor is powered off.  The difference in this
case is that I can ctrl-altFsomething and get to other virtual terminals.
I can also kill X windows by going to the terminal X runs on and hitting
ctrl-alt-backspace.  This was more than I could do on the other machine.

So, I conclude that I'm doing something really fundamental really
wrong(ly).  I want to start by asking if I should expect the sid/unstable
version of X windows to have any conflicts with running on a system using
the older 2.2.20 woody/stable kernel (both systems I'm having display
problems with run sid/unstable XFree86 and the stable 2.2.20 kernel)?  I
noted among the messages on screen when either firing up or killing X
windows that it was compiled using the 2.4.22 kernel.  I also noted a
pointer to /dev/mice/???  that my system couldn't make sense of in
XF86Config-4, and which I edited to point to /dev/psaux.

Before going on to any more in-dpeth trouble shooting on this, I'd just
like to ask if I might not be running into problems at some really basic
level like using the older, stable kernel with the newer XFree86.

Thanks, James

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[Ray Olszewski]

1.My memory is hazy on this (because I always upgrade immediately to a 
recent 2.4.x kernel after installing, and it's been some months now since I 
did my last install), but I think I recall that the 2.2.20 kernel on the 
Debian install disks uses the framebuffer (if so, you'll note that early in 
the boot/init sequence, the display "blinks" and you see  it change to a 
display that has a small, color  penguin near the top - that's the sign of 
the kernel framebuffer). The kernel framebuffer and X sometimes do not play 
well together, so that *could* be the source of your problem.

If it is, you need either to switch to a kernel without framebuffer support 
(see next item) or tell X that it needs to use the kernel framebuffer 
device (I don't do it this way so don't recall how to do it ... might even 
be an option in the setup script, which you can run with, I think, 
"dpkg-reconfigure xserver-xfree86" ...perhaps someone else can chime in 
here with more exact advice?).

2. After you switch from Woody to Sid, you'd do better to switch to the 
current kernel ... either the kernel-image-2.4.22-* appropriate for your 
hardware or your own kernel, compiled from kernel-source-2.4.22 . 2.2.20 is 
really just intended as a temporary kernel for use during install.

3. The other possibility I can think of is that you are trying to use a 
vfreq or hfreq that your monitor deos not support (or have I previously 
suggested this? I don't recall your earlier postings in any detail). 
Probably not, since this problem usually makes it impossible toswitch back 
to vts.

4. I'm not sure what is putting a "pointer to /dev/mice/???" in your 
XF86Config-4 file, but that sounds like an attempt by something to use the 
devfs filesystem for devices, a pesudo-filesystem you probably do not have 
installed. Your adopted solution should serve, but it would be better to 
correct this through dpkg-reconfigure than as a hand edit ... that way, it 
will survive apt-get update/upgrade cycles.


At 11:21 AM 12/9/2003 -0600, jamtat@mailsnare.net wrote:
>Hello all.  I'm still experimenting with various ways of installing
>Debian.  Since I seem to have hosed the gui on a system I've been using,
>and since a "new" computer showed up in the dumpster over at the
>department, my latest victim for cruel Debian install experiments is a
>P166 with 32MB RAM, 2GB HD and S3Trio64v+ video card (among other things).
>I chose the floppy install: six diskettes, then everything downloaded from
>the 'net (the machine had an SMC NIC as well, and I have a fairly fast
>connection here at the U).  So, the base system was installed as Woody
>(2.2.20 kernel and all).  Side note: I really wanted to try out the new
>installer beta, but I couldn't access any documentation on it (maybe
>because of the Debian server compromises of late).
>
>After installing the base system, I edited /etc/apt/sources.list and
>switched over to unstable.  I then ran apt-get update, apt-get
>dist-upgrade.  Then, I proceeded to install additional software - the X
>window system being the central concern, installed using tasksel.  I also
>installed (apt-got) fluxbox for a WM.  Entered settings for my monitor
>and video card when asked.  On next boot, however, I got pretty much the
>same black screen I wrote to the list about earlier - though that black
>screen was with a different video card, monitor and computer: it's just
>blank black, as though the monitor is powered off.  The difference in this
>case is that I can ctrl-altFsomething and get to other virtual terminals.
>I can also kill X windows by going to the terminal X runs on and hitting
>ctrl-alt-backspace.  This was more than I could do on the other machine.
>
>So, I conclude that I'm doing something really fundamental really
>wrong(ly).  I want to start by asking if I should expect the sid/unstable
>version of X windows to have any conflicts with running on a system using
>the older 2.2.20 woody/stable kernel (both systems I'm having display
>problems with run sid/unstable XFree86 and the stable 2.2.20 kernel)?  I
>noted among the messages on screen when either firing up or killing X
>windows that it was compiled using the 2.4.22 kernel.  I also noted a
>pointer to /dev/mice/???  that my system couldn't make sense of in
>XF86Config-4, and which I edited to point to /dev/psaux.
>
>Before going on to any more in-dpeth trouble shooting on this, I'd just
>like to ask if I might not be running into problems at some really basic
>level like using the older, stable kernel with the newer XFree86.





-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[jamtat]

Thanks for your input, Ray.  I was a bit imprecise (as usual on my first
try) in describing the problem.  I think maybe it's not a framebuffer
problem, for the following reason: during initial bootup, I do see all the
boot messages (I seem to have given a misimpression about that).  There is
no small color penguin - which I've seen in other instances, like booting
from a Knoppix CD.  It's just plain text output.  The screen going blank
occurs at the point, at the end of the boot messages, where xdm starts.
After the "starting xdm" message appears is when the screen goes blank.
At first, there's some illumination there - not cross-hatching, like you
sometimes see - but some noticeable degree of phosphor excitement.  After
about 1 second it goes black.  At that point, the power light on the
monitor begins to blink - like when it's getting no video input (e.g.,
when the computer gets powered off).  At that point, I can hit
ctrl-alt-bkspc - twice - and get back to a terminal.  Likewise, I can hit
ctrl-alt-Fwhatever and get to another virtual terminal.  Here's an excerpt
from /var/log/messages/XFree86.0.log (the very beginning and very end)
that may be relevant:

----------------------------------------------------
XFree86 Version 4.2.1.1 (Debian 4.2.1-14 20031113215638 root@newraff.debian.org) / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 October 2002
	If the server is older than 6-12 months, or if your card is
	newer than the above date, look for a newer version before
	reporting problems.  (See http://www.XFree86.Org/)
Build Operating System: Linux 2.4.22-rc2 i686 [ELF]
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Tue Dec  9 13:13:47 2003
(==) Using config file: "/etc/X11/XF86Config-4"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "MicroscanADI"
(**) |   |-->Device "S3Trio64v+"
(**) |-->Input Device "Generic Keyboard"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "pc104"
(**) XKB: model: "pc104"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(==) Keyboard: CustomKeycode disabled
(**) |-->Input Device "Configured Mouse"
(**) |-->Input Device "Generic Mouse"
(WW) The directory "/usr/lib/X11/fonts/CID" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist.
	Entry deleted from font path.
(**) FontPath set to "unix/:7100,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi"
(==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
(II) Module ABI versions:
	XFree86 ANSI C Emulation: 0.1
	XFree86 Video Driver: 0.5
	XFree86 XInput driver : 0.3
	XFree86 Server Extension : 0.1
	XFree86 Font Renderer : 0.3
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
Not loading .note.GNU-stack
Not loading .note.GNU-stack
Not loading .note.GNU-stack
Not loading .note.GNU-stack
Not loading .note.GNU-stack
Not loading .note.GNU-stack
<snip>
(WW) System lacks support for changing MTRRs
(==) s3(0): Backing store disabled
(II) s3(0): Using XFree86 Acceleration Architecture (XAA)
	Screen to screen bit blits
	Solid filled rectangles
	8x8 color pattern filled rectangles
	Solid Lines
(II) s3(0): Acceleration enabled
(II) s3(0): Using PIO
(II) s3(0): Using SW cursor
(**) Option "dpms"
(**) s3(0): DPMS enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension LBX
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Keyboard "Generic Keyboard" handled by legacy driver
(**) Option "Protocol" "PS/2"
(**) Configured Mouse: Protocol: "PS/2"
(**) Option "CorePointer"
(**) Configured Mouse: Core Pointer
(**) Option "Device" "/dev/psaux"
(**) Option "ZAxisMapping" "4 5"
(**) Configured Mouse: ZAxisMapping: buttons 4 and 5
(**) Configured Mouse: Buttons: 5
(**) Option "Protocol" "ImPS/2"
(**) Generic Mouse: Protocol: "ImPS/2"
(**) Option "SendCoreEvents" "true"
(**) Generic Mouse: always reports core events
(**) Option "Device" "/dev/psaux"
(**) Option "ZAxisMapping" "4 5"
(**) Generic Mouse: ZAxisMapping: buttons 4 and 5
(**) Generic Mouse: Buttons: 5
(II) XINPUT: Adding extended input device "Generic Mouse" (type: MOUSE)
(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
--------------------------------------------------------------

That last entry seems like maybe it's trying to access some sort of devfs
thing as well, doesn't it?  So, maybe getting the newer kernel is the
answer to this problem: maybe the newer XFree86 presumes a devfs-enabled
kernel (guessing here, since I have a vague impression that 2.2.20 doesn't
support devfs)?  This is what my rather limited understanding indicates at
this point.  Any further input?

Thanks, James

PS > 4. I'm not sure what is putting a "pointer to /dev/mice/???" in your
Actually, I think it was /dev/input/mice (trying to recall something I
saw briefly late last night).

On Tue, 9 Dec 2003, Ray Olszewski wrote:

> 1.My memory is hazy on this (because I always upgrade immediately to a
> recent 2.4.x kernel after installing, and it's been some months now since I
> did my last install), but I think I recall that the 2.2.20 kernel on the
> Debian install disks uses the framebuffer (if so, you'll note that early in
> the boot/init sequence, the display "blinks" and you see  it change to a
> display that has a small, color  penguin near the top - that's the sign of
> the kernel framebuffer). The kernel framebuffer and X sometimes do not play
> well together, so that *could* be the source of your problem.
>
> If it is, you need either to switch to a kernel without framebuffer support
> (see next item) or tell X that it needs to use the kernel framebuffer
> device (I don't do it this way so don't recall how to do it ... might even
> be an option in the setup script, which you can run with, I think,
> "dpkg-reconfigure xserver-xfree86" ...perhaps someone else can chime in
> here with more exact advice?).
>
> 2. After you switch from Woody to Sid, you'd do better to switch to the
> current kernel ... either the kernel-image-2.4.22-* appropriate for your
> hardware or your own kernel, compiled from kernel-source-2.4.22 . 2.2.20 is
> really just intended as a temporary kernel for use during install.
>
> 3. The other possibility I can think of is that you are trying to use a
> vfreq or hfreq that your monitor deos not support (or have I previously
> suggested this? I don't recall your earlier postings in any detail).
> Probably not, since this problem usually makes it impossible toswitch back
> to vts.
>
> 4. I'm not sure what is putting a "pointer to /dev/mice/???" in your
> XF86Config-4 file, but that sounds like an attempt by something to use the
> devfs filesystem for devices, a pesudo-filesystem you probably do not have
> installed. Your adopted solution should serve, but it would be better to
> correct this through dpkg-reconfigure than as a hand edit ... that way, it
> will survive apt-get update/upgrade cycles.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[Ray Olszewski]

At 01:44 PM 12/9/2003 -0600, jamtat@mailsnare.net wrote:
>Thanks for your input, Ray.  I was a bit imprecise (as usual on my first
>try) in describing the problem.  I think maybe it's not a framebuffer
>problem, for the following reason: during initial bootup, I do see all the
>boot messages (I seem to have given a misimpression about that).  There is
>no small color penguin - which I've seen in other instances, like booting
>from a Knoppix CD.  It's just plain text output.  The screen going blank
>occurs at the point, at the end of the boot messages, where xdm starts.
>After the "starting xdm" message appears is when the screen goes blank.

OK. First thing to wonder is if this is some sort of xdm problem. Test this 
by removing the symlink /etc/rc2.d/S99xdm and rebooting. This change should 
leave you with a standard login: prompt on VT1.

Log in and run "startx", and see if you have the same problem.

>At first, there's some illumination there - not cross-hatching, like you
>sometimes see - but some noticeable degree of phosphor excitement.  After
>about 1 second it goes black.  At that point, the power light on the
>monitor begins to blink - like when it's getting no video input (e.g.,
>when the computer gets powered off).

This detail actually is important. It is an indicator of a problem with an 
hsync or vsync signal to the monitor. Make sure your X setup is set to use 
default size of 640x480 and color depth of 8 (not great settings, but very 
vanilla ones, likely to find a workable modeline).

[...]

>(II) XINPUT: Adding extended input device "Generic Mouse" (type: MOUSE)
>(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
>(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
>--------------------------------------------------------------
>
>That last entry seems like maybe it's trying to access some sort of devfs
>thing as well, doesn't it?

No. devfs entries are all of the general form /dev/*/* . This is just 
trying to access an ordinary device, probably one related to power 
management. I'm unsure of the details here, except that my Debian-Sid 
workstation does not have that device either, and X survives its absence 
quite well. It **may** mean that your X setup is trying to use 
power-management in some way that your system does not support, though.

But note that it is only a warning, not an error (the deleted portions are 
only information and warning messages too, no errors).

>So, maybe getting the newer kernel is the
>answer to this problem: maybe the newer XFree86 presumes a devfs-enabled
>kernel (guessing here, since I have a vague impression that 2.2.20 doesn't
>support devfs)?  This is what my rather limited understanding indicates at
>this point.  Any further input?

I don't have a 2.2.20 source tree handy to examine, and I don't otherwise 
recall if it supports devfs. Based on my system here, current (or at least 
recent) X doesn't assume devfs is in use.

>Thanks, James
>
>PS > 4. I'm not sure what is putting a "pointer to /dev/mice/???" in your
>Actually, I think it was /dev/input/mice (trying to recall something I
>saw briefly late last night).

If you see it again, try again. But I can't suggest anything based on this 
description.

As a general matter, if we are looking at the possibility of hardware 
problems, you might want to report the details of how you consifured X (in 
the dpkg-mediated dialog) and what the relevant sections (Modules,  Device, 
Monitor, Screen, and ServerLayout) of XF86Config look like. Also tell us 
what monitor you are using and what you know about its multisync 
capabilities (this last item is an RTFM exercise).



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[jamtat]

Apologies if this gets double-posted.  I sent it 2 or 3 hrs ago and
haven't seen it hit the list yet, so I'm resending.

On Tue, 9 Dec 2003, Ray Olszewski wrote:

> OK. First thing to wonder is if this is some sort of xdm problem. Test this
> by removing the symlink /etc/rc2.d/S99xdm and rebooting. This change should
> leave you with a standard login: prompt on VT1.
>
> Log in and run "startx", and see if you have the same problem.
>
Same problem.  A bit of phosphor excitement as the server starts, and some
blinking.  Then it goes totally black and the power light starts blinking.

> This detail actually is important. It is an indicator of a problem with an
> hsync or vsync signal to the monitor. Make sure your X setup is set to use
> default size of 640x480 and color depth of 8 (not great settings, but very
> vanilla ones, likely to find a workable modeline).
>
Tried 640x480x8 with the current hsync and vsync.  Same problem - black
screen after a blink or two.

> I don't have a 2.2.20 source tree handy to examine, and I don't otherwise
> recall if it supports devfs. Based on my system here, current (or at least
> recent) X doesn't assume devfs is in use.
>
I tried the new kernel and am running it now.  It has not resolved the
problem.

> As a general matter, if we are looking at the possibility of hardware
> problems, you might want to report the details of how you consifured X (in
> the dpkg-mediated dialog) and what the relevant sections (Modules,  Device,
> Monitor, Screen, and ServerLayout) of XF86Config look like. Also tell us
> what monitor you are using and what you know about its multisync
> capabilities (this last item is an RTFM exercise).
>
When I installed X using tasksel, a set of dialogues ran after the
download asking details about video card, monitor, keyboard and mouse.  I
entered the values there.  I initially edited (by hand) a line in the
section that deals with the mouse.  Since then, I have run
dpkg-reconfigure xserver-xfree86 at least 4 or 5 times to try and fiddle
with settings to see if that would help.  Those mouse settings have almost
surely been overwritten by now.  The way XF86Config-4 looks is sort of a
moving target for this reason: I'm not sure what to show you.  This
monitor is a Microscan ADI 4V LM-1564.  Like most of the other stuff I
have, this one is a castoff that came with no documentation.  Specs I
found on the web for it say it can do 1280x1024 maximum, and that hsync is
30-64, vsync 50-100.  I tried those settings initially at 24 bit color and
640x480, 800x600 and 1024x768 resolutions.  Later I went down to 50-80 on
vsync.  Since your last reply I've selected 640x480 only in
dpkg-reconfigure xserver-xfree86 and 8 bit color.  I also tried limiting
hsync down to 30-40 and vsync to 50-60.

Though it may not be relevant, I'd like to ask how I go about specifying a
window manager.  I apt-get(ted) fluxbox as I mentioned, but I'm just not
sure if I need to configure the system somehow so that the computer knows
to start it.  I'm assuming that, even if that's not configured correctly,
I should still see something when I run "startx," and that it's therefore
probably not relevant to the problems I'm having.  But not being sure, and
needing to perhaps confront that aspect at some stage, I thought I should
mention it.  What I really need is some sort of description of setting up
X from start to finish.  Unfortunately, I haven't located such a resource
yet.  Any recommendations anyone?

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[jamtat]

I was finally able to get a working display by using the vesa xserver.  I
can get 1024x768 with 16 bit color with this.  Strange that the S3
xserver, which is supposed to be for this card, would not work.  Any ideas
why, anyone?

I still get the /dev/input/mice missing directory error, but that doesn't
seem to interfere with X running.

The mouse cursor was acting really wildly, but I think that was because I
installed gpm.  Once I kill gpm (killall gpm), it behaves normally.  I
tried setting the mouse input device to /dev/gpmdata, as the manpage
suggests, but that did not resolve the problem: only killing gpm makes
the cursor behave normally under Xwindows.  Since I like to use alot
of virtual terminals, I'll miss having gpm functioning.  Anyone have any
ideas about how to make gpm work alongside Xwindows?

And, on a similar note: I like to have my virtual terminals set at vga=5
(I include that comment in lilo.conf).  However, once I fire up X windows,
then exit it, the console gets wierd.  About 1/4 of the console screen is
cut off at the bottom.  If I change vga=5 to vga=normal, I don't get that
lower 1/4 of the screen getting cut off, but I also get a text size I
don't really like in the virtual terminals.  Anyone have any ideas on how
to resolve this problem, or other insights into it?  Does it happen
because the xserver I'm using messes with the video BIOS?

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[Peter Garrett]

There are several S3 cards. I had a similar problem with the S3Trio
dx/gx, I think it was ... apparently the drivers are quite specific for
the model.

On Wed, 2003-12-10 at 15:18, jamtat@mailsnare.net wrote:
> I was finally able to get a working display by using the vesa xserver.  I
> can get 1024x768 with 16 bit color with this.  Strange that the S3
> xserver, which is supposed to be for this card, would not work.  Any ideas
> why, anyone?
> 
> I still get the /dev/input/mice missing directory error, but that doesn't
> seem to interfere with X running.
> 
> The mouse cursor was acting really wildly, but I think that was because I
> installed gpm.  Once I kill gpm (killall gpm), it behaves normally.  I
> tried setting the mouse input device to /dev/gpmdata, as the manpage
> suggests, but that did not resolve the problem: only killing gpm makes
> the cursor behave normally under Xwindows.  Since I like to use alot
> of virtual terminals, I'll miss having gpm functioning.  Anyone have any
> ideas about how to make gpm work alongside Xwindows?
> 
> And, on a similar note: I like to have my virtual terminals set at vga=5
> (I include that comment in lilo.conf).  However, once I fire up X windows,
> then exit it, the console gets wierd.  About 1/4 of the console screen is
> cut off at the bottom.  If I change vga=5 to vga=normal, I don't get that
> lower 1/4 of the screen getting cut off, but I also get a text size I
> don't really like in the virtual terminals.  Anyone have any ideas on how
> to resolve this problem, or other insights into it?  Does it happen
> because the xserver I'm using messes with the video BIOS?
> 
> Thanks, James
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[Ray Olszewski]

At 07:51 PM 12/10/2003 +1100, Peter Garrett wrote:

>There are several S3 cards. I had a similar problem with the S3Trio
>dx/gx, I think it was ... apparently the drivers are quite specific for
>the model.
>
>On Wed, 2003-12-10 at 15:18, jamtat@mailsnare.net wrote:
> > I was finally able to get a working display by using the vesa xserver.  I
> > can get 1024x768 with 16 bit color with this.  Strange that the S3
> > xserver, which is supposed to be for this card, would not work.  Any ideas
> > why, anyone?

The original message was a bit more specifci than this, referring to 
an  "S3Trio64v+ video card" ... but that identifier is for a chip, not a 
card, and the X documentation (at www.xfree86.org) says that the current S3 
server works only for S3Trio64v+ video cards that use specific RAMDAC 
chips. So it *could* still be a hardware compatibility issue.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[pa3gcu]

On Wednesday 10 December 2003 09:51, Peter Garrett wrote:
> There are several S3 cards. I had a similar problem with the S3Trio
> dx/gx, I think it was ... apparently the drivers are quite specific for
> the model.

In fact there are many chipsets all really called S3, yes confusing i know, 
but a complete list of them and thier respective drivers can be found in.
/usr/X11R6/lib/X11/Cards
http://www.xfree86.org/current/Status29.html#29
Is a list of supported cards also.

-- 
If the Linux community is a bunch of theives because they
try to imitate windows programs, then the Windows community
is built on organized crime.

Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[pa3gcu]

On Wednesday 10 December 2003 16:33, Ray Olszewski wrote:
> The original message was a bit more specifci than this, referring to
> an  "S3Trio64v+ video card" ... but that identifier is for a chip, not a
> card, and the X documentation (at www.xfree86.org) says that the current S3
> server works only for S3Trio64v+ video cards that use specific RAMDAC
> chips. So it *could* still be a hardware compatibility issue.

I used to use one of these and i still have a copy of XF86Config should one 
need it.
That card uses the "sis" driver or it did when i had mine working, to be 
honest i found it a peice of crap and went out and brought another make of 
card.

-- 
If the Linux community is a bunch of theives because they
try to imitate windows programs, then the Windows community
is built on organized crime.

Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Getting a valid display under Debian revisited

[jamtat]

On Wed, 10 Dec 2003, Peter Garrett wrote:
>
> There are several S3 cards. I had a similar problem with the S3Trio
> dx/gx, I think it was ... apparently the drivers are quite specific for
> the model.
>
I'm thinking it's more likely that the s3 xserver has gotten somehow
corrupted or more buggy as XFree gets updated.  This is because I have
other cards that look just like this one that I've used in other machines.
Under XFree 3.3.6 (the Debian I use now has XFree 4.2.1) the s3 xserver
powered that card just fine.  This is what leads me to conclude that the
xserver has gotten buggy in subsequent versions.  I suppose the other
possibility is that these s3Trio64v+ cards could look almost identical,
could have identifying marks printed on them indicating they are
s3Trio64v+'s, but actually be quite different on the hardware level.  But
it's all pretty much guesswork for those of us who do not write drivers
and/or develop manufacturing standards.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs