[driver] New life for Serial mice

[driver] New life for Serial mice

[Vojtech Pavlik]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Hi!

If you still have your 3-button MouseSystems (or any other serial) mouse
somewhere in your driver, forgotten becase of the incredibly slow update
rate causing so much jumping of the pointer on the screen that it is
unusable, you may want to pull it out and give it a try.

Or if you're still using it with some old 486 computer, this driver is
for you. 

What it does is that it enhances the update rate from 24 (with current
GPM and X drivers) to 96. This is almost what the best USB mice do.

It's a kernel driver. Yes, it's a kernel driver for serial mice,
something that has been loathed by some. In 322 lines of code, all of
serial mouse handling. And much better than ever before.

Try it out. Installation notes are in the README file.
Patch against 2.4.5-ac9.

Have fun ...

-- 
Vojtech Pavlik
SuSE Labs

[-- Attachment #2: sermouse.tar.gz --]
[-- Type: application/x-gunzip, Size: 7123 bytes --]

Re: [driver] New life for Serial mice

[Guest section DW]

> In 322 lines of code,

[hmm - gzipped, ach]

Including the code in a readable form is much better - many people
would glance at it and perhaps have remarks.
And in those cases where the code is too large to give,
a URL is preferable.

Andries

Re: [driver] New life for Serial mice

[James Simmons]

Is it possible to move serio.c and serport.c up into drivers/char. I'm
finding many drivers that use this and it is a mess to have to enable
joysticks just to use other types of devices like touchscreens.

Re: [driver] New life for Serial mice

[Vojtech Pavlik]

On Wed, Jun 06, 2001 at 09:17:56AM -0700, James Simmons wrote:

> Is it possible to move serio.c and serport.c up into drivers/char. I'm
> finding many drivers that use this and it is a mess to have to enable
> joysticks just to use other types of devices like touchscreens.

Possible it indeed is.

-- 
Vojtech Pavlik
SuSE Labs

Re: [driver] New life for Serial mice

[Jeff Garzik]

hmmm.  I just looked over this, and drivers/char/joystick/ser*.[ch].

Bad trend.

Serial needs to be treated just like parport: the basic hardware code,
then on top of that, a selection of drivers, all peers:  dumb serial
port, serial mouse, joystick, etc.

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: [driver] New life for Serial mice

[Vojtech Pavlik]

On Wed, Jun 06, 2001 at 12:31:28PM -0400, Jeff Garzik wrote:

> hmmm.  I just looked over this, and drivers/char/joystick/ser*.[ch].
> 
> Bad trend.
> 
> Serial needs to be treated just like parport: the basic hardware code,
> then on top of that, a selection of drivers, all peers:  dumb serial
> port, serial mouse, joystick, etc.

Agreed. Completely.

And proposed a couple times before.

But not in my power.

So I used a N_MOUSE line discipline instead
 - the best tap into the serial/tty stack I found.

-- 
Vojtech Pavlik
SuSE Labs

Re: [driver] New life for Serial mice

[Russell King]

On Wed, Jun 06, 2001 at 07:01:58PM +0200, Vojtech Pavlik wrote:
> On Wed, Jun 06, 2001 at 12:31:28PM -0400, Jeff Garzik wrote:
> > hmmm.  I just looked over this, and drivers/char/joystick/ser*.[ch].
> > 
> > Bad trend.
> > 
> > Serial needs to be treated just like parport: the basic hardware code,
> > then on top of that, a selection of drivers, all peers:  dumb serial
> > port, serial mouse, joystick, etc.
> 
> Agreed. Completely.

I suggest that if someone is thinking about this that they look at
serial_core.c in the ARM patch hunk.
   (ftp.arm.linux.org.uk/pub/armlinux/source/kernel-patches/v2.4/)

Note that you shouldn't apply the whole patch - it probably won't compile
for anything but ARM atm.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [driver] New life for Serial mice

[James Simmons]

> > > hmmm.  I just looked over this, and drivers/char/joystick/ser*.[ch].
> > > 
> > > Bad trend.
> > > 
> > > Serial needs to be treated just like parport: the basic hardware code,
> > > then on top of that, a selection of drivers, all peers:  dumb serial
> > > port, serial mouse, joystick, etc.
> > 
> > Agreed. Completely.
> 
> I suggest that if someone is thinking about this that they look at
> serial_core.c in the ARM patch hunk.
>    (ftp.arm.linux.org.uk/pub/armlinux/source/kernel-patches/v2.4/)
> 
> Note that you shouldn't apply the whole patch - it probably won't compile
> for anything but ARM atm.

Never noticed it until now. Very nice patch :-) I have to agree as well.
It would be nice if we had 

