[gpm]Re: [eeprom@bol.com.br: Re: Links 2.0pre5: Mouse smooth]

[Petr Baudis]

Dear diary, on Sat, Jun 08, 2002 at 12:36:42PM CEST, I got a letter,
where Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> told me, that...
> On Sat, 8 Jun 2002, Petr Baudis wrote:
> 
> > Dear diary, on Fri, Jun 07, 2002 at 12:08:41PM CEST, I got a letter, where
> > eeprom@bol.com.br told me, that...
> > > I think that using /dev/gpmdata is a a very good solution for GPM's mouse
> > > problem on Framebuffer. Using gpmdata would also free GPM from beeing hooked
> > > and I can then still continue to use the mouser on other console
> > > applications.  Today I always have to close Links before I use the mouse to
> > > copy/paste something or user the mouse on Midnight Commander.
> >
> > This is probably a bug; Links doesn't steal mouse from other applications (at
> > least the old one didn't). Please elaborate.
> >
> > > The use of gpmdata could be triggered by a parameter passed to Link, like the
> > > -g parameter to enter graphic mode.
> >
> > Maybe it would be a nice possibility to write simple library which reads msc
> > from /dev/gpmdata and exposes some nice API. Then patch for using it instead of
> > gpm in svgalib and fb drivers should be trivial
> 
> no, its not trivial. gpm returns data in /dev/gpmdata only when console is
> in KD_GRAPHICS mode. So you have to switch console to KD_GRAPHICS -- and
> the problem is: if you don't restore it when terminating links, the
> console dies locked-up forever. So you'd have to catch ALL signals, like
> in svgalib and xserver.

Well, what's wrong on catching all signals? :) It sounds weird, though.

> Another problem is that if you run gpm with -R, you break mouse in all
> other applications: xserver, svgalib, dosemu. You must reconfigure them
> all to read data from /dev/gpmdata instead of reading mouse device
> directly. And then you could not use third button and mouse wheel in
> xserver and svgalib just because 'microsoft' protocol in /dev/gpmdata
> doesn't support them.

Ah.. true, that didn't come to my mind as well, acknowledged.

> I think it would be really much more easy to patch gpm to return smooth
> data than to mess with KD_GRAPHICS, catch all signals, force the admin to
> use -R and reconfigure all software (and losing all mouse features that
> gpm doesn't understand).

I'll probably talk with Nico about exposing paralel better designed (not
struct-based thus hopefully much better extensible) API soon. A pity that your
mail on gpm mailing list didn't get much interest yet, however that list tends
to be rather lazy and it frequently takes more than few days to others to
reply..

Moving to links-discuss. And, let's crosspost this anyway ;). Please, people
replying to this from links-discuss, cc gpm@lists.linux.it as well (*shudder*
stupid mailing list software inserting reply-to things).

-- 
 
				Petr "Pasky" Baudis
 
* ELinks maintainer                * IPv6 guy (XS26 co-coordinator)
* IRCnet operator                  * FreeCiv AI hacker
.
Object orientation is in the mind, not in the compiler. -- Alan Cox
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/