Menu
▾
▴
linuxconsole-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
| 2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
| 2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
| 2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
| 2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
| 2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Dominik K. <dom...@un...> - 2000-03-08 07:32:29
|
On Tue, Mar 07, 2000 at 07:54:08PM -0500, James Simmons wrote: ... > Thinking about creating a console directory for now and a diff against > various kernel versions. Opinions? Just what i wanted to propose. Another note regarding coding style: All _exported_ functions and variables need to have constant name prefix. I propose the following: con_ console device (already used for this) kb_ keyboard driver vt_ virtual terminal handling (already used for this) vte_ video terminal emulation Comments? Eric, what format should we use for the docs? Plain text? Nroff? I would discount TeX and SGML because people can not be expected to have these tools installed, even so one could use a SGML subset and sed/awk scripts to convert them to text. Since man pages are already written in nroff and nroff is generating decent printer output (and since it's the Unix standard way of delivering documents anyway), i would propose to use nroff for the other docs to be included into the kernel as well. And i recall you are well versed in nroff anyway... ;-) So i see the following directory structure for now Documentation/console The documentation drivers/char/console The generic console code Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: James S. <jsi...@ac...> - 2000-03-08 01:24:23
|
> I'll add a pointer to the "Related Resources" section. Great. > The EvStack site at pepsi.visus.com has apparently disappeared. Yes. The papers behind it are at http://zhrodague.net/~jmcc/ggi/EvStack/paper/ > I'm not qualified to write these explanations. If somebody on the list > is, rough up something (plain text is OK) and I'll webify it. They have to come forward and write something. > Well...deliverables 1 and 2 maybe. Hm. We need names for these. I dub > them "Sapphire" (2.2.x emulation patch) and "Emerald" (2.3.x emulation patch). > The more advanced stuff in deliverable 3 ("Ruby") really is new features > and will probably have to wait for 2.5.x if I know Linus. Hey. Linus will not like a lots of new features for 2.3.X. Also it makes more sense to prep the input drivers and fbdev driver for it. > I think we need to first develop a modest, easily comprehensible set of > Sapphire and Emerald patches that bug-fix the emulation, without trying > to hit the larger issues yet. By doing this, and getting these patches > accepted, we'll open the door for more ambitious things later. Yep. > I'm working on Sapphire right now. I've downloaded Dominik's 2.2.1 patch > and am reconciling it with 2.2.12. My objective is to produce a minimal > patch that doesn't include a whole bunch of formatting changes. I'll > test that patch on my stock Red Hat 6.1 system. Great. I will give it a try once you are done. > Once I have that verified, I'll generate a patch for console_codes(4) > that updates it appropriately. Dominik, you could speed things up > by sending me a functional description of your changes. > > Next step after that would be to generate a minimal Emerald patch, > test it, and check that the updated console_code(4) page correctly > describes it. Which is already their unless someone wants to contribute more to his patch. > Once we have these things, we can should be able to deliver a neat > package to Linus and Alan that will bring both kernel lines up to > snuff in the emulation department and document that properly. > Then we can take on the bigger stuff. Agree. > Everything you know is wrong. But some of it is a useful first > approximation. Thats what we physicist say. Remember approximate the cow as a sphere. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Eric S. R. <es...@th...> - 2000-03-08 00:52:58
|
James Simmons <jsi...@ac...>: > Looks good. Something nice is maybe add is previous and present > approaches to a new console system such as Vojtech work > (http://www.suse.cz/development/input), I'll add a pointer to the "Related Resources" section. > Evstack (look in archive) The EvStack site at pepsi.visus.com has apparently disappeared. > and > probably other solutions that will come out of the woodwork. What > are/where the basic ideas behind them. What problems they had/have. Then > we can explain our approach. How we are attempted to solve these problems > they are/have encountered. I'm not qualified to write these explanations. If somebody on the list is, rough up something (plain text is OK) and I'll webify it. > As we figure out what we are going to do we can write a long term page > since the things on the page right now could go in with the current 2.3.X > kernels. Well...deliverables 1 and 2 maybe. Hm. We need names for these. I dub them "Sapphire" (2.2.x emulation patch) and "Emerald" (2.3.x emulation patch). The more advanced stuff in deliverable 3 ("Ruby") really is new features and will probably have to wait for 2.5.x if I know Linus. I think we need to first develop a modest, easily comprehensible set of Sapphire and Emerald patches that bug-fix the emulation, without trying to hit the larger issues yet. By doing this, and getting these patches accepted, we'll open the door for more ambitious things later. I'm working on Sapphire right now. I've downloaded Dominik's 2.2.1 patch and am reconciling it with 2.2.12. My objective is to produce a minimal patch that doesn't include a whole bunch of formatting changes. I'll test that patch on my stock Red Hat 6.1 system. Once I have that verified, I'll generate a patch for console_codes(4) that updates it appropriately. Dominik, you could speed things up by sending me a functional description of your changes. Next step after that would be to generate a minimal Emerald patch, test it, and check that the updated console_code(4) page correctly describes it. Once we have these things, we can should be able to deliver a neat package to Linus and Alan that will bring both kernel lines up to snuff in the emulation department and document that properly. Then we can take on the bigger stuff. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Everything you know is wrong. But some of it is a useful first approximation. |
|
From: James S. <jsi...@ac...> - 2000-03-08 00:48:45
|
> > The next big issue is what do we place in CVS. The whole kernel tree or > > just certain branches. Downloading via CVS a whole kernel the first time > > is not going to be fun if you have a cheesy modem. Of course we have to > > deal with docs for people who want to try the console code and have to > > patch their kernels. > > I don't have enough kernel-hacking experience to have an opinion about > this. Thinking about creating a console directory for now and a diff against various kernel versions. Opinions? "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: James S. <jsi...@ac...> - 2000-03-08 00:15:54
|
On Tue, 7 Mar 2000, Eric S. Raymond wrote: > I have uploaded a draft web page and project description. > > About the only thing there that might be even mildly controversial > is the list of deliverables. Anybody got a problem with these? Looks good. Something nice is maybe add is previous and present approaches to a new console system such as Vojtech work (http://www.suse.cz/development/input), Evstack (look in archive) and probably other solutions that will come out of the woodwork. What are/where the basic ideas behind them. What problems they had/have. Then we can explain our approach. How we are attempted to solve these problems they are/have encountered. As we figure out what we are going to do we can write a long term page since the things on the page right now could go in with the current 2.3.X kernels. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Eric S. R. <es...@sn...> - 2000-03-07 22:39:31
|
I have uploaded a draft web page and project description. About the only thing there that might be even mildly controversial is the list of deliverables. Anybody got a problem with these? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "If I must write the truth, I am disposed to avoid every assembly of bishops; for of no synod have I seen a profitable end, but rather an addition to than a diminution of evils; for the love of strife and the thirst for superiority are beyond the power of words to express." -- Father Gregory Nazianzen, 381 AD |
|
From: Eric S. R. <es...@th...> - 2000-03-07 21:54:01
|
James Simmons <jsi...@ac...>: > We also have to organize who is going to do what. So > far I know I will be working on the fbdev/fbcon and multihead support > part. Dominik Kubla wants to work on proper VT 100 and other types of > term emulations. Raymond is going to be working on our web site, > documentation, and more terminal emulation stuff. I assume Vojtech is > going to continue his input work. These are the assumptions on the web page I'm drafting. > Well its time to discuss which tree to use. Some people spoke of the > 2.2.X. Other want to work on the 2.3.X branch. Well their are pros and > cons to both. The 2.2.X kernels are stable so we don't have to worry to > much about keeping in sync with any important changes. The draw back is > except for bug fixes alot of our changes wouldn't be back ported. Also > the changes I'm doing to fbdev where I'm moving the console code out of > the fbdev drivers into fbcon.c will not be there. This means if we change > things we might have to update all the fbdev drivers from time to time. > Same is true even for the 2.3.X tree for the input device drivers. This > might change if and when Vojtech work is incorporated into 2.3.X. > If we go with the 2.3.X and if Vojtech work goes in and I finish > changing the fbdev API we have the pro of not breaking any important > drivers all the time. Only a handful of files to change. The con is we > have to keep up with any important changes all the time. It seems to me that we have three deliverables: 1. console.c and man page patches for 2.2.x to fix ANSI conformance in the terminal emulation. These need to go to Alan Cox for merge into the old stable tree. I think Dominik has already done this work. It needs to be tested and documented, which is my job. 2. console.c and man page patches for 2.3.x to fix ANSI conformance in the terminal emulation. These need to go to Linus for inclusion before 2.4. Likewise I think Dominik has already done this work. 3. A line of patches for 2.4.x that implements the heavy stuff; fbdev refactoring, multihead, scrollback, etc. These can't go in until 2.5.x. These things are what I'm going to list as deliverables on the project web page, unless somebody objects. > The next big issue is what do we place in CVS. The whole kernel tree or > just certain branches. Downloading via CVS a whole kernel the first time > is not going to be fun if you have a cheesy modem. Of course we have to > deal with docs for people who want to try the console code and have to > patch their kernels. I don't have enough kernel-hacking experience to have an opinion about this. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" |
|
From: James S. <jsi...@ac...> - 2000-03-07 19:49:06
|
Howdy!!! First its time to register developers. Please send me or Eric Raymond a email with your sourceforge account username. We will add you to the developement list. We also have to organize who is going to do what. So far I know I will be working on the fbdev/fbcon and multihead support part. Dominik Kubla wants to work on proper VT 100 and other types of term emulations. Raymond is going to be working on our web site, documentation, and more terminal emulation stuff. I assume Vojtech is going to continue his input work. Everyone is welcomed so step forward and tell what parts you want to work on. Remember this a group project and we all have worked in group projects so I don't have to spell out how CVS developement is done. Think 3 times before you commit and discuss your ideas/changes with everyone. Well its time to discuss which tree to use. Some people spoke of the 2.2.X. Other want to work on the 2.3.X branch. Well their are pros and cons to both. The 2.2.X kernels are stable so we don't have to worry to much about keeping in sync with any important changes. The draw back is except for bug fixes alot of our changes wouldn't be back ported. Also the changes I'm doing to fbdev where I'm moving the console code out of the fbdev drivers into fbcon.c will not be there. This means if we change things we might have to update all the fbdev drivers from time to time. Same is true even for the 2.3.X tree for the input device drivers. This might change if and when Vojtech work is incorporated into 2.3.X. If we go with the 2.3.X and if Vojtech work goes in and I finish changing the fbdev API we have the pro of not breaking any important drivers all the time. Only a handful of files to change. The con is we have to keep up with any important changes all the time. The next big issue is what do we place in CVS. The whole kernel tree or just certain branches. Downloading via CVS a whole kernel the first time is not going to be fun if you have a cheesy modem. Of course we have to deal with docs for people who want to try the console code and have to patch their kernels. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Eric S. R. <es...@th...> - 2000-03-07 19:30:26
|
Dominik Kubla <dom...@un...>: > Here are some online resources about terminal emulation: > > European Computer Manufacturers Association: > http://www.ecma.ch/ > > * The ECMA standards (counterparts to the ISO terminal standards). > > The Terminal Information Archive: > http://www.cs.utk.edu/~shuford/terminal/ > > * Lots of useful info. > > VT Terminal Information > http://vt100.net/ > > * This site has the VT220 reference manual online! I'm draffting a web page now. This stuff will go on it. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), |
|
From: Dominik K. <dom...@un...> - 2000-03-07 19:27:25
|
On Tue, Mar 07, 2000 at 01:37:20PM -0500, James Simmons wrote:
>
> You got it. Go have fun. Thank you for handling our web pages and adding
> to our project.
Here are some online resources about terminal emulation:
European Computer Manufacturers Association:
http://www.ecma.ch/
* The ECMA standards (counterparts to the ISO terminal standards).
The Terminal Information Archive:
http://www.cs.utk.edu/~shuford/terminal/
* Lots of useful info.
VT Terminal Information
http://vt100.net/
* This site has the VT220 reference manual online!
Yours,
Dominik Kubla
--
Networking Group, Hospital of Johannes Gutenberg-University
Obere Zahlbacher Straße 69, 55101 Mainz, Germany
Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521
|
|
From: James S. <jsi...@ac...> - 2000-03-07 19:13:48
|
> Hi. I've seen a lot of good stuff written in this list so far. (and were > not even a week old ;) Its just starting :) The number of people interested keeps growing. Even Eric Raymond is involved in this project. > also, another possiblity would be to make solid api's for the fb, and > inputX, then create whatever console code you wanted in userspace, bypassing > any of linus's kernel decisions. Personally I think this is the best approach for multihead aware programs. A VT should just be a one keyboard and one display. I used to think it was a cool idea to map a multiple devices like several display or several keyboards to a VT. So a VT would be 3 display and 2 keyboards and other crazy combos. Fbdev sort of does this now. It maps a console to a display. With working with fbdev I realize now its a PITA. Know I think its better if a app wants to be multihead aware to open the explict hardware devices and grab them for themselves. Now of course the kernel has to see if someone is using a VT for any device you want to explictly use. Take /dev/fb. You wouldn't want to be on a console and then all the sudden a X session starts because someone ran X on anther station requestion that head you are on. I really like to see the X server some day just using /dev/input and /dev/fb instead of any VTs like its does now. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Eric S. R. <es...@th...> - 2000-03-07 19:00:13
|
James Simmons <jsi...@ac...>: > You got it. Go have fun. Thank you for handling our web pages and adding > to our project. Hm.. I seems to be a develper now but not an admin. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 |
|
From: James S. <jsi...@ac...> - 2000-03-07 18:56:18
|
> Well, i can not send them and i think scanning and putting them on the web > is also a no-no. So i will act as a document server for these docs... ;-) > > I always intended to have the function description in the source right > at the start of the function... So your in charge of that. > Make the terminal emulation a loadable module. Have the console driver > look for module "vte" and then you can use the alias mechanismen of > modload to push the appropriate module. If that fails fall back to dumb > line mode (similiar to the framebuffer initialization). > > Does that appear a workable solution? Yes:) "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: James S. <jsi...@ac...> - 2000-03-07 18:52:28
|
ftp://ftp.clark.net/pub/dickey/vttest/vttest.tar.gz This program test to see if a console system is vt100 complainent. Here is some more console work=20 http://www-klinik.uni-mainz.de/staff/kubla/Linux/console.patch-2.2.1.gz "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/|=20 fbdev/gfx developer \ o.O|=20 http://www.linux-fbdev.org =3D(_)=3D=20 http://linuxgfx.sourceforge.net U It might or might not apply to later versions... Yours, Dominik Kubla --=20 Networking Group, Hospital of Johannes Gutenberg-University = =20 Obere Zahlbacher Stra=DFe 69, 55101 Mainz, Germany = =20 Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 = =20 |
|
From: James S. <jsi...@ac...> - 2000-03-07 18:32:04
|
You got it. Go have fun. Thank you for handling our web pages and adding to our project. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U On Tue, 7 Mar 2000, Eric S. Raymond wrote: > I'm ready to rough out a web page, submit a project description, and > so forth, as soon as I get administrator privs. > -- > <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> > > "Among the many misdeeds of the British rule in India, history will look > upon the act of depriving a whole nation of arms, as the blackest." > -- Mohandas Gandhi > > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linuxconsole-dev > |
|
From: Eric S. R. <es...@sn...> - 2000-03-07 17:43:55
|
I'm ready to rough out a web page, submit a project description, and so forth, as soon as I get administrator privs. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "Among the many misdeeds of the British rule in India, history will look upon the act of depriving a whole nation of arms, as the blackest." -- Mohandas Gandhi |
|
From: Dominik K. <dom...@un...> - 2000-03-07 14:42:30
|
On Tue, Mar 07, 2000 at 09:31:06AM -0500, James Simmons wrote: > > This would be really nice. I don't have any manuals for various terminals > so it would be nice if you could send them to me. Or better yet if we get > them on the projects web page. If it's legal. > Well, i can not send them and i think scanning and putting them on the web is also a no-no. So i will act as a document server for these docs... ;-) I always intended to have the function description in the source right at the start of the function... > Yeap. I like to see this too. Eterm for the console :) So a great step > forward would be to move terminal emulation into a seperate file. Write a > common interface for terminal emulation and write a nice HOWTO to create > a terminal type. Either that or provide a way for userland to shape the > terminal to the type it wants. I like to see that also in a seperate > file. Which do we think is better to do? A userland interface to set the > console to some type of emulation or provide a interface so someone could > write their own terminal emulation module. I kind of like the userland > solution. It coudl get bloated really quick. Make the terminal emulation a loadable module. Have the console driver look for module "vte" and then you can use the alias mechanismen of modload to push the appropriate module. If that fails fall back to dumb line mode (similiar to the framebuffer initialization). Does that appear a workable solution? Dominik |
|
From: James S. <jsi...@ac...> - 2000-03-07 14:25:42
|
> > I looked over your patch. It nice to see better VT102 emulation. I thought > > you where the one that posted about splitting the terminal emulation from > > I mentioned that as my goal in the message posted to lkml. So you are not > far of the mark. ;-) I thought so. I was going by memory. > > the console code. You could do things like HP console emulation etc. Thats > > a possible idea. > > All we need to do is to pull the necessary info out of *BSD's pcvt. And > there are other interesting variants, like Siemens (for those BS2000 folks) > or even 5250 or 3270 (argh!). I have a VT420 reference manual at hand and > can loan VT340 programmers manual if need should be (imagine: REGIS or > SIXEL graphics on the console). There is also the TEK4xxx emulation in > xterm (that would scrap the need for svgalib to run gnuplot on the console) This would be really nice. I don't have any manuals for various terminals so it would be nice if you could send them to me. Or better yet if we get them on the projects web page. If it's legal. > So there are lots of possibilities and if we offer a clean DDI to add > additional emulations besides the standard "linux" brand, we might see > them happen: people code all sorts of odd stuff if left alone with a > computer and some legacy hardware/software ;-) Yeap. I like to see this too. Eterm for the console :) So a great step forward would be to move terminal emulation into a seperate file. Write a common interface for terminal emulation and write a nice HOWTO to create a terminal type. Either that or provide a way for userland to shape the terminal to the type it wants. I like to see that also in a seperate file. Which do we think is better to do? A userland interface to set the console to some type of emulation or provide a interface so someone could write their own terminal emulation module. I kind of like the userland solution. It coudl get bloated really quick. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Firstname L. <ms...@ho...> - 2000-03-07 00:56:23
|
Hi. I've seen a lot of good stuff written in this list so far. (and were not even a week old ;) As for keeping things simple, the simplest way to get multi-console support is to add /dev/InputX (event) support to GGI. Someone said they were planning to do this, i forgot who. with /dev/InputX support, you should be able to run XGGI on one monitor, with a keyboard and mouse, and run a seperate instance on a second monitor, with a USB keybaord and differn't mouse. It might not be as flexable as you were hopeing, (actually you could probably just make extra drivers to generate /dev/InputX events, like one that hooks to telnetd, so someone could telnet in, and that input comming over the network could be used as the input of the console), or as fast as you were hopeing, but should be able to satisfy a large number of the cases, with minimal work, and get a lot more people interested in the project. (and ready to bitch about what they don't like with the way it's being done :) also i've heard that there's a ggi-terminal emulator, which let's you run a shell. Of course linus wouldn't be needed to do this either, since it dosn't mess with the kernel. also, another possiblity would be to make solid api's for the fb, and inputX, then create whatever console code you wanted in userspace, bypassing any of linus's kernel decisions. But adding event support to GGI is still the quickest way to get feedback. Corey (note: i don't know about others, but i intend to actually use this once it's created ;) ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com |
|
From: Firstname L. <ms...@ho...> - 2000-03-07 00:09:03
|
>Hey there. As I currently ``maintain`` (ha!) the EvStack/GGI Console >system, is there any call for a reimplementation of GGI Console >to 2.3.x, using the fbdev drivers instead of KGI? (not that >KGI backend support can`t be added..) > >A functional port of the output side of GGI Console to the 2.3.x kernel >will proably give us a good base to work on >multihead issues, and I can use the 2.3.x /dev/event system for input. > >Shouldn`t take more that two weeks by myself to port it to >the ix86 arch. Any takers on testing this project? >-- >Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. Yes! I have 2 matrox cards running fbdev, hooked to 2 monitors, a ps/2 keyboard, and a USB keyboard working as /dev/InputX (acutally i have a ATI card and a 3rd monitor, but not enough PCI slots... had to take out to get the USB card in :) I currently also have GGI running and use "tile" to tile across the 2 monitors. If you port evstack to the ix86, i'll test it on a recent 2.3.x and if it works, i can start tossing all those old 386's i've been keeping around to use as dumb Xterms/clients. :) Corey ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com |
|
From: <jmc...@li...> - 2000-03-05 18:13:45
|
Forgot to post where the EvStack (ancient) code resides: http://zhrodague.net/~jmcc/ggi/EvStack/ Pull down the entrie CVS repository. -- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 415.701.0792 fax jmc...@li..., http://www.linuxcare.com/ Linuxcare. Support for the revolution. |
|
From: Dominik K. <dom...@un...> - 2000-03-05 16:17:10
|
On Sun, Mar 05, 2000 at 11:13:00AM -0500, James Simmons wrote:
>
> I looked over your patch. It nice to see better VT102 emulation. I thought
> you where the one that posted about splitting the terminal emulation from
I mentioned that as my goal in the message posted to lkml. So you are not
far of the mark. ;-)
> the console code. You could do things like HP console emulation etc. Thats
> a possible idea.
All we need to do is to pull the necessary info out of *BSD's pcvt. And
there are other interesting variants, like Siemens (for those BS2000 folks)
or even 5250 or 3270 (argh!). I have a VT420 reference manual at hand and
can loan VT340 programmers manual if need should be (imagine: REGIS or
SIXEL graphics on the console). There is also the TEK4xxx emulation in
xterm (that would scrap the need for svgalib to run gnuplot on the console)
So there are lots of possibilities and if we offer a clean DDI to add
additional emulations besides the standard "linux" brand, we might see
them happen: people code all sorts of odd stuff if left alone with a
computer and some legacy hardware/software ;-)
Dominik
--
Looking for information about professional american football in Europe?
Then visit the independant "NFL@Europe Fan Site" at:
http://www-klinik.uni-mainz.de/staff/kubla/NFLE/
|
|
From: James S. <jsi...@ac...> - 2000-03-05 16:07:40
|
> IMO console and vc's are different. So let's agree on consistent terminology > right away: > > console = /dev/console System console device, might be serial terminal > or even a teletype/line printer. > > virtual tty's = /dev/tty[0-9]+ > > Virtual tty's with VT102 terminal emulation. > Should be called vt's IMHO and we should use > something like ptmx/pts to create the devices > on demand (what do you think? And PLEASE nobody > mention devfs in my presence!) Agree. In fact when I think VT I prefere to think of it as Video Terminal instead of virtual terminal. In theory you could have vitrual terminals even on serial consoles. P.S I read your page on devfs. > What i want to do is to separate the two. Keep the console small and clean. > If you are running linux on a PC104 embedded system with serial console, > then there is no need for VC's. Fortunately we can do this already, but the > code is still mixed right now. Agree. I like to see that as well. > Some thing we might want to look into is a network-base console (using UDP > unicast/multicast/broadcast or whatever one uses for these things). Wow. That would be powerful. > > Vojtechs work :) Screw the /dev/mouse crap. We have /dev/event. It > > basically works like /dev/shmiq on IRIX. Its a event queue. A app opens it > > and reads the event packets that arrive. It works for ANY input device :) > > Raw access to the input hardware. > > The problem i see here is that this becomes too opaque for the casual user. > Might be clean and nice from a design standpoint, but will certainly irritate > some folks. Well such a system is being used for USB already so I think people are getting use to it. Especially people with iMacs which have only USB. > > We have to deal with SMP multihead systems. You could have different > > processes running on different CPUs using different heads. As you can see > > we need locking to ensure data structures are altered by the wrong VT. > > Next problem I bet you didn't think about. Printk being called inside a > > bottom handler can also cause nasty race conditions. This was something > > Mares notices while working with Vojtech. > > Ouch! Your pulling my leg, do you? We don't even have support for partioning > linux systems and you want to build a console framework for this? But with > the /390 port and thingies like E10k around this is something we have to > think about. I'll ask a friend of mine about his input: he's the local expert > for the Convex/HP supercomputers... I think they use a seperate HP workstation > as console device. Nope I'm not pulling you leg. > It's the same i posted to linux-kernel last week when this discussion > started. Unfortunately i have (again!) no network when running >2.3.36 > kernels and my laptop just forgot about some essential keys (i wonder > what the DELL support will say about this when i call in tomorrow!) so i > am somewhat hobbled at the moment. I looked over your patch. It nice to see better VT102 emulation. I thought you where the one that posted about splitting the terminal emulation from the console code. You could do things like HP console emulation etc. Thats a possible idea. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Dominik K. <dom...@un...> - 2000-03-05 12:54:27
|
On Sat, Mar 04, 2000 at 11:48:05PM -0500, James Simmons wrote:
...
> Thats me and Geert writing that code :) What is needed to deal with in the
> console system is keeping track of what VTs are active. Right now only one
> can be active (fg_console) :(
IMO console and vc's are different. So let's agree on consistent terminology
right away:
console = /dev/console System console device, might be serial terminal
or even a teletype/line printer.
virtual tty's = /dev/tty[0-9]+
Virtual tty's with VT102 terminal emulation.
Should be called vt's IMHO and we should use
something like ptmx/pts to create the devices
on demand (what do you think? And PLEASE nobody
mention devfs in my presence!)
What i want to do is to separate the two. Keep the console small and clean.
If you are running linux on a PC104 embedded system with serial console,
then there is no need for VC's. Fortunately we can do this already, but the
code is still mixed right now.
Some thing we might want to look into is a network-base console (using UDP
unicast/multicast/broadcast or whatever one uses for these things).
> Vojtechs work :) Screw the /dev/mouse crap. We have /dev/event. It
> basically works like /dev/shmiq on IRIX. Its a event queue. A app opens it
> and reads the event packets that arrive. It works for ANY input device :)
> Raw access to the input hardware.
The problem i see here is that this becomes too opaque for the casual user.
Might be clean and nice from a design standpoint, but will certainly irritate
some folks.
> We have to deal with SMP multihead systems. You could have different
> processes running on different CPUs using different heads. As you can see
> we need locking to ensure data structures are altered by the wrong VT.
> Next problem I bet you didn't think about. Printk being called inside a
> bottom handler can also cause nasty race conditions. This was something
> Mares notices while working with Vojtech.
Ouch! Your pulling my leg, do you? We don't even have support for partioning
linux systems and you want to build a console framework for this? But with
the /390 port and thingies like E10k around this is something we have to
think about. I'll ask a friend of mine about his input: he's the local expert
for the Convex/HP supercomputers... I think they use a seperate HP workstation
as console device.
> > PS: I have put my console-patch up for grabs at:
> >
> > http://www-klinik.uni-mainz.de/staff/kubla/Linux/
It's the same i posted to linux-kernel last week when this discussion
started. Unfortunately i have (again!) no network when running >2.3.36
kernels and my laptop just forgot about some essential keys (i wonder
what the DELL support will say about this when i call in tomorrow!) so i
am somewhat hobbled at the moment.
Yours,
Dominik
--
Looking for information about professional american football in Europe?
Then visit the independant "NFL@Europe Fan Site" at:
http://www-klinik.uni-mainz.de/staff/kubla/NFLE/
|
|
From: <kim...@at...> - 2000-03-05 12:33:21
|
> 2. Multiple input devices (mice, keyboards, etc.): this needs tight
> cooperation with the USB folks to match what they do with non-USB
> drivers (to the extend applicable to the device in question). Only major
> point here is a clean-up of the various mouse drivers (excluding serial
> mice): there should be only one mouse protocol be spoken by /dev/mouse.
> Instead of the different minor devices we should have mouse0...mouseN
> with probing order defined at compile time and a kernel command line
> override.
The USB code uses a trimmed down version of Vojtech Pavlik's event
interface for HID devices. That includes keyboards, mice, tablets, um, ups's
I think, and pretty much anything that has a button on it. The rest of his
complete input patch handles most mice, and joystickts(oh yeah, USB ones
too). In the USB code the input interface is allready tagged as an option.
You need to enable keyboard compatibility and mouse emulation. If you don't
enable those options, then the only way to get input from those devices is
through his event interface device.
I'm currently attempting to slap together an XFree4 driver for Vojtech's
interface in my spare time. I'm hoping that with it you'll be able to have
X use a different keyboard than the kernel. Or, have two different X's use
different keyboards, for multiseat purposes.
As a matter of terminology, I think multiseat is a much better term for a
system where multiple people can sit down and have independant sessions.
Were as multihead could also be just somebody with a 3840x1024 desktop.
Both have their uses, and are /really/ neat, but we do need to tell the
ideas apart.
Back to the existing code. From what I can tell of the internal kernel
interface, all handlers can get a shot at all input, if they feel like it.
Which is consistant with me being able to type and read from the keyboard
evdev at the same time. So, if the console interface were able to handle
this style of input events the whole mess could be handled from either
userland or in the kernel, perhaps with some sort of fallover.
userland: "cat /dev/evdev0 > /dev/consoledev0" effectivly attaches evdev0
to console0. Ugly, but functional.
kernel: input_register_handler(&console_handler); - the same event parser
would be used, so we could get both interfaces for the price of one.
As for that fallover, what I meant by that is, maybe, any device(s) not
explicitly claimed by anything else(any console) would just fall through to
a default. That way no configuration would need to be done in the
default/simplest case. ei: you let the smoke out of your AT/PS2 keyboard
port. No problem, just plug in a USB keyboard and everything is happy.
Then, of course, there is the biggest reason for considering Vojtech's
interface: It's allready in the kernel, via the USB code.
-- Nick Lopez
kim...@at...
|
1998 messages has been excluded from this view by a project administrator.