1) A seperate serial directory under drivers.

2) A nice structure that input devices and the tty layer can use. It is
   just a waste to go threw the tty layer for input devices. It would also
   make serial driver writing easier if the api is designed right :-) 

Re: [driver] New life for Serial mice

[Russell King]

On Wed, Jun 06, 2001 at 01:20:53PM -0700, James Simmons wrote:
> Never noticed it until now. Very nice patch :-) I have to agree as well.
> It would be nice if we had 
> 
> 1) A seperate serial directory under drivers.
> 
> 2) A nice structure that input devices and the tty layer can use. It is
>    just a waste to go threw the tty layer for input devices. It would also
>    make serial driver writing easier if the api is designed right :-) 

I am planning some day (don't know when yet though) to convert the 16x50
driver over to the serial_core stuff.

NB, Ted Tytso mentioned something at the 2.5 conference about integrating
some of the serial layer with the tty layer.
--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [driver] New life for Serial mice

[James Simmons]

> > It would be nice if we had 
> > 
> > 1) A seperate serial directory under drivers.
> > 
> > 2) A nice structure that input devices and the tty layer can use. It is
> >    just a waste to go threw the tty layer for input devices. It would also
> >    make serial driver writing easier if the api is designed right :-) 
> 
> I am planning some day (don't know when yet though) to convert the 16x50
> driver over to the serial_core stuff.

I ported it over to my tree. I will have to figure out how to incorporate
the input serial stuff without breaking all the input drivers we have. In
CVS we have alot of them. This will make life so much easier since all I
will have to do is change one file for changes I make to the tty layer. I
have improved andrew mortons console patch to work with multiple consoles
and for different types of console devices. Instead of altering all the 
console drivers I'm planning on intergrating the locking into the tty
layer. That patch is needed for serial devices as well as video terminals.
Your work might help speed up devleopement.

> NB, Ted Tytso mentioned something at the 2.5 conference about integrating
> some of the serial layer with the tty layer.

What does he have in mind? I like to keep my VT changes in sync with what
he has in mind.

Re: [driver] New life for Serial mice

[Vojtech Pavlik]

On Wed, Jun 06, 2001 at 03:39:04PM -0700, James Simmons wrote:

> > > It would be nice if we had 
> > > 
> > > 1) A seperate serial directory under drivers.
> > > 
> > > 2) A nice structure that input devices and the tty layer can use. It is
> > >    just a waste to go threw the tty layer for input devices. It would also
> > >    make serial driver writing easier if the api is designed right :-) 
> > 
> > I am planning some day (don't know when yet though) to convert the 16x50
> > driver over to the serial_core stuff.
> 
> I ported it over to my tree. I will have to figure out how to incorporate
> the input serial stuff without breaking all the input drivers we have. In
> CVS we have alot of them. This will make life so much easier since all I
> will have to do is change one file for changes I make to the tty layer. I
> have improved andrew mortons console patch to work with multiple consoles
> and for different types of console devices. Instead of altering all the 
> console drivers I'm planning on intergrating the locking into the tty
> layer. That patch is needed for serial devices as well as video terminals.
> Your work might help speed up devleopement.

Sounds cute. Where do I find the result of your work?

> > NB, Ted Tytso mentioned something at the 2.5 conference about integrating
> > some of the serial layer with the tty layer.
> 
> What does he have in mind? I like to keep my VT changes in sync with what
> he has in mind.

-- 
Vojtech Pavlik
SuSE Labs

Re: [driver] New life for Serial mice

[James Simmons]

> > I ported it over to my tree. I will have to figure out how to incorporate
> > the input serial stuff without breaking all the input drivers we have. In
> > CVS we have alot of them. This will make life so much easier since all I
> > will have to do is change one file for changes I make to the tty layer. I
> > have improved andrew mortons console patch to work with multiple consoles
> > and for different types of console devices. Instead of altering all the 
> > console drivers I'm planning on intergrating the locking into the tty
> > layer. That patch is needed for serial devices as well as video terminals.
> > Your work might help speed up devleopement.
> 
> Sounds cute. Where do I find the result of your work?

For Russell's work I placed it in the ruby tree under linux/drivers/serial. No
changes have happened to it. Well at least not yet. What I like to see is:

serial_driver -> serial common code -----> serial tty 
				      |	
				      |--> serial input

For my one system I have for my only serial device a joystick. Do I really
need a serial terminal for this device. Termios changes to joystick, give
me a break. It just another layer of uneeded bloat. A nice clean design
like this would be really nice. The code is in CVS if you want to play
with it. 

As for the console lock it is already in CVS as well. Their are a few race
conditions dealing with printk and register_console to pound out but its
there and it works well. The basic changes I have made are the functions
acquire_console_sem and release_console_sem take a struct tty_driver
argument. This way we can flush one driver that was busy while printk was
running when the tty code finish doing what it was doing. Now when printk
gets called it attempts to write data to all the consoles if they already
not busy. This way it only locks out one console at a time. This way
serial console doesn't have to be locked waiting for fbcon to finish
printing to the console. A semaphore in struct tty_driver is shared with
struct console. The better news is now we can use IRQ/DMA based devices
for the console system. 

		

Re: [driver] New life for Serial mice

[Pavel Machek]

Hi!
> 
> If you still have your 3-button MouseSystems (or any other serial) mouse
> somewhere in your driver, forgotten becase of the incredibly slow update
> rate causing so much jumping of the pointer on the screen that it is
> unusable, you may want to pull it out and give it a try.
> 
> Or if you're still using it with some old 486 computer, this driver is
> for you. 
> 
> What it does is that it enhances the update rate from 24 (with current
> GPM and X drivers) to 96. This is almost what the best USB mice do.

What's the "prediction" stuff? Does it mean you are guessing some values
by interpolation? [If so, what kind of update rate would it do on USB?]
								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [driver] New life for Serial mice

[Vojtech Pavlik]

On Wed, Jun 06, 2001 at 11:21:34PM +0000, Pavel Machek wrote:

> > If you still have your 3-button MouseSystems (or any other serial) mouse
> > somewhere in your driver, forgotten becase of the incredibly slow update
> > rate causing so much jumping of the pointer on the screen that it is
> > unusable, you may want to pull it out and give it a try.
> > 
> > Or if you're still using it with some old 486 computer, this driver is
> > for you. 
> > 
> > What it does is that it enhances the update rate from 24 (with current
> > GPM and X drivers) to 96. This is almost what the best USB mice do.
> 
> What's the "prediction" stuff? Does it mean you are guessing some values
> by interpolation?

Extrapolation, yes.

> [If so, what kind of update rate would it do on USB?]

It wouldn't make any difference - on USB you always get whole packets,
while over serial port the data is processed byte by byte and thus we
know a little of the information before the whole packet arrives.

-- 
Vojtech Pavlik
SuSE Labs

Re: [driver] New life for Serial mice

[Pavel Machek]

Hi!

> > > If you still have your 3-button MouseSystems (or any other serial) mouse
> > > somewhere in your driver, forgotten becase of the incredibly slow update
> > > rate causing so much jumping of the pointer on the screen that it is
> > > unusable, you may want to pull it out and give it a try.
> > > 
> > > Or if you're still using it with some old 486 computer, this driver is
> > > for you. 
> > > 
> > > What it does is that it enhances the update rate from 24 (with current
> > > GPM and X drivers) to 96. This is almost what the best USB mice do.
> > 
> > What's the "prediction" stuff? Does it mean you are guessing some values
> > by interpolation?
> 
> Extrapolation, yes.

Can't it make mouse jump forward and back when user suddenly stops?

> > [If so, what kind of update rate would it do on USB?]
> 
> It wouldn't make any difference - on USB you always get whole packets,
> while over serial port the data is processed byte by byte and thus we
> know a little of the information before the whole packet arrives.

Ouch, nice trick!
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

Re: [driver] New life for Serial mice

[Vojtech Pavlik]

On Fri, Jun 08, 2001 at 06:20:46PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > If you still have your 3-button MouseSystems (or any other serial) mouse
> > > > somewhere in your driver, forgotten becase of the incredibly slow update
> > > > rate causing so much jumping of the pointer on the screen that it is
> > > > unusable, you may want to pull it out and give it a try.
> > > > 
> > > > Or if you're still using it with some old 486 computer, this driver is
> > > > for you. 
> > > > 
> > > > What it does is that it enhances the update rate from 24 (with current
> > > > GPM and X drivers) to 96. This is almost what the best USB mice do.
> > > 
> > > What's the "prediction" stuff? Does it mean you are guessing some values
> > > by interpolation?
> > 
> > Extrapolation, yes.
> 
> Can't it make mouse jump forward and back when user suddenly stops?

In theory - yes. It doesn't seem to be a problem in practice, though.
It'll happen when a user slows down the mouse pointer motion faster than
exponentially (base 2). I haven't been able to stop that fast.

> > > [If so, what kind of update rate would it do on USB?]
> > 
> > It wouldn't make any difference - on USB you always get whole packets,
> > while over serial port the data is processed byte by byte and thus we
> > know a little of the information before the whole packet arrives.
> 
> Ouch, nice trick!

Most importantly - it makes serial mice usable.

-- 
Vojtech Pavlik
SuSE Labs

Re: [driver] New life for Serial mice

[Mike Coleman]

Vojtech Pavlik <vojtech@suse.cz> writes:
> > Can't it make mouse jump forward and back when user suddenly stops?
> 
> In theory - yes. It doesn't seem to be a problem in practice, though.
> It'll happen when a user slows down the mouse pointer motion faster than
> exponentially (base 2). I haven't been able to stop that fast.

Put a big brick on your desktop and *ram* it with your mouse.  :-)

