Re: improved console interface (was: Re: some console code checked in

On Thu, Apr 25, 2002 at 12:16:02PM +0100, Gaute B Strokkenes wrote: > Just barely. The set of supported charsets is not. For instance, > Solaris iconv does not recognise "ISO-8859-1", and > iconv_open("UTF-8", "UTF-8") will fail. > > Adding support for a system-internal encoding seems like a pr

Re: improved console interface (was: Re: some console code checked in

On Tue, Apr 23, 2002 at 05:27:57AM -0400, Gaute B Strokkenes wrote: > Yes. It is up to you to eventually decide whether it is easier to > keep the extra information together with or separate from the > character number. I'm just pointing out that it is possible. I > suppose it might be easiest

Re: improved console interface (was: Re: some console code checked in

On Tue, Apr 23, 2002 at 02:18:33AM +0200, Marcus Brinkmann wrote: > There are probably more points that I forgot now, Yeah, I have two more. When having character data and attribute data not interleaved, you have an ugly race condition that can lead to an update of the attributes but not the tex

Re: improved console interface (was: Re: some console code checked in

On Tue, Apr 23, 2002 at 01:50:50PM +0200, Wolfgang Jährling wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > > 2. Scroll back buffer. It seems to me best to have the scroll back buffer > > maintained in the generic component, so it is retained across detach/attach > > and can be shared by m

Re: improved console interface (was: Re: some console code checked in

Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > 2. Scroll back buffer. It seems to me best to have the scroll back buffer > maintained in the generic component, so it is retained across detach/attach > and can be shared by many display drivers. This requires that it is part of > the mmap'able file

Re: improved console interface (was: Re: some console code checked in

On Tue, Apr 23, 2002 at 05:27:57AM -0400, Gaute B Strokkenes wrote: > Absolutely. See, for instance, > . You will have to wade through > a lot of poorly worded standardese in order to convince yourself of > that, though. Well, I have no problems with doing

Re: improved console interface (was: Re: some console code checked in

On Mon, Apr 22, 2002 at 11:13:47PM -0400, Gaute B Strokkenes wrote: > Any Unicode character will fit in 21 bits, so you have plenty of bits > left over for attirbutes of various sorts. Furthermore, the Unicode > standard guarantees that this will alwasy be so. Is this also true for UCS-4? Becau

Re: improved console interface (was: Re: some console code checked in

On Tue, Apr 23, 2002 at 02:18:33AM +0200, Marcus Brinkmann wrote: > There are probably more points that I forgot now, Oh, yeah, the exact data format of the mmap'able area. We need to store the character value and the attributes (bold, color etc). We can settle on some common attributes, and lea

Re: improved console interface (was: Re: some console code checked in

On Tue, Apr 23, 2002 at 02:18:33AM +0200, Marcus Brinkmann wrote: > When seperating separate, dammit. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www

improved console interface (was: Re: some console code checked in

On Tue, Mar 19, 2002 at 09:06:33PM -0500, Roland McGrath wrote: > First are some feature concerns, with a garnish of efficiency concerns that > are no doubt in fact negligible. There are several things you get from > having the virtual terminal (the screen matrix) maintained in a common > layer i

Re: some console code checked in

On Tue, Mar 19, 2002 at 09:06:33PM -0500, Roland McGrath wrote: > Our chief concern to begin with is clean code reuse and consistency of the > terminal emulation for standard display devices. Turning the interface > inside out doesn't lose that. Yeah, sure. I think it is important I get the key

Re: some console code checked in

Our chief concern to begin with is clean code reuse and consistency of the terminal emulation for standard display devices. Turning the interface inside out doesn't lose that. But I am still on the fence about what the proper structure really is. First are some feature concerns, with a garnish

Re: some console code checked in

> Yes, this is a serious problem. It is also not easy to solve this in the > kernel. What you can get easily is a beep that blocks the system, but I am > not sure how hard it is to get a non-blocking beep at the kernel level > (seems to require some interrupt stuff to switch it off at the right t

Re: some console code checked in

On Tue, Mar 19, 2002 at 12:00:37AM +0100, Marcus Brinkmann wrote: > On Mon, Mar 18, 2002 at 04:51:37PM +0100, Jeroen Dekkers wrote: > > What's wrong with a high priority thread doing the beep which blocks for a > > specific amount of time during the beep? > > Although it will work better than a n

Re: some console code checked in

Marcus Brinkmann <[EMAIL PROTECTED]> writes: > Do I add or remove confusion if I say that the console server should support > both models? The generic part of the console server would then always pass > through without interpretation, the device specific part can either pass it > on further to t

Re: some console code checked in

On Mon, Mar 18, 2002 at 03:12:54AM -0500, Roland McGrath wrote: > I checked in some build nit fixes, and started a ChangeLog file. It seems the change to mutations.h got lost in the shuffle. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann

Re: some console code checked in

On Mon, Mar 18, 2002 at 04:51:37PM +0100, Jeroen Dekkers wrote: > What's wrong with a high priority thread doing the beep which blocks for a > specific amount of time during the beep? Although it will work better than a normal priority thread it is not fundamentally different. Marcus -- `Rhuba

Re: some console code checked in

On Mon, Mar 18, 2002 at 05:35:42PM +0100, Niels Möller wrote: > For the traditional serial console device, what happens is that the > application uses terminfo escape sequences, the the terminal (i.e. the > hardware box at the other end of the serial cable) interprets them. > Here, the console and

Re: some console code checked in

Marcus Brinkmann <[EMAIL PROTECTED]> writes: > This scheme already exists, but at the application level. It is > called terminfo(5) and works very well. I think it would be a > mistake to reimplement it, just poorer. For the traditional serial console device, what happens is that the application

Re: some console code checked in

On Mon, Mar 18, 2002 at 01:29:35PM +0100, Marcus Brinkmann wrote: > On Mon, Mar 18, 2002 at 03:12:54AM -0500, Roland McGrath wrote: > > I don't think anything else uses those particular io ports (0x61 turns the > > speaker on, 0x48 controls the timer that drives the tone frequency), so > > console

Re: some console code checked in

On Mon, Mar 18, 2002 at 03:36:03PM +0100, Niels Möller wrote: > I have no idea how "scroll-region" escape codes should be implemented > on a text-to-speech terminal (my best guess is "not at all"), Of course it would not be supported. > If every device has some pointers for the basic operations,

Re: some console code checked in

On Mon, Mar 18, 2002 at 01:29:35PM +0100, Marcus Brinkmann wrote: > seperate separate! Thanks Thomas ;) -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marc

Re: some console code checked in

On Mon, Mar 18, 2002 at 03:12:54AM -0500, Roland McGrath wrote: > I checked in some build nit fixes, and started a ChangeLog file. Thanks. > I think all the terminal emulation stuff belongs in the common layer and > not in the vga code. All that stuff would be the same for a different sort > of

Re: some console code checked in

I checked in some build nit fixes, and started a ChangeLog file. Just some quick first thoughts, not having read all the code. I think all the terminal emulation stuff belongs in the common layer and not in the vga code. All that stuff would be the same for a different sort of output device. Ea

some console code checked in

Hi, as Roland asked me for it, I have checked in the console code as far as I have come. I welcome comments to the code, but please note the following: Everything in input.h, focus.h and focus.c is completely undeveloped. It is only there to make the rest compile. input.h shows some ideas for