Menu
▾
▴
linuxconsole-dev
|
From: Firstname L. <ms...@ho...> - 2000-03-09 21:52:15
|
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.
add to this section of web page:
3.Desirable features such as multi-head operation, scrollback, and support
for different fonts & textmodes
per VC have not yet been implemented.
actually, should it be per VC keymaps, or per application? *smile*
Corey
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
|
|
From: James S. <jsi...@ac...> - 2000-03-10 14:30:06
|
> 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 handle it per keyboard. Any suggestions on what level to handle keymaps!! Maybe both like fbdev handles video modes. Each VT has a private keymap. Where if you set the keymap by /dev/kbd it would set the keymap for all keyboards. What does everything think of this idea ? > add to this section of web page: > 3.Desirable features such as multi-head operation, scrollback, and support > for different fonts & textmodes per VC have not yet been implemented. I believe with fbcon you can have different fonts per VC. Same with textmodes. Well in theory fbcon can handle text modes. Its just no one has yet. What I like to see is VT_RESIZE fixed. Right now it sets all the VTs to a new mode. It should only set the mode for the current active VT. Fbdev should be used to set the mode for all consoles. This is done by opening /dev/fb and setting to new mode. It will have a flag to tell fbdev to preserve the mode after you call close on /dev/fb. This in effect will cause all VTs to change their mode. "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-10 15:00:29
|
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! > I believe with fbcon you can have different fonts per VC. Same with > textmodes. Well in theory fbcon can handle text modes. Its just no one You don't want true textmodes or you are (again) hobbled by the hardware: eg EGA/VGA allows either underline or color, not both! 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-13 08:35:52
|
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? Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
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: 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: 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-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 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: Steffen S. <s.s...@ph...> - 2000-03-13 08:33:17
|
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). 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. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
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: 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: 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: 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-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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X