-- 
Mike Coleman, mkc@mathdogs.com
  http://www.mathdogs.com -- problem solving, expert software development

Re: (driver) New life for Serial mice

[Pavel Machek]

Hi!

> > > Can't it make mouse jump forward and back when user suddenly stops?
> > 
> > In theory - yes. It doesn't seem to be a problem in practice, though.
> > It'll happen when a user slows down the mouse pointer motion faster than
> > exponentially (base 2). I haven't been able to stop that fast.
> 
> Put a big brick on your desktop and $ram$ it with your mouse.  :-)

:-)))))))))))))))))))))

Put warning in Configure.help that this driver is not compatible with
certain kinds of bricks ;-))))).
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: [driver] New life for Serial mice

[Vojtech Pavlik]

On Fri, Jun 08, 2001 at 03:19:46PM -0500, Mike Coleman wrote:

> Vojtech Pavlik <vojtech@suse.cz> writes:
> > > Can't it make mouse jump forward and back when user suddenly stops?
> > 
> > In theory - yes. It doesn't seem to be a problem in practice, though.
> > It'll happen when a user slows down the mouse pointer motion faster than
> > exponentially (base 2). I haven't been able to stop that fast.
> 
> Put a big brick on your desktop and *ram* it with your mouse.  :-)

Cool idea! Gotta try ... ;)

