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: Eric S. R. <es...@th...> - 2000-03-17 23:44:38
|
James A Simmons <jsi...@ac...>: > No problem. Thats why we are all working together. I posted the latency > patch I recieved. Petr pointed out things about it. Thanks Petr. I haven't > heard from Eric. Eric ready to break and build new things. I'm done for the moment. I posted Sapphire and Emerald to linux-kernel. Now to wait and see if they make it into the next kernel release. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> ...Virtually never are murderers the ordinary, law-abiding people against whom gun bans are aimed. Almost without exception, murderers are extreme aberrants with lifelong histories of crime, substance abuse, psychopathology, mental retardation and/or irrational violence against those around them, as well as other hazardous behavior, e.g., automobile and gun accidents." -- Don B. Kates, writing on statistical patterns in gun crime |
|
From: Firstname L. <ms...@ho...> - 2000-03-17 18:59:01
|
> > > Do you have access to a old monochrome display adapter (MDA)? In that > > case you might want to give KGI a try and test it yourself. > >No :( > Last time i checked the monichrome driver in kgicon failed to compile (cause it wasn't being maintained). I assume that KGI has a similar issue. give it a try. Corey ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com |
|
From: James A S. <jsi...@ac...> - 2000-03-17 15:50:43
|
> I have been busy lately(no not on "ruby"...) But i hope to do some > work over the weekend. If you can post the patch before 12:00 UTC > today, i'll be able to pick it up. Otherwise i'll be 70 km away from > the nearest access point until Monday morning... No problem. Thats why we are all working together. I posted the latency patch I recieved. Petr pointed out things about it. Thanks Petr. I haven't heard from Eric. Eric ready to break and build new things. Now that exams are out of the way for me and the wekeend is here its time to have fun. I test vttest on the standard kernel. Pretty cool. I'm going to test it tonight on our kernel work. Vojtech are you ready to port your code into our CVS? |
|
From: Petr V. <VAN...@vc...> - 2000-03-17 12:23:59
|
On 16 Mar 00 at 21:07, James Simmons wrote:
> From: Pavel Machek <pa...@su...>
> To: lin...@bu..., lin...@su..., mi...@ch...,
> jsi...@ac...
> PS: Would it be possible to declare that fbcon is re-entrant, but may
> mess the screen up in such case?
No. Accesses to accelerators cannot be interrupted. But it is possible
to place down_trylock around them...
> + * Bigger buffer means better console writing performance, but worse
> + * latency of console switches.
> -char con_buf[PAGE_SIZE];
> -#define CON_BUF_SIZE PAGE_SIZE
> +#define CON_BUF_SIZE (PAGE_SIZE/10)
> +char con_buf[CON_BUF_SIZE];
Is not 400 too small? It is ~3 lines...
> +static int softint_missed = 0;
> -static void console_softint(unsigned long ignored)
> +static void console_softint(unsigned long ignored)
> +{
> + run_task_queue(&con_task_queue);
> + softint_missed = 1;
> + if (down_trylock(&console_sem)) {
> + printk( "console_softint request dropped\n" );
Is it really good idea to do printk() when console_sem is held?
> - spin_unlock_irq(&console_lock);
> ret = copy_to_user(buf, con_buf_start, orig_count);
You do not have to have locked console here... You need only
exclusive access to console copy buffer, but not to console
code itself. All code should check for console changes as copy_to_user
can sleep (and vc_screen copy to/from vcs does this checks).
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Dominik K. <dom...@un...> - 2000-03-17 06:51:56
|
On Thu, Mar 16, 2000 at 09:05:57PM -0500, James Simmons wrote: > > Hi everyone!! > > I just started adding stuff to ruby. I ported emerald code over to ruby > and made sure it was in sync with 2.3.99-pre1. Dominik I know you are > working on ruby already. Could you sync your stuff with whats in CVS. I > recieved a patch that fixes some latency problems with the console > system. I will post soon. We can look it over and add it to CVS. I have been busy lately(no not on "ruby"...) But i hope to do some work over the weekend. If you can post the patch before 12:00 UTC today, i'll be able to pick it up. Otherwise i'll be 70 km away from the nearest access point until Monday morning... 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-17 02:01:32
|
Here is the patch I was telling you about. "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 ---------- Forwarded message ---------- Date: Wed, 15 Mar 2000 23:42:56 +0100 From: Pavel Machek <pa...@su...> To: lin...@bu..., lin...@su..., mi...@ch..., jsi...@ac... Subject: Low latency for fbcon Hi! USB audio was unusable on my computers: both use fbcon and usb is _very_ sensitive to interrupt latencies. Fbcon happily disables interrupts for half a second. I hopefully fixed that. It brings slight problems with printk's (they tend to do even more garbage on screen than they used to if there's concurent output), but at least I can listen to mp3's on my usb audio. Try it. Take a look at down_trylock -- I hope I did not put the logic backward. Pavel PS: Would it be possible to declare that fbcon is re-entrant, but may mess the screen up in such case? --- clean//drivers/char/console.c Wed Mar 15 14:06:50 2000 +++ linux/drivers/char/console.c Wed Mar 15 23:34:49 2000 @@ -1786,18 +1786,17 @@ } } -/* This is a temporary buffer used to prepare a tty console write - * so that we can easily avoid touching user space while holding the - * console spinlock. It is allocated in con_init and is shared by - * this code and the vc_screen read/write tty calls. +/* This is a temporary buffer used to prepare a tty console write so + * that we can easily avoid touching user space while holding the + * console spinlock. It is shared by this code and the vc_screen + * read/write tty calls. * - * We have to allocate this statically in the kernel data section - * since console_init (and thus con_init) are called before any - * kernel memory allocation is available. + * Bigger buffer means better console writing performance, but worse + * latency of console switches. */ -char con_buf[PAGE_SIZE]; -#define CON_BUF_SIZE PAGE_SIZE -DECLARE_MUTEX(con_buf_sem); +#define CON_BUF_SIZE (PAGE_SIZE/10) +char con_buf[CON_BUF_SIZE]; +DECLARE_MUTEX(console_sem); static int do_con_write(struct tty_struct * tty, int from_user, const unsigned char *buf, int count) @@ -1834,7 +1833,7 @@ orig_count = count; if (from_user) { - down(&con_buf_sem); + down(&console_sem); again: if (count > CON_BUF_SIZE) @@ -1845,17 +1844,17 @@ } buf = con_buf; - } + } else + if (down_trylock(&console_sem)) /* Lock failed */ + return -EINVAL; /* At this point 'buf' is guarenteed to be a kernel buffer * and therefore no access to userspace (and therefore sleeping) - * will be needed. The con_buf_sem serializes all tty based + * will be needed. The console_sem serializes all tty based * console rendering and vcs write/read operations. We hold * the console spinlock during the entire write. */ - spin_lock_irq(&console_lock); - himask = hi_font_mask; charmask = himask ? 0x1ff : 0xff; @@ -1972,7 +1971,6 @@ do_con_trol(tty, currcons, c); } FLUSH - spin_unlock_irq(&console_lock); out: if (from_user) { @@ -1988,32 +1986,21 @@ goto again; } - up(&con_buf_sem); } + up_console_sem(); return n; #undef FLUSH } -/* - * This is the console switching tasklet. - * - * Doing console switching in a tasklet allows - * us to do the switches asynchronously (needed when we want - * to switch due to a keyboard interrupt). Synchronization - * with other console code and prevention of re-entrancy is - * ensured with console_lock. +static int softint_missed = 0; + +/* + * Must be called with console_sem hold. */ -static void console_softint(unsigned long ignored) +static void do_console_softint(void) { - /* Runs the task queue outside of the console lock. These - * callbacks can come back into the console code and thus - * will perform their own locking. - */ - run_task_queue(&con_task_queue); - - spin_lock_irq(&console_lock); - + softint_missed = 0; if (want_console >= 0) { if (want_console != fg_console && vc_cons_allocated(want_console)) { hide_cursor(fg_console); @@ -2035,8 +2022,38 @@ sw->con_scrolldelta(vc_cons[currcons].d, scrollback_delta); scrollback_delta = 0; } +} - spin_unlock_irq(&console_lock); +void up_console_sem(void) +{ + if (softint_missed) + do_console_softint(); + up(&console_sem); +} + +/* + * This is the console switching tasklet. + * + * Doing console switching in a tasklet allows + * us to do the switches asynchronously (needed when we want + * to switch due to a keyboard interrupt). Synchronization + * with other console code and prevention of re-entrancy is + * ensured with console_lock. + */ +static void console_softint(unsigned long ignored) +{ + /* Runs the task queue outside of the console lock. These + * callbacks can come back into the console code and thus + * will perform their own locking. + */ + run_task_queue(&con_task_queue); + + softint_missed = 1; + if (down_trylock(&console_sem)) { + printk( "console_softint request dropped\n" ); + return; + } + up_console_sem(); } #ifdef CONFIG_VT_CONSOLE @@ -2827,9 +2844,9 @@ op->data = temp; } - spin_lock_irq(&console_lock); + down(&console_sem); rc = sw->con_font_op(vc_cons[currcons].d, op); - spin_unlock_irq(&console_lock); + up_console_sem(); op->data = old_op.data; if (!rc && !set) { --- clean//drivers/char/vt.c Fri Mar 3 22:52:01 2000 +++ linux/drivers/char/vt.c Wed Mar 15 23:18:04 2000 @@ -807,9 +807,9 @@ * make sure we are atomic with respect to * other console switches.. */ - spin_lock_irq(&console_lock); + down(&console_sem); complete_change_console(newvt); - spin_unlock_irq(&console_lock); + up_console_sem(); } } --- clean//drivers/char/vc_screen.c Fri Mar 3 22:52:01 2000 +++ linux/drivers/char/vc_screen.c Wed Mar 15 23:18:22 2000 @@ -91,7 +91,6 @@ */ extern char con_buf[PAGE_SIZE]; #define CON_BUF_SIZE PAGE_SIZE -extern struct semaphore con_buf_sem; static ssize_t vcs_read(struct file *file, char *buf, size_t count, loff_t *ppos) @@ -104,12 +103,11 @@ unsigned short *org = NULL; ssize_t ret; - down(&con_buf_sem); + down(&console_sem); /* Select the proper current console and verify * sanity of the situation under the console lock. */ - spin_lock_irq(&console_lock); attr = (currcons & 128); currcons = (currcons & 127); @@ -236,9 +234,7 @@ * all the data to userspace from our temporary buffer. */ - spin_unlock_irq(&console_lock); ret = copy_to_user(buf, con_buf_start, orig_count); - spin_lock_irq(&console_lock); if (ret) { read += (orig_count - ret); @@ -254,8 +250,7 @@ if (read) ret = read; unlock_out: - spin_unlock_irq(&console_lock); - up(&con_buf_sem); + up_console_sem(); return ret; } @@ -271,12 +266,11 @@ u16 *org0 = NULL, *org = NULL; size_t ret; - down(&con_buf_sem); + down(&console_sem); /* Select the proper current console and verify * sanity of the situation under the console lock. */ - spin_lock_irq(&console_lock); attr = (currcons & 128); currcons = (currcons & 127); @@ -310,9 +304,7 @@ /* Temporarily drop the console lock so that we can read * in the write data from userspace safely. */ - spin_unlock_irq(&console_lock); ret = copy_from_user(con_buf, buf, this_round); - spin_lock_irq(&console_lock); if (ret) { this_round -= ret; @@ -436,9 +428,8 @@ ret = written; unlock_out: - spin_unlock_irq(&console_lock); - up(&con_buf_sem); + up_console_sem(); return ret; } --- clean//include/linux/console.h Sat Feb 19 19:52:22 2000 +++ linux/include/linux/console.h Wed Mar 15 22:04:17 2000 @@ -91,7 +91,8 @@ #define CON_CONSDEV (2) /* Last on the command line */ #define CON_ENABLED (4) -extern spinlock_t console_lock; +//extern spinlock_t console_lock; +extern struct semaphore console_sem; struct console { -- I'm pa...@uc.... "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents me at di...@li... |
|
From: James S. <jsi...@ac...> - 2000-03-17 02:00:22
|
Hi everyone!! I just started adding stuff to ruby. I ported emerald code over to ruby and made sure it was in sync with 2.3.99-pre1. Dominik I know you are working on ruby already. Could you sync your stuff with whats in CVS. I recieved a patch that fixes some latency problems with the console system. I will post soon. We can look it over and add it to CVS. "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-17 01:53:30
|
> There already is a patch to make Voitech's input drivers work with KGI, > though I had no time to test it myself or with the lates versions by > Voitech. > Maybe Voitech himself could also have a look at what I have done. We all have to work together to get things done. > No. I see a tty (special file) as the application interface (mapper) > to a virtual terminal. And a virtual terminal from my point of view is > exactly one input device (kii_device_t) and exactly one output > device (kgi_device_t). These are keyboard and display _abstractions_ > that need not be visible on a display to have the application be > able to use it. Okay. So you can use /dev/tty even when no keyboard or display is attacted. The current method is dummy_con when no display is avaliable and in Vojtech work he has a dummy_keyboard when no keyboard is present. Which is mapped by take_over_console for displays and I don't know for input devices. I have to look. Dummy con is what I use on a explict open of /dev/fb so fbcon isn't used. This prevents fbcon using accels at the same time as /dev/fb. > This draws a clear boundary between the > mappers (terminal emulator, graphical console) and the drivers, > enforcing modularity. The natural flow appears to be heading in this way. > The KGI terminal emulator API makes it > difficult enough to mess with the display hardware except through > the display driver so that noone will try to use this approach. > Why I think doing so is not a good approach? Because it hardcodes > mapper details into drivers. This is a BIG no-no for KGI. I agree. Thats the way it should be. > The only point -- which I am also not > that happy with -- is the behaviour of mmap() on the /dev/graphic > special > file, which is modified such that resources aquired by one process > are not inherited by child processes or threads. This is a point Linus > himself stated to be 'an approach that might make sense in that and some > other contexts'. I just spoke about this on the kernel mailing list. > It could be made the standard behaviour if drivers had > a chance to influence the result of a fork. Currently in Linux > they haven't for whatever reason, so we have to live with that. For now. I know when I finish linux GFX so SGI Infinte Reality engine can be ported over this problem will be fixed. > > > A "workplace" may consist of several heads. > > > > Thast teh whole machine. You can have a bunch of heads per machine > > normally. > > No, it is _not_ the whole machine. It's the heads _one_ user has access > to. > This has implications on other resources, such as sound devices, local > peripherals, user-accessible interfaces (serial, parallel, ...). > Managing those via /etc/security/console.perms is a nice approach, but > will require distinction of workplaces. Okay. > Do you have access to a old monochrome display adapter (MDA)? In that > case you might want to give KGI a try and test it yourself. No :( "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: Steffen S. <s.s...@ph...> - 2000-03-16 09:15:01
|
James Simmons wrote: > > In KGI terminology "focus" refers to a collection of physical input > > device > > drivers or event sources. E.g mice, graphic tablets, user specific > > applications, etc. All events generated by these event sources will > > be reported to the same event sink (input device). Currently this may > > be the input device of a terminal emulator. Later a /dev/event mapper > > will be added. > > Okay. the Y input devices of a head is a focus. Vojtech has /dev/event > and a input device and it's being used for USB devices. Now that Vojtech > work will be head into CVS very soon you can take a look at what he has > done and we can combine whatever both of you have developed. There already is a patch to make Voitech's input drivers work with KGI, though I had no time to test it myself or with the lates versions by Voitech. Maybe Voitech himself could also have a look at what I have done. > I hope you still see a tty as just one keyboard and one display. No. I see a tty (special file) as the application interface (mapper) to a virtual terminal. And a virtual terminal from my point of view is exactly one input device (kii_device_t) and exactly one output device (kgi_device_t). These are keyboard and display _abstractions_ that need not be visible on a display to have the application be able to use it. This draws a clear boundary between the mappers (terminal emulator, graphical console) and the drivers, enforcing modularity. The KGI terminal emulator API makes it difficult enough to mess with the display hardware except through the display driver so that noone will try to use this approach. Why I think doing so is not a good approach? Because it hardcodes mapper details into drivers. This is a BIG no-no for KGI. > Linus doesn't care for people breaking the rules. Neither do I. The current KGI implementation tries hard not to break any UNIX concepts to achive it's goal. At least I am not aware of any cases and would be more than grateful for anyone who spotted this to be the case to tell me so I can fix it. The only point -- which I am also not that happy with -- is the behaviour of mmap() on the /dev/graphic special file, which is modified such that resources aquired by one process are not inherited by child processes or threads. This is a point Linus himself stated to be 'an approach that might make sense in that and some other contexts'. It could be made the standard behaviour if drivers had a chance to influence the result of a fork. Currently in Linux they haven't for whatever reason, so we have to live with that. > > A "head" (or workplace as I prefer) in KGI terminology refers to a focus > > and all output devices --simply speaking-- this focus may be focused on. > > Okay. X input devices and Y output devices. > > > A "workplace" may consist of several heads. > > Thast teh whole machine. You can have a bunch of heads per machine > normally. No, it is _not_ the whole machine. It's the heads _one_ user has access to. This has implications on other resources, such as sound devices, local peripherals, user-accessible interfaces (serial, parallel, ...). Managing those via /etc/security/console.perms is a nice approach, but will require distinction of workplaces. > > Why have I split this? Because this avoids unneccessary constraints > > on what virtual terminal is displayed on what display and each > > KGI-head may appear to be a multidisplay workplace. > > So /dev/vc/X appears to userland as one big VT pool even if internally > where have a bunch of VT pools to each console. We just have to make sure > you can't VT switch from one head to another head. If the heads are in two > different offices then if we VT switch to another VT that's in another > office I really don't feel like getting up and going to another office to > use another VT. For KGI this simply puts constraints on the internal mapping tables, which determine which input or output device gets mapped to which focus or display. Currently this table is static and handcoded, simply because this sufficed to test KGIs multihead capabilities and there are more important things to code right now; this being not a major issue. Do you have access to a old monochrome display adapter (MDA)? In that case you might want to give KGI a try and test it yourself. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
From: James S. <jsi...@ac...> - 2000-03-16 03:17:06
|
> > I have though about that but have no answer. In a multihead system where > > should printk go to. Any suggestion anyone ? > > KGI currently takes the <int console_printk_console> to send kernel > messages > to. There can be functions implemented to alter this variable, > so that e.g. that VT-switches on the 'system console focus' make > kernel messages appear on the currently active one. > However, this is a policy decision. It should be displayed on every active console. I haven't thought about the details yet. I like to get multihead woking first. "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-16 03:13:25
|
Since 2.3.99 is out our we going to post your patch and very soon pass it off to linus. "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-16 03:12:13
|
> In KGI terminology "focus" refers to a collection of physical input > device > drivers or event sources. E.g mice, graphic tablets, user specific > applications, etc. All events generated by these event sources will > be reported to the same event sink (input device). Currently this may > be the input device of a terminal emulator. Later a /dev/event mapper > will be added. Okay. the Y input devices of a head is a focus. Vojtech has /dev/event and a input device and it's being used for USB devices. Now that Vojtech work will be head into CVS very soon you can take a look at what he has done and we can combine whatever both of you have developed. I hope you still see a tty as just one keyboard and one display. Linus doesn't care for people breaking the rules. I think he will not mind the flexable api of where we can build a head from userland. > A "head" (or workplace as I prefer) in KGI terminology refers to a focus > and all output devices --simply speaking-- this focus may be focused on. Okay. X input devices and Y output devices. > A "workplace" may consist of several heads. Thast teh whole machine. You can have a bunch of heads per machine normally. > Why have I split this? Because this avoids unneccessary constraints > on what virtual terminal is displayed on what display and each > KGI-head may appear to be a multidisplay workplace. So /dev/vc/X appears to userland as one big VT pool even if internally where have a bunch of VT pools to each console. We just have to make sure you can't VT switch from one head to another head. If the heads are in two different offices then if we VT switch to another VT that's in another office I really don't feel like getting up and going to another office to use another VT. "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: Dominik K. <dom...@un...> - 2000-03-15 20:30:07
|
On Wed, Mar 15, 2000 at 09:58:25AM -0500, Eric S. Raymond wrote: > Hi, > is it possible to place #ifndef CONFIG_CONSOLE_LEGACY around > this region. I already have it in my tree for 0x9B. Reason is > that there are some computers here which do not think that ISO-8859-x > is right thing and use other encodings due to old code. For our > case it is library database system originally written in 1988-1990 for > SCO. And this system uses CP895 encoding, which has couple of > important characters (exactly 32) in range 0x80 - 0x9F. That's not a problem: 8bit-controls should only be used after a S8C1T sequence has been issued, unless the terminal setup has enabled 8bit C1 controls as default. See my comment in the sources. > Alternate solution is to add some escape sequence to disable > these control characters. Then I can add this sequence to init > terminfo/termcap entry... I think we need to implement some IOCTL's and a userland (curses-based) replacement for the setup of a VT terminal. Any volunteers? BTW: setterm is problematic because it misuses control functions allocated by the standards (both ISO and DEC) for entirely different purposes! 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-15 14:58:48
|
Note for Ruby. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> It is the assumption of this book that a work of art is a gift, not a commodity. Or, to state the modern case with more precision, that works of art exist simultaneously in two "economies," a market economy and a gift economy. Only one of these is essential, however: a work of art can survive without the market, but where there is no gift there is no art. -- Lewis Hyde, The Gift: Imagination and the Erotic Life of Property |
|
From: Steffen S. <s.s...@ph...> - 2000-03-15 13:36:21
|
Dominik Kubla wrote: > On Wed, Mar 15, 2000 at 01:13:55PM +0100, Steffen Seeger wrote: > > > So far KGI contains a dumb console terminal emulator (no ESC sequences > > are parsed) and a fairly clean and complete xterm/vt100 emulation with > > optional linux-console extensions. Others can easily be added. > > Ah: Could you give me a pointer here? I am currently modularizing the > terminal emulation for inclusion in "ruby"... As I already wrote in my posting from 03/08/2000 08:51:54, "Re: comments on multi-heading/console": > PS: some `low-level introductionary style`articles that > explain how KGI handles the human-machine interaction > issues may be found at > > http://www.tu-chemnitz.de/~sse/ggi > > People on this list may or may not want to read and comment on it. > > PPS: The sample implementation code referred in these articles > may be found there as well. Browseable or downloadable at > your choice. It is fairly useable in terms of a console > replacement and I had a simple true multihead system going > with two keyboards and two monitors, each running > independent sessions, with multiple virtual terminals, etc. Most features requested on this list so far are already implemented in one or the other way in KGI. I am sorry detailed documentation is not yet available, I am working on it and it will be included in the next snapshot. Your comments are welcome. (Please direct KGI specific discussion to the KGI mailing list at gg...@kl... or me personally). Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
From: Dominik K. <dom...@un...> - 2000-03-15 12:42:55
|
On Wed, Mar 15, 2000 at 01:13:55PM +0100, Steffen Seeger wrote: > So far KGI contains a dumb console terminal emulator (no ESC sequences > are parsed) and a fairly clean and complete xterm/vt100 emulation with > optional linux-console extensions. Others can easily be added. Ah: Could you give me a pointer here? I am currently modularizing the terminal emulation for inclusion in "ruby"... 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: Steffen S. <s.s...@ph...> - 2000-03-15 12:35:51
|
James A Simmons wrote: > > On Mon, 13 Mar 2000, Steffen Seeger wrote: > > > James Simmons wrote: > > > > > > > Another desirable feature to add to the web page is per VC keymaps. i > > > > remember chaning my keymap for dosemu, and screwing over some of my other > > > > apps on other VC's because of it. > > > > > > I though about that. The question is should this be per keyboard or per > > > VC. > > > > It could be per keyboard, or per input group (focus). > > I assume a focus is a head. In KGI terminology "focus" refers to a collection of physical input device drivers or event sources. E.g mice, graphic tablets, user specific applications, etc. All events generated by these event sources will be reported to the same event sink (input device). Currently this may be the input device of a terminal emulator. Later a /dev/event mapper will be added. A "head" (or workplace as I prefer) in KGI terminology refers to a focus and all output devices --simply speaking-- this focus may be focused on. A "workplace" may consist of several heads. Why have I split this? Because this avoids unneccessary constraints on what virtual terminal is displayed on what display and each KGI-head may appear to be a multidisplay workplace. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
From: Steffen S. <s.s...@ph...> - 2000-03-15 12:19:12
|
Dominik Kubla wrote: > On Tue, Mar 14, 2000 at 12:08:35PM -0500, James A Simmons wrote: > > > > These are like user-defined function keys? E.g. fixed set of > > > keys but you can define the characters they send on press/release? > > > Could you give some more details on that? > > UDK's are just like the function strings you can right now assign with > loadkeys. Just that you don't need to run loadkeys, the application can > define actions if the UDK area isn't locked (something you can do either > with a control function or using terminal setup). Later terminals had > more functionality IIRC. Ok, so the terminal emulator is responsible for caring about this. KGI passes plain UNICODE keycodes (with some vendor specific extensions) to the terminal emulators, which then do the function key -> string mapping. As terminal emulators (in KGI) are instantiated per-virtual this issue (which actually is emulator specific) can be addressed inside the terminal emulators. However, currently KGI assumes function keys are focus-local, but this can be made device (virtual terminal) local with a few straightforward changes in two functions in the KII implementation. So far KGI contains a dumb console terminal emulator (no ESC sequences are parsed) and a fairly clean and complete xterm/vt100 emulation with optional linux-console extensions. Others can easily be added. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
From: Dominik K. <dom...@un...> - 2000-03-14 17:20:17
|
On Tue, Mar 14, 2000 at 12:08:35PM -0500, James A Simmons wrote: > > These are like user-defined function keys? E.g. fixed set of > > keys but you can define the characters they send on press/release? > > Could you give some more details on that? UDK's are just like the function strings you can right now assign with loadkeys. Just that you don't need to run loadkeys, the application can define actions if the UDK area isn't locked (something you can do either with a control function or using terminal setup). Later terminals had more functionality IIRC. > Is this info at http://vt100.net ? Not sure, since UDK's and loadable fonts were introduces in vt220. Look at the pcvt docs from the *BSD sources. (they are in arch/i386/isa/pcvt/ in an unpacked *BSD source tree, some ftp servers like ftp.fu-berlin.de provide unpacked source trees) 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 A S. <jsi...@ac...> - 2000-03-14 17:13:24
|
On Mon, 13 Mar 2000, Steffen Seeger wrote: > Dominik Kubla wrote: > > > > On Fri, Mar 10, 2000 at 09:35:35AM -0500, James Simmons wrote: > > > > > > > Another desirable feature to add to the web page is per VC keymaps. i > > > > remember chaning my keymap for dosemu, and screwing over some of my other > > > > apps on other VC's because of it. > > > > > > I though about that. The question is should this be per keyboard or per > > > VC. I really need to look at the solaris driver for /dev/kbd. I think they > > > > Per VC definitely! We need per VC keymaps and charsets (Yuk!) for true > > DEC VT compatibility if we ever want to go higher than vt102. From vt220 > > on there are "user-defined keys" and "downloadable charsets". You wouldn't > > want an application on tty1 to redefine the keymap and charset for ttyX. > > There are even security implications here! > > These are like user-defined function keys? E.g. fixed set of > keys but you can define the characters they send on press/release? > Could you give some more details on that? Is this info at http://vt100.net ? |
|
From: James A S. <jsi...@ac...> - 2000-03-14 17:10:12
|
On Mon, 13 Mar 2000, Steffen Seeger wrote: > James Simmons wrote: > > > > > Another desirable feature to add to the web page is per VC keymaps. i > > > remember chaning my keymap for dosemu, and screwing over some of my other > > > apps on other VC's because of it. > > > > I though about that. The question is should this be per keyboard or per > > VC. > > It could be per keyboard, or per input group (focus). I assume a focus is a head. > KGI handles key translations per focus, so that several devices > (keyboard, numpad) _can_ have the same translations. > Of course there _may_ be device dependent translations too. > This gives a per-focus consistent keymap. More details in the > KGI documentation to come. ????? "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
|
From: James A S. <jsi...@ac...> - 2000-03-14 16:35:21
|
On Tue, 14 Mar 2000, Pauli Ojanpera wrote: > _I'm sorry if this is not relevant_. > > As there's no differences between ps2 mouse and keyboard ports > I think you should keep in mind the possibility that there > may some day be several inputs for the multihead console. > I.e. two user workstations. Thats what we have in mind:) In the input suite by Vojtech you can plug a ps/2 keybaord int the mouse and keyboard ports. JUst note one thing. Some BIOS get confussed at boot time if you have a PS/2 keyboard plugged into a PS/2 mouse port. So you have to sometimes plug the keyboard into the mouse port after booting. With USB keyboards this is really needed. "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
|
From: James A S. <jsi...@ac...> - 2000-03-14 16:32:36
|
On 14 Mar 2000, Kirk Reiser wrote:
> Well, I cannot seem to get the stuff out of the bloody archive. The
> cvs summary page says the module is linuxconsole but cvs tells me
> there is no such module. Seems to me there should be more than one
> module any with three different versions. Clews? Clews? Does anyone
> have any clews?
There are three different modules. Saphhire, emerald, ruby.
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linuxconsole
co sapphire
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linuxconsole
co emerald
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linuxconsole
co ruby
Sapphire is for 2.2.X
Emerald is against 2.3.X
Ruby is new system thats for 2.5.X
"Look its a text editor, no its a OS, no its Emacs"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
|
|
From: James A S. <jsi...@ac...> - 2000-03-14 16:29:26
|
On Tue, 14 Mar 2000, Eric S. Raymond wrote: > Brad Douglas <Br...@NE...>: > > I've been testing the Emerald patch on my PPC all night. I haven't done any > > specific testing for the console, but everything seems in order. I know a > > few of us are busy trying to crank out the fbdev patches for 2.4.x... It's > > probably why the list kinda died. > > It's up to James to decide when to ship Sapphire and Emerald. But I'm trying > to nudge people into testing so we can do it soon. I've given Sapphire > a pretty good workout, so far. Send it out. Sorry fbdev and a exam have been keeping busy. "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
|
From: James A S. <jsi...@ac...> - 2000-03-14 16:27:18
|
On Tue, 14 Mar 2000, Dominik Kubla wrote: > On Mon, Mar 13, 2000 at 05:34:10PM -0500, Eric S. Raymond wrote: > > Hello? Hello? Is anyone alive out there? > > > > Is anybody testing the Sapphire and Emerald release candidates? > > We don't have much time left if we want to get the bugfix version > > into 4.0. > > Well, i am already working on "Ruby", since 2.3.51 will not work > on any of my systems for various reasons... Hopefully 2.3.52 > will bring at least enable my laptop to test the stuff, i am just > now compiling 2.3.52-2 to see if there are any improvements. Really :) I see you haven't put it in CVS yet. "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
1998 messages has been excluded from this view by a project administrator.
