Actually, in potato, you can get gpm to port the mice data to
/dev/gpmdata and then just get X to read that, thus removing the need
to kill gpm. It was broken for a while, but it works fine now.
>>>>> "Aaron" == Aaron Solochek <[EMAIL PROTECTED]> writes:
> I have always just killed gpm from the init scripts, because gpm
> and X have never gotten along on my system. Also a ps/2. Its
> stupid, and dselect loves to reinstall the scripts, so that my
> mouse will either die as soon as dselect starts configuring
> stuff, or will go all crazy.
> -Aaron Solochek
> On Fri, 10 Mar 2000, Debian Linux User Gary L. Dolan wrote:
>> On Fri, Mar 10, 2000 at 08:22:38AM -1000, Jason Christensen
>> wrote: > I have no problems with a PS/2 mouse & 2.2.14. > > On
>> 10 Mar 2000, Joachim Trinkwitz wrote: > > > The boot messages
>> tell me that a PS/2 mouse port is found, but the > > cursor
>> doesn't follow the mouse at all. > > Under what circumstances
>> are you talking about, X or console? If you're > talking about
>> the console, make sure you're running gpm. > > > > > Is there
>> a trick, some other kernel options as in older kernels ...? >
>> > > > No trick for me. You may want to review your kernel
>> configuration. It's > possible that your old config file has
>> some slight differences to configs > for 2.2.14 regarding PS/2
>> mice.
>>
>> I have the same problem, in the x console. I thought perhaps it
>> might be XF86 3.3.6 that is the problem. I re-compiled kernel
>> 2.2.14, and the problem persists. Basically, the ps2 mouse is
>> frozen in the x window; i.e., it reacts much like the old bus
>> mouse problem. So now I kill gpm when invoking x, then use
>> startx gpm -R -m /dev/psaux -t ps2 and the mouse works fine in
>> x.
>>
>>
>> -- Unsubscribe? mail -s unsubscribe
>> [EMAIL PROTECTED] < /dev/null
>>
>>
> -- Unsubscribe? mail -s unsubscribe
> [EMAIL PROTECTED] < /dev/null
--
Marshal Wong
(Yes, that is my first name. Not a title.)
wo drueckt dich der Schuh?
where presses you the shoe
'what's your problem?'
