New life for Serial mice
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 ...
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 1 line
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
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.
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.
Signature · 3 lines
Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft |
Quoted 7 lines · 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.
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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 3 lines · James Simmons
Is it possible to move
serio.candserport.cup intodrivers/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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 10 lines · Vojtech Pavlik
Quoted 7 lines · 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.
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
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.
Quoted 8 lines
Quoted 1 line
Agreed. Completely.
I suggest that if someone is thinking about this that they look at
serial_core.cin 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 :-)
Quoted 8 lines · James Simmons
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 11 lines
Quoted 8 lines
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_corestuff.
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.
Quoted 2 lines
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.
Quoted 11 lines · James Simmons
Quoted 10 lines
Quoted 7 lines
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_corestuff.
Quoted 9 lines
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?
Quoted 5 lines
Quoted 2 lines
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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 11 lines
Quoted 10 lines
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.
Quoted 1 line
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.
Hi!
Quoted 11 lines
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
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 5 lines · Pavel Machek
Quoted 5 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 1 line
[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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Hi!
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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?
Quoted 5 lines
Quoted 1 line
[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
Signature · 2 lines
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+
Quoted 13 lines · Pavel Machek
Hi!
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
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.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
[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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
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?
Quoted 33 lines · Vojtech Pavlik
Quoted 5 lines · Pavel Machek
Quoted 5 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 1 line
[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.
Signature · 7 lines
Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 3 lines
John Lenton ([email protected]) -- Random fortune: Hear about... the nymphomaniac teenager popularly known as Little Often Annie?
Quoted 5 lines · Vojtech Pavlik
Quoted 1 line
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. :-)
Signature · 2 lines
Mike Coleman, [email protected] http://www.mathdogs.com -- problem solving, expert software development
Quoted 8 lines · Mike Coleman
Quoted 5 lines · Vojtech Pavlik
Quoted 1 line
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 ... ;)
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Re: (driver) New life for Serial mice
In reply to Vojtech PavlikHi!
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
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
Signature · 2 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [email protected]