Menu
▾
▴
linuxconsole-dev
|
From: Eric S. R. <es...@sn...> - 2000-03-08 09:39:33
|
OK. I think I have a minimal patch, equivalent to Dominik's 2.2.1 patch, that works on the 2.2.12 console.c. This is a candidate for Sapphire 1, but it's not tested yet; I should probably sleep before I try rebuilding my kernel ;-). Dominik, am I correct in believing these are all of the functional changes in the emulation? \E[6m blink added \E[21m turn off 1 removed 0x84 IND added 0x85 NEL added 0x88 HTS added 0x8d RI added \E[?6n DECXCPR added \E[?15n Printer status added \E[?25n UDK status added \E[?26n Keyboard status added \E[?75n Data integrity added \E[x DECREQTPARM added \E[ n k VPB added \E[ n j HPB added \E[ n I CHT added \E[ n W CTC added (n=0, 2, 5) \E[ n Y CVT added \E[ n Z CBT added \E[s DECRC removed \E[u DECSC removed And, if I have it right, you didn't mess with anything that was (a) before the comment "VT102 emulator" (b) after the end of do_con_trol (except for the ESnormal->ESinit change in do_con_write). If so, then I have reduced the patch from 99K to 18K. I think this makes it rather more likely to be accepted :-). -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Good intentions will always be pleaded for every assumption of authority. It is hardly too strong to say that the Constitution was made to guard the people against the dangers of good intentions. There are men in all ages who mean to govern well, but they mean to govern. They promise to be good masters, but they mean to be masters. -- Daniel Webster |
|
From: Dominik K. <dom...@un...> - 2000-03-08 10:35:12
|
On Wed, Mar 08, 2000 at 04:38:31AM -0500, Eric S. Raymond wrote: > OK. I think I have a minimal patch, equivalent to Dominik's 2.2.1 > patch, that works on the 2.2.12 console.c. This is a candidate for > Sapphire 1, but it's not tested yet; I should probably sleep before I > try rebuilding my kernel ;-). > > Dominik, am I correct in believing these are all of the functional > changes in the emulation? > > \E[6m blink added > \E[21m turn off 1 removed > 0x84 IND added > 0x85 NEL added > 0x88 HTS added > 0x8d RI added > \E[?6n DECXCPR added > \E[?15n Printer status added > \E[?25n UDK status added > \E[?26n Keyboard status added > \E[?75n Data integrity added > \E[x DECREQTPARM added > \E[ n k VPB added > \E[ n j HPB added > \E[ n I CHT added > \E[ n W CTC added (n=0, 2, 5) > \E[ n Y CVT added > \E[ n Z CBT added > \E[s DECRC removed > \E[u DECSC removed Looks like it. BTW i would prefer that you use the correct CSI instead of \E[, because \E[ is only the 7bit translation of the correct C1 control code. Of coures you would have to define the term "Control Sequence Introducer" before using it. And the page should mention how a valid ESCape and control has to look like. See the following references: ECMA-35 (ISO 2022), Section 13, "Structure and use of escape sequences" ECMA-48 (ISO 6429), Section 5.4, "Control sequences" > And, if I have it right, you didn't mess with anything that was > > (a) before the comment "VT102 emulator" > (b) after the end of do_con_trol (except for the ESnormal->ESinit > change in do_con_write). I think so, but i am not sure. I am just working on a 2.2.14 patch... > If so, then I have reduced the patch from 99K to 18K. I think this > makes it rather more likely to be accepted :-). We should also patch the MAINTAINERS file, shouldn't we? 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: Eric S. R. <es...@th...> - 2000-03-08 10:51:50
|
Dominik Kubla <dom...@un...>: > > Dominik, am I correct in believing these are all of the functional > > changes in the emulation? > > Looks like it. BTW i would prefer that you use the correct CSI instead > of \E[, because \E[ is only the 7bit translation of the correct C1 control > code. Of coures you would have to define the term "Control Sequence > Introducer" before using it. And the page should mention how a valid > ESCape and control has to look like. console_codes(4) already covers this. I'll make sure I conform. > > And, if I have it right, you didn't mess with anything that was > > > > (a) before the comment "VT102 emulator" > > (b) after the end of do_con_trol (except for the ESnormal->ESinit > > change in do_con_write). > > I think so, but i am not sure. I am just working on a 2.2.14 patch... How will this differ from the 2.2.12 patch I just generated? We may be unnecessarily duplicating work here... > We should also patch the MAINTAINERS file, shouldn't we? Yes, but how we do that exactly will depend on how we do our release packaging (which is James's problem). BTW, in the revised console_codes(4) page, I refer to the existing console as `version 1'. You and I are working on `version 2', emulation patches only. Versions 3 and up will be the big rewrite. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Morality is always the product of terror; its chains and strait-waistcoats are fashioned by those who dare not trust others, because they dare not trust themselves, to walk in liberty. -- Aldous Huxley |
|
From: Dominik K. <dom...@un...> - 2000-03-08 12:13:16
|
On Wed, Mar 08, 2000 at 05:50:43AM -0500, Eric S. Raymond wrote: > How will this differ from the 2.2.12 patch I just generated? We may be > unnecessarily duplicating work here... The 2.2.1 patch of mine had much more in it then just simple vt102 related fixes (some of the control sequences are for vt220 and up). But i guess they can stay. So if you'll send me your version of the patch, i will base the 2.2 branch on that. One question arise: should i bother to backport the 2.2 stuff to 2.0? Given the fact that 2.0 is still seen as somewhat more stable than 2.2 and that it appears to be a one-timer (since there won't be too many new 2.0 release). I would say yes. > BTW, in the revised console_codes(4) page, I refer to the existing > console as `version 1'. You and I are working on `version 2', emulation > patches only. Versions 3 and up will be the big rewrite. VT320 terminals provide a secondary and tertiary DA, which i am likely to implement to give the user-land an idea about the version of the console emulator. Secondary DA: Request: CSI > 0 c Reply: CSI > 41 ; Pv ; 0 c (where Pv is the firmware revision) Tertiary DA: Request: CSI = 0 c Reply: DCS ! | D...D ST (where D...D is the device id) Haven figured out a use for the tertiary DA yet. Using the hostid as device id has the same implications as the Unique Processor ID of Pentium III cpus (ignoring the fact that hostid is in widespread use in the Unix world) Comments? 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: Eric S. R. <es...@th...> - 2000-03-08 16:26:14
Attachments:
PATCH
|
Dominik Kubla <dom...@un...>: > The 2.2.1 patch of mine had much more in it then just simple vt102 > related fixes (some of the control sequences are for vt220 and up). > But i guess they can stay. So if you'll send me your version of the patch, > i will base the 2.2 branch on that. Enclosed. > One question arise: should i bother to backport the 2.2 stuff to 2.0? > Given the fact that 2.0 is still seen as somewhat more stable than > 2.2 and that it appears to be a one-timer (since there won't be too > many new 2.0 release). I would say yes. I doubt there's much extra work involved as the console driver hasn't changed that fast. So we might as well ship for 2.0 as well. > > BTW, in the revised console_codes(4) page, I refer to the existing > > console as `version 1'. You and I are working on `version 2', emulation > > patches only. Versions 3 and up will be the big rewrite. > > VT320 terminals provide a secondary and tertiary DA, which i am likely to > implement to give the user-land an idea about the version of the console > emulator. > > Secondary DA: > > Request: CSI > 0 c > Reply: CSI > 41 ; Pv ; 0 c (where Pv is the firmware revision) OK. To make version comparisons easier later on, I suggest we return "200" for the first version. > Tertiary DA: > > Request: CSI = 0 c > Reply: DCS ! | D...D ST (where D...D is the device id) > > Haven figured out a use for the tertiary DA yet. Using the hostid > as device id has the same implications as the Unique Processor ID > of Pentium III cpus (ignoring the fact that hostid is in widespread > use in the Unix world) I think I'd stay away from that. This reminds me. What do your canned responses to the Keyboard Status, Data Integrity check, and DECREQTPARM actually mean? I want to mention this in the man page. (I was able to find docs on the printer and UDK status). -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell |
|
From: Dominik K. <dom...@un...> - 2000-03-08 17:14:19
|
On Wed, Mar 08, 2000 at 11:24:49AM -0500, Eric S. Raymond wrote:
...
> > Haven figured out a use for the tertiary DA yet. Using the hostid
> > as device id has the same implications as the Unique Processor ID
> > of Pentium III cpus (ignoring the fact that hostid is in widespread
> > use in the Unix world)
>
> I think I'd stay away from that.
Well we could report the instance: eg. 1 for tty1, 2 for tty2, that could
be useful and wouldn't waste too many bytes...
> This reminds me. What do your canned responses to the Keyboard Status,
> Data Integrity check, and DECREQTPARM actually mean? I want to mention this
> in the man page. (I was able to find docs on the printer and UDK status).
Keyboard Status Report (Source: VT420 Progamming Summary, p147):
Request (Host to VT420) CSI ? 26 n
Report (VT420 to Host) CSI ? 27 ; Pla ; Pst ; Ptyp n
Pla = keyboard dialect
1 = North American
2 = British
3 = Flemish
4 = French Canadian
5 = Danish
6 = Finnish
7 = German
8 = Dutch
9 = Italian
10 = Swiss French
11 = Swiss German
12 = Swedish
13 = Norwegian
14 = French/Belgian
15 = Spanish
16 = Portuguese
28 = Canadian (English)
Pst = keyboard status
0 = keyboard ready
3 = no keyboard
8 = keyboard busy
Ptyp= keyboard type
0 = LK201
1 = LK401
DECREPTPARM (Source: http://www.cs.utk.edu/~shuford/terminal/virek100.txt)
Report (VT100 to Host) CSI Ps ; Pp ; Pb ; Px ; Pr ; Pm ; Pf x
Ps = type of report
1 = report as requested by the host
2 = unsolicited report
Pp = parity
1 = no parity
4 = even parity
5 = odd parity
Pb = bits per character
1 = 8 bits
2 = 7 bits
Px = transmit speed
Pr = receive speed
0 = 50 bps
8 = 75 bps
16 = 110 bps
24 = 134.5 bps
32 = 150 bps
40 = 200 bps
48 = 300 bps
56 = 600 bps
64 = 1200 bps
72 = 1800 bps
80 = 2000 bps
88 = 2400 bps
96 = 3600 bps
104 = 4800 bps
112 = 9600 bps
120 = 19200 bps
Pm = bit rate multiplier
1 = 16x
Pf = value of the for switches in block 5 of SETUP-B if the STP
option is installed.
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: Eric S. R. <es...@th...> - 2000-03-08 17:32:58
|
Dominik Kubla <dom...@un...>: > Well we could report the instance: eg. 1 for tty1, 2 for tty2, that could > be useful and wouldn't waste too many bytes... True. > Keyboard Status Report (Source: VT420 Progamming Summary, p147): > DECREPTPARM (Source: http://www.cs.utk.edu/~shuford/terminal/virek100.txt) Great! I'll include these resources in nroff comments in the man page source. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787 |
|
From: James S. <jsi...@ac...> - 2000-03-08 16:34:45
|
> > We should also patch the MAINTAINERS file, shouldn't we?
>
> Yes, but how we do that exactly will depend on how we do our release
> packaging (which is James's problem).
The best thing to do is place these patches in CVS and announce it on
linux-kernel so people can go test it. Have CVS with 3 top directorys for
each release. Sapphire, emrald, and ruby. Ruby is going to be the big on!
Once we get feed back and any possible bug fixes we can send it off to
linus. Perhapsa tree like this
CVS -> shappire -> v2.0
-> v2.2
-> v2.3
-> emrald -> v2.0
-> v2.2
-> v2.3
-> ruby -> v2.3
-> v2.4
I have been working on fbdev today with a few new patchs. I going to see
if I can sneak some time in to clean up the data struct stuff. Their are
three data structs for the current console system.
struct vt_struct;
struct vc_data;
struct vc;
struct vt_struct is whats in tty->driver_data. Their is only some code
relating to it in vt.c. Struct vc_data is everywhere for a video terminal
system. I don't see it in any serial consoel code. It is a hardware
independent data struct that represents the state of the video terminal
device. The next data struct is vc which is this
struct vc {
struct vc_data *d;
/* might add scrmem, vt_struct, kbd at some time,
to have everything in one place - the disadvantage
would be that vc_cons etc can no longer be static */
};
Which is really used anywhere. Just a few struct vc_data *conp =
vc_cons[con].d;
So it would look like using just vc_data and expanding it would be the
best choose I think. Any opinons?
"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 16:52:45
|
James Simmons <jsi...@ac...>: > > > > We should also patch the MAINTAINERS file, shouldn't we? > > > > Yes, but how we do that exactly will depend on how we do our release > > packaging (which is James's problem). > > The best thing to do is place these patches in CVS and announce it on > linux-kernel so people can go test it. Have CVS with 3 top directorys for > each release. Sapphire, emrald, and ruby. OK. I gather the idea is that the base version of each file in the CVS is copied from the release we're going to ship the patch for? Sapphire is in good shape, I think. I've handed a Sapphire candidate to Dominik. I will test my copy later today, after I finish updating console_codes(4). > So it would look like using just vc_data and expanding it would be the > best choose I think. Any opinons? Not from here, I don't know that code. BTW, have we done a public launch announcement for c.o.l.a yet? If not, I'll write and ship one. -- <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-09 00:51:33
|
> > The best thing to do is place these patches in CVS and announce it on > > linux-kernel so people can go test it. Have CVS with 3 top directorys for > > each release. Sapphire, emrald, and ruby. > > OK. I gather the idea is that the base version of each file in the CVS is > copied from the release we're going to ship the patch for? The idea is to keep seperate the emarld, sapphire and ruby branch. People don't want to download our work for 2.0.x, 2.2.x, and 2.3.X. This saved on the download. > Sapphire is in good shape, I think. I've handed a Sapphire candidate > to Dominik. I will test my copy later today, after I finish updating > console_codes(4). Cool. Now that CVS is ready we can place it in there. > > So it would look like using just vc_data and expanding it would be the > > best choose I think. Any opinons? > > Not from here, I don't know that code. Hum I will talk to linus about this. I don't want to do something that linus doesn't like. > BTW, have we done a public launch announcement for c.o.l.a yet? > If not, I'll write and ship one. Not really. I announced it on lkml but that was it. "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-09 04:34:39
|
James Simmons <jsi...@ac...>: > Cool. Now that CVS is ready we can place it in there. It's still really Dominik's patch -- I'll let him check it in. I'm not sure how to handle the changes to console_codes(4). Maybe I'll just ship those direct to Andries. > > BTW, have we done a public launch announcement for c.o.l.a yet? > > If not, I'll write and ship one. > > Not really. I announced it on lkml but that was it. OK, I'll get us some publicity. I'm good at that ;-). Though, on second thought, maybe the time to make noise might be when we ship Emerald and Sapphire? I kind of like putting working code on the table along with an announcement. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear.... Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew |
|
From: James S. <jsi...@ac...> - 2000-03-09 15:50:13
|
On Wed, 8 Mar 2000, Eric S. Raymond wrote: > James Simmons <jsi...@ac...>: > > Cool. Now that CVS is ready we can place it in there. > > It's still really Dominik's patch -- I'll let him check it in. > I'm not sure how to handle the changes to console_codes(4). Maybe > I'll just ship those direct to Andries. Okay. He needs a sourceforge account to check it in. > OK, I'll get us some publicity. I'm good at that ;-). Though, on second > thought, maybe the time to make noise might be when we ship Emerald and > Sapphire? I kind of like putting working code on the table along with > an announcement. Not yet. Once we have code for people to download and play with. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Mike A. H. <mh...@me...> - 2000-03-09 19:44:26
|
On Wed, 8 Mar 2000, Eric S. Raymond wrote: >Date: Wed, 8 Mar 2000 23:33:24 -0500 >From: Eric S. Raymond <es...@th...> >To: James Simmons <jsi...@ac...> >Cc: Linux Console Project <lin...@li...> >Subject: Re: [Linuxconsole-dev] Progress on Sapphire > >James Simmons <jsi...@ac...>: >> Cool. Now that CVS is ready we can place it in there. > >It's still really Dominik's patch -- I'll let him check it in. >I'm not sure how to handle the changes to console_codes(4). Maybe >I'll just ship those direct to Andries. > >> > BTW, have we done a public launch announcement for c.o.l.a yet? >> > If not, I'll write and ship one. >> >> Not really. I announced it on lkml but that was it. > >OK, I'll get us some publicity. I'm good at that ;-). Though, on second >thought, maybe the time to make noise might be when we ship Emerald and >Sapphire? I kind of like putting working code on the table along with >an announcement. I agree. Otherwise we could get /.ed and not really have anything for people to look at. They'd likely look and then forget about the project as too premature.. Lets hold off on a c.o.l.a announcement until code is ready - assuming it will be soon of course. Take care, TTYL -- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate Suspicious Anagram #4: Word: PRESIDENT CLINTON OF THE USA Anagram: TO COPULATE HE FINDS INTERNS |
|
From: Eric S. R. <es...@th...> - 2000-03-09 20:05:14
|
Mike A. Harris <mh...@me...>: > I agree. Otherwise we could get /.ed and not really have > anything for people to look at. They'd likely look and then > forget about the project as too premature.. Lets hold off on a > c.o.l.a announcement until code is ready - assuming it will be > soon of course. We're kind of blocked on Dominik right now. He has to produce versions of Emerald and Sapphiire that can be applied to 2.2.14 and the current 2.3.x before we can go forward. I've got the documentation changes ready. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary. -- H.L. Mencken |
|
From: Dominik K. <dom...@un...> - 2000-03-10 08:17:19
|
On Thu, Mar 09, 2000 at 03:03:35PM -0500, Eric S. Raymond wrote: > Mike A. Harris <mh...@me...>: > > I agree. Otherwise we could get /.ed and not really have > > anything for people to look at. They'd likely look and then > > forget about the project as too premature.. Lets hold off on a > > c.o.l.a announcement until code is ready - assuming it will be > > soon of course. > > We're kind of blocked on Dominik right now. He has to produce > versions of Emerald and Sapphiire that can be applied to 2.2.14 > and the current 2.3.x before we can go forward. I'm working! I'm working! :-) I hope to have the first "vt102-only" patches ready over the weekend, together with a list of open issues. Unfortunately some very important work-related problemes have cropped up on my end, which takes an unforseen amount of time right now.... 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 |
Thanks for helping keep SourceForge clean.
X