You are not logged in.
there are no stupid questions? here is one:
i wondered if it is possible to have an PS/2- and a USB-mouse running gpm on the same vc ... tried to start gpm (second mouse) while one instance was running already (first mouse)
O0o.oops(): [gpn.c(195)]: gpm is already running as pid 1789
The impossible missions are the only ones which succeed.
Offline
no ideas???
The impossible missions are the only ones which succeed.
Offline
not sure if there is an easier way of doing this, but you can check out this guys how-to, he's wanting to set up 2 seperate independent users sharing a dual-head, dual-input, 1 computer system. There may be better ways of having only dual-input, but you can check it out:
http://www.linuxplanet.com/linuxplanet/ … ls/3100/1/
Hapy.
Offline
not sure if there is an easier way of doing this, but you can check out this guys how-to, he's wanting to set up 2 seperate independent users sharing a dual-head, dual-input, 1 computer system. There may be better ways of having only dual-input, but you can check it out:
http://www.linuxplanet.com/linuxplanet/ … ls/3100/1/
Hapy.
the thing this guy did is really a great idea, but not really new (and i already tried it on an SuSE about half a year ago with simmilar settings --- it works and is really great, believe me)
but my problem is another (maybe my explaination is miserable in the first post, sorry):
i have a PS/2 mouse and a USB-mouse
-> under X they both work nice together
Section "InputDevice"
Driver "mouse"
Identifier "Mouse[1]"
Option "Device" "/dev/input/mice"
Option "Name" "Autodetection"
Option "Protocol" "imps/2"
Option "Vendor" "Sysp"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
Driver "mouse"
Identifier "Mouse[3]"
Option "Device" "/dev/psaux"
Option "InputFashion" "Mouse"
Option "Name" "PS/2-Mouse"
Option "Protocol" "ps/2"
EndSection
[...]
Section "ServerLayout"
Identifier "Layout[all]"
InputDevice "Keyboard[0]" "CoreKeyboard"
InputDevice "Mouse[1]" "CorePointer"
InputDevice "Mouse[3]" "SendCoreEvents"
Option "Clone" "off"
Option "Xinerama" "off"
Screen "Screen[0]"
# Screen "Screen[1]" relative "Screen[0]" 1 0
EndSection
the problem is that in the VC's i can start only one gpm ... and a gpm-server as far i know can only use one mouse --- so in the VC i have only one mouse available
Who needs 2 mouses for one VC? ME, because it's on a Laptop and when i'm at home, i want to use the confortable USB mouse, and when i'm between the University and home, i want to have the internal mouse working
... my idea is something like making Profiles for the startup-options in the /etc/rc.* ... but this means i must rewrite for sure more than 60% of the scripts to have a profile that i can choose at startup
-> this "Profile-Idea" would also solve the eth0=dhcp timeout when you are offline (you dont need to set -t and dont neet also to wait 60s)
instead of DAEMONS() i thougth about having 2 or more different lists that are used as profiles --- how to do this nice, is the other question ... and an additional problem is: in DAEMONS you cannot (AFAIK) specify parameters for the daemons to run -> this is the greatest problem to solve
The impossible missions are the only ones which succeed.
Offline
The "profiles" already exist - sort of :-) it's the "schemes" of the pcmcia package. I would have to check the details myself but the cardmanager can act according to values of the $SCHEME environment variable. And you can set this variable already during boot via the append command. Everything that is not known by the kernel is passed to init. And everything init does not know it will simply leave for the rest. of the boot sequence.
Later on you can also change between schemes via the card-manager-control command.
I think for each scheme you can execute commands - either by editing a file or executing a shell script - I forgot. And with that you can easily change the gpm configuration in /etc/conf.d. *Usually* the network config should be more straight foward since that is what the schemes are really for. But I don't know (yet) how this cooperates with AL setup.
Offline
The "profiles" already exist - sort of :-) it's the "schemes" of the pcmcia package. I would have to check the details myself but the cardmanager can act according to values of the $SCHEME environment variable. And you can set this variable already during boot via the append command. Everything that is not known by the kernel is passed to init. And everything init does not know it will simply leave for the rest. of the boot sequence.
you mean i can append a variable to the kernel at boottime and this will be available during the whole boot process for other processes?
if i call in lilo
boot: myKernel GPM_ARGS="-m /dev/misc/psaux -t ps2 -S "" "
you think, that this will override the GPM_ARGS in /etc/rc.conf ?
this would be great if it is so ... did i understand what you said right?
Later on you can also change between schemes via the card-manager-control command.
I think for each scheme you can execute commands - either by editing a file or executing a shell script - I forgot. And with that you can easily change the gpm configuration in /etc/conf.d. *Usually* the network config should be more straight foward since that is what the schemes are really for. But I don't know (yet) how this cooperates with AL setup.
thanx for the tip
The impossible missions are the only ones which succeed.
Offline
This line will set the GPM_ARGS variable, yes. BUT : once the boot process gets to /etc/conf.d or /etc/rc.conf it will override what you set at boot time. So, if you want to go that way, I would uncomment all GPM_ARGS in rc.conf and /etc/conf.d/gpm and create several entries for lilo with appropriate GPM_ARGS.
I just did a quick test with grub and no spaces in the variable, but I could actually access the variable I set. And the way you wrote it is correct, it is not an "append" argument, it is just added to the end. Now, if only I remembered where I found that documented .... ;-)
Offline
This line will set the GPM_ARGS variable, yes. BUT : once the boot process gets to /etc/conf.d or /etc/rc.conf it will override what you set at boot time. So, if you want to go that way, I would uncomment all GPM_ARGS in rc.conf and /etc/conf.d/gpm and create several entries for lilo with appropriate GPM_ARGS.
I just did a quick test with grub and no spaces in the variable, but I could actually access the variable I set. And the way you wrote it is correct, it is not an "append" argument, it is just added to the end. Now, if only I remembered where I found that documented .... ;-)
ok, i have to type a lot at boot, but it works, great, thanx a lot
The impossible missions are the only ones which succeed.
Offline