Re: (driver) New life for Serial mice
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 [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] - 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/
Re: (driver) New life for Serial mice
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 [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] - 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/
Re: [driver] New life for Serial mice
On Fri, Jun 08, 2001 at 03:19:46PM -0500, Mike Coleman wrote: > Vojtech Pavlik <[EMAIL PROTECTED]> 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 - 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/
Re: [driver] New life for Serial mice
On Fri, Jun 08, 2001 at 03:19:46PM -0500, Mike Coleman wrote: Vojtech Pavlik [EMAIL PROTECTED] 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 - 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/
Re: [driver] New life for Serial mice
Vojtech Pavlik <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] http://www.mathdogs.com -- problem solving, expert software development - 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/
Re: [driver] New life for Serial mice
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 +, 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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Hear about... the nymphomaniac teenager popularly known as Little Often Annie? PGP signature
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] 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. > > > > 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+ - 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/
Re: [driver] New life for Serial mice
On Wed, Jun 06, 2001 at 11:21:34PM +, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] 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. 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. - 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/
Re: [driver] 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. 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: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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/
Re: [driver] New life for Serial mice
On Wed, Jun 06, 2001 at 11:21:34PM +, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] 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. 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+ - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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 +, 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Hear about... the nymphomaniac teenager popularly known as Little Often Annie? PGP signature
Re: [driver] New life for Serial mice
Vojtech Pavlik [EMAIL PROTECTED] 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, [EMAIL PROTECTED] http://www.mathdogs.com -- problem solving, expert software development - 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/
Re: [driver] New life for Serial mice
> > 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. - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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. - 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/
Re: [driver] New life for Serial mice
> > 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. - 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/
Re: [driver] New life for Serial mice
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 ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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/
Re: [driver] New life for Serial mice
> > > 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 :-) - 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/
Re: [driver] New life for Serial mice
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 ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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 | - 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/
Re: [driver] New life for Serial mice
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. - 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/
Re: [driver] New life for Serial mice
> 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 - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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. - 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/
Re: [driver] New life for Serial mice
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 | - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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 - 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/
Re: [driver] New life for Serial mice
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 ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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/
Re: [driver] New life for Serial mice
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 :-) - 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/
Re: [driver] New life for Serial mice
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 ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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/
Re: [driver] New life for Serial mice
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. - 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/
