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: James S. <jsi...@ac...> - 2000-03-11 14:56:01
|
> > Bloat. He doesn't even like the idea of posix termios in the kernel. > > He feels that userland should define any other type of console. > > That is what I was thinking, but thinking about what Eric said convinced me > otherwise. There are definite advantages to having all the terminal > emulations hidden behind the /dev/ttyN that we're used to using. I don't knwo what to think about this. I do know I want the terminal emulation in a seperate file just for clean code. As for modularity that will have to be discussed with Linus and Alan. "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: James S. <jsi...@ac...> - 2000-03-11 14:47:58
|
On Sat, 11 Mar 2000, Jim Peters wrote: > I'm clear about consoles - each of /dev/tty[1-6] and X-Windows in my example > is a separate console, only one of which is displayed at any one time. > > I'm also clear about heads in sense of a bunch of hardware all somehow in > use together, by one person. > > In your CAD example, those 8 keyboard/screen combinations could in fact be 8 > heads, if used independently (one person checking his mail, the next > editing, whatever). > > However, for your big everyone-work-on-the-same-screen example, they count > as just one head, right, that has 8 users ? > > Clear I think. You got it :) > When I was thinking about one keyboard and two monitors, I was thinking of > two independent consoles being displayed on the two monitors. If we have > hot-keys to switch the keyboard from one monitor to the other, then > effectively we have an emulation of two heads, since these two consoles are > independent. It's like constantly plugging the keyboard into one port or > the other, or having a switch-box in the line to switch between the two > ports. I rather see one head form from the one keyboard and one monitor. The other video display sort of hanges out their waiting for some userland app to grab it. "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: James S. <jsi...@ac...> - 2000-03-11 14:46:06
|
On Fri, 10 Mar 2000, Brad Midgley wrote: > > At the present, I suggest a master/slave[x] designation somewhere in fbdev > > and have data destined for the console spew onto the master. I'll talk with > > another thing people want to see is mirroring to two monitors (eg on a > laptop with an external projector connected). it makes the most sense to > have the kernel doing it (rather than, say, trying to hack X to drive two > different framebuffers with the same image) Have the kernel handle this would be messy. Have a api that allows a userland app to piece it together would be cleaner and easier to manage. "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: James S. <jsi...@ac...> - 2000-03-11 14:37:02
|
On Sat, 11 Mar 2000, Eric S. Raymond wrote: > I now have *tested* and conditionalized patches against 2.2.14 and 2.3.51. > We could ship these...but I'd like the rest of you to test them first. Okay. With vttest I assume. > James, are you going to check the 2.2.14 and 2.3.51 console.c files > in as baselines? Yes. I already have. Just modify the console code with your diff and place it in CVS. P.S I'm laying out the directory tree structure for ruby :) "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: Jim P. <ji...@ag...> - 2000-03-11 09:32:06
|
James Simmons wrote:
> > What is his objection?
>
> Bloat. He doesn't even like the idea of posix termios in the kernel.
> He feels that userland should define any other type of console.
That is what I was thinking, but thinking about what Eric said convinced me
otherwise. There are definite advantages to having all the terminal
emulations hidden behind the /dev/ttyN that we're used to using.
If the solution *has* to exist in user-land, then kernel changes will be
needed to redirect tty input/output on a per-tty basis from the back end of
the /dev/tty device (after stty stuff) to a selected user-space console
server, which will then in turn plug into the input event stream, and some
kind of display (fbdev or GGI?).
Maybe have some kind of /dev/??? device that the console server connects to,
which allows it to feed input bytes to the /dev/tty* ttys it's been assigned
to, and receive output bytes sent to those ttys. Perhaps a stream of:
{ tty-number length-in-bytes data-bytes } x ???
The kernel code would act as a kind of multiplexor, gathering/distributing
data between the list of current ttys and current console servers through
this interface. The standard `linux' console-code would remain as a default
and fall-back within the kernel.
I can see advantages of having a console server outside the kernel, in that
it can use interfaces that are not designed to be used from within the
kernel, if it wishes, such as GGI. Will fbdev acceleration also require
cooperation from user-space libraries ? In which case the same applies
here.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim@aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
|
|
From: Jim P. <ji...@ag...> - 2000-03-11 09:31:56
|
I'm clear about consoles - each of /dev/tty[1-6] and X-Windows in my example
is a separate console, only one of which is displayed at any one time.
I'm also clear about heads in sense of a bunch of hardware all somehow in
use together, by one person.
In your CAD example, those 8 keyboard/screen combinations could in fact be 8
heads, if used independently (one person checking his mail, the next
editing, whatever).
However, for your big everyone-work-on-the-same-screen example, they count
as just one head, right, that has 8 users ?
Clear I think.
When I was thinking about one keyboard and two monitors, I was thinking of
two independent consoles being displayed on the two monitors. If we have
hot-keys to switch the keyboard from one monitor to the other, then
effectively we have an emulation of two heads, since these two consoles are
independent. It's like constantly plugging the keyboard into one port or
the other, or having a switch-box in the line to switch between the two
ports.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim@aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
|
|
From: Eric S. R. <es...@th...> - 2000-03-11 08:29:53
|
I now have *tested* and conditionalized patches against 2.2.14 and 2.3.51. We could ship these...but I'd like the rest of you to test them first. James, are you going to check the 2.2.14 and 2.3.51 console.c files in as baselines? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, "Policy Lessons from Recent Gun Control Research," |
|
From: Eric S. R. <es...@th...> - 2000-03-11 07:46:48
|
OK, I now have fully conditionalized versions of both Sapphire and Emerald (I downloaded 2.3.51 earlier tonight so I *know* the diffs are good). -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Faith may be defined briefly as an illogical belief in the occurrence of the improbable...A man full of faith is simply one who has lost (or never had) the capacity for clear and realistic thought. He is not a mere ass: he is actually ill. -- H. L. Mencken |
|
From: Brad M. <br...@tu...> - 2000-03-11 06:13:34
|
> At the present, I suggest a master/slave[x] designation somewhere in fbdev > and have data destined for the console spew onto the master. I'll talk with another thing people want to see is mirroring to two monitors (eg on a laptop with an external projector connected). it makes the most sense to have the kernel doing it (rather than, say, trying to hack X to drive two different framebuffers with the same image) Brad Turbolinux Frontier Group br...@tu... | http://www.turbolinux.com/~brad/ |
|
From: James S. <jsi...@ac...> - 2000-03-11 04:01:55
|
One other thing. I will be moving my contining fbdev api changes to this tree. This way I can send all the changes right away to linus when 2.5.X comes out. "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: James S. <jsi...@ac...> - 2000-03-11 04:00:01
|
> > should printk go to. Any suggestion anyone ? > > At the present, I suggest a master/slave[x] designation somewhere in fbdev > and have data destined for the console spew onto the master. I'll talk with > Petr and ask for his input and experiences. I'll move further discussion of > this thread to linux-fbdev, since it's really a fbdev issue. Not really. What about the ability to send kernel output to the printer. Yes 2.3.X does have such ability. What about a system with a serial console and regular VT. Yes some PC motherboards are now starting to support serial consoles. The ia64 machines have both I believe. Which one do we send it to then. "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: Brad D. <Br...@NE...> - 2000-03-11 03:54:47
|
> -----Original Message----- > From: James Simmons [mailto:jsi...@ac...] > > > I guess a head could simply be defined as "A head is equal > to an active VT". > > The definition of a head is implied by VT. > > No. More than one VT can be on a head. I like the idea of VT > pools per > head. Why do I call it pools. Because I like to think of it > expandable > and shrinkable. Right now their is 32 VTs. With a multihead > system you > would have number of heads * 32 VTs. This can get quite > expensive. So you > would start with one VT and if you VT switch grow a new VT. > So teh VT pool > grows. Only one VT can be active per head. Yes, you're right. At it's core, a head can have (theoretcally) an unlimited number of VTs, but there will always be at least one. That's why I chose the wording I did. Perhaps it is too vague. > > My question didn't get answered, tho... Or maybe I'm using > the wrong > > definition of console: Can there be two active consoles at > the same time > > (in the instance of multi-head)? When I ask this, I'm > thinking of say, > > kernel message output to console. > > I have though about that but have no answer. In a multihead > system where > should printk go to. Any suggestion anyone ? At the present, I suggest a master/slave[x] designation somewhere in fbdev and have data destined for the console spew onto the master. I'll talk with Petr and ask for his input and experiences. I'll move further discussion of this thread to linux-fbdev, since it's really a fbdev issue. Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@ac...> - 2000-03-11 03:54:00
|
> If I suggest a concrete example, can you tell me which are heads and which > are consoles ? This is hypothetical example, that I think may be possible, > if I understand correctly what is being suggested. > > Let's say we have two desks back-to-back, a machine on the floor, with two > video cards, and two monitors, two keyboards, two mice plugged in. Two > people use that one machine, independently, running console-programs on > several screens (switched with Alt-Fn), and also running X-Windows and > X-Windows apps. Physically we have two independent `stations' (by which I'm > meaning seat-desk-keyboard-monitor). Are these two `heads' ? Or are they > two `consoles', with multiple `heads' being switched between with (Ctrl-) > Alt-F?. Okay. We have some confussion. A console is a device thats composed of a keyboard type of device and some video output. This can be a real console like a serial console. It can be a virtual terminal, meaning a fake or emulated serial console, thats made of a pc keyboard and a video card with monitor. To see different examples of different types of consoles look at the console_init function in tty_io.c. What you described above is a system with two ACTIVE consoles and several inactive consoles depending on how many different VTs both people are logged into. Say person one is logged into 3 different VTs and person 2 is logged in 5. Thus we have 6 ((5+3)-2 active) inactive console. A head is a bit different since its just a collect of input and output devices working together. In this example we have 2 heads. Let me give you a example of another type of a head. Imagine you work at a engineering company working on a CAD project. Now a team wants to work on this project. Say we have a multiheaded system with 8 keyboards and 8 fbdev devices so in essence we have 8 seperate active consoles. It would be ideal of each video output showed the same thing but each person at each console could modify that image on the screen. So each worker can alter in project in real time with respect to each other. So when the app would start you would open each /dev/fb and accept input from each keyboard/mouse from where each employee is sitting. So this is one head a app created that's composed of a several fbdev and input devices. Now in this case all the fbdev drivers show the same image. Now if really want to get fancy you could have it so each fbdev is a part of a big desktop. Imagine a projection on a wall made from a several fbdev images pieced together and the inputs be hooked to it. Each empolyee can look at the wall and you would see several cursors flying around doing abunch of things each independent of each other. Like one empolyee closing some window and another moving one. Consider a class of students with a teacher. Now their is only one computer with a bunch of keyboards and a bunch of video outputs devices. The teacher has one console go to his/her desk and the other consoles go to the students. Now the teacher wants to give a presentation. So the teacher wants what he/she has on her console displayed on all the students consoles. Now we don't want the students fooling around with the presentation so they are in essence locked out. The app the teacher starts grabs all their video outputs but not their keyboards. Here we have a head that composed of several video outputs and one keyboard. Of course you can create more than one head by say you doing both thing above at the same time. > Let's say we add a VT100 terminal on the next desk on a serial cable. Is > this another `console', or `head', or both ? Or is just one of these three > `stations' really considered to be the official `console' of the system ? All 3 would be a active console of the system. > Things seem to get much more confusing if we think of someone with one > keyboard/mouse and two monitors, with some hot-keys to switch the stream of > input events between one monitor or the other (between the applications > visibly running on those monitors). But this could be seen as a kind of > emulation of the two `stations' above - somehow an emulation of two > keyboards/mice through just one. Here you have one console (one keyboard/one monitor) and one floating monitor that free for a app to grab. Userland builds the head. The app could grab the keyboard and the two monitors. In this case this means any input is sent to both video outputs devices. > Or is this too inflexible a viewpoint ? You may want your two monitors to > work in cooperation, perhaps moving apps from one monitor to the other, or > even having X-Windows spanning two monitors. To me this bunch of hardware > counts as one `station', but does it count as multiple `heads' or multiple > `consoles' as well ? Confusing. See above. "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: James S. <jsi...@ac...> - 2000-03-11 03:17:25
|
On Fri, 10 Mar 2000, Eric S. Raymond wrote: > James Simmons <jsi...@ac...>: > > I saw that too. Me depressed. I didn't finish my fbdev changes. Also > > Vojtech input suite didn't get in :( It looks like we have alot of work > > cut out for us. > > I'll conditionalize the Sapphire patch so the new features aren't > enabled unless you set CONSOLE_VERSION >= 200. We should do the same thing > with the 2.3.x patch. Maybe I'll get to both tonight. Thats a good idea. As soon as 2.4.0 is out I will move the necessary branches into CVS. It should be easy to keep it in sync with 2.4.X "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: Eric S. R. <es...@th...> - 2000-03-11 03:08:44
|
James Simmons <jsi...@ac...>: > I saw that too. Me depressed. I didn't finish my fbdev changes. Also > Vojtech input suite didn't get in :( It looks like we have alot of work > cut out for us. I'll conditionalize the Sapphire patch so the new features aren't enabled unless you set CONSOLE_VERSION >= 200. We should do the same thing with the 2.3.x patch. Maybe I'll get to both tonight. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Still, if you will not fight for the right when you can easily win without bloodshed, if you will not fight when your victory will be sure and not so costly, you may come to the moment when you will have to fight with all the odds against you and only a precarious chance for survival. There may be a worse case. You may have to fight when there is no chance of victory, because it is better to perish than to live as slaves. --Winston Churchill |
|
From: James S. <jsi...@ac...> - 2000-03-11 03:06:17
|
> I guess a head could simply be defined as "A head is equal to an active VT". > The definition of a head is implied by VT. No. More than one VT can be on a head. I like the idea of VT pools per head. Why do I call it pools. Because I like to think of it expandable and shrinkable. Right now their is 32 VTs. With a multihead system you would have number of heads * 32 VTs. This can get quite expensive. So you would start with one VT and if you VT switch grow a new VT. So teh VT pool grows. Only one VT can be active per head. > My question didn't get answered, tho... Or maybe I'm using the wrong > definition of console: Can there be two active consoles at the same time > (in the instance of multi-head)? When I ask this, I'm thinking of say, > kernel message output to console. I have though about that but have no answer. In a multihead system where should printk go to. Any suggestion anyone ? "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: James S. <jsi...@ac...> - 2000-03-11 03:00:20
|
> >If the X driver or some svgalib application dropped out without
> >resetting the fb mode correctly, then the local ttys became "lost" and
> >unviewable. (Any way out of this?) svgalib is particular nasty to
> >use with the console fb.
Never ever use libsvga with fbdev. Both hit the hardware at the same time
and for low end hardware this locks the card or even damages it. As for
the X problem I have a patch that saves the console mode before opening
/dev/fb. If X dies then /dev/fb is closed which then restores the video
mode back to normal. Also fbdev drivers should be check all modes before
actually setting them so you can't set insane modes.
> I've heard that the sysRq key is supposed to help. compile in "magic sysRq
> key" support in the kernel, then press Alt-SysRq-{some letter which i
> forgot}.
Alt-SysRq-K
> i never got it working, cause i haven't had the problem and the
> sysRq key at the same time, but *tell me if you get it working* I would very
> much like to have the procedure for this figured out.
If you still set a insane mode often the fbdev drivers are not written
well enough to check the mode. This leaves the console in a undefine state.
Even the magic keys can't save you.
> >I have been particular vulnerable to this
> >since I've been using banshee and voodoo3 cards for quite a while and
> >their drivers are vastly improving and still not 100% stable. I've
> >also been meaning to have a good look at ggi, but too much to do and
> >so little time...
GGI take advantage of video hardware in any environment. Its preety neat.
I use Mesa-GGI so I can run OpenGL on the console with fbdev of course.
"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: James S. <jsi...@ac...> - 2000-03-11 02:17:03
|
> echo -e "subscribe linux-console\n.\n" | mail -s subscribe maj...@vg... I subscribed just in case. We need to show them to here. > > About a week ago. > > Great, then I (we) haven't missed out on _too_ much :) Look threw the archives for the goods. > > > What changes are planned? > > [ ... lots of cool ideas, plans, wishes and stuff ... ] Alot. As you follow the list you will see the goals. > > > I'd eventually like to be able to set/reset on a per-console basis > > > whatever video modes I like, > > > > Okay. Fbcon allows that to a limited degree. See other post. > Anyway good luck with this project, it sounds very worthwhile. Thanks. "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: James S. <jsi...@ac...> - 2000-03-11 02:13:04
|
> Seems like we missed the boat on 2.4.x... Linus just announced 2.3.51 being > the last 2.3 kernel and then he'll start with 2.4-pre and only accept > bugfixes. So i guess i'll have to split the 2.3 patch into two pieces: > - bugfixes for the VT emulator > - enhancements of the VT emulator I saw that too. Me depressed. I didn't finish my fbdev changes. Also Vojtech input suite didn't get in :( It looks like we have alot of work cut out for us. This means the ruby tree is going to be huge. The good news is that we have more time to work with the 2.4.X kernels. This way when 2.5.X hits we hit linus with lots of patches right away. The good news is with this project several people from several subsystems can work together to form a uniform and complete console system. As soon as pre-2.4.X comes out I will place the necessary trees from the source in CVS. Then we can play with it. We just have to keep it in sync with 2.4.X which will now be just bug fixes. "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: James S. <jsi...@ac...> - 2000-03-11 01:59:01
|
On Fri, 10 Mar 2000, Eric S. Raymond wrote: > James Simmons <jsi...@ac...>: > > We hope. I had a talk with Alan Cox about that. He doesn't care for the > > idea of terminal emulation modules :( > > What is his objection? Bloat. He doesn't even like the idea of posix termios in the kernel. He feels that userland should define any other type of console. "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 > -- > <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> > > "Taking my gun away because I might shoot someone is like cutting my tongue > out because I might yell `Fire!' in a crowded theater." > -- Peter Venetoklis > |
|
From: Dominik K. <dom...@un...> - 2000-03-11 01:20:45
|
On Fri, Mar 10, 2000 at 04:56:48PM -0500, Eric S. Raymond wrote: > This file describes the first console driver changes from the Linux Console > Project. It applies to both the "Sapphire" patch for 2.2.x and the "Emerald" > patch for 2.3.x. Seems like we missed the boat on 2.4.x... Linus just announced 2.3.51 being the last 2.3 kernel and then he'll start with 2.4-pre and only accept bugfixes. So i guess i'll have to split the 2.3 patch into two pieces: - bugfixes for the VT emulator - enhancements of the VT emulator Just had 2.3.50, with the 2.3.40 patch applied, compile without problems. Unfortunately my laptop locks up when i boot it (not console related: the cardbus controller is probably grabbing the kbd irq for the ethernet card). Time now to get some well-deserved sleep... 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-10 21:56:28
|
This file describes the first console driver changes from the Linux Console Project. It applies to both the "Sapphire" patch for 2.2.x and the "Emerald" patch for 2.3.x. The second patch band changes fix the double off-by-one error which manifests itself in the accordeon test from vttest. The third band is a patch from linux-kernel: it has to do with wrongly neglecting the intensity bit in certain operations. The other patch bands make the following changes to the terminal emulation: Code Action Changed in patch Reason ------ --------------- ------------------ ---------------------------- \E[6m blink added Support for ECMA-48 \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 : 0x84 IND added Supports VT220 8-bit mode 0x85 NEL added : 0x88 HTS added : 0x8d RI added : \E[?6n DECXCPR added More exact VT100 emulation \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[21m turn off 1 removed Conflicts with ECMA-48 \E[s DECRC removed Not in either VT100 or ECMA-48 \E[u DECSC removed : All three removed capabilities are redundant with other escape sequences supported by the driver (\E[22m, \E7, and \E8 respectively). None are or have ever been used by the Linux terminfo/termcap entry. Sizes: text data bss dec hex filename 23452 332 1028 24812 60ec console.o (2.2.12 old) 25036 332 1028 26396 671c console.o (2.2.12 new) -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Live free or die; death is not the worst of evils. -- General George Stark. |
|
From: Eric S. R. <es...@th...> - 2000-03-10 20:58:58
|
Dominik Kubla <dom...@un...>: > On Fri, Mar 10, 2000 at 02:50:41PM -0500, Eric S. Raymond wrote: > > > So what do these changes do? What problem are they fixing? > > The first two changes fix the double off-by-one error which manifests itself > in the accordeon test from vttest. > > The third one is a patch i picked up from linux-kernel and it has to do > with wrongly neglecting the intensity bit in certain operations IIRC. Good, I'll add these notes to the patch description I'm assembling. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc |
|
From: Dominik K. <dom...@un...> - 2000-03-10 20:51:31
|
On Fri, Mar 10, 2000 at 02:50:41PM -0500, Eric S. Raymond wrote: > So what do these changes do? What problem are they fixing? The first two changes fix the double off-by-one error which manifests itself in the accordeon test from vttest. The third one is a patch i picked up from linux-kernel and it has to do with wrongly neglecting the intensity bit in certain operations IIRC. 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...@sn...> - 2000-03-10 19:50:15
|
In the 2.3.40 patch, I see the following:
--- linux/drivers/char/console.c.orig Tue Dec 21 00:43:01 1999
+++ linux/drivers/char/console.c Wed Jan 26 21:21:14 2000
@@ -234,7 +234,7 @@
unsigned short *d, *s;
if (t+nr >= b)
- nr = b - t - 1;
+ nr = b - t;
if (b > video_num_lines || t >= b || nr < 1)
return;
if (IS_VISIBLE && sw->con_scroll(vc_cons[currcons].d, t, b, SM_UP, nr))
@@ -252,7 +252,7 @@
unsigned int step;
if (t+nr >= b)
- nr = b - t - 1;
+ nr = b - t;
if (b > video_num_lines || t >= b || nr < 1)
return;
if (IS_VISIBLE && sw->con_scroll(vc_cons[currcons].d, t, b, SM_DOWN, nr))
@@ -365,7 +365,7 @@
static void update_attr(int currcons)
{
attr = build_attr(currcons, color, intensity, blink, underline, reverse ^ decscnm);
- video_erase_char = (build_attr(currcons, color, 1, 0, 0, decscnm) << 8) | ' ';
+ video_erase_char = (build_attr(currcons, color, intensity, 0, 0, decscnm) << 8) | ' ';
}
/* Note: inverting the screen twice should revert to the original state */
It looks like a similar change is in the 2.2.1 patch, but I missed it
amidst the clutter caused by the code reformatting. The minimized
version I posted does *not* include this change.
So what do these changes do? What problem are they fixing?
--
<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"
|
1998 messages has been excluded from this view by a project administrator.