-- 
Vojtech Pavlik
SuSE Labs

Re: [driver] New life for Serial mice

[John R Lenton]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]


sorry I'm late, could you tell me where this driver/patch is?

also, my problem with USB mice on slow machines is that it takes
up too much CPU, and you get a jumpy mouse if your box is doing a
lot of work (like a heavy nfs server, say). Would this driver do
the same to that box?


On Fri, Jun 08, 2001 at 06:15:21PM +0200, Vojtech Pavlik wrote:
> On Wed, Jun 06, 2001 at 11:21:34PM +0000, Pavel Machek wrote:
> 
> > > If you still have your 3-button MouseSystems (or any other serial) mouse
> > > somewhere in your driver, forgotten becase of the incredibly slow update
> > > rate causing so much jumping of the pointer on the screen that it is
> > > unusable, you may want to pull it out and give it a try.
> > > 
> > > Or if you're still using it with some old 486 computer, this driver is
> > > for you. 
> > > 
> > > What it does is that it enhances the update rate from 24 (with current
> > > GPM and X drivers) to 96. This is almost what the best USB mice do.
> > 
> > What's the "prediction" stuff? Does it mean you are guessing some values
> > by interpolation?
> 
> Extrapolation, yes.
> 
> > [If so, what kind of update rate would it do on USB?]
> 
> It wouldn't make any difference - on USB you always get whole packets,
> while over serial port the data is processed byte by byte and thus we
> know a little of the information before the whole packet arrives.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/
> 

-- 
John Lenton (john@grulic.org.ar) -- Random fortune:
Hear about...
	the nymphomaniac teenager popularly known as Little Often Annie?

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